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: [email protected] [[email protected]] on behalf of Sergio R. Caprile [[email protected]] Sent: Wednesday, May 14, 2014 2:10 PM To: [email protected] 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 [email protected] https://lists.nongnu.org/mailman/listinfo/lwip-users _______________________________________________ lwip-users mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/lwip-users
