On Sat, Mar 9, 2013 at 8:46 PM, Leonid Isaev <[email protected]> wrote: > On Sat, 9 Mar 2013 14:22:17 +0100 > Jouke Witteveen <[email protected]> wrote: > >> On Fri, Mar 8, 2013 at 9:02 PM, Leonid Isaev <[email protected]> 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
