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

[Kel Modderman]

Reinhard Tartler wrote:

>On Mon, Mar 06, 2006 at 09:16:58PM +1000, Kel Modderman wrote:
>  
>
>>Huh? Since when did networking stuff such as this belong in early 
>>userpsace? The idea scares me to be honest.
>>    
>>
>
>You need it when you want to mount root via nfs across wpa secured
>network. Granted, this is not a that common use case, and we don't need
>to implement it quickly.
>  
>

A world without wires scenario? :-)

>>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).
>>    
>>
>
>Right. But your scripts allow another usecase: Run wpasupplicant in
>roaming mode, but keep the interface up all the time (to the view of
>ifupdown). This needs a user provided wpasupplicant, though.
>  
>

Okay, now I understand, thanks for clarifying.

>  
>
>>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.
>>    
>>
>
>Perhaps we could extend the init script so that the daemon listens to
>more than one interface. But I cannot think of any usecase where this
>would make sense. If you use the init script, you want some sort of
>roaming daemon. Well, perhaps if you run wpasupplicant over both wire
>and wireless, and have different networks at your workplace. Hm, I don't
>think this is that common, though.
>  
>

What i mean: i can ifup ath0, ifdown ath0, ifup eth1, ifdown eth1, all 
interfaces can use wpa_supplicant. The old daemon can only be used with 
one IFACE, because it is defined in /etc/default/wpasupplicant. (i have 
3 wifi devices attached to this machine for example).

>  
>
>>>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.
>>    
>>
>
>well, we would need to settle on either madwifi or madwifi-ng. Or
>provide 2 binary packages for wpasupplicant, compiled for each binary.
>But I don't think this is feasible.
>  
>

Agreed.

>What I actually meant is that we could perhaps find some heuristics to
>autodetect the variable $IF_WPA_DRIVER for selected chipsets (e.g.
>centrino and atheros). These heuristics could use pci ids and can always
>be overriden by the user.
>  
>

Some basic heuristics yes, but nothing as complex complex as you 
describe. The supported chipsets and their names w.r.t. to wpasupplicant 
are well documented.

>  
>
>>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).
>>    
>>
>
>ubuntu currently ships madwifi. Madwifi-ng was considered, Adam Conrad
>even prepared some test packages for dapper, but it seems that there
>were problems. Last time I asked Scott, he told me that dapper will most
>likely stay with madwifi. I think that the inclusion of madwifi-ng will
>be reconsidered end May or somewhen in June.
>  
>

Well, I hope we can co-ordinate that, I have already madwifi-ng prepared 
for debian. And i would't mind assisting with ubuntu's effort if pointed 
in the right direction.

>  
>
>>There is currently discussion on the hostap mailing list about adding 
>>dbus communication sockets to wpa_supllicant and friends, iirc.
>>    
>>
>
>This would be very useful for the NetworkManager developers, who manage
>quite everything via dbus (dhclient, etc.).
>
>
>So, in a nutshell, we can support 3 different modes of operation:
>
>1. Managed mode in /etc/network/interfaces:
>
>example /etc/network interfaces:
>
>iface wlan0 inet dhcp
>	wpa-conf managed
>	wpa-driver madwifi
>	wpa-psk	deadbeefandmuchlongerkey 
>
>wpasupplicant daemon is running as long as the interface is if-up'ed
>
>2. User provided configuration
>
>example /etc/network interfaces:
>
>iface wlan0 inet dhcp
>	wpa-conf /home/user/.wpa/wpa_supplicant.conf
>
>
>wpasupplicant daemon is running as long as the interface is if-up'ed,
>the user has to provide a usable wpasupplicant configuration by copying
>an example template from /usr/share/doc/wpasupplicant/examples and
>editing it.
>
>3. Roaming mode
>
>example /etc/network interfaces:
>
>iface wlan0 inet dhcp
>
>wpasupplicant is started via /etc/init.d/wpasupplicant, and waits for
>the interface to come up. This is what the OP poster of this thread
>would want to use. Note that this mode won't work on machines affected
>by #350963. 
>
>This mode is activated in /etc/default/wpasupplicant. 
>
>
>Did I miss other modes of operation? 
>
>  
>

I think you've covered it okay.

Thanks, Kel.