[pkg-wpa-devel] Bug#383907: Is there an easy way to check if an interface is managed by wpa_action?

[Kel Modderman]

On Tuesday 22 August 2006 18:06, Reinhard Tartler wrote:
> Kel Modderman <kelrin at tpg.com.au> writes:
> > On Monday 21 August 2006 00:02, Reinhard Tartler wrote:
> >> This of course fails if the interface is controlled by wpa-roam aka
> >> /sbin/wpa_action. I hardcased the check here for my interface, but it
> >> would be nice if acpi-support could be improved and call `wpa_action $x
> >> stop` by itself. For this we need to provide a reliable check if the
> >> interface is managed by wpa_action or not.
> >
> > You can check for the location of the ctrl_interface domain socket (that
> > may be in a different location according to config file used) or pidfile
> > (which is what the wpa-ifupdown init script/hack uses to identify
> > interfaces bound by wpa_supplicant/wpa_cli, and it is a fixed location).
>
> The ctrl_interface socket may be changed by the user, so this is a
> nogo. The pid file is a fixed location, but might get stale (i.e. it is
> still there, but the corresponding daemon has died or has been killed by
> the user. Even checking if there was a PID with that number doesn't work
> reliably, because there might be another process with the same PID).
>
> How about this:
>
> if [ -x /sbin/wpa_action && /sbin/wpa_action check $IFACE ];
>    wpa_action ath0 down
> else
>    ifdown ath0
> fi

This 'check' should be currently implemented in SVN.

>
> > Is this a workaround for #383168? If so, my current kludge is to have the
> > suspend manager, in my case it was hibernate but now it is powersave,
> > stop the wpa-ifupdown service on suspend.
>
> #383168 (list of optimized glibc packages in postinst script is
>  outdated) seems unrelated to me. Was this a typo?

Sorry, i meant the bug you reported against madwifi, its failure to suspend 
correctly.

>
> Your 'kludge' sounds interesting. How does it work with hibernate?
> Perhaps we can write some hints in README.Debian (or README.suspending)

Lets get the basis for the documentation straight, and it'll be difficult to 
give generic advice, when some modules are behaving better than others. We 
can try as best we can.

Thanks, Kel.