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  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Fri, 16 Nov 2007 09:30:11 +0100
From:	"Jonas Danielsson" <>
To:	"David Miller" <>
Subject: Re: [PATCH] net/ipv4/arp.c: Fix arp reply when sender ip 0

2007/11/16, David Miller <>:
> From: "Jonas Danielsson" <>
> Date: Thu, 15 Nov 2007 22:40:13 +0100
> > Is there a reason that the target hardware address isn't the target
> > hardware address?

> Because of this, in cases where a choice can be made Linux will
> advertise what is most likely to result in successful communication.
> This is likely why we are changing that target address to the one of
> the interface actually sending back the reply rather than the zero
> value you used.
> In fact I think this information can be useful to the sender of
> the DAD request.

There seem to be some confusion about what my patch really does. It
does not set the hardware address to a zero value.

An example to illustrate:

We have two computers.
Computer A
HW: 00:AA:00:AA:00:AA

Computer B
IP: None
HW: 00:BB:00:BB:00:BB

Computer B want to find out if IP is free for use. It
sends an arp-request.

Opcode: request (0x0001)
Sender HW: 00:BB:00:BB:00:BB
Sender IP:
Target HW:   00:00:00:00:00:00
Target IP:

The reply from the Linux kernel in computer A, before the patch would look like:

Opcode: reply (0x0002)
Sender HW: 00:AA.00:AA:00:AA
Sender IP:
Target HW:  00:AA:00:AA:00:AA
Target IP:

And the reply from the Linux kernel, in computer A, after the patch
would look like:

Opcode: reply (0x0002)
Sender HW: 00:AA.00:AA:00:AA
Sender IP:
Target HW:  00:BB:00:BB:00:BB
Target IP:

It is the fact that the Target HW  address is set to computer A and
not computer B that my patch wants to fix. And the Target IP:
is because OpenBSD and windows replied in that way.

I wanted to change this because, among other things, dhcpcd-2.0.3 has
the following code in its arpCheck-function:

if ( memcmp(ArpMsgRecv.tHaddr,ClientHwAddr,ETH_ALEN) )
if ( DebugFlag )
	    	"target hardware address mismatch:"  [...]

This check will always fail when replies come from Linux machines,
since the target hardware address will not match the client mac

To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to
More majordomo info at

Powered by blists - more mailing lists