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, on ppp0, with a 3com 509b card <called eth0.  The inside net has a win 3.11 and a win95 machine, and, both set with <blackhole> as their gateway.  I can watch all the packets on 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>
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

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....

smokieAuthor Commented:
eth0      Link encap:10Mbps Ethernet  HWaddr 00:20:AF:04:4C:42
          inet addr:  Bcast:  Mask:
          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 netmask eth0
Have you looked at the ip masquerade howto:
And the net3 howto(the internal network should be working first):
Cloud Class® Course: Python 3 Fundamentals

This course will teach participants about installing and configuring Python, syntax, importing, statements, types, strings, booleans, files, lists, tuples, comprehensions, functions, and classes.

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?

smokieAuthor Commented:
Kernel routing table
Destination     Gateway         Genmask         Flags MSS    Window Use Iface   *      UH    1500   0        0 ppp0    *        U     1500   0        8 eth0       *            U     3584   0      117 lo
default   *               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 ?
smokieAuthor Commented:
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.

smokieAuthor Commented:
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.
Have you ever compiled the kernel and wondered about using the option in the Networking section of the config which enables PC/TCP compatibility mode?

Best bet though is to upgrade to 2.0.29 and also enable the PC/TCP compat. feature.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Linux Networking

From novice to tech pro — start learning today.