On Sat, Mar 9, 2013 at 8:46 PM, Leonid Isaev <lisaev@umail.iu.edu> wrote:
On Sat, 9 Mar 2013 14:22:17 +0100 Jouke Witteveen <j.witteveen@gmail.com> wrote:
On Fri, Mar 8, 2013 at 9:02 PM, Leonid Isaev <lisaev@umail.iu.edu> wrote:
Hi,
I have been running testing/netctl for a couple of days now and noticed some issues (some of which are not really netctl specific). I thought it might be better to bring them up here, as opposed to flyspray.
1. There used to be a DHCP_OPTIONS variable in netcfg, but it is never mentioned in netctl documentation. Meanwhile, ip_set() in globals, does have DHCPOptions. Was making this variable invisible to the user intentional? It is quite convenient when dealing with buggy DHCP servers (e.g. -d switch for dhcpcd)...
By the capitalization, you can tell that DHCPOptions is intended to be usable in profiles. However, this feature went undocumented because in the past users have made a mess with it. For instance, by backgrounding the daemon. If DHCP servers are buggy, they should be fixed, thats not netctl's fault. However, if you can come up with a
I agree, so I usually send a part of daemon.log to our IT... not sure if it helps though.
piece of documentation that makes users not want to use this variable, I'd love to include it.
Will do.
2. There is a WPADriver variable whuch is not read if a profile is included in a group by netctl-auto (because profiles are parsed in separate subshells). This a good thing, as different profiles can have incompatible values of WPADriver, but I think it should be included in documentation (it can seriously confuse a user, myself included, who looks at ps auxww).
Your new documentation suggests the same holds for other variables too, but I cannot quickly see which ones. If WPADriver is the only one, I would prefer the suggestion is removed from the documentation ;-).
WPAConfigFile? But this is logically for wpa-config security which is incompatible with netctl-auto (there is a comment in netctl-auto, but I'd also make it clear in netctl.special). The reason why I mentioned it is because I tried to make netctl call wpa_supplicant with -Dnl80211, but wext kept showing up...
So basically, WPADriver is the only ignored option in netctl-auto?
OTOH, is there any case when we need such a control? E.g. doesn't -D nl80211,wext work always? So perhaps there is no practical use for WPADriver in the 1st place.
For wired connections, we use the 'wired' driver. Being able to choose your driver is a valuable option, but just as in the DHCPOptions case one that most users should not be bothered with.
3. This is the main issue, albeit also present in netcfg. With wpa_supplicant 2.0 and wpa_actiond 1.4 we noticed a sizeable delay when shutting down netctl-auto (resp. net-auto-wireless) in a WPA-EAP environment. This is somehow related to the fact that wpa_actiond is never killed by netctl/netcfg which only terminates wpa_supplicant/dhcp client. The real problem may be in wpa_supplicant, but regardless, netctl/netcfg should properly clean up after itself.
What is the problem, precisely? If wpa_actiond sees the supplicant has disappeared, it quits.
Please see https://mailman.archlinux.org/pipermail/arch-general/2013-March/033036.html. Basically, with wpa_actiond 1.4 (which IIRC includes wpa_ctrl code from wpa_supplicant 2.0) some of us noticed ~10sec delays when netctl-auto is stopped. Currently I can only test this on a WPA enterprise univ. network. Of course, I can't prove that this is not a bug in wpa_actiond, but it doesn't seem that way. Since I have a hw control and light indicator on my laptop wifi card, I can tell that interface is down, but systemd waits for something, and the only thing which is not killed by netctl is wpa_actiond. Killing it explicitly helps in my case at least.
Interesting. If you've got a lot of time, you could try to find the wpa_actiond commit that introduced this delay. I wouldn't be surprised if reverting dadc6 would remove the delay. Another thing you could try is increase the delay on line 106 of netctl's lib/8021x. I would say that the correct way of terminating is sending the 'terminate' call to the supplicant. This should take care of both wpa_supplicant and wpa_actiond. The current netctl code gives the supplicant and wpa_actiond 1 second to die. After that, it kills the supplicant (but not wpa_actiond).
But regardless as long as netctl cleans up wpa_supplicant and dhcpcd, why not other daemons it spawned?
We could do a similar timeout thing as for wpa_supplicant, but in the end it would be nice if everything just terminates after our 'friendly' request.
In a systemd setting, this all seems perfectly fine, doesn't it?
Yes, iff one can ensure that the daemons are killed in a correct order.
However the following question is valid: is there any way we can rely on systemd's cgroup mechanism to trim the clean-up code? If it is only possible to start a profile as a systemd service, then I'd say there is no need to terminate wpa_supplicant (in wpa_stop()); dhcpcd is a different story though as I don't know how it would behave when interface suddenly disappears (if wpa_supplicant is killed first). So, I think it is OK to leave some processes in netctl's cgroup after ExecStop=... returns but not all.
I am gonna think about not forcefully killing the supplicant. Indeed, systemd should be able to deal with this for us.
Best, L. PS: BTW I forgot to thank you for the great job you did on netctl :)
Glad to be working with you.
Pts. (2) and (3) are 'fixed' by the following small patch...
Cheers,
-- Leonid Isaev GnuPG key: 0x164B5A6D Fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
Regards, - Jouke
-- Leonid Isaev GnuPG key: 0x164B5A6D Fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D