# DHCP failing on some Belkin Routers. **URL:** \ **Category:** Rabbit\ **Tags:** belkin, rabbit, dhcp\ **Created:** [July 11, 2016, 3:59pm UTC](https://forums.digi.com/t/dhcp-failing-on-some-belkin-routers/17069 "2016-07-11T15:59:14Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![ravenb72](https://avatars.discourse-cdn.com/v4/letter/r/e47774/32.png) [@ravenb72](https://forums.digi.com/u/ravenb72)\ **Post date:** [July 11, 2016, 3:59pm UTC](https://forums.digi.com/t/dhcp-failing-on-some-belkin-routers/17069/1 "2016-07-11T15:59:14Z")
We have had a product out for several years and not had any issues with DHCP. After doing a recent firmware update we had reports of units not initializing on Belkin routers. I confirmed the problem using DC 10.72A, RCM5760 module and a Belkin N300 (F9K1002V5). It works on a slightly older Belkin N150 (F91009V2). The sample program dhcp.c shipped with DC also fails, output below: ========= DHCP.C ========= Enter the following keystrokes: 0-9 toggle specified interface up/down p ping a host P ping the same host again w do a HTTP HEAD request to specified host W HTTP HEAD from the same host again t print the interface, router, ARP and DNS server tables r add a router entry R delete a router entry n add a nameserver (DNS) entry N delete a nameserver entry f flush an ARP table entry i set new IP address and netmask Interface 0 is qualified for DHCP. Starting network (DHCP timeout 8 seconds)… Done sock\_init() opt\_callback: got option 15, length 7 on i/f 0 opt\_callback: got option 0, length 128 on i/f 0 Interface # 0 is now UP Network Parameters: My IP Address = 0A0A0602 Netmask = FFFFFF00 DHCP fell back to defaults Interface table: # IP addr. Mask Up Lnk Type MTU Flags Peer/router * * * 0 10.10.6.2 255.255.255.0 yes yes eth 1500 \*D 10.0.0.1 Router table: # Flags Address i/f Net/preference Mask/exp(sec) * * * 0 D 10.0.0.1 0 0 0 ARP cache: # v i ip eth ru flags * * * 0 1 0 10.0.0.1 00:00:00:00:00:00 0 Query GW Hop Nameserver list: IP: 0A000001 flags: 0120 = = = = = = = = = = = = = = = This doesn’t fail when DC 10.64 is used. Does anyone have any insight into this issue? I’d rather not revert back to 10.64. I am wondering if Belkin have changed something on their side? ---
**Author:** ![TomCollins](https://sea2.discourse-cdn.com/flex016/user_avatar/forums.digi.com/tomcollins/32/37_2.png) [@TomCollins](https://forums.digi.com/u/TomCollins)\ **Post date:** [July 11, 2016, 6:58pm UTC](https://forums.digi.com/t/dhcp-failing-on-some-belkin-routers/17069/2 "2016-07-11T18:58:26Z")
Can you run that sample again, with BOOTP\_VERBOSE defined for both DC 10.64 and DC 10.72A? There were lots of changes to BOOTP.LIB between those two releases, and it’s possible one of them introduced a bug that the Netgear firmware’s DHCP server triggers. You might also want to use Wireshark to capture the packets. Add your information to this post and I’ll look into it. If necessary, you can report the issue to Digi tech support for further investigation. ---
**Author:** ![ravenb72](https://avatars.discourse-cdn.com/v4/letter/r/e47774/32.png) [@ravenb72](https://forums.digi.com/u/ravenb72)\ **Post date:** [July 12, 2016, 8:10am UTC](https://forums.digi.com/t/dhcp-failing-on-some-belkin-routers/17069/3 "2016-07-12T08:10:51Z")
Thanks Tom, here is the output using 10.64 and then 10.72A. I hope this sheds a bit more light on the issue.I had to break this into two posts because of the length. * * * DC10.64 - Belkin N300, BOOTP\_VERBOSE ========= DHCP.C ========= Enter the following keystrokes: 0-9 toggle specified interface up/down p ping a host P ping the same host again w do a HTTP HEAD request to specified host W HTTP HEAD from the same host again t print the interface, router, ARP and DNS server tables r add a router entry R delete a router entry n add a nameserver (DNS) entry N delete a nameserver entry f flush an ARP table entry i set new IP address and netmask Interface 0 is qualified for DHCP. Starting network (DHCP timeout 8 seconds)… Done sock\_init() DHCP: Sending DISCOVER request on i/f 0 DHCP: incoming on i/f 0 DHCP: offered 0A000029 DHCP: Sending REQUEST on i/f 0 DHCP: incoming on i/f 0 DHCP: Setting results for i/f 0… lease=4294967295 sec IP=0A000029 mask=FFFFFF00 Interface # 0 is now UP Network Parameters: My IP Address = 0A000029 Netmask = FFFFFF00 DHCP OK. Permanent lease DHCP server = 0A000001 Boot server = 0A000001 Routers: 0A000001 DNS servers: 0A000001 Timezone (fallback only) = 0h Interface table: # IP addr. Mask Up Type MTU Flags Peer/router * * * 0 10.0.0.41 255.255.255.0 yes eth 1500 \*DD 10.10.6.1 Router table: # Flags Address i/f Net/preference Mask/exp(sec) * * * 0 P 10.10.6.1 0 0.0.0.0 0.0.0.0 1 D 10.0.0.1 0 0 0 ARP cache: # v i ip eth ru flags * * * 0 1 0 10.10.6.1 00:00:00:00:00:00 0 GW 1 2 0 10.0.0.1 00:00:00:00:00:00 0 GW Nameserver list: IP: 0A000001 flags: 0120 IP: 0A0A0601 flags: 0102 = = = = = = = = = = = = = = = ---
**Author:** ![ravenb72](https://avatars.discourse-cdn.com/v4/letter/r/e47774/32.png) [@ravenb72](https://forums.digi.com/u/ravenb72)\ **Post date:** [July 12, 2016, 8:10am UTC](https://forums.digi.com/t/dhcp-failing-on-some-belkin-routers/17069/4 "2016-07-12T08:10:57Z")
DC10.72A - Belkin N300, BOOTP\_VERBOSE ========= DHCP.C ========= Enter the following keystrokes: 0-9 toggle specified interface up/down p ping a host P ping the same host again w do a HTTP HEAD request to specified host W HTTP HEAD from the same host again t print the interface, router, ARP and DNS server tables r add a router entry R delete a router entry n add a nameserver (DNS) entry N delete a nameserver entry f flush an ARP table entry i set new IP address and netmask Interface 0 is qualified for DHCP. Starting network (DHCP timeout 8 seconds)… Done sock\_init() DHCP: Sending DISCOVER request on i/f 0 DHCP: incoming on i/f 0 DHCP: offered 0A000029 DHCP: Sending REQUEST on i/f 0 DHCP: incoming on i/f 0 opt\_callback: got option 15, length 7 on i/f 0 opt\_callback: got option 0, length 128 on i/f 0 DHCP: Setting results for i/f 0… Lease is 4294967295 seconds IP=0A000029 mask=FFFFFF00 DHCP: time to renew i/f 0 DHCP: Sending RENEW request on i/f 0 DHCP: time to rebind i/f 0 DHCP: Sending REBIND request on i/f 0 DHCP: expired i/f 0 DHCP: Couldn’t renew/rebind lease on i/f 0 DHCP: ‘default’ state 103 tick on i/f 0 DHCP: Didn’t acquire lease on i/f 0 DHCP: Fallback to 0a0a0602 on i/f 0 Interface # 0 is now UP Network Parameters: My IP Address = 0A0A0602 Netmask = FFFFFF00 DHCP fell back to defaults Interface table: # IP addr. Mask Up Lnk Type MTU Flags Peer/router * * * 0 10.10.6.2 255.255.255.0 yes yes eth 1500 \*D 10.0.0.1 Router table: # Flags Address i/f Net/preference Mask/exp(sec) * * * 0 D 10.0.0.1 0 0 0 ARP cache: # v i ip eth ru flags * * * 0 1 0 10.0.0.1 00:00:00:00:00:00 0 Query GW Hop Nameserver list: IP: 0A000001 flags: 0120 = = = = = = = = = = = = = = = DHCP: driving state machine for i/f 0 DHCP: driving state machine for i/f 0 ---
**Author:** ![TomCollins](https://sea2.discourse-cdn.com/flex016/user_avatar/forums.digi.com/tomcollins/32/37_2.png) [@TomCollins](https://forums.digi.com/u/TomCollins)\ **Post date:** [July 13, 2016, 7:37pm UTC](https://forums.digi.com/t/dhcp-failing-on-some-belkin-routers/17069/5 "2016-07-13T19:37:37Z")
Looks like a bug related to permanent DHCP leases (0xFFFFFFFF) that originally appeared in 10.72 (10.70 should match behavior of what you saw in 10.64). Please give this a try. Go into BOOTP.LIB and change the conditionals in dhcp\_tick() that look at SEC\_TIMER: ```auto case DHCP_ST_BOUND: if ((_if_dhcp_lease & (1u << iface)) && (long)(SEC_TIMER - di->t1) > 0) ... case DHCP_ST_RENEW: if ((_if_dhcp_lease & (1u << iface)) && (long)(SEC_TIMER - di->t2) > 0) ... case DHCP_ST_REBIND: if ((_if_dhcp_lease & (1u << iface)) && (long)(SEC_TIMER - di->lease) > 0) ``` ---
**Author:** ![TomCollins](https://sea2.discourse-cdn.com/flex016/user_avatar/forums.digi.com/tomcollins/32/37_2.png) [@TomCollins](https://forums.digi.com/u/TomCollins)\ **Post date:** [July 14, 2016, 3:39pm UTC](https://forums.digi.com/t/dhcp-failing-on-some-belkin-routers/17069/6 "2016-07-14T15:39:01Z")
I did some local testing and it’s looking good. Update pushed to GitHub ([https://github.com/digidotcom/DCRabbit\_10/commit/9c6030e31e711371c6f9e049e86e6ed069e1799c](https://github.com/digidotcom/DCRabbit_10/commit/9c6030e31e711371c6f9e049e86e6ed069e1799c)) and you can pull the updated BOOTP.LIB from here: [https://raw.githubusercontent.com/digidotcom/DCRabbit\_10/9c6030e31e711371c6f9e049e86e6ed069e1799c/Lib/Rabbit4000/tcpip/BOOTP.LIB](https://raw.githubusercontent.com/digidotcom/DCRabbit_10/9c6030e31e711371c6f9e049e86e6ed069e1799c/Lib/Rabbit4000/tcpip/BOOTP.LIB) ---
**Author:** ![ravenb72](https://avatars.discourse-cdn.com/v4/letter/r/e47774/32.png) [@ravenb72](https://forums.digi.com/u/ravenb72)\ **Post date:** [July 15, 2016, 8:30am UTC](https://forums.digi.com/t/dhcp-failing-on-some-belkin-routers/17069/7 "2016-07-15T08:30:57Z")
Thanks Tom, Yes this did seem to do the trick. Seems a little strange that this hadn’t been discovered before now? I am reasonably sure that I had to go all the way back to 10.64 to find a version that would work with the Belkins.