Bug 142384 (IT_56632) - RH EL 3 U4: ARP reply has same source and target addresses
Summary: RH EL 3 U4: ARP reply has same source and target addresses
Alias: IT_56632
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel   
(Show other bugs)
Version: 3.0
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: David Miller
QA Contact: Brian Brock
Depends On:
Blocks: 145824
TreeView+ depends on / blocked
Reported: 2004-12-09 13:24 UTC by Issue Tracker
Modified: 2007-11-30 22:07 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-02-06 21:32:35 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 Issue Tracker 2004-12-09 13:25:00 UTC
Escalated to Bugzilla from IssueTracker

Comment 1 Larry Troan 2004-12-09 13:28:36 UTC
The duplicate address detection scheme outlined in RFC2131 results in
an ARP reply with the source and target addresses being the same. The
ARP reply contents are:

     SHA - 00-0A-23-44-2A-3F
     SPA -
     THA - 00-00-00-00-00-00
     TPA -

     SHA - 00-0B-AA-88-C7-1D
     SPA -
     THA - 00-0B-AA-88-C7-1D
     TPA -

According to RFC 826, the algorithm should swap the source and target

  Is the opcode ares_op$REQUEST?  (NOW look at the opcode!!)
 Swap hardware and protocol fields, putting the local
     hardware and protocol addresses in the sender fields.
 Set the ar$op field to ares_op$REPLY
 Send the packet to the (new) target hardware address on
     the same hardware on which the request was received.

And later, an explanation of target hardware address:

  The target hardware address is included for completeness and
  network monitoring.  It has no meaning in the request form, since
  it is this number that the machine is requesting.  Its meaning in
  the reply form is the address of the machine making the request.

We can see the arp.c kernel file calling arp_send with the target
ip in the dest_ip and src_ip:

 /* Special case: IPv4 duplicate address detection packet (RFC2131) */
 if (sip == 0) {
    if (arp->ar_op == htons(ARPOP_REQUEST) &&
        inet_addr_type(tip) == RTN_LOCAL)
    goto out;

arp_send signature:

 void arp_send(int type, int ptype, u32 dest_ip, struct net_device
*dev, u32 src_ip,
               unsigned char *dest_hw, unsigned char *src_hw, unsigned
char *target_hw)

Nothing could be found in any RFC that states an ARP reply can have
the same hardware and protocol address for the source and target. This
ARP reply is causing problems for some customer applications. From the
RFCs and lack of an explanation in the source code, this appears to be
a defect.

Comment 2 Jay Fenlason 2004-12-09 22:39:35 UTC
I'll need to see the complete set of arptables commands they're using on their 
system.  arptables is a dangerous tool that can be configured to break network 
connectivity in many wierd ways.  Most likely they're not DROPping packets 
that they should, or rewriting them incorrectly. 

Comment 3 Brian Baker 2004-12-17 18:26:55 UTC
The system is a normal install of redhat and no modification has been 
made through arptables.  We're simply sending a standard dhcp 
duplicate address detection ARP packet to a vanilla system and are 
not receiving the correct response.

When we send:

	  SHA - 00-0A-23-44-2A-3F
	  SPA -
	  THA - 00-00-00-00-00-00
	  TPA -

We SHOULD see:

	  SHA - 00-0B-AA-88-C7-1D
	  SPA -
	  THA - 00-0A-23-44-2A-3F
	  TPA -

However, we are seeing:

	  SHA - 00-0B-AA-88-C7-1D
	  SPA -
	  THA - 00-0B-AA-88-C7-1D
	  TPA -

Since we have done no mangling of arp packets on the RedHat system 
via arptables, we believe this is a violation of the Address 
Resolution module algorithm outlined in RFC 826. 

Comment 4 Jay Fenlason 2004-12-17 18:45:54 UTC
If you aren't using arptables, why did you open this bug against the 
arptables package?  I'm assuming you meant to open this against the 
kernel, and brainod it, so I'm reassigning it to the kernel 

Comment 5 Brian Baker 2004-12-17 19:08:55 UTC
Oops, sorry.

Comment 6 David Miller 2005-02-06 21:32:35 UTC
There is nothing explicitly forbidding both target and source
being the same.

If you can find chapter and verse of an RFC which explicitly
forbids this, I'll look into fixing it.  But it's totally legal
as far as I can tell, and we've behaved this way for many years
and this is the first complaint I've ever header of about this

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