From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jerry Van Baren Date: Fri, 11 Jul 2008 15:15:14 -0400 Subject: [U-Boot-Users] PATCH for U-Boot 1.3.3 DHCP fails with netgear WGR614v6 In-Reply-To: <4877AEE0.6070802@gmail.com> References: <200807111217.03285.rgetz@blackfin.uclinux.org> <4877A499.8040202@gmail.com> <4877ABD6.5060800@ge.com> <4877AEE0.6070802@gmail.com> Message-ID: <4877B142.5090204@ge.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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