Bug 30290 - ARP resolving bug
Summary: ARP resolving bug
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel   
(Show other bugs)
Version: 7.1
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: David Miller
QA Contact: Brock Organ
Depends On:
TreeView+ depends on / blocked
Reported: 2001-03-02 09:47 UTC by Igor
Modified: 2007-04-18 16:31 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-03-16 11:21:28 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Igor 2001-03-02 09:47:42 UTC
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( at 00:00:F8:70::95:0C [ether] on eth0
d2.ntc( at <incomplete> on eth0

Expected Results:  d1.ntc( at 00:00:F8:70::95:0C [ether] on 
d2.ntc( at 00:50:73:25:D2:00 [ether] on eth0

kernels from previous versions of RH works normal.

Comment 1 David Miller 2001-03-03 00:48:32 UTC
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 07:27:41 UTC
Additional description.
d0.ntc 00:00:F8:70:92:9B (DEC PC 5510 RH 7.0.91)
d1.ntc 00:00:F8:70:95:0C (DEC PC 5510 RH 6.1)
d2.ntc 00:50:73:25:d2:00 (Cisco 3640 IOS 11.3.6T enterp.)
d3.ntc 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 0000.0000.0000, dst 
0000.0000.0000 it's our address

d2#IP ARP throttled out the ARP Request for
d2#IP ARP: sent req src 0050.7325.d200, dst 
0000.0000.0000 FastEthernet 0/0
d2#IP ARP rep filtered src 0000.0000.0000, dst 
0050.7325.d200 it's our address

Comment 3 David Miller 2001-03-06 08:23:02 UTC
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

Comment 4 Igor 2001-03-06 09:21:41 UTC
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 20:40:32 UTC
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 12:19:21 UTC
wolverine with kernel from fisher:

d2#debug arp

d0#ping d2
d2#IP ARP: rcvd req src 0000.f870.929b, dst 
FastEthernet 0/0
d2#IP ARP: sent rep src 0050.7325.d200, dst 
0000.f870.929b FastEthernet 0/0

Comment 7 David Miller 2001-03-14 06:19:48 UTC
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 11:30:59 UTC
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 13:14:23 UTC
Can you please try a new kernel from rawhide ?
The Wolverine kernel had a bug in the tulip driver that caused such

Comment 10 Igor 2001-03-16 11:21:17 UTC
A new kernel from rawhide works well.

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