Home/Support/Support Forum/DHCP failing on some Belkin Routers.
Welcome to Digi Forum, where you can ask questions and receive answers from other members of the community.

DHCP failing on some Belkin Routers.

0 votes
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?
asked Jul 11, 2016 in Rabbit by ravenb72 New to the Community (1 point)
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.
commented Jul 11, 2016 by TomCollins Veteran of the Digi Community (2,311 points)
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

= = = = = = = = = = = = = = =
commented Jul 12, 2016 by ravenb72 New to the Community (1 point)
moved Jul 12, 2016 by ravenb72
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
commented Jul 12, 2016 by ravenb72 New to the Community (1 point)
moved Jul 12, 2016 by ravenb72

Please log in or register to answer this question.

1 Answer

0 votes
 
Best answer
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:
Code:
	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)
answered Jul 13, 2016 by TomCollins Veteran of the Digi Community (2,311 points)
selected Jul 14, 2016 by ravenb72
I did some local testing and it's looking good.  Update pushed to GitHub (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
commented Jul 14, 2016 by TomCollins Veteran of the Digi Community (2,311 points)
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.
commented Jul 15, 2016 by ravenb72 New to the Community (1 point)
...