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

[Radouch, Zdenek]

Well, as far as seeing something else, I, too, can see something else when I 
configure my network
differently with respect to where the DHCP server is, and I, too, can see 
things working.
But in my current configuration (which happens to be our corporate network with 
hundreds of different
machines connecting correctly all the time) the lwIP stack does not work.
A workaround that ignores the failure, or one that avoids a failure by not 
checking is not exactly a solution
(I know, you said dirty), so I need to find and fix the problem -- we can't 
afford deploying an embedded
product with something so blatantly broken.

The sequence I see looks like this:

"No.","Time","Source","Destination","Protocol","Length","Info"
"390","0.814720","0.0.0.0","255.255.255.255","DHCP","395","DHCP Discover - 
Transaction ID 0x5542a27"
"409","0.854480","172.16.16.7","255.255.255.255","DHCP","392","DHCP Offer    - 
Transaction ID 0x5542a27"
"424","0.896977","0.0.0.0","255.255.255.255","DHCP","395","DHCP Request  - 
Transaction ID 0x169c39e2"
"433","0.907728","172.16.16.7","255.255.255.255","DHCP","392","DHCP ACK      - 
Transaction ID 0x169c39e2"
"443","0.930603","6c:ad:f8:e5:27:fe","Broadcast","ARP","87","Who has 
172.16.20.182?  Tell 0.0.0.0"
"447","0.932726","6c:ad:f8:e5:27:fe","6c:ad:f8:e5:27:fe","ARP","102","172.16.20.182
 is at 6c:ad:f8:e5:27:fe"
"459","0.956479","0.0.0.0","255.255.255.255","DHCP","395","DHCP Decline  - 
Transaction ID 0x2eab4956"

All is well until packet #447 -- the address has not been validated yet, the 
DHCP machine is still in
the DHCP_CHECKING state, so there should not be an ARP entry for the still 
invalid IP address (172.16.20.182).
I have stepped through enough code to understand the rejection: it happens in 
dhcp.c(960)
in dhcp_arp_reply(). Unfortunately I don't understand the ARP code, and I don't 
understand how it
interacts with the DHCP client, hence my looking for someone who knows the lwIP 
ARP design.

That is, I am looking for someone who could tell me what the lwIP ARP is 
expected to do in this exact
situation (DHCP ack while IP=0) and how exactly is the new IP address handed 
from the DHCP client
to the rest of the stack (including the ARP module).

-Z

________________________________________
From: address@hidden address@hidden on behalf of Sergio R. Caprile 
address@hidden
Sent: Wednesday, May 14, 2014 2:10 PM
To: address@hidden
Subject: Re: [lwip-users] broken DHCP/ARP interaction

Hi,
Quick&dirty workaround: disable ARP checking by defining
DHCP_DOES_ARP_CHECK to 0

Analysis:
I'm no expert in DHCP nor ARP, but I don't see anything similar to what
you are experiencing.
I've setup three scenarios:
1- different IP (static) prior to DHCP
2- same IP (static) prior to DHCP
3- 0.0.0.0
In scenarios 1 and 3, everything works "as expected"
In scenario 2, I see a "gratuitous ARP", but the address is accepted
anyway. Here is my capture:

No.     Time           Source                Destination
Protocol Length Info
      1 0.000000000    192.168.1.42          255.255.255.255
DHCP     350    DHCP Discover - Transaction ID 0xabcd0001

      2 0.001705000    192.168.1.1           192.168.1.42
DHCP     342    DHCP Offer    - Transaction ID 0xabcd0001

      3 0.002564000    192.168.1.42          255.255.255.255
DHCP     350    DHCP Request  - Transaction ID 0xabcd0002

      4 0.040420000    192.168.1.1           192.168.1.42
DHCP     342    DHCP ACK      - Transaction ID 0xabcd0002

      5 0.040841000    3com_03:04:05         Broadcast
ARP      60     Gratuitous ARP for 192.168.1.42 (Request)

Frame 5: 60 bytes on wire (480 bits), 60 bytes captured (480 bits) on
interface 0
Ethernet II, Src: 3com_03:04:05 (00:01:02:03:04:05), Dst: Broadcast
(ff:ff:ff:ff:ff:ff)
Address Resolution Protocol (request/gratuitous ARP)
    Hardware type: Ethernet (1)
    Protocol type: IP (0x0800)
    Hardware size: 6
    Protocol size: 4
    Opcode: request (1)
    [Is gratuitous: True]
    Sender MAC address: 3com_03:04:05 (00:01:02:03:04:05)
    Sender IP address: 192.168.1.42 (192.168.1.42)
    Target MAC address: 00:00:00_00:00:00 (00:00:00:00:00:00)
    Target IP address: 192.168.1.42 (192.168.1.42)

      6 0.499760000    3com_03:04:05         Broadcast
ARP      60     Gratuitous ARP for 192.168.1.42 (Request)


I suggest you check your options and step the code to see where this
rejection takes place

--

_______________________________________________
lwip-users mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/lwip-users