[pkg-wpa-devel] Re: Non-roaming usage of the daemon: Radio kill switch

[Reinhard Tartler]

On Sun, Apr 09, 2006 at 09:54:50AM +0200, Felix Homann wrote:
> > If youare unhappy with them, I'm happy to read your suggestions how to
> > reword them to make them even more clear. What kind of additional
> > information did you expect? and where?
> 
> I've just prepared a seperate mail for this.

Thank you for your suggestions. I will see what can be merged to our
current package.
 
> > Nowhere in the old package it was 
> > advertised that wpasupplicant would work with ifplugd at all. It rather
> > happens to work with that, and that specific undocumented behavior 
> 
> Well, would you even call the kernel's ability to run wpa_supplicant 
> a "specific undocumented behavior"? It is the other way round: ifplugd is 
> intended to work with e.g. wpa_supplicant exactly the way it does/did. You 
> simply don't want this behavior anymore.

It is intended? Neither in the documentation of wpasupplicant, nor in
the documentation of ifplugd I could find a note that these pieces of
software are intendend to be used together in any way. Where did you get
this piece of information from?

I looked on google http://www.google.com/search?q=wpasupplicant+ifplugd, 
and all I found were some mails on some user mailing lists, which
suggested this combination as workaround for wpasupplicant not being
able to call dhclient when you are not connected yet. This functionality
is there now, and it is called 'action scripts', which we support
properly now.

> > Now we changed the situation,
> 
> Yes, and things got broken. As you can tell from other messages on the list 
> using ifplugd together with a "mode 3" wpa_supplicant is very common. As long 
> as the new approach can't reproduce it's functionality the init script 
> approach should not be deprecated.

I can understand that this hack was somewhat commen because you had no
other choice. Anyway, the old package did not provide some real
instructions how to use that, so I don't considered this as 'supported
behavior'. Then some ppl complained on this mailing list, so we decided
to reintroduce the init script with instruction how to reenable it.

> Keep in mind that the wpa_supplicant/ifplugd solution is not only useful for 
> roaming but even for the simple (?) task of having a nicely behaving wlan 
> button.

My wlan button works as expected: When I press it, wpasupplciant calls
the action script with command DISCONNECTED. When I repress it, then my
interface is configured with the help of whereami nicely. No need to
ifup or ifdown the interface.

Btw, what does YOUR wlan button do exactly?

> > sure. you can customize the action script to your needs
> 
> In which way, how? It is rather undocumented!

If you had bothered to look at it, we prepared a skeleton action script,
with comments how it is intended to be used. What do you want more?

> > and perhaps 
> > lower the timeout. 
> 
> Where? (I actually know where, but it's not documented). I guess the timeout 
> is there for a reason. Would it have any unwanted side effects to lower the 
> timeout to 0? I don't think a user should mess with ifupdown.sh.

Why not? it is a conffile after all, so on the next upgrade, dpkg will
prompt the user with a conffile change and he can remerge his changes
any time. 

If you think the timeout should be configurable, thats something we can
talk about. How about introducing a new wpa-timeout command for /e/n/i?

Gruesse,
	Reinhard