After upgrading to dhcpcd-6.6.7, I noticed that the --timeout parameter is not respected, breaking one of my monitoring scripts. It can be trivially demonstrated by setting a low value. I don't know when this regression was introduced but can confirm that 6.4.7 works as expected.
Here's a concrete demonstration of the issue, in a situation where no response is provided: lb1 dhcpcd # dhcpcd -LT -d eth0 -t 5 dhcpcd[3576]: version 6.6.7 starting dhcpcd[3576]: DUID 00:01:00:01:1b:ac:ad:5a:00:1b:21:cf:02:08 dhcpcd[3576]: eth0: IAID 21:cf:02:08 dhcpcd[3576]: eth0: delaying IPv4 for 0.2 seconds dhcpcd[3576]: eth0: soliciting a DHCP lease dhcpcd[3576]: eth0: sending DISCOVER (xid 0xbe6fd178), next in 3.3 seconds dhcpcd[3576]: eth0: invalid UDP packet from 10.0.2.8 dhcpcd[3576]: eth0: sending DISCOVER (xid 0xbe6fd178), next in 7.4 seconds dhcpcd[3576]: eth0: sending DISCOVER (xid 0xbe6fd178), next in 16.8 seconds dhcpcd[3576]: eth0: sending DISCOVER (xid 0xbe6fd178), next in 32.9 seconds dhcpcd[3576]: eth0: sending DISCOVER (xid 0xbe6fd178), next in 63.4 seconds ... and so it goes on. Further, if the -t parameter is omitted, it does *not* time out after 30 seconds as the man page implies.
This only happens when you specify the -T flag, for testing. Why are you using this flag? Fixed here anyway. http://roy.marples.name/projects/dhcpcd/ci/659219d5589d93715841a93eb91885cc4337b58b?sbs=0
Well, why not? The test mode is well implemented and I use the program as part of a DHCPD failover mechanism. I wait upon changes to the leases file via inotify in order to keep them in sync, with periodic breaks to test whether any other host is servicing DISCOVER requests. If so, any local instance of dhcpd is stopped, otherwise it is started. Such an approach does not work properly if the run time of the client is unpredictable. Whatever the use case may be, the timeout parameter is not documented as being context sensitive so it came as a surprise.
It's not supposed to be context sensitive, the issue will be fixed in the next dhcpcd release. Gentoo can decide if they want to fix it in an ebuild or not for the time being.
(In reply to Roy Marples from comment #4) > It's not supposed to be context sensitive, the issue will be fixed in the > next dhcpcd release. Gentoo can decide if they want to fix it in an ebuild > or not for the time being. Roger that. Thanks.
Fixed in 6.8.1, now in portage
