[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Radouch, Zdenek
Subject: Re: [lwip-users] broken DHCP/ARP interaction
Date: Wed, 14 May 2014 20:27:42 +0000

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:

"390","0.814720","","","DHCP","395","DHCP Discover - 
Transaction ID 0x5542a27"
"409","0.854480","","","DHCP","392","DHCP Offer    - 
Transaction ID 0x5542a27"
"424","0.896977","","","DHCP","395","DHCP Request  - 
Transaction ID 0x169c39e2"
"433","0.907728","","","DHCP","392","DHCP ACK      - 
Transaction ID 0x169c39e2"
"443","0.930603","6c:ad:f8:e5:27:fe","Broadcast","ARP","87","Who has  Tell"
 is at 6c:ad:f8:e5:27:fe"
"459","0.956479","","","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 (
I have stepped through enough code to understand the rejection: it happens in 
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).


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

Quick&dirty workaround: disable ARP checking by defining

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
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
DHCP     350    DHCP Discover - Transaction ID 0xabcd0001

      2 0.001705000 
DHCP     342    DHCP Offer    - Transaction ID 0xabcd0001

      3 0.002564000
DHCP     350    DHCP Request  - Transaction ID 0xabcd0002

      4 0.040420000 
DHCP     342    DHCP ACK      - Transaction ID 0xabcd0002

      5 0.040841000    3com_03:04:05         Broadcast
ARP      60     Gratuitous ARP for (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
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: (
    Target MAC address: 00:00:00_00:00:00 (00:00:00:00:00:00)
    Target IP address: (

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

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


lwip-users mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]