[pkg-wpa-devel] Re: wpasupplicant experimental branch

[Kel Modderman]

Reinhard Tartler wrote:
> On Sun, Mar 26, 2006 at 10:49:29PM +1000, Kel Modderman wrote:
>   
>> Recently I have done much work in the experimental branch to create a 
>> wpasupplicant package that *I* am happy with. The version sitting in 
>> experimental right now is very dodgy, it'd be great to replace it with 
>> something with more quality.
>>     
>
> What we currently have in svn seems to me very improved!
>
> I just switched my notebook to use this /etc/network/interfaces:
>
> auto ath0
> iface ath0 inet dhcp
>         wpa-conf /etc/wpa_supplicant.conf
>         wpa-action /etc/wpa_supplicant/action.d/dhclient
>         wpa-driver madwifi
>
> And now I have a quite nice roaming solution. Thanks to the action
> script, roaming should no longer be a problem anymore. If I had some
> networks which required manual configuration of interfaces, I could
> write my own action script. Great stuff, I love it :)
>   

To take advantage of the action script, you are required to use the 
manual inet MODE. So, in the above example, you are simply starting the 
wpa_supplicant daemon and calling dhclient via ifupdown, not wpa_cli. 
This is neccesary, or else we will experience conflicting behaviours due 
to more than one process configuring your interface.

Something like this is quite useful for a hotplugged cardbus card to 
take advantage of an action script:

allow-hotplug ath0
iface ath0 inet manual
        wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf
        wpa-driver madwifi
        wpa-action /etc/wpa_supplicant/action.d/dhclient

Then, start a wpa_cli shell (wpa_gui), do some scanning or 
disconnect/reconnect events, and observe.

To take a look at what is happening, use the --verbose option of 
if{up,down}.
> Just a question, why do you introduced an 'action.d' directory? do you
> expect other packages dropping action script in there? Do you intend to
> include all files which are dropped there by default?
>
> I think we can install this simple action script to
> /usr/share/doc/wpasupplicant/examples/simple-action-script and let the
> default configuration choose that. If the user wants a more
> sophisticated action script, then he can copy this to this home
> directory and edit this to his needs. no problem.
>   

Nack,

a) /usr may not be mounted when we call that script
b) i think that the dhclient script is quite useful to a large 
percentage of users, why not keep a dpkg handle on that file instead of 
forcing the user to manually copy an example script to a more suitable 
location?
c) i'd like to keep the action.d directory, for future possibilities 
(some ideas are trapped in my head to allow full network profiling via 
wpa_cli callbacks)
d) lets not hide the good stuff in the /usr/share/doc area, like so many 
other packages do
e) i hope some others contribute their action scripts, so that we may 
include them at some stage
f) it is not hurting anyone

i'd like to provide a skeleton action script in the examples dir 
however, that would be a good idea
> just a glitch: could we please provide some symlinks from
> /usr/sbin/wpa_supplicant to /sbin/wpa_supplicant for transitional
> purposes? This broke my former home made scripts.
>   

Strong ack. Will do that immediately.
> The traditional solution which involved running wpasupplicant as system
> service running all the time is deprecated by the solution we have
> currently in experimental. This includes dropping the idea of the init 
> script completley in favor of integration with ifupdown. This feels more
> natural than anything we had before.
>   

Ack.
> We have currently 2 Problems. One is that we need to revise and update
> our current documentation. We need to make sure that a user gets easy
> examples for easy cases and outline how he can create more complex
> configurations.
>   
Ack.
> The secound problem we have is a well defined upgrade path. The file
> /etc/network/interfaces is not a conffile, so we could perhaps try to
> detect if the user already used wpasupplicant on one interface (and
> which), and then ask via debconf if his /etc/network/interfaces should
> be adapted to look like this:
>
> auto eth1
> iface eth1 inet dhcp
> 	wpa-driver wext
> 	wpa-conf /etc/wpa_supplicant.conf
>
> but since we are talking here about a very sensitive part of system
> configuration, we are perhaps better of with writing a high priority
> debconf notice that the user should revise his /etc/network/interfaces
> with an example and point him to the appropriate documentation, iff we
> are actually upgrading. (no need to bug on new installs).
>   

Yep, certainly, I'll start on a preinst script immediately. Although, i 
have not had much experience with debconf so far.
>   
> Let me summarise the situation how I see it so far:
>> There are still some things on the TODO list to cut through, documenting 
>> interfaces file usage being the highest priority. But before we throw 
>> time at that, it needs some exposure/testing.
>>     
>
> Experimental seems to be the best place for testing, I think.
>
> The currently prepared upload of wpasupplicant_0.4.8-1 in svn should
> perhaps be rethought. It was intended as interim solution only which
> should fix some bugs which are currently open in debugs. I didn't expect
> that Kels work in experimental would rock that hard that quick. Now we
> need to decide where to go from here. I'd love to see the new world
> order of wpasupplicant to be uploaded to unstable as soon as possible,
> so that we get wider testing as early as possible, to get a good package
> for etch!
>   

I think we should contemplate adding some code to this package to warn 
of future changes, and some other transition easing code i cannot think 
of right now :-)
> I propose this for now: Lets upload what we have in experimental now,
> and ask more people to test that. In paralell, lets work on the debconf
> warning and improve our documentation. When we are happy enough with
> that, lets upload that as 0.4.8-1 to unstable, perhaps next weekend.
>   

Ok, i have already responed to this, but i'd like to repeat here, that 
if the ifupdown script is to be the core of this package, please please 
please allow me the chance to give the green light before any upload.

Thanks, Kel.