Fix arp reply when received arp probe with sender ip 0.
Can't find any ground in RFC2131 to send a non-valid arp-reply in
the special case of sender ip being set to 0.
- Bug fix for arp handling when sender ip is set to 0.
Send a correct arp reply instead of one with sender ip and sender
hardware adress in target fields.
Now sends target ip and target hw as received in arp probe.
Signed-off-by: Jonas Danielsson <[email protected]>
---
arp.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Index: arp.c
===================================================================
RCS file: /usr/local/cvs/linux/os/linux-2.6/net/ipv4/arp.c,v
retrieving revision 1.22
diff -u -w -r1.22 arp.c
--- arp.c 13 Oct 2006 12:45:47 -0000 1.22
+++ arp.c 15 Nov 2007 10:34:44 -0000
@@ -827,7 +827,8 @@
if (arp->ar_op == htons(ARPOP_REQUEST) &&
inet_addr_type(tip) == RTN_LOCAL &&
!arp_ignore(in_dev,dev,sip,tip))
- arp_send(ARPOP_REPLY,ETH_P_ARP,tip,dev,tip,sha,dev->dev_addr,dev->dev_addr);
+ arp_send(ARPOP_REPLY, ETH_P_ARP, sip, dev, tip, sha,
+ dev->dev_addr, sha);
goto out;
}
Hello!
> Send a correct arp reply instead of one with sender ip and sender
> hardware adress in target fields.
I do not see anything more legal in setting target address to 0.
Actually, semantics of target address in ARP reply is ambiguous.
If it is a reply to some real request, it is set to address of requestor
and protocol requires recipient of this arp reply to test that the address
matches its own address before creating new entry triggered by unsolicited
arp reply. That's all.
In the case of duplicate address detection, requestor does not have
any address, so that it is absolutely not essential what we use as target
address. The only place, which could depend on this is the tool, which
tests for duplicate address. At least, arping written by me, should
work with any variant.
So, please, could you explain what did force you to think that use of 0
is better?
Alexey
Hi,
I started to look at this code when I was working on a project of
rewriting a dhcp-client.
I wanted to make the client use arp to determine if the offered
address was free or in use.
Thats when I noticed that linux machines responded in this, for me, odd way.
The problem is not really the target ip address in the reply, it is
the fact that the target hardware address is set to the hardware
address of the machines that is sending the reply.
The target hardware address should be the same as the destination
address in the ethernet frame.
The dhcp clients I examined, and the implementation of the arpcheck
that I use will compare the target hardware field of the arp-reply and
match it against its own mac, to verify the reply. And this fails with
the current implementation in the kernel.
As for the the target ip set to 0, that is the behavior I saw in
Windows and OpenBSD machines and figured it was a valid approach. The
main thing is however that the target machine address in the arp reply
in this case will confuse dhcp-clients trying to verify the reply.
And even if your arping implementation will work with any variant,
other implementation of this approach of duplicate ip detection
expects a differeant behavior.
Is there a reason that the target hardware address isn't the target
hardware address?
-Jonas
2007/11/15, Alexey Kuznetsov <[email protected]>:
> Hello!
>
> > Send a correct arp reply instead of one with sender ip and sender
> > hardware adress in target fields.
>
> I do not see anything more legal in setting target address to 0.
>
>
> Actually, semantics of target address in ARP reply is ambiguous.
> If it is a reply to some real request, it is set to address of requestor
> and protocol requires recipient of this arp reply to test that the address
> matches its own address before creating new entry triggered by unsolicited
> arp reply. That's all.
>
> In the case of duplicate address detection, requestor does not have
> any address, so that it is absolutely not essential what we use as target
> address. The only place, which could depend on this is the tool, which
> tests for duplicate address. At least, arping written by me, should
> work with any variant.
>
> So, please, could you explain what did force you to think that use of 0
> is better?
>
> Alexey
>
From: "Jonas Danielsson" <[email protected]>
Date: Thu, 15 Nov 2007 22:40:13 +0100
> Is there a reason that the target hardware address isn't the target
> hardware address?
Linux subscribes to the host based addressing model rather
than an interface based addressing model. Both approaches
are valid by RFCs.
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.
2007/11/16, David Miller <[email protected]>:
> From: "Jonas Danielsson" <[email protected]>
> 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
IP: 192.168.0.1
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 192.168.0.1 is free for use. It
sends an arp-request.
Request:
Opcode: request (0x0001)
Sender HW: 00:BB:00:BB:00:BB
Sender IP: 0.0.0.0
Target HW: 00:00:00:00:00:00
Target IP: 192.168.0.1
The reply from the Linux kernel in computer A, before the patch would look like:
Reply:
Opcode: reply (0x0002)
Sender HW: 00:AA.00:AA:00:AA
Sender IP: 192.168.0.1
Target HW: 00:AA:00:AA:00:AA
Target IP: 192.168.0.1
And the reply from the Linux kernel, in computer A, after the patch
would look like:
Reply:
Opcode: reply (0x0002)
Sender HW: 00:AA.00:AA:00:AA
Sender IP: 192.168.0.1
Target HW: 00:BB:00:BB:00:BB
Target IP: 0.0.0.0
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: 0.0.0.0
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 )
syslog(LOG_DEBUG,
"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
address.
-Jonas
From: "Jonas Danielsson" <[email protected]>
Date: Fri, 16 Nov 2007 09:30:11 +0100
> 2007/11/16, David Miller <[email protected]>:
> > From: "Jonas Danielsson" <[email protected]>
> > 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.
I knew you were talking about the IP address not the hardware
address.
> The reply from the Linux kernel in computer A, before the patch would look like:
>
> Reply:
> Opcode: reply (0x0002)
> Sender HW: 00:AA.00:AA:00:AA
> Sender IP: 192.168.0.1
> Target HW: 00:AA:00:AA:00:AA
> Target IP: 192.168.0.1
And this is exactly a sensible response in my opinion.
On Fri, 16 Nov 2007, David Miller wrote:
> From: "Jonas Danielsson" <[email protected]>
> Date: Fri, 16 Nov 2007 09:30:11 +0100
>
> > 2007/11/16, David Miller <[email protected]>:
> > > From: "Jonas Danielsson" <[email protected]>
> > > 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.
>
> I knew you were talking about the IP address not the hardware
> address.
>
> > The reply from the Linux kernel in computer A, before the patch would look like:
> >
> > Reply:
> > Opcode: reply (0x0002)
> > Sender HW: 00:AA.00:AA:00:AA
> > Sender IP: 192.168.0.1
> > Target HW: 00:AA:00:AA:00:AA
> > Target IP: 192.168.0.1
>
> And this is exactly a sensible response in my opinion.
I don't see how you can say that, since it appears to be in violation
of RFC 826:
"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. In some implementations (which do not get to look
at the 14.byte ethernet header, for example) this may save some
register shuffling or stack space by sending this field to the
hardware driver as the hardware destination address of the
packet."
Since the MAC address of the machine making the request is
00:BB:00:BB:00:BB, and not 00:AA:00:AA:00:AA, Linux appears to
be in violation of the ARP RFC.
Regarding the Target IP, RFC 826 says:
"The target protocol address is necessary in the request form
of the packet so that a machine can determine whether or not
to enter the sender information in a table or to send a reply.
It is not necessarily needed in the reply form if one assumes
a reply is only provoked by a request. It is included for
completeness, network monitoring, and to simplify the suggested
processing algorithm described above (which does not look at
the opcode until AFTER putting the sender information in a
table).
So it's ambiguous about the target IP address in an ARP reply packet,
but a value of 0.0.0.0 makes more logical sense to me than using
192.168.0.1 in this example case, since it should reflect the requestor
IP address, which is unknown in this case.
-Bill
Bill Fink wrote, On 11/16/2007 08:26 PM:
...
> Regarding the Target IP, RFC 826 says:
>
> "The target protocol address is necessary in the request form
> of the packet so that a machine can determine whether or not
> to enter the sender information in a table or to send a reply.
> It is not necessarily needed in the reply form if one assumes
> a reply is only provoked by a request. It is included for
> completeness, network monitoring, and to simplify the suggested
> processing algorithm described above (which does not look at
> the opcode until AFTER putting the sender information in a
> table).
>
> So it's ambiguous about the target IP address in an ARP reply packet,
> but a value of 0.0.0.0 makes more logical sense to me than using
> 192.168.0.1 in this example case, since it should reflect the requestor
> IP address, which is unknown in this case.
IMHO, you are mostly right, but, according to this, if it's ambiguous
then only, if there is the target IP or no target IP, so here 0.0.0.0
or 0.0.0.0...
Regards,
Jarek P.
Hello!
> Is there a reason that the target hardware address isn't the target
> hardware address?
It is bound only to the fact that linux uses protocol address
of the machine, which responds. It would be highly confusing
(more than confusing :-)), if we used our protocol address and hardware
address of requestor.
But if you use zero protocol address as source, you really can use
any hw address.
> The dhcp clients I examined, and the implementation of the arpcheck
> that I use will compare the target hardware field of the arp-reply and
> match it against its own mac, to verify the reply. And this fails with
> the current implementation in the kernel.
1. Do not do this. Mainly, because you already know that this does not work
with linux. :-) Logically, target hw address in arp reply is just
a nonsensial redundancy, it should not be checked and even looked at.
2. What's about your suggestion, I thought about this and I am going to agree.
Arguments, which convinced me are:
- arping still works.
- any piece of reasonable software should work.
- if Windows understands DaD (is it really true? I cannot believe)
and it is unhappy about our responce and does not block use
of duplicate address only due to this, we _must_ accomodate ASAP.
- if we do,we have to use 0 protocol address, no choice.
Alexey
On Mon, 19 Nov 2007, Alexey Kuznetsov wrote:
> Hello!
>
> > Is there a reason that the target hardware address isn't the target
> > hardware address?
>
> It is bound only to the fact that linux uses protocol address
> of the machine, which responds. It would be highly confusing
> (more than confusing :-)), if we used our protocol address and hardware
> address of requestor.
>
> But if you use zero protocol address as source, you really can use
> any hw address.
>
> > The dhcp clients I examined, and the implementation of the arpcheck
> > that I use will compare the target hardware field of the arp-reply and
> > match it against its own mac, to verify the reply. And this fails with
> > the current implementation in the kernel.
>
> 1. Do not do this. Mainly, because you already know that this does not work
> with linux. :-) Logically, target hw address in arp reply is just
> a nonsensial redundancy, it should not be checked and even looked at.
Repeating what I posted earlier from the ARP RFC 826:
"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. In some implementations (which do not get to look
at the 14.byte ethernet header, for example) this may save some
register shuffling or stack space by sending this field to the
hardware driver as the hardware destination address of the
packet.
Unless there is some other RFC that supercedes this, which doesn't appear
to be the case since it's also STD37, it appears to me that the current
Linux behavior is wrong. It clearly states that for the ARP reply, the
target hardware address is "the address of the machine making the request",
and not the address of the machine making the reply as Linux is apparently
doing.
> 2. What's about your suggestion, I thought about this and I am going to agree.
>
> Arguments, which convinced me are:
>
> - arping still works.
> - any piece of reasonable software should work.
> - if Windows understands DaD (is it really true? I cannot believe)
> and it is unhappy about our responce and does not block use
> of duplicate address only due to this, we _must_ accomodate ASAP.
> - if we do,we have to use 0 protocol address, no choice.
I agree the target protocol address should be 0 in this case.
-Bill
From: Bill Fink <[email protected]>
Date: Tue, 20 Nov 2007 00:16:07 -0500
> On Mon, 19 Nov 2007, Alexey Kuznetsov wrote:
>
> > 2. What's about your suggestion, I thought about this and I am going to agree.
> >
> > Arguments, which convinced me are:
> >
> > - arping still works.
> > - any piece of reasonable software should work.
> > - if Windows understands DaD (is it really true? I cannot believe)
> > and it is unhappy about our responce and does not block use
> > of duplicate address only due to this, we _must_ accomodate ASAP.
> > - if we do,we have to use 0 protocol address, no choice.
>
> I agree the target protocol address should be 0 in this case.
Patches, someone :-)