Link to home
Start Free TrialLog in
Avatar of smokie
smokie

asked on

Eth0 only partly there...

I thought perhaps you might beable to help with a problem
here that seems to have all the "guru's" I have consulted stumped.
Here''s the layout:
Linux darkstar 2.0.23 #3 Fri Jun 6 20:52:07 CDT 1997 i586  I have the linux machine here, darkstar.sysinfo.com on 204.246.65.62 ppp0, with a 3com 509b card <called blackhole.sysinfo.com 192.168.80.1 eth0.  The inside net has a win 3.11 and a win95 machine, 192.168.80.10 and 192.168.80.20, both set with 192.168.80.1 <blackhole> as their gateway.  I can watch all the packets on 192.168.80.0/255 with various net tools, incuding tcpdump.  the win machines can play togeth fine.  but, blackhole will not recognize their packets, and they seem to not see those of blackhole.  So, there at this point is nothing getting masqueraded out.  All policies for ipfw are accept, to make it as open as possible now.    <damn, the buffered space here is hardly adequate to give a proper rundown of what is really being observed over ehre, sorry>
Avatar of lewiar
lewiar

Really, I'd need to see the output of ifconfig, route and ipfwadm -Fl.

Assuming there is no problem with netmasks and routes... It is of course possible that there is a hardware problem... I have seen a card which could recieve but not transmit....

J
Avatar of smokie

ASKER

eth0      Link encap:10Mbps Ethernet  HWaddr 00:20:AF:04:4C:42
          inet addr:192.168.80.1  Bcast:192.168.80.255  Mask:255.255.255.0
          UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1
          RX packets:4902 errors:4 dropped:4 overruns:0
          TX packets:86 errors:0 dropped:0 overruns:0
          Interrupt:10 Base address:0x300
A bad card was considered, but, card swaps produce the same results.  As for the ipfwadm rules, aren't we getting ahead of ourselves on that?  ipfwadm with no rules set leaves it a wide open accept policy, and pinging the internal interface from within the internal net should work according to the FAQ's surrounding this type of setup, yes?
Yes ping should work to or from the internal network.
Have you setup a route?
route add -net 192.168.80.0 netmask 255.255.255.0 eth0
Have you looked at the ip masquerade howto:
http://www.linuxhq.com/HOWTO/mini/IP-Masquerade
And the net3 howto(the internal network should be working first):
http://www.linuxhq.com/HOWTO/NET-3-HOWTO.html
Can you ping the ethernet interface of your linux box from a win95 box on the local network?

Can you telnet to it?

If you can't, the problem is with your basic networking setup - post the output of a route -n please.

If the above tests work, then does the machine route properly? If not, have you actually recompiled the kernel with IP routing support? Are you booting from your recompiled kernel?


Avatar of smokie

ASKER

Kernel routing table
Destination     Gateway         Genmask         Flags MSS    Window Use Iface
204.246.71.10   *               255.255.255.255 UH    1500   0        0 ppp0
192.168.80.0    *               255.255.255.0   U     1500   0        8 eth0
127.0.0.0       *               255.0.0.0       U     3584   0      117 lo
default         204.246.71.10   *               UG    1500   0       44 ppp0
Nope, the win machines talk fine to one another, but, even though the linux box can see traffic on the wire, it's packets don't make it to the win boxes properly, nor do the win boxes talk completely to the linux box.  And, even with the ppp0 interface down, there are no changes.  If anyone would like to request it, I have tcpdump traces I will be happy to e-mail to anyone.  This issue has been a pain for far too long here, and has stumped every guru we have contacted.  All are stumped...
Have you defined any firewalling/maquering parameters after booting the kernel ? If so, can you try not to define them, and then try to contact the other hosts ? Are you sure that the problem isn't with the Win-machines configuration ?
Avatar of smokie

ASKER

As stated, not ipfwadm rules are setup, the default policy is accept, the win boxen talk fine to one another, the linux box sees all traffic on the eth0 interface, yet, the win boxen and the linux box seem to talk improperly to one another.  The win boxen have the linux box as their gateway, and seek to do dns from the host files on those machines and via the resolve setup of the linux box...
Try updating the kernel to 2.0.29 NOT 2.0.30.
I've got several machines linked via ethernet and 56k bridges and masqerade works fine. The 2.0.30 kernel at times stopped forwading packets but when I backed off to 2.0.29 the other day the problems cleared. 2.0.31 Is due out real soon and promises to fix all this and be released code, not experimental.

Avatar of smokie

ASKER

am about to try this.  Have held off as I was under the impression that 2.0.23 had everything in place, though not as many ip-masq modules available.  Have asked repeatedly if there was a bug in 2.0.23 that caused the troubles I see here, but have as yet gotten no info to suggest this.  Thing is, there were so may reports of folks succeeding with the earlier 2.0.x and previous kernels, I have been looking for info to suggest that there's something drastically wrong with the earlier kernels.
ASKER CERTIFIED SOLUTION
Avatar of nicademus
nicademus

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial