[pkg-wpa-devel] cleaning up our suggested modes of use

[Marc Haber]

On Wed, Aug 02, 2006 at 11:40:51PM +1000, Kel Modderman wrote:
> On Wednesday 02 August 2006 23:11, Marc Haber wrote:
> > So I need to migrate back to wpa_supplicant.conf after migrating from
> > wpa_supplicant.conf to /e/n/i after learning that wpa_supplicant.conf
> > was deprecated.
> 
> Well, what this package allows in terms of usability is increasing as my own 
> knowledge of wpa_supplicant increases (and programming ability). I became 
> involved with the development of the package just after it was decided that 
> we move away from that stuff. So yes, there is some volatility with respect 
> to the way this package is being used, and yes this package is being actively 
> developed, and yes it is part of a developing debian release. So lets not 
> stumble upon past history again please, but rather look towards what happens 
> in the future and how people are going to adapt to the changes as part of a 
> release upgrade.

Agreed. I was actually trying to find out whether I have misunderstood
and might be doing something wrong by actively going back.

> > > > What is the /usr/sbin/foo --bar mentioned in the /e/n/i chapter?
> > >
> > > Ok, i should substitute that crap for a real world example of some common
> > > pre-up action/command, any ideas of a good one?
> >
> > So that action/command is not actually necessary here? Then I was
> > confused since siretart's example had whereami calls there, and I got
> > the impression they're actually needed.
> 
> It was confusing, and has been totally removed.

Great.

>  I had hopes it would serve purpose to illustrate that custom pre-up
>  commands can be used with any of the logical interfaces. Any example
>  of a good one can be re-added to the doc.

Try prose. "Custom pre-up commands can be used with any of the logical
interfaces" in the docs, or a little bit more terse as a comment in
the example /e/n/i file. Or write "/some/custom/pre-up/command"

> > And how do you implement your wireless roaming? All controlled by
> > wpa_supplicant?
> 
> Yes. wpa_supplicant and wpa_cli.

I see.

> When wpa_supplicant is launched, it uses a network interface to scan for an 
> appropriate network. If one is found, and successfully associated to, it 
> sends a CONNECTED signal to the ctrl_interface socket.

For some reason (may be caused by ap_scan=2 which I need due to hidden
ssids in some of my "home" networks), wpa_supplicant first configures
the interface for one network, waits a minute, and then tries the
others one after the other, which greatly slows down the roaming. Is
it possible to have wpa_supplicant first look which networks are
_visible_ and immediately take one of these if there is configuration
for it? Only if none of the visible networks matches, hidden ssids
should be tried (as this takes _much_ longer).

> Our script, /sbin/wpa_action uses this information to control ifupdown. This 
> is where the LOGICAL interfaces feature of ifupdown comes in.

I understand.

> But rather than me explaining all this here in great detail, please read 
> wpa_action(8), and if there is not sufficient detail in it to tell you how it 
> works in technical detail, i would prefer to add it there, than to the 
> mailing list.

You're right.

Greetings
Marc

-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things."    Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 621 72739835