[pkg-wpa-devel] Re: wpasupplicant init script

[Kel Modderman]

Reinhard Tartler wrote:

>On Fri, Mar 03, 2006 at 11:20:34AM -0500, Jason Lunz wrote:
>  
>
>>>This is a more advanced usage of wpasupplicant. It requires in every
>>>case manual editing of an wpasupplicant configuration file,
>>>      
>>>
>>well, sort of. The default wpasupplicant configuration file will
>>associate with any open AP, so that part's fine. What requires manual
>>configuration is ifplugd.
>>
>>Any time I want to add a WEP/WPA-protected AP, I only have to add a
>>single stanza to wpasupplicant.conf. Everything else is already set up,
>>assuming the network has DHCP.
>>    
>>
>
>This doesn't work cleanly on every available WLAN Chipset. I'm very
>unhappy that this used to be the default mode in wpasupplicant in the
>past, because my driver (madwifi-old) has problems with this mode of
>operation.
>
>  
>
>>>and I can imagine that his doesn't work with all available drivers.
>>>      
>>>
>>True, but I intend to continue submitting patches to any wireless
>>drivers I use to make them work this way. I've done so for bcm43xx
>>already, though that driver has more basic problems with roaming that
>>make this rather useless atm.
>>
>>The actual change is very simple; it's only necessary that the driver
>>reports carrier while associated and vice-versa.
>>    
>>
>
>And it is necessary that the driver supports background scanning, which
>isn't supported by madwifi.
>
>  
>
>>>We we currently plan is that it should be possible to configure the most
>>>common setups (wpa-pks, peap, etc) in /etc/network/interfaces. As you
>>>pointed out, this wont work for your setup. For your setup, you indeed
>>>need some kind of init script to run wpa_supplicant all the time.
>>>      
>>>
>>I think this is going in the wrong direction. I would say the common use
>>case for wireless is a roaming laptop, and a static configuration isn't
>>very well-suited to that.
>>    
>>
>
>I agree, but I think that having the local admin editing
>/etc/wpa_supplicant.conf to add the credential which are needed to
>connect to your network is static configuration as well, which I don't
>like too much.
>  
>

I'd like to support both scenario's. A static setup (non-mobile) and 
roaming.

>  
>
>>I think some inter-package coordination is needed in debian so that
>>a straightforward roaming-wireless-laptop is either the default, or is
>>easily set up by installing a few packages by flipping a setting
>>somewhere. We're not very far from that, really, though it took me a
>>while to figure that out.
>>    
>>
>
>Right. I've seen that use-case working in ubuntu/dapper using
>NetworkManager and ipw2200 drivers. Worked like a charm (modulo of wpa
>not supported in that version of Network Manager).
>
>Having said this, I want to repeat my observations about this problem:
>
>There are users who have an wireless router at home and have configured
>them to make wpa-psk only. Perhaps they use different interface aliases
>in /etc/network/interfaces, so configuration can be completly in
>/e/n/i without issues. This is what I want to become the default mode of
>operation, because it is way easier to configure. Think about
>configuration tools like gnome-system-admin editing /e/n/i as well.
>
>There are also users who use wpasupplicant as replacement for wparoamd.
>This is quite hard to support, because we need to require the user to
>provide a usable wpasupplicant.conf. This used to be the default mode in
>the past. Your mail (and another request I got in private) convinced me
>that we need to support this mode of operation as well.
>  
>

Agreed.

>The latter mode gets especially quite problematic in the case of
>mkinitramfs, which brings the interface up in the early userspace. This
>was the main reason why we wanted to remove the init script altogether.
>In order to solve this problem nicely, we would need to make sure that
>wpasupplicant binary gets into the initramfs along with a suitable
>config. You can now imagine that this gets way easier when we just
>consider the first mode of operation I described above.
>
>But in fact, also the latter mode would be doable, if debian's initramfs
>would already mount /var/{run,lock} as tmpfs, just like ubuntu already
>does. In this case, we could fire it up in the early userspace and
>forget about it. The initramfs needs to be regenerated every time the
>configuration changes, though.
>  
>

Huh? Since when did networking stuff such as this belong in early 
userpsace? The idea scares me to be honest.

>Now the question: How do we proceed from here? I can think that our
>ifupdown scripts should also support an always running wpasupplicant
>daemon, which was started either by early userspace or an ordinary
>initscript. Therefore I will see if I find some time tomorrow to
>reenable the initscript and extend (and of course test) Kels work on the
>hooks.  If this works somehow, I intend to get this package uploaded to
>experimental, in order to get some broader testing. If everyone is happy
>again, then lets get this work back to the stable branch of
>wpasupplicant.
>  
>

The idea behind the ifupdown scripts i have begun working on was to 
allow users who would not like to use an always running daemon but to 
set static setups in their e/n/i (and build upon these scripts as time 
and new knowledge allow).

They are self-contained, and can be *optionally* used instead of an init 
script (or otherwise) based daemon. It also means that multiple 
interfaces can spawn their own wpa_supplicant process, a feature which 
is not supported by any init script so far.

If you really think its worth appending a network block to an already 
existing wpa_supplicant.conf/ctrl_interface, you must determine what the 
last network id is. Then you can define a new network bock on 
((last_network_id++)) via wpa_cli. I see no point to this; because if 
the user is using a .conf file, why would they need the ifupdown hooks 
if they already know how to define the network in their working .conf 
file?. Currently, if an admin decides to activate these ifupdown 
bindings by usig them in  e/n/i, any pre-existing wpa_supplicant process 
binding $IFACE will be terminated.

It also adds complexity to the scripts, I am not convinced the extra 
complexity will acheive much, but I am definately not going to 
discourage the notion of trying new things out :-)

>Regarding our 'stable' branch (i.e. svn trunk): I think I will prepare
>an upload updating to 0.4.8 and see if we can satisfy the request of the
>debian utopia team.
>
>How does this sound?
>  
>

0.4.8 has been around for quite some time now, just do it already :-)

>  
>
>>There's now a GPL bcm43xx driver in linux for the broadcom chipsets. The
>>state of the in-kernel intel centrino ipw2xxx is improving. So it seems
>>likely that in etch, it should be possible for a majority of laptops to
>>simply work like this out of the box. I don't think it should be an
>>"advanced configuration".
>>    
>>
>
>I think atheros chipssets are also a quite popular chipset. Which has
>its own set of problems regarding wpasupplicant. It would be great if
>wpasupplicant would 'just work' on all chipsets, but this isn't going to
>happen too soon. Perhaps we can fix issues like #295445 using pci-ids
>for selected common and tested chipsets.
>  
>

This is a bad idea. If you want wpa_supplicant to support both 
madwifi-old and -ng, you must go against Jouni's decision to make that a 
compile time decision. I already asked him directly on hostap + madwifi 
mailing lists about this very issue. Its not something that should be 
patched into this package IMHO.

Alternatively, we can co-ordinate the arrival of madwifi-ng into our 
respective distributions, and adjust wpa_supplicant accordingly 
(although i have no idea how ubuntu handle madwifi).

>I also think that the usecase you presented us is a local user alone on
>his laptop who moves from one wireless net to another. I don't think
>that he should have to edit /etc/wpa_supplicant.conf everytime he moves
>to a new network, requiring root priviledges. To satisfy this usecase, I
>think some real interface managing service like NetworkManager is the
>right way.
>

Strong ACK. Just wish their was an alternative that does not rely on gui 
. . .

> Unfortunately, I've seen frontends for Gnome and KDE only up
>to now. But since all communication is via DBUS, it should be rather
>easy to implement a simple CLI application which allows the user to edit
>his network settings without the requirement to be root.
>  
>

There is currently discussion on the hostap mailing list about adding 
dbus communication sockets to wpa_supllicant and friends, iirc.

>I understand that this is not possible right now. Therefore I agree that
>we should keep the solution we had in past releases of wpasupplicant.
>Nevertheless, the local admin should have to enable it manually. This
>was already the case in past releases of the package, IIRC.
>
>Gruesse,
>	Reinhard
> 
>

Thanks, Kel.