[pkg-wpa-devel] What's wrong with the new configuration scheme, IMO

[kelrin at tpg.com.au]

Quoting Felix Homann <fexpop at onlinehome.de>:

> On Friday 21 April 2006 14:50, Reinhard Tartler wrote:
> > Well, we don't prevent using the package as it has been used
> before, we
> > now even provide the init script in the examples/ directory again.
> >
> > But we don't want to have it installed by default, because we
> really
> > don't think that this belongs in the wpasupplicant package.
> 
> It's been the package maintainers who once put the script into
> /etc/init.d and  
> thus suggested using it. So it should be the package maintainers
> obligation 
> to only remove it if there's a clean way not to break working
> systems.
> 
> > I have made some thoughts about a package which works like this:
> >
> >  * Start wpasupplicant as system service (daemon).
> 
> Good idea ;-)
> 
> 
> >  * Make the daemon use an action script.
> >  * the action script checks what location we connected to (look at
> the
> >    essid), and does this:
> >    * determine which network alias in /e/n/i this location is
> associated
> 
> I guess that this isn't necessary in a lot of cases, since DHCP is
> very common 
> in the wireless world.
> 
> >    * call ifupdown like this: 'ifup $IFACE=$LOCATION'
> >  * On disconnection, the action script ifdowns $IFACE
> 
> Why not integrate nicely with existing packages: let ifplugd do this
> task.
> 
> >
> > This package makes the following assumptions:
> >
> >  * Only one interface is to be managed
> 
> Why this restriction? Would it make the action script too complex?
> (Then you'd 
> better use ifplugd+guessnet; you can easily run 1 wpa_supplicant for
> 2 
> interfaces or 2 wpa_supplicants for 2 interfaces.)
> 
> >  * by default, it assumes that the alias in /e/n/i matches the
> essid
> >  * otherwise check a mapping file [optional]
> 
> Then I would have to edit wpa_supplicant.conf and /e/n/i for every
> single AP I 
> want to connect to even if they are all using DHCP? 
> 
> > Problems which I still have to think about:
> >
> >  * What happens if we connect to a yet unconfigured location?
> 
> It should not happen without user interaction.
> 
> >  * What if there have been no locations configured yet? (shall
> >    wpasupplicant run anyway, allowing managing of
> wpa_supplicant.conf
> >    via wpa_cli/wpa_gui, or should it doesn't start the daemon at
> all?)
> 
> Ask the user on install. 
> 
> >  * ifdown will bring the link down. Does this confuse wpasupplicant
> too
> >    much?
> 
> No problem on my machine.
> 
> > I think this follows the guessnet/ifplugd configuration scheme, but
> I
> > haven't looked too much into guessnet yet.
> 
> It's actually so very close to a wpa_supplicant+ifplugd+guessnet
> (I'll call it 
> WIG) setup that I'd rather suggest to put the init script back into 
> wpasupplicant (don't activate it by default) and add some
> documentation on 
> how to configure a WIG system.
> 
> I don't really stick to WIG - I know a lot of things a WIG system
> cannot 
> (easily) do - but the system you propose seems inferior, sorry. 

If its inferior, please submit a patch against wpasupplicant containing:

  * a wpasupplicant init script (nad related conffiles)
  * comprehensive documentation about howto use the "WIG" setup

Again, I would like to point out, that the lack of *any* official
documentation about this kind of setup was the catalyst for my writing
the ifupdown integration (unless I completely missed something).

This would of course mean you are not willing to allow wifiroamd summer
of code project time to prove itself, and just need this done within
wpasupplicant *now*. I am not sure this is the best cause of action,
considering a few other people have plotted and discussed a plan to
bridge the gap between the old setup and the existing one.

Thanks, Kel.