[Dnsmasq-discuss] Behavior on DHCP denied

[0zl]

On 4/19/23 08:37, Geert Stappers wrote:

> On Wed, Apr 19, 2023 at 03:16:37AM +0300, 0zl wrote:
>> On 4/18/23 22:51, Geert Stappers wrote:
>>> On Tue, Apr 18, 2023 at 08:24:17PM +0100, Simon Kelley wrote:
>>>> On 18/04/2023 16:35, 0zl wrote:
>>>>> Hello,
>>>>>
>>>>> This is an issue I've experienced
>>>>> with ESP8266 and proxy ARP on my WiFi network.
>>> Please confirm that it is proxy ARP
>>> as in https://en.wikipedia.org/wiki/Proxy_ARP
>> Yes this is proxy ARP in https://en.wikipedia.org/wiki/Proxy_ARP.
> Acknowlegde
>
>
>> HostAPd has an option called proxy_arp which setups up proxy_arp
>> with additional requirements to meet the Hotspot 2.0 standards. It
>> comes built in with a couple of snoopers, including a DHCP snooper to
>> configure proxy_arp without the need for additional software.
> Somehow I do read:
>    "I could make it complicated, so I made it complicated"
>
> The good thing, the thing I might regret,
> is that we have now this interesting problem ...
>   
>
>>>>> I was able to work around it by assigning the devices an
>>>>> infinite lease, however I think dnsmasq's behavior is undesirable.
>>>>>
>>>>> In short, ESP8266 is on a network with proxy ARP setup; getting the
>>>>> initial lease works fine, however once proxy ARP kicks in it fails to
>>>>> renew. This is the chain of events leading up to the issue:
>>>>>
>>>>>     * MCU tries to renew the address
>>>>>     * dnsmasq properly renews its address
>>>>>     * MCU sends an ARP request to check if the address is in use and
>>>>>       receives an ARP reply from the router because of proxy ARP
>>>>>     * MCU mistakenly believes that the address was assigned already even
>>>>>       though it was not, sends a DENIED message back to dnsmasq and tries
>>>>>       again
>>>>>     * dnsmasq then allocates the exact same address that the MCU just rejected
>>>>>
>>>>> I think in this scenario, dnsmasq should try to allocate a different
>>>>> address because MCU has rejected it already.
>>>>>
>>>>> Not sure what people in this mailing list think, but it feels like
>>>>> dnsmasq shouldn't be doing this.
>>>> This situation was considered and there should be sensible behaviour.
>>>>
>>>> Dnsmasq uses a hash of the MAC address to determine which the address to
>>>> offer to the client, which would cause the same address always to be offered
>>>> to the client. But if a client returns a DHCPDECLINE reply then a global
>>>> variable is incremented. That variable is also used as an input to the hash
>>>> function, so when the client asks again for an address it should get offered
>>>> a different one.
>>>>
>>>> So, this situation has been considered, but something is going wrong in your
>>>> setup. Please could you post more details of the configuration you are using
>>>> and logs of what happens so we can try and work out what is going wrong?
>>> Yes, interesting problem.
>>> I do hope there will be libpcap files.
>>>
>> I've attached a pcap file,
> See it.
>
>
>> if you need any more logs or information please let me know.
> Simon already did:
>
>>>> Please could you
>>>> post more details of the configuration you are using and logs of
>>>> what happens so we can try and work out what is going wrong?
>> Only thing I've changed for this capture is setting the lease
>> time to 2m in order to make it faster for me to capture this for you,
>> in normal operation it was set to 8hours.
> Have that visible in the configuration file.
>   
>
>> Note that the capture includes a ARP probe from the ESP
> Which package number (which package numbers) in the .pcap
> are we talking about?  If it are 6 and 7, say so.
>
>
>> and no response,
>> just keep in mind that the WiFi router does in fact respond to it, it just
>> doesn't do so over that bridge port so it didn't get captured on the
>> gateway's end.
>   "that bridge port"???
>
>
> Regards
> Geert Stappers
> Looking forward to the further information
> for Subject: Re: [Dnsmasq-discuss] Behavior on DHCP denied

Hi,

Regarding the packages numbers in the .pcap. Buck wrote a really good 
response which explains what I was talking about in depth. So I don't 
think there is a need to respond to it. As for my config file, I'll 
share it here:

domain-needed
bogus-priv

no-resolv
server=127.0.0.1#40

local=/rlan.eu.org/
domain=rlan.eu.org
dhcp-fqdn

address=/use-application-dns.net/
address=/wpad.rlan.eu.org/

interface=br-lan

dhcp-authoritative
dhcp-rapid-commit

dhcp-option=42,0.0.0.0
dhcp-range=10.146.97.0,10.146.98.255,8h

I didn't mention it in the previous emails, but the first thing I tried 
was remove dhcp-authoritative anddhcp-rapid-commit but that did not 
help. The capture I sent used that config, but with 2m set instead of 8h 
as lease time.