How can I reduce chattyness of udhcpc?

I keep getting the DHCP renewals for my router, every 3 minutes, since my ISP has configured the lease time too short ( 300 seconds ) ... so my syslog is full with:

Wed Jun 13 15:57:48 2018 daemon.notice netifd: wan (2933): udhcpc: sending renew to xxx.xxx.xxx.xxx
Wed Jun 13 15:57:48 2018 daemon.notice netifd: wan (2933): udhcpc: send: Network unreachable
Wed Jun 13 15:57:48 2018 daemon.notice netifd: wan (2933): udhcpc: sending renew to 0.0.0.0
Wed Jun 13 15:57:48 2018 daemon.notice netifd: wan (2933): udhcpc: lease of xxx.xxx.xxx.xxx obtained, lease time 300
Wed Jun 13 16:00:19 2018 daemon.notice netifd: wan (2933): udhcpc: sending renew to xxx.xxx.xxx.xxx
Wed Jun 13 16:00:19 2018 daemon.notice netifd: wan (2933): udhcpc: send: Network unreachable
Wed Jun 13 16:00:19 2018 daemon.notice netifd: wan (2933): udhcpc: sending renew to 0.0.0.0
Wed Jun 13 16:00:19 2018 daemon.notice netifd: wan (2933): udhcpc: lease of xxx.xxx.xxx.xxx obtained, lease time 300
Wed Jun 13 16:02:49 2018 daemon.notice netifd: wan (2933): udhcpc: sending renew to xxx.xxx.xxx.xxx
Wed Jun 13 16:02:49 2018 daemon.notice netifd: wan (2933): udhcpc: send: Network unreachable
Wed Jun 13 16:02:49 2018 daemon.notice netifd: wan (2933): udhcpc: sending renew to 0.0.0.0
Wed Jun 13 16:02:49 2018 daemon.notice netifd: wan (2933): udhcpc: lease of xxx.xxx.xxx.xxx obtained, lease time 300

I have 2 questions:
A) Can I get rid of this messages by some kind of verbosity settings in BusyBox ?
B) What does the "Sending renew to 0.0.0.0" means? Why my router is doing that ( is that a broadcast?)

Thanks in advance!

Using a different logger would allow you manage the logging yourself.

"notice" is just that, something important to notice

send: Network unreachable

suggests possible misconfiguration.

The way I read it, udpcpcd is trying to reach the DHCP server that supplied the lease (as expected), but is unable to so (unexpected). This might be due to firewall rules, your ISP configuring an IP address for their DHCP server that isn't routable, or something else. Since udhcpc can't renew the least "the way it is supposed to", it then falls back on requesting it from "any on-link DHCP server that is listening"

Thanks to @h8red see also, from June 6th/7th:

https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=e4259bed3f20f8f132555ae8aef379e3d2ffb938

This reverts a change made in Sep 2017 [1] which introduced
MSG_DONTROUTE flag to prevent udhcpc from reaching out to servers on a
different subnet. That change violates RFC2131 by forcing fully
configured clients, who got their configurations through an offer
relayed by a DHCP relay, from renewing through a unicast request
directly to the DHCP server, resulting in the client resorting to
boradcasting lease extension requests instead of unicasting them,
further breaking RFC2131.

The problem with MSG_DONTROUTE appears when talking to a properly
configured DHCP server that rejects non-compliant requests. Such server
will reject lease extension attempts sent via broadcast rather than
unicast, as is the case with Finnish ISPs Telia and DNA as well as
Estonian ISP Starman. [...]

@mariano.silva There are two issues here:

  • First, your ISP's lease time is 300 seconds, which means udhcpc will attempt to renew starting 180 seconds after the lease is granted. This is the correct behaviour and you cannot (nor should you) change that. udhcpc will inform you about these matters in the log.

  • Second, sending renewals to 0.0.0.0 is the same problem I've been having. More info on the reason and fix here https://github.com/openwrt/openwrt/pull/1017. If you upgrade to any version from e4259be or after, you'll hopefully have your problem fixed.

1 Like

That was it, fixed now! No more requests to 0.0.0.0 !

The 180 seconds was ok , of course.