[arch-projects] [netctl] Few observations

[Leonid Isaev]

On Sat, 9 Mar 2013 14:22:17 +0100
Jouke Witteveen <j.witteveen at gmail.com> wrote:

> On Fri, Mar 8, 2013 at 9:02 PM, Leonid Isaev <lisaev at 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...

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.

> 
> > 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.

But regardless as long as netctl cleans up wpa_supplicant and dhcpcd, why not
other daemons it spawned?

> 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.

Best,
L.
PS: BTW I forgot to thank you for the great job you did on netctl :) 

> 
> > 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <http://mailman.archlinux.org/pipermail/arch-projects/attachments/20130309/057d5c72/attachment.asc>