Red Hat Bugzilla – Bug 30290
ARP resolving bug
Last modified: 2007-04-18 12:31:53 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)
Steps to Reproduce:
Actual Results: d1.ntc(172.22.13.0) at 00:00:F8:70::95:0C [ether] on eth0
d2.ntc(172.22.3.255) at <incomplete> on eth0
Expected Results: d1.ntc(172.22.13.0) at 00:00:F8:70::95:0C [ether] on
d2.ntc(172.22.3.255) at 00:50:73:25:D2:00 [ether] on eth0
kernels from previous versions of RH works normal.
Please obtain a tcpdump from the machine "d2" , and specifically
make note if the ARP request is visiable at d2. Once you've obtained
this information, you need to do one of two things based upon the results:
1) If the ARP request is seen by "d2", I need to know what OS/hardware
"d2" is running.
2) If the ARP request is not seen by "d2", you have a local configuration
problem of some sort, probably at one of your switches/hubs between
your system and "d2".
d0.ntc 172.22.55.4/16 00:00:F8:70:92:9B (DEC PC 5510 RH 7.0.91)
d1.ntc 172.22.13.0/16 00:00:F8:70:95:0C (DEC PC 5510 RH 6.1)
d2.ntc 172.22.3.255/16 00:50:73:25:d2:00 (Cisco 3640 IOS 11.3.6T enterp.)
d3.ntc 172.22.3.254/16 00:10:FF:DB:98:A8 (Cisco 7507 IOS 12.0.8 enterp.)
ARP request is seen by d2.
d2#IP ARP req filtered src 172.22.55.4 0000.0000.0000, dst 172.22.3.255
0000.0000.0000 it's our address
d2#IP ARP throttled out the ARP Request for 172.22.55.4
d2#IP ARP: sent req src 172.22.3.255 0050.7325.d200, dst 172.22.55.4
0000.0000.0000 FastEthernet 0/0
d2#IP ARP rep filtered src 172.22.55.4 0000.0000.0000, dst 172.22.3.255
0050.7325.d200 it's our address
So the question is why d2, the cisco, is never responding to
ARP requests. The request looks fine from the debugging
output on the cisco. Do you have some kind of firewalling
or similar setting made on this cisco that might have consequences
There is no corresponding firewalling. But d0 works well if the "fisher" kernel
installed and loaded with the same "wolverine" environment.
Ok, then what do the debugging messages on "d2" look like with
the working "wolverine" kernel? They ought to look much
different, and the differences will show us what is going wrong.
wolverine with kernel from fisher:
d2#IP ARP: rcvd req src 172.22.55.4 0000.f870.929b, dst 172.22.3.255
d2#IP ARP: sent rep src 172.22.3.255 0050.7325.d200, dst 172.22.55.4
0000.f870.929b FastEthernet 0/0
It seems that the broken case uses an ethernet address of zero.
This is a problem.
I'm going to guess that you are using a Tulip card with the
tulip.o driver? If you could tell me what card is in the failing
DEC PC 5510 machine, and what ethernet address the card
has when running the failing kernel, we can begin to look more
precisely for what the problem is.
You can find out the ethernet address the kernel thinks the card
has using ifconfig or by looking at the kernel messages printed
after the driver is loaded for the card.
DEC PC 5510 has build-in FastEthernet adapter based on chip 21143.
In both cases MAC address is incorrectly recognized as 00:00:00:00:00:00.
Can you please try a new kernel from rawhide ?
The Wolverine kernel had a bug in the tulip driver that caused such
A new kernel from rawhide works well.