Re: [lwip-users] broken DHCP/ARP interaction

[Radouch, Zdenek]

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: address@hidden [mailto:lwip-
> address@hidden 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
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/lwip-users