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

[Kel Modderman]

On Wednesday 02 August 2006 23:11, Marc Haber wrote:
> On Wed, Aug 02, 2006 at 10:24:14PM +1000, Kel Modderman wrote:
> > On Wednesday 02 August 2006 21:55, Marc Haber wrote:
> > > On Wed, Aug 02, 2006 at 09:36:45PM +1000, Kel Modderman wrote:
> > > > On Wednesday 02 August 2006 21:13, Marc Haber wrote:
> > > > > On Sat, Jul 22, 2006 at 11:22:57AM +1000, Kel Modderman wrote:
> > > > > > Development of the "new order" wpasupplicant seems to be
> > > > > > stabilising, and I see now two clear modes of operation, and
> > > > > > would like to propose a clean up; consolidate documentation and
> > > > > > code support for (IMO) the two preferred modes of operation.
> > > > > >
> > > > > >   1. managed mode, all WPA settings given via the interfaces
> > > > > > stanza for any given network interface
> > > > > >   2. roaming mode via wpa-roam/wpa_action: requires user supplied
> > > > > > or hand crafted wpa_supplicant.conf, and supports multiple
> > > > > > locations and network profiles
> > > > >
> > > > > So the people who have moved from wpa_supplicant.conf to
> > > > > /etc/network/interfaces a few releases ago when wpa_supplicant.conf
> > > > > was deprecated are now asked to migrate back?
> > > >
> > > > No, absolutely not.
> > >
> > > How can I have roaming without wpa_supplicant.conf?
> >
> > You cannot.
>
> 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.

>
> > Even if a wpa_supplicant.conf file is provided again, it is required to
> > edit it *and* the /etc/network/interfaces file. We are writing an
> > excellent document that explains where and how to adapt a
> > not-installed-by-deafult wpa_supplicant.conf file you your needs. The
> > amount of work is equal, imho.
>
> As long as the way to do it is going to stay this time, I'm fine with
> that.
>
> > > In the "How it works" chapter, it shuold be mentioned that the magic
> > > is hidden in a ifupdown action script,
> > > /etc/network/if-pre-up.d/wpasupplicant.
> >
> > Actually, it is /etc/wpa_supplicant/ifupdown.sh, with a
> > wpasupplicant.links file like so:
> >
> > etc/wpa_supplicant/ifupdown.sh /etc/network/if-pre-up.d/wpasupplicant
> > etc/wpa_supplicant/ifupdown.sh /etc/network/if-down.d/wpasupplicant
> > etc/wpa_supplicant/ifupdown.sh /etc/network/if-post-down.d/wpasupplicant
>
> Ah, nice. Didn't see that.

The script and what it does during each phase of ifupdown has been described 
in the current working copy of README.modes.

> >
> > > "Notes about managed mode" has a typo, "automattically".

Fixed.

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

 
>
> > > In "Controlling the Roaming Daemon with wpa_action" it is said that
> > > ifupdown shouldn't be called manually. Is it possible to associate a
> > > eth1 "down" action with wpa_action eth1 stop so that the entire
> > > interface can be cleanly taken down with ifdown eth1 as it would be
> > > for a wired ethernet?
> >
> > Not right now, this is tricky and there is an open bug for it (#373180).
>
> I see.
>
> > > whereami is not used at all, in difference to what siretart has
> > > written in this thread.
> >
> > I do not use it.
>
> And how do you implement your wireless roaming? All controlled by
> wpa_supplicant?

Yes. wpa_supplicant and wpa_cli.

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. If there is a wpa_cli 
daemon listening to the ctrl_interface socket, the signal can trigger 
an "action" script. The action script takes two arguments, the network 
interface name, and the action (CONNECTED or DISCONNECTED). In addition to 
these arguments, there are some environmental variable of interest:

WPA_CTRL_DIR, the path to the ctrl_interface socket
WPA_ID, the unique network indentification number
WPA_ID_STR, the value of 'id_str' when given, falls back to 'default'

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

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.

The wpa_cli(8) manpage also briefly describes some of these features, as i 
wrote them for Jouni.

Thanks, kel.