Bug 30290 - ARP resolving bug
ARP resolving bug
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
7.1
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: David Miller
Brock Organ
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-03-02 04:47 EST by Igor
Modified: 2007-04-18 12:31 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-03-16 06:21:28 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Igor 2001-03-02 04:47:42 EST
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)




Reproducible: Always
Steps to Reproduce:
1.ping d1
2.ping d2
3.arp -a
	

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 
eth0
d2.ntc(172.22.3.255) at 00:50:73:25:D2:00 [ether] on eth0

kernels from previous versions of RH works normal.
Comment 1 David Miller 2001-03-02 19:48:32 EST
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". 
Comment 2 Igor 2001-03-06 02:27:41 EST
Additional description.
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#debug arp

d0#ping 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#ping 172.22.55.4
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
Comment 3 David Miller 2001-03-06 03:23:02 EST
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
here?
Comment 4 Igor 2001-03-06 04:21:41 EST
There is no corresponding firewalling. But d0 works well if the "fisher" kernel 
installed and loaded with the same "wolverine" environment.
Comment 5 David Miller 2001-03-06 15:40:32 EST
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.
Comment 6 Igor 2001-03-12 07:19:21 EST
wolverine with kernel from fisher:

d2#debug arp

d0#ping d2
d2#IP ARP: rcvd req src 172.22.55.4 0000.f870.929b, dst 172.22.3.255 
FastEthernet 0/0
d2#IP ARP: sent rep src 172.22.3.255 0050.7325.d200, dst 172.22.55.4 
0000.f870.929b FastEthernet 0/0
Comment 7 David Miller 2001-03-14 01:19:48 EST
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.
Comment 8 Igor 2001-03-14 06:30:59 EST
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.
Comment 9 Arjan van de Ven 2001-03-14 08:14:23 EST
Can you please try a new kernel from rawhide ?
The Wolverine kernel had a bug in the tulip driver that caused such
behavior.
Comment 10 Igor 2001-03-16 06:21:17 EST
A new kernel from rawhide works well.

Note You need to log in before you can comment on or make changes to this bug.