dhcp_fine_tmr() was called every 10ms, but lwIP expects it to be
called every DHCP_FINE_TIMER_MSECS (500ms).
Since the fine timer ticks are currently 50 times faster than lwIP
expects, the client burns through the bounded exponential backoff
sequence for the DHCPREQUEST messages in 2.44 seconds rather than 122
seconds, after which it uses a new xid and returns to sending
DHCPDISCOVER messages. If there is enough latency in the server, the
client could receive an ACK response within DHCP_TIMEOUT_MS (10
seconds), but reject it because it has already moved on with another
xid after 2.44 seconds.
We have seen this occur with our boards. When our rack of 16 boards
get powered on together, they all request for an address from the
network switch's DHCP server in near lock-step and we see that only a
few of the boards actually obtain a lease. Fixing the timing to 500ms
allowed all of the boards to obtain a lease consistently.
Fixes: 98ad145db61a ("net: lwip: add DHCP support and dhcp commmand")
Signed-off-by: Luca Jones <[email protected]>
---
net/lwip/dhcp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/lwip/dhcp.c b/net/lwip/dhcp.c
index b798014ebcb..94a707756a2 100644
--- a/net/lwip/dhcp.c
+++ b/net/lwip/dhcp.c
@@ -25,7 +25,7 @@ static char boot_file_name[DHCP_BOOT_FILE_LEN];
static void call_lwip_dhcp_fine_tmr(void *ctx)
{
dhcp_fine_tmr();
- sys_timeout(10, call_lwip_dhcp_fine_tmr, NULL);
+ sys_timeout(DHCP_FINE_TIMER_MSECS, call_lwip_dhcp_fine_tmr, NULL);
}
static int dhcp_loop(struct udevice *udev)
--
2.53.0
