[Dnsmasq-discuss] ARP ignores DHCP ACKs !

Simon Kelley simon at thekelleys.org.uk
Wed Dec 25 09:46:15 GMT 2013


On 24/12/13 21:48, Nikita N. wrote:
> yes Jim, ipv6 is enabled on my win7, but it doesnt seem to bother.. ipv6
> frames just fly away ignored, nobody cares I guess.. ;)
>
> Wanted to ask to Simon about those ICMP frames you are talking about..
> are they "mandatory", I mean they "must" receive an answer for the
> connection to stay alive, or they can just be dropped?
>

I slightly mislead you about those. They are ARP requests, not ICMP echo 
requests, and the point is that they should NOT be answered. Before the 
client REQUESTS the address and starts to use it, it sends an ARP 
request: if something else on the net answers, then the address is 
already in use, and the client sends a DHCPDECLINE. That causes the 
server to make the address unusable and then send the client a different 
one.

Both the client and the server can do "address in use" tests. The server 
uses ICMP echo requests because it has an IP address and the test must 
be routeable. The client uses ARP because it doesn't at that point have 
an IP address, and the test only needs to work on the local net.

The important point for your situation is that it's perfectly normal to 
see a DHCP client make an ARP request as part of the address-aquisition 
process, and for that ARP request to go un-answered.

Cheers,

Simon.


> I made few tests about ICMP frames, they appear from client to GW as
> soon as a DNS query is answered, at least in XP and Vista looks so..
> As soon as dnsmasq DNS answers "www.test.com is at xxx.xxx.xxx.xxx",
> client sends a ICMP to GW (host unreach,port unreach), I can see them
> either in the traces from GW and from client as well..
> So I did that test: I instructed the GW to drop all ICMP frames incoming
> and outcoming (ipfilter on GW interface) .
> As result, connection stays alive anyway in XP and Vista, no matter
> client ICMP dont get any answer back..
> Is that normal behavior? if yes, Im going to keep that ICMP drop filter,
> so to get rid of all those useless frames.. :P
>
> About Win7, I cant see any ICMP, nor in or out.. I cant get anyway to
> see any DNS req either from client ..
> That is most strange, isnt it?
>
> Im keeping testing..
>
> On Tue, Dec 24, 2013, at 11:22 AM, Simon Kelley wrote:
>> On 24/12/13 12:35, Nikita N. wrote:
>>> Hi :) Im having a strange issue here with DHCP/ARP I cant solve..
>>> DHCP works good, it receives a REQ from client MAC asking the preferred
>>> ip, e.g. 192.168.0.10, and DHCP answers correctly ACK..
>>> But after that, my client keeps asking the following ARP requests to
>>> broadcast: "Who has 192.168.0.10? Tell 0.0.0.0" .. it expects the answer
>>> like "192.168.0.10 is at XX.XX.XX.XX.XX", where XX is the client MAC..
>>> but it never comes :(
>>
>> Are you sure about the order of these events? Most DHCP clients will
>> check that the address they've been offered is not in use by anonther
>> machine before accepting it, and they do that by sending ICMP echo
>> requests. To send the echo request, the client's kernel will need to
>> send ARP requests and that probably what you are seeing.
>>
>> I'd expect to see the client sending these ARPs _afer_ the DHCPOFFER and
>> before the DHCPREQUEST.
>>
>>
>> Cheers,
>>
>> Simon.
>>
>>> those ARP frames are generated by the client (source=XX) and never
>>> receive any answer..
>>> on the opposite, when the client sends ARPs requesting the GW (Who has
>>> 192.168.0.1?) the ARP responses come correctly pointing to the correct
>>> GW MAC..
>>> It looks like dnsmasq does NOT inform the system ARP about the client ip
>>> it just ACKed, resulting always in connection error/absent ..
>>>
>>> So, my question is, how can I instruct dnsmasq to inform the system ARP
>>> with the new client MAC/ip, after DHCP sent correctly the ACK?
>>> Thanks :)
>>>
>>
>>
>> _______________________________________________
>> Dnsmasq-discuss mailing list
>> Dnsmasq-discuss at lists.thekelleys.org.uk
>> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
>




More information about the Dnsmasq-discuss mailing list