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.
_______________________________________________
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
