Roaming functionality with wpasupplicant (was: [pkg-wpa-devel] cleaning up our suggested modes of use)

[Kel Modderman]

On Wednesday 02 August 2006 21:42, Marc Haber wrote:
> On Wed, Aug 02, 2006 at 01:30:03PM +0200, Reinhard Tartler wrote:
> > On Wed, Aug 02, 2006 at 01:13:25PM +0200, 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. this falls under mode 1.
>
> I missed the "roaming" in my original question. Let me re-phrase.
>
> So the people who have moved from wpa_supplicant.conf to
> /etc/network/interfaces a few releases ago when wpa_supplicant.conf
> was deprecated (losing their roaming ability in the process) are now
> asked to migrate back if they want to have roaming functionality?

Providing a pre-installed wpa_supplicant.conf _never_ provided a default 
roaming ability without extra steps to set it up. There are no sensible 
defaults for that file; there are no sensible defaults for roaming with 
wpasupplicant alone. It requires one setup tools to make meaningful network 
connections, for instance. It also requires that one provides details about 
known networks (no, I do not find association to open network out of the box 
to be sensible good default). These steps require knowledge, and this can be 
provided by documentation and support applications.

Therefore, I do not see providing or not providing wpa_supplicant.conf as an 
issue. The documentation should, and currently does state where an 
appropriate starting point exists, an example configuration file. This 
requires the end user to do an extra step; copy the file to a suitable 
location (or open a text editor, and copy from the many examples provided by 
the package). But it also forces another step; the end user _must_ read the 
documentation to get that far.

If the end user has read the documentation, and the documentation is well 
written and informative, and the underlying code supports the documentation, 
I think the end user will have a better chance of successfully achieving what 
they set out to do than simply giving them a default /etc/wpa_supplicant.conf 
file.

I would also argue that Mode #1, Managed mode, would be used very often, and 
does not require a wpa_supplicant.conf file. New users expecting roaming 
abilities would be far more likely to look for a graphical tool such as 
NetworkManager or KWlan, these applications do not require that we provide a 
wpa_supplicant.conf file. Experienced end users should be more comfortable 
with the fact that there is some minor manual intervention, and reading to be 
done, as long as it works when it is done ;-)

Or are you simply a bit annoyed that roaming is now intrinsicly possible with 
the "new order" package, and you have to dig up a wpa_supplicant.conf file 
again to make use of the new feature?

As stated in a previous mail, this new feature came about from hard work and a 
deeper understanding of the software than we had 6 months ago. I refuse to 
draw analogies to the new roaming scheme and that of the previous packaging; 
there are none.

> >
> > this is a feature with the 0.5 branch of wpasupplicant. Example use:
> >
> > auto ath0
> > iface ath0 inet manual
> >         wpa-driver madwifi
> >         wpa-roam /etc/wpa_supplicant/wpa_supplicant.conf.local
> >
> > iface default inet manual
> >         up /usr/sbin/whereami --hint ath0
> >
> > iface olymp inet manual
> >         up /usr/sbin/whereami --hint ath0
>
> I remember using whereami from the whereami package back in 2004 when
> my notebook began changing wired networks multiple times a day, and I
> didn't like it because a lot of features were missing (especially if
> no DHCP is in use). On the wired connection, I am using guessnet in
> the mean time - is there a possibility to have wpasupplicant roam with
> guessnet instead of whereami?

I think guessnet is far more appropriate, fwiw. It is far more feature 
complete than whereami (imo), and has an ifupdown function. In fact, I 
seriously considered its usage in the current wpa_action script, here are the 
reasons why I did not:

1. It is primarily used to guess what network we are currently connected to. 
wpa_supplicant already knows _alot_ about this; essid, bssid and id_str are 
all valid identifiers available at the time of successful association. Why 
waste time and effort "guessing" this information when we already have 
enough?

2. It requires more steps to setup. For each network there is extra guesswork 
to be done (point #1, why do we need to to extra guesswork?). There is more 
of a learning curve associated with associated with making 'wpa-roam' 
JustWork. 

Here are reasons why I did consider it:

1. It can control ifupdown. These means we lose a small amount of shell code 
from wpa_action. However, it would require a similar hack to what we 
currently do, --force the first active LOGICAL interface up. This is 
necessary due to the fact that ifupdown does not yet support silently (not 
recording state) upping the master roaming interface without any inet METHOD.

2. It is well established and proven software and it would fit in well with an 
interfaces file that already uses guessnet for a wired interface.

I probably had more thoughts about guessnet at the time, but cannot recall 
them. Please add your 2c worth.

I like Reinhard's idea of providing a framework for allowing such a plugin 
interface to provide "roaming logic". However, at this point in time, I do 
not consider logic provided outside of wpa_supplicant in any way superior, or 
even required. I simply find guessing the network, when it is already known, 
unnecessary.

Please, lets discuss this some more, maybe some new and interesting features 
can be a product of this discussion.

Reinhard, did you find the time to review the changes yet? What are your 
concerns and what changes do you like?

Thanks, Kel.