ESP-IDf-LWIP: Potentiall ARP-Checking BUG?

[tltltl]

Hey people

I have an issue where I can see, that the ESP does perform the DHCP negotiation perfectly fine, and afterwards sends a DHCP-Decline. Based on my investigation I'm pretty sure it happens because of the ARP-Checking the LWIP does afterwards. After it has successful negotiated an IP, it does an additional check if the IP is really free by sending an ARP-Request for the IP it wants to use. This is the behavior that is expected as per RFC 5227.

Sadly I couldn't test it with the following option disabled, as the network I have an issue with is a customers and I need to be there physically as I cannot reproduce with other WiFi's. I keep you updated when I know more regarding that option.

Code: Select all

CONFIG_LWIP_DHCP_DOES_ARP_CHECK=y 

Back to the problem: In Wireshark I see that the ESP does a ARP-Request after ACK'd DHCP. From the network somewhere the ESP gets an ARP-Response for the requested IP-address, meaning that IP is already "used". BUT the MAC-address inside the ARP-Response is the same as the MAC-address of the ESP. Meaning the ESP gets an ARP-Response for ITSELF.
When looking at the code is don't see any validation of MAC-address and the code just assumes, that we have an IP-conflict and discards the DHCP-IP with a decline.
https://github.com/espressif/esp-lwip/b ... hcp.c#L963


Which all leads me to the question:
Is this really how it should be or am I hitting a bug from LWIP? Shouldn't be there a validation which checks if the received ARP-reply is the MAC of itself - and if yes ignore that ARP-reply?

Thanks already and have a nice day!
Tltltl

[WiFive]

https://github.com/espressif/esp-idf/issues/2182