oliver gould wrote:
> On Sat, Apr 22, 2006 at 11:38:50AM +0100, Ricardo Correia Pinto wrote:
>  
>> 	While catching up with the latest changes, I've noticed
>> wpa_supplicant's BSD driver already implements scanning using the ioctl's
>> I mention in the PDF (It's also mentioned in tech-kern by rpaulo). It also
>> has a control interface wich can be used to trigger scans, and perform
>> some wpa-related tasks.
>>
>> 	This raises a question: reinvent the wheel by implementing the
>> scanning functions of wpa_supplicant or use the functions offered by it?
> 
> While I definitely agree that code reuse is a Good Thing, let me play
> devil's advocate for a second..
> 
> There are two approaches (presumably) to using wpa_supplicant: copying
> their scanning code over into this project; or interfacing with the
> wpa_supplicant daemon.  There might be some problems with both of these.
> 
> Since wpa_supplicant is licensed under the GPL, importing their source
> would require this project to be licensed under the GPL.  I don't know
> if this is desirable.
> 
> If there is a way to interface with the daemon, this would not force
> these licensing constraints.  However, it would require all users to run
> this extra daemon, whether they are using WPA or not.  The
> wpa_supplicant page [1] indicates support isn't global across chipsets
> and drivers.  Of course, it may not be possible to support all chipsets,
> but I would assume we'd want to go with the broadest coverage possible.
> 
>  [1] http://hostap.epitest.fi/wpa_supplicant/
> 

You've already noticed the bsd-gpl dual licensing.

I think the key design decision is how a scanning+roaming service ties 
into the supplicant.  wpa_supplicant currently has the two combined in a 
single program and I'm not sure that's good.  I'd consider splitting 
things apart with wpa_supplicant depending this other service to locate 
an ap and deal with roaming.  The hard part of this is managing 
authentication and in particular roaming.

Note that similar issues exists in the authenticator component.  The 
linux hostapd program was originally designed to handle all ap services, 
not just authentication (e.g. 802.11 management frames are passed up to 
it for some drivers).  When I integrated hostapd with the net80211 layer 
I decided it was better for it to act purely as an authenticator.  This 
has some issues but for the most part has worked well.

I would look to a system like OS X for guidance on the UI component of 
this facility.  I find their wireless support to be way more usable than 
any other system.  But unlike OS X whatever system you come up with must 
still work w/ only command line tools.  Whether this is done by 
providing a cli to the service or falling back to ifconfig+net80211 is 
unclear.

	Sam