Roaming functionality with wpasupplicant (was: [pkg-wpa-devel]
cleaning up our suggested modes of use)
Kel Modderman
kelrin at tpg.com.au
Thu Aug 3 01:24:49 UTC 2006
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.
More information about the Pkg-wpa-devel
mailing list