At long last, I understand the problem. The lesson I learned is that you can't trust the packet ether addresses -- they were being faked by the Cisco hardware (sending a packet with someone else's source address). The problem itself is a case of a poorly designed ARP proxy/optimization within the Cisco enterprise AP software.
The problematic sequence is as follows: [here the AP/DHCP is a Cisco enterprise AP network, the device is a WiFi module running lwIP] 0. A device associates with a WiFi network (SSID) 1. The device requests IP address from a DHCP server 2. The DHCP server sends an IP address to the device 3. The device attempts to validate the IP address by sending out "ARP who has" for the IP address offered by the DHCP server. This is the standard gratuitous ARP request to ensure that there is no device with the same IP address; no reply is expected. 4. The Cisco AP to which the WiFi device is connected sends (wrongly) an ARP response (for the offered IP address) to the WiFi device! Note that at this point in time, the IP address has not yet been assigned to any interface, so it is an error for the AP to proxy ARP. Furthermore, it is wrong to send a proxy reply to the very device on behalf of which the proxy is sent. 5. The device sees an [unexpected] ARP reply (with what should be its IP address), and consequently rejects the IP address. Note that the lwIP DHCP code does not notice that the ARP response contains its own MAC address in all fields; it simply acts on it. It is not clear to me exactly how the Cisco AP ARP proxy module learns about the IP address, but it is clear that it uses a wrong algorithm. As is, the Cisco algorithm produces an ARP [proxy] reply before and without knowing that the address has actually been assigned. That is, it is not caching responses, it is synthesizing responses before any real device did (or could) send them. Instead, it should simply cache ARP responses; this would have guaranteed that at least on the assignment the proxy replies were valid. Regarding the lwIP code, it could be more defensive. The "bad" ARP packet that causes the DHCP rejection has all four MAC addresses (ether src, ether dest, sender hardware, target hardware) the same, equal to the MAC address of the device itself. I would think such packet should be discarded. To conclude, no, the DHCP/ARP lwIP code is not broken per se, but it will not work when deployed against the Cisco Aironet Enterprise AP solution. -Z > -----Original Message----- > From: lwip-users-bounces+zradouch=irobot....@nongnu.org [mailto:lwip- > users-bounces+zradouch=irobot....@nongnu.org] On Behalf Of Simon > Goldschmidt > Sent: Thursday, May 15, 2014 2:04 AM > To: Mailing list for lwIP users > Subject: Re: [lwip-users] broken DHCP/ARP interaction > > "Radouch, Zdenek" wrote: > > However, in this case the ARP does something that is outright wrong - > - > > it answers an ARP query for an IP address that has not been assigned > > yet -- the DHCP client is still trying to ensure that it is OK to use > > the address (hence the ARP query). So the behavior is completely > broken with respect to temporal dependencies. > > I can't reproduce this, but I do think it would be a bug. However, > Sergio is right in that you should take cautions to not receive (loop- > back) self-sent packets. While it might not break things like you see > (it does not, for me), it can lead to other anomalties like receiving > your own broadcast on broadcast sockets or seeing a reply to a > Gratuitizs ARP you send (so IPv4 AutoIP and IPv6 address selection > won't work). > > Simon > > _______________________________________________ > lwip-users mailing list > lwip-users@nongnu.org > https://lists.nongnu.org/mailman/listinfo/lwip-users _______________________________________________ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users