Ben Warren wrote: > Jerry Van Baren wrote: >> Ben Warren wrote: >>> Robin Getz wrote: >>>> I was trying out U-Boot 1.1.3 with a new(er) router netgear WGR614v6 >>>> - firmware version V2.0.19_1.0.19NA, on a Blackfin BF537-STAMP. >>>> >>>> http://kbserver.netgear.com/products/wgr614v6.asp >>>> >>>> and found that dhcp fails :( >> >> More correctly, the *second* DHCP request fails. >> >>>> bfin> dhcp >>>> BOOTP broadcast 1 >>>> BOOTP broadcast 2 >>>> BOOTP broadcast 3 >>>> BOOTP broadcast 4 >>>> BOOTP broadcast 5 >>>> >>>> Retry count exceeded; starting again >>>> >>>> When turning on some more verbose debug messages (in the net driver >>>> & in the network code, not all of which exists in U-Boot release or >>>> trunk), we can see exactly what is going on... >>>> >>>> ============================= >> >> First DHCP request... >> >>>> bfin> dhcp >>>> Eth_halt: ...... >>>> Eth_init: ...... >>>> BOOTP broadcast 1 >>>> setting transaction ID to 3268fe22 >>>> BFIN EMAC send: length = 343 >>>> BFIN EMAC rx: length = 552 >>>> packet received >>>> packet received >>>> Receive from protocol 0x800 >>>> Got IP >>>> len=308, v=45 >>>> passing packet len= 280 >>>> DHCPHandler: got packet: (src=67, dst=68, len=280) state: 3 >>>> Filtering pkt = 0 >>>> DHCPHandler: got DHCP packet: (src=67, dst=68, len=280) state: 3 >>>> DHCP: state=SELECTING bp_file: "" >>>> TRANSITIONING TO REQUESTING STATE >>>> IP was: 0.0.0.0 >>>> IP now: 192.168.0.9 >> >> ...worked. >> >>>> Bootfile: >>>> DhcpSendRequestPkt: Sending DHCPREQUEST >> >> Why is the second DHCP request being sent? What is the second DHCP >> request asking for (sniff the net with wireshark). It should be >> asking for its current IP address (e.g. a renewal) if anything. >> > I think this is how it's supposed to work, but don't quote me... Client > starts in 'Discover' state, sending a broadcast looking for servers. > One or more servers respond with proposals. Client changes to 'Request' > state, and sends a request. Server then has the option of sending an > ARP to see if the IP address is already taken and eventually sends ACK > or NAK.
Yes, but that describes the *first* DHCP which *succeeded* (above). The target then initiates a second DHCP (presumably with the same MAC address and, I would presume/deduce with a lease renewal request rather than a "gimme a new IP" request) which the server(?) bungles. > But why the NAK in this case? The server should recognize that it > offered this IP address to the device with this MAC address. Maybe it > is a timing thing like somebody saw a while ago with a Windows DHCP server. Yes, Windows is my suspicion too, our emails probably crossed in the server. > Fun stuff... > > regards, > Ben Makes a slow day go faster. :-) gvb ------------------------------------------------------------------------- Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 _______________________________________________ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
