Re: [PATCH] net/ipv4/arp.c: Fix arp reply when sender ip 0 (was: Strange behavior in arp probe reply, bug or feature?)
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 - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] net/ipv4/arp.c: Fix arp reply when sender ip 0 (was: Strange behavior in arp probe reply, bug or feature?)
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 - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] net/ipv4/arp.c: Fix arp reply when sender ip 0
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 :-) - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] net/ipv4/arp.c: Fix arp reply when sender ip 0
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. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] net/ipv4/arp.c: Fix arp reply when sender ip 0
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 - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] net/ipv4/arp.c: Fix arp reply when sender ip 0
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. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] net/ipv4/arp.c: Fix arp reply when sender ip 0
DM == David Miller [EMAIL PROTECTED] writes: 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 DM And this is exactly a sensible response in my opinion. Why send the reply at all? Sending a unicast packet with yourself as destination MAC seems a bit useless. Do switches propagate it? /Benny - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] net/ipv4/arp.c: Fix arp reply when sender ip 0
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 - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] net/ipv4/arp.c: Fix arp reply when sender ip 0 (was: Strange behavior in arp probe reply, bug or feature?)
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 - 1.22 +++ arp.c 15 Nov 2007 10:34:44 - @@ -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; } - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] net/ipv4/arp.c: Fix arp reply when sender ip 0 (was: Strange behavior in arp probe reply, bug or feature?)
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 - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] net/ipv4/arp.c: Fix arp reply when sender ip 0 (was: Strange behavior in arp probe reply, bug or feature?)
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 - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] net/ipv4/arp.c: Fix arp reply when sender ip 0
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. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
