On Sun, 16 Mar 2003 10:35:17 -0800 (PST) Meph Istopheles <meph@xxxxxxxxxxxxxxxxxxx> wrote: > > All this was nothing -- after hitting send, I realised that I'd > hosed ~all~ my networking capability. I figured out where my > mistake was, but not ~what~ the correct entries should be. In > the end, I just removed all the settings I'd made & got back to > just being able to ping either way, inside & outside, as well as > ftp between the 'puters, but I can't get the W98 beyond the Linux > box. > Are you still running routed? I'm beginning to believe that there's no routing between networks without it. At least I haven't managed to do that with kernel routing alone. routed is what you'll need to ping your public network from the private network. As for accessing the internet from the private network alone, you don't need routing. Masquerade will do. Try adding this rule to your firewall and see if the private 'net can ping the internet (don't forget to configure the machines in the private net with 10.0.0.2 as default gateway): ipchains -I forward -s 10.0.0.0/255.0.0.0 -d 0.0.0.0/0.0.0.0 -j MASQ Note that I have taken the 10/8 (as currently configured) as the source (-s) 'net for masqing, if you change the config of eth0:1, change -s accordingly. > > > Your kernel routing table does look a bit funny... Could you > > please repost the output of route with the -n argument, and the > > ifconfig output for eth's as well? Would be a bit easier to > > read ;-) > > Sure: > > /sbin/route -n > Kernel IP routing table > Destination Gateway Genmask Flags Metric Ref Use > Iface 10.0.0.3 10.0.0.1 255.255.255.255 UGH 0 0 > 0 eth0 10.0.0.0 10.0.0.2 255.255.255.0 UG 0 0 > 0 eth0 63.249.19.0 0.0.0.0 255.255.255.0 U 0 0 > 0 eth0 10.0.0.0 0.0.0.0 255.0.0.0 U 0 0 > 0 eth0 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 > 0 lo 0.0.0.0 63.249.19.1 0.0.0.0 UG 0 0 0 > eth0 Hm - if I were you, I'd try to kick Rhiannon (the 10.0.0.3, right?) out of the routing tables. This route says that to reach Rhiannon, the machine has to send packets to 10.0.0.1 (that was Ra-Hoor, IIRC), which is clearly a nonsense. Otherwise, the table looks fine. The route #2 is, I think, unnecessary, but doesn't seem to disturb either. Your two subnets are covered by #3 and #4 (the local network is currently 10/8, the route will change when you change eth0:1 to 10.0.0/24, as this is IIRC what you want), and the default gw is the last route. > > # /sbin/ifconfig > eth0 Link encap:Ethernet HWaddr 00:C0:4F:60:E4:5F > inet addr:63.249.19.72 Bcast:63.249.19.255 > Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 > Metric:1 RX packets:3053288 errors:0 dropped:0 overruns:0 > frame:0 TX packets:3483744 errors:0 dropped:0 overruns:0 > carrier:2365 collisions:74625 txqueuelen:100 > RX bytes:2174866056 (2074.1 Mb) TX bytes:2745016344 (2617.8 > Mb) Interrupt:10 Base address:0xdc00 > > eth0:1 Link encap:Ethernet HWaddr 00:C0:4F:60:E4:5F > inet addr:10.0.0.2 Bcast:10.255.255.255 Mask:255.0.0.0 > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > Interrupt:10 Base address:0xdc00 > > lo Link encap:Local Loopback > inet addr:127.0.0.1 Mask:255.0.0.0 > UP LOOPBACK RUNNING MTU:16436 Metric:1 > RX packets:28056 errors:0 dropped:0 overruns:0 frame:0 > TX packets:28056 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:0 > RX bytes:2272902 (2.1 Mb) TX bytes:2272902 (2.1 Mb) > > > By the way, I'm trying to write a firewall script so I can > > ditch ipchains in favour of iptables (which would then probably > > do for you what it does for me), and I discovered that during > > my attempts to configure the kernel as lean as possible I > > excluded some important modules. Bugger. I recompiled it and > > found that it screwed up my bttv modules. I recompiled them as > > well, but it won't work. I remember that installing bttv needed > > a bit of hacking when I did it last time, but, that's all I can > > remember. The joys of Linux. > > Oops. Wish I could help, but while I've heard mention of bttv > modules, I've no idea what the do.... Oh, got it... It turned out that since my last compilation, I somehow managed to inadvertently exclude a kernel module necessary for bttv to work (videodev.o) during some intermediate reconfig. I was cautious and compiled the new kernel as a new version (2.4.18-MarkI) which prevented me from copying it from the old kernel module directory as it was signed with a different version name, although they all come from same stupid sources. Linus has his bad days as anyone else, I guess. So it took me several module recompiles to get the stupid videodev.o and several more thanks to my stupidity (reconfigured the kernel and recompiled without saving the reconfigured Makefile - D'oh!) Cheers -- Horror Vacui Registered Linux user #257714 Go get yourself... counted: http://counter.li.org/ - and keep following the GNU. To unsubcribe send e-mail with the word unsubscribe in the body to: Linux-Anyway-Request@xxxxxxxxxxxxx?body=unsubscribe