[Dnsmasq-discuss] Behavior on DHCP denied

[Geert Stappers]

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
-- 
Silence is hard to parse