FS#35668 - [netctl] 1.1-1 does not allow dhcpcd timeout to be set universally, causes wifi-menu to malfunction
Attached to Project:
Arch Linux
Opened by John Alber (rallyemax) - Thursday, 06 June 2013, 04:17 GMT
Last edited by Jouke Witteveen (jouke) - Saturday, 27 July 2013, 20:29 GMT
Opened by John Alber (rallyemax) - Thursday, 06 June 2013, 04:17 GMT
Last edited by Jouke Witteveen (jouke) - Saturday, 27 July 2013, 20:29 GMT
|
Details
Description:
Netctl does not allow dhcpcd lease negotiation timeout to be set universally (for all profiles), which causes wifi-menu to fail to establish a connection where the default timeout of 10 seconds is insufficient. It is possible to set the timeout manually in each profile, but this defeats the purpose of a tool like wifi-menu. For the combination of my netbook and access point, a timeout of 20 seconds has proven to be sufficient. For other APs, 10 seconds is sometimes enough. My server seems to be fine with 10 seconds on all APs I've tried. Many other users require timeouts in excess of 10 seconds, some up to 30. The need for variable timeouts would seem to necessitate a netctl-wide configuration option. Netctl's predecessor netcfg permitted dhcpcd options to be set in /etc/conf.d/netcfg, and these options applied to all network profiles. Any resolution should not be limited to setting the dhcpcd timeout. Sometimes other dhcpcd options are best set universally rather than in a profile-specific manner. The best result would be the ability to set any option dhcpcd itself accepts. Additional info: ---------------- netctl version: 1.1-1 log: A logfile showing the output of a failed connection attempt due to a dhcpcd lease negotiation timeout is attached. There is nothing special there, but it does confirm that the default timeout is 10 seconds. It takes 5 seconds for the router to offer an IP to the system, and another 5 seconds pass before the lease is finalized, thus triggering the timeout. 
log.txt
(2.9 KiB)
|
This task depends upon
Closed by Jouke Witteveen (jouke)
Saturday, 27 July 2013, 20:29 GMT
Reason for closing: Not a bug
Additional comments about closing: Hooks can be used. Some documentation improvements in 277b1.
Saturday, 27 July 2013, 20:29 GMT
Reason for closing: Not a bug
Additional comments about closing: Hooks can be used. Some documentation improvements in 277b1.
OT: you can set/override defaults in hook files, i.e. /etc/netctl/hooks/01-long-dhcp-timeout (be sure to make the file executable). Alternatively, you could do it per interface in /etc/netctl/interfaces.
Is there some sort of error/bug/inefficiency in my router at play? Very likely, lease negotiation shouldn't take more than 10 seconds. Then again, the dhcpcd default is 30 seconds, and empirically 20 seconds is the lowest value that permits me to successfully complete lease negotiation nearly 100% of the time. This was true with netcfg, it is still true with netctl (although netctl is a huge improvement IMHO in terms of simplicity and, for reasons that I don't fully understand, in terms of successfully and quickly reconnecting when a connection is lost...which in the case of one of my boxes happens often due to the ath9k / regulatory domain kernel issue).
Re: hook files / interfaces. True enough. Or I can do what I did before I forked netctl to provide a .conf file, which is change the hardcoded bash default. Or any number of things. But I thought the issue is not what I can do to hack around my particular problems, but how to design netctl in an Arch- and systemd- compliant manner. When a configuration option is needed by a non-trivial section of the userbase, a .conf file should be provided. And if I read the Arch/systemd news correctly, the appropriate place would be in /etc/netctl/netctl.conf (/etc/conf.d is deprecated, right?). Using bash parameter substition doesn't seem like a clean way to provide a default setting that may need to be changed on a global basis.
None of this is very relevant for stationary systems, but for portable systems where numerous networks are regularly accessed, a global .conf file is a much cleaner way of setting default DHCP options than the alternatives.
At the very least, if you decide that it should be left to the user to use hooks or /etc/netctl/interfaces, the documentation should note this. Passing options to the DHCP client is trivial with manually generated profiles, but it's obfuscated when utilizing wifi-menu (it requires a review of the bash code to determine where precisely the default is set...not a big deal but not really transparent, either).
[Edit:
I just reviewed the code, and it's also not obvious (without checking the code) that hooks are processed before profiles, but /etc/netctl/interfaces after profiles. This is fine (and can be useful), but if you do end up documenting the issue, it would be worthwhile to make clear that any options set in hooks are overridden by profiles, and any options set in /etc/netctl/interfaces override the profiles.]
The documentation should indeed be updated to mention the described behavior. Patches are welcome.
I don't think we need a symlink at /etc/netctl.conf or /etc/netctl/netctl.conf given that the /etc/netctl/hooks/dhcp.conf is adequately documented. On the other hand, I don't know how placing a conf file one directory level deep in a package directory squares with the Arch way of doing things -- perhaps you mentioned the symlink because the .conf file should be more exposed.
I'm glad you agree that the documentation should reflect the priority interplay between hooks, interfaces files, and profiles. I think the ability to have global defaults with profile- and/or interface-based overrides may turn out to be rather useful to someone (not in terms of setting the timeout, but certainly for other DHCP settings).
Let me know if you have any suggested changes to my proposed edits, and I'll be happy to revise further.