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.
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. Fun stuff... regards, Ben ------------------------------------------------------------------------- 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
