linux-kernel - Strange behavior in arp probe reply, bug or feature?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <cac0ab7d0711140724i5019d72byb1b34156788897b9@mail.gmail.com>
Date:	Wed, 14 Nov 2007 16:24:25 +0100
From:	"Jonas Danielsson" <the.sator@...il.com>
To:	linux-kernel@...r.kernel.org
Subject: Strange behavior in arp probe reply, bug or feature?

Hi,

I was working on a project that involved having our dhcp-client
performing a check on the offered IP-address to make sure it wasn't in
use.
The standard way of doing this is sending out an arp request with the
sender ip set to 0. (RFC2131).

When I was testing out my implemented solution I noticed that my linux
machines responded a bit odd to this arp-request.
The arp-reply had the sender-ip field set to the same as the target-ip
field and the target-hwaddr field the same as the sender-hwaddr field.
All the values where the addresses of the machine replying to the request.
This is not a standard arp way of replying.

I checked the code in net/ipv4/arp.c and found this:

/* Special case: IPv4 duplicate address detection packet (RFC2131) */
       if (sip == 0) {
               if (arp->ar_op == __constant_htons(ARPOP_REQUEST) &&
                   inet_addr_type(tip) == RTN_LOCAL)
                      arp_send(ARPOP_REPLY,ETH_P_ARP

,tip,dev,tip,sha,dev->dev_addr,dev->dev_addr);
               goto out;
       }

This code will implement the strange behavior mentioned above.

I checked the arp-request against a box running Windows XP and one
running OpenBSD, none of them had this strange beahvior, but rather
replied in a way that
I expected to see, with the requesting machines mac in the target
hw-addr field and 0.0.0.0 in the target ip field.

The linux boxes I tested against ran the 2.16.18 and the 2.16.22
kernel and the code above is still used in the 2.16.23-1 kernel.

I changed the code above on one of them to have the arp_send called in
a "normal" way:

arp_send(ARPOP_REPLY,ETH_P_ARP,sip,dev,tip,sha,dev->dev_addr,sha);

After the change the replies looked like the ones I was receiving from
the OpenBSD and Windows-box.

The comment above the code mention the RFC2131, but there is no
mention, that I can see to this construction of the reply. I can only
see the specification of setting the sender ip to 0.
I can't understand the need for this strange way of constructing an
arp-reply packet. Is this a feature or a bug?

Regards
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/