[arch-projects] [netctl] Few observations

Sun Mar 10 19:35:06 EDT 2013

On Sun, 10 Mar 2013 10:08:07 +0100
Jouke Witteveen <j.witteveen at gmail.com> wrote:

> On Sat, Mar 9, 2013 at 8:46 PM, Leonid Isaev <lisaev at umail.iu.edu> wrote:
> > 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...
> 
> So basically, WPADriver is the only ignored option in netctl-auto?

Yes, correct.

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

Completely forgot about those :) But whouldn't the type "ethernet" be
sufficient, i.e. if "Auth8021X=yes", then use "WPADriver=wired" automatically?

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

That patch seems reasonable, and since this has not been noticed before,
worked OK with wpa_supplicant 1.0. But I haven't tried reverting it yet.

I also haven't played with timeout in 8021x, but I think that wpa_supplicant is
dead during the delay because my wifi interface is down (indicator light goes
red)...

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

I always thought that 'wpa_cli wlan0 terminate' will effectively send a sigterm
to wpa_supplicant, so do we ever get to killing the latter explicitly? And
if we do, perhaps it should be 'kill -kill'?

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

-- 
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/20130310/b66ff196/attachment.asc>