[arch-projects] [netctl] Few observations

Sun Mar 10 05:08:07 EDT 2013

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?

> 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