Why Linux is blind to this ARP reply 2968

andres a know

Sorry to be so late getting back to you. Extra load at work and fighting a cold has left me pretty tired at the end of the day :(

Here's what I see -- let me know if I'm wrong anywhere:

-- Your 10.10.0.0 net is segmented by several routers. Are they running proxy arp and-or filled with static routes? Are there multiple paths to different lan locations?

Have you tried traceroute on Linux to see how packets are traveling through the lan to the IBM routers? Do Win boxes (tracert) use the same routes from the same location? Are the routers emitting redirects for better pathways?

I'm wondering if Linux does not "like" something about the arp reply. Eg., since IBMs are on the same (logical) subnet, Linux places the arp request (bcast) directly on the wire, the IBMs reply, Linux spots what it considers an inconsistency and rejects the reply. Have you checked that the returned IBM MAC address is, in fact, the MAC of the IBM interface and not an intervening router.

You may need to examine both the ethernet frames and the arp packets in every detail to butture that "correct" data is being returned. That includes the destination IP-MAC of Linux and source IP-MAC of IBM. How does it compare to what Win machines see?

-- The packets are getting on the wire as seen by ethereal. You might run ethereal on Linux so as to have the same tool available on both Linux and Win.

If the Win boxes seem to be operating "correctly" you can use them -- both their configuration and packets -- to find what they seem to be doing that Linux is not.

-- Linux seems not to pick the packets off the wire -- with ethereal running in promisc mode? -- Same-similar behavior on Solaris -- not picking up arp replies.

I can't imagine that Linux-Solaris would not pick up an ethernet frame with the "correct" MAC destination address. How else could they communicate with the other lan hosts? Arp and ping are two of the simplest protocols around and arp is absolutely essential.

Linux is pretty robust but does have it's quirks. Your host setups seem pretty simple, however, ie., a single nic, a single IP. Default IP settings should work OK. You can check the main ones here: $ catproc-sys-net-ipv4-conf-eth0-* 1 1 0 0 0 0 0 0 0 1 1 1 1 0 $ lsproc-sys-net-ipv4-conf-eth0acceptredirects forwarding proxyarp sharedmedia acceptsourceroute logmartians rpfilter tag arpfilter mcforwarding secureredirects bootprelay mediumid sendredirects

Googling did turn up a few similar examples, but they involved multi-homed hosts. One sounded very much like yours, but no one replied (and it is several years old). So not much to go by. Here's the best:

It uses # ip route add ... to place a route in a policy routing table. I really hoped you could avoid doing that if possible. Also not sure how to implement the same thing on Solaris.

I'm sure VmWare is not the source of your problems but not sure how-if it might complicate a solution on that machine. I'm not familiar with the ins-n-outs of VmWare to be of any help there.

Is it possible for you or someone else to ping a Linux box from one of the IBMs. This request may very well place an arp entry for the IBM on the Linux box. If so, you could use it to place a static arp entry into Linux. You might try to use a Win host for the info needed to make a static arp entry. If this works, it should apply on Solaris too -- I hope ;-)

Note about your current config: Kernel IP routing table Destination Gateway Genmask Flags Iface 10.10.0.39 10.10.1.54 255.255.255.255 UGH eth0 Using the host IP for the GW is probably not going to work reliably. It should cause unicast packets to simply use loopback. Something like: # route add -host 10.10.0.39 will use default GW to send packets and 10.10.0.0 is already in route table. It is usually-sometimes more reliable to install all net routes before any host or GW routes.

The IPs-netmasks from routing table you posted: net: 10.10.0.021 netmask: 255.255.248.0 (-21) -byte- -byte- -byte-- -byte- -net-- -net-- sub -- -host--

net: 10.10.96.019 netmask: 255.255.224.0 (-19) -net-- -net-- sub -----host---

I'm sending these links along in case they are informative-useful: Basic and advanced Linux networking doc

The doc for Linux's ip utility. See especially: # ip link show # ip route show # ip route add

Linux policy routing "in depth"

arp packet format, options, and codes

If I keep going I'll make your hair fall out, so I'll stop now and hope there is something useful here ;-)

The main thing at this point is that you will have to see if you can ping from Linux to next hop, to next hop, etc., to IBM. Watch packets, compare to traceroute path, ping traceroute path point by point. Compare to Windows output.

Try a static arp table entry once you have the "correct" MAC address for IBM. Is "correct" the MAC on the IBM interface or the MAC of a "router" that is shuttling packets? (EG., all arp entries on this solo box at home match IPs to the default GW MAC).

Tedious, probably uneeded, but do double check that Win is using the same MAC as Linux (on the dual OS or boot machine) in its arp requests. Check options in packets while you're at it. I would hate to think that MS and IBM are talking via some "optimized" feature-flag from LanMan days before IBM recognized MS as its nemesis.

There has to be something that is different in the way Win is talking to the IBMs that Linux and Solaris are not-cannot duplicate. That or something in the Win IP stack that works OK in a "routed" IP subnet address space. Sure hope there is a better solution than policy routing.

There may be a couple of other things I have forgotten to suggest, but surely this is enough (too much?) for now. If anything comes to me tomorrow, I'll try to get it posted earlier.

good luck and let us know how it's going, prg email above disabled