Bug 30290

Summary:	ARP resolving bug
Product:	[Retired] Red Hat Linux	Reporter:	Igor <kil>
Component:	kernel	Assignee:	David Miller <davem>
Status:	CLOSED RAWHIDE	QA Contact:	Brock Organ <borgan>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	7.1
Target Milestone:	---
Target Release:	---
Hardware:	i386
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2001-03-16 11:21:28 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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(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-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 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 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
here?

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

Comment 10 Igor 2001-03-16 11:21:17 UTC

A new kernel from rawhide works well.