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

[Reinhard Tartler]

On Mon, Mar 27, 2006 at 06:23:27PM +1000, Kel Modderman wrote:
> >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.

How do you make sure that the interface gets an ip via dhcp before running
any other scripts besides wpasupplicant? This is a quite important
point, because at least in ubuntu, interfaces are always ifupped via
udev, so there is no difference between hotplugged and not hotplugged
interfaces. Many other daemons like openvpn and ntpdate are running from
scripts in /etc/network/if-up.d. We need to make sure that
/etc/network/if-pre-up.d/wpasupplicants blocks until the interface got
an ip or was configured by alternate means. (e.g. statically).

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

I took a closer look to the dhcp action script. I noticed that when
roaming, the dhclient does not reliably request a new lease when getting
disconnected. I'm not sure why this happens, but I really think we
should signal a running dhclient daemon that we want the lease to be
renewed when we connect to a new location.
 
> To take a look at what is happening, use the --verbose option of 
> if{up,down}.

Very handy, thanks.

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

This is only valid if we want to make that script active by default,
what we don't.

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

So you do want to make it active by default?

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

hm. I think this makes only sense if the action.d/* scripts are active
by default. Currently, it seams to me like a heap with propably useful
scripts. To my understanding, this is whats /usr/share/doc/*/examples is
for.

> d) lets not hide the good stuff in the /usr/share/doc area, like so many 
> other packages do

I expect users to look at /usr/share/doc and manpages in the first place
when looking for information how to use a package. Therefore I don't
think /usr/share/doc/wpasupplicant is a heap for useless piles of
information nobody cares. If this would be the case, we could drop that
directory completely. Better lets tidy up that place so the users get
the information they need quickly.

If you think that place should be better advertised, we can drop a
readme pointing to that place for configuration examples.

> e) i hope some others contribute their action scripts, so that we may 
> include them at some stage
> f) it is not hurting anyone

but it doesn't help either. Let's better try to provide a useful default
configuration and provide pointer how to customize the package to their
needs.

I don't want the default action script to be a conffile for this reason:
I expect many users to customize/edit that script to include local
configuration. If this happens, they will be bugged on every upgrade.
Therefore I suggest that if we don't intend to make it active by
default, to not ship it in /etc, so that we don't need to care about
conffile handling at all.

If we do want to make it active by default, I'd like to provide some
means of overriding it with a local version but without needing to touch
any conffiles, so that upgrades go smoothly.

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

Already done ;)


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

Ok, then let's just focus on warning the user on upgrades, and let the
user handle the conversion, as we don't see how to safely convert the
local configuration.

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

No problem, I'll respect that and ask you before every upload :)

Gruesse,
	Reinhard