Busybox udhcpc | Renew the APs IP TIMEOUT when connected to new router

I have connected an AP to the router Ethernet port. Following are the logs produced from the router in which dnsmasq is running. :

 Thu Jun  1 05:33:42 IST 2017 dnsmasq-dhcp[8068]: DHCPREQUEST(brlan1) 192.168.106.190 4a:57:86:13:74:af 
 Thu Jun  1 05:33:42 IST 2017 dnsmasq-dhcp[8068]: DHCPNAK(brlan1) 192.168.106.190 4a:57:86:13:74:af wrong network
 Thu Jun  1 05:33:51 IST 2017 dnsmasq-dhcp[8068]: DHCPREQUEST(brlan1) 192.168.106.190 4a:57:86:13:74:af 
 Thu Jun  1 05:33:51 IST 2017 dnsmasq-dhcp[8068]: DHCPNAK(brlan1) 192.168.106.190 4a:57:86:13:74:af wrong network
 Thu Jun  1 05:33:56 IST 2017 dnsmasq-dhcp[8068]: DHCPREQUEST(brlan1) 192.168.106.190 4a:57:86:13:74:af 
 Thu Jun  1 05:33:56 IST 2017 dnsmasq-dhcp[8068]: DHCPNAK(brlan1) 192.168.106.190 4a:57:86:13:74:af wrong network
 Thu Jun  1 05:33:59 IST 2017 dnsmasq-dhcp[8068]: DHCPREQUEST(brlan1) 192.168.106.190 4a:57:86:13:74:af 
 Thu Jun  1 05:33:59 IST 2017 dnsmasq-dhcp[8068]: DHCPNAK(brlan1) 192.168.106.190 4a:57:86:13:74:af wrong network
 Thu Jun  1 05:34:00 IST 2017 dnsmasq-dhcp[8068]: DHCPREQUEST(brlan1) 192.168.106.190 4a:57:86:13:74:af 
 Thu Jun  1 05:34:00 IST 2017 dnsmasq-dhcp[8068]: DHCPNAK(brlan1) 192.168.106.190 4a:57:86:13:74:af wrong network
 Thu Jun  1 05:34:03 IST 2017 dnsmasq-dhcp[8068]: DHCPDISCOVER(brlan1) 192.168.106.190 4a:57:86:13:74:af 
 Thu Jun  1 05:34:03 IST 2017 dnsmasq-dhcp[8068]: DHCPOFFER(brlan1) 192.168.0.8 4a:57:86:13:74:af 
 Thu Jun  1 05:34:03 IST 2017 dnsmasq-dhcp[8068]: DHCPREQUEST(brlan1) 192.168.0.8 4a:57:86:13:74:af 
 Thu Jun  1 05:34:03 IST 2017 dnsmasq-dhcp[8068]: DHCPACK(brlan1) 192.168.0.8 4a:57:86:13:74:af

I can see that the router didn't receive DHCPDISCOVER packet from the client for a period of time even though the server sends DHCPNAK multiple times.

Later I have checked the busybox dhcpc.c file code. And I found that,

                /* We might be either on the same network
                  * (in which case renew might work),
                  * or we might be on a completely different one
                  * (in which case renew won't ever succeed).
                  * For the second case, must make sure timeout
                  * is not too big, or else we can send
                  * futile renew requests for hours.
                  * (Ab)use -A TIMEOUT value (usually 20 sec)
                  * as a cap on the timeout.
                  */

I would like to know the reason behind why the AP (in which udhcpc is running) won't able to send DHCPDISCOVER until the TIMEOUT happens when it is connected to a complete new network.

When I rebooted the AP, the router able to get DHCPDISCOVER as soon as it sends DHCPNAK.

A 20 second timeout looks reasonable and is very common for most devices I have seen.

Thanks @mbo2o. What might be the consequences if I change the timeout to 0?

A spike in requests while the router is trying to setup/respond to the initial request.
You need to allow a reasonable time for a response.

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.