[pkg-wpa-devel] Bug#360387: new mode 3 proposal

Sun Apr 2 20:02:01 UTC 2006

Hi,

thanks for the quick answer. I'll reply, but I guess my other proposal
superseded this.

Am Sonntag, den 02.04.2006, 21:45 +0200 schrieb Reinhard Tartler:
> On Sun, Apr 02, 2006 at 09:07:58PM +0200, Joachim Breitner wrote:
> > The big advantage of this is that
> >  a) you can have different ifupdown settings for different locations. I
> > have quite complex stuff configured there (e.g. different VPNs to be put
> > up, modifying /etc/ld.preload for tsocks, etc). 
> 
> Why isn't this possible in action scripts as well?
Maybe I got them wrong, but it seems that the action script seems not be
able to select a different virtial interface, correct me if I'm wrong.

I hope you are not suggestion that I re-implement the complete
ifup.d/ifdown.d and guessnet logic in the action script?

> >  b) cat /etc/network/run/ifstate says what devices are _really_ up, not
> > what wifi devices are sitting and waiting for access points.
> 
> Do you really rely on this?
It's convinient, one cronjob that has to run every two minutes when WLAN
is up uses that, and I see no reason why this should not be the
authoritive source of network status, including for things like
notification areas.

> Does this really get updated when you loose
> connection to your location in the old method?
Yes, that is the beauty.

> >  c) /e/n/interfaces configs refer to _networks_, not hardware, which
> > makes a log of sense IMHO
> 
> Well, this is a quite philosophical argumentation. You cannot really
> argue that 'lo' more a network than a device, but you configure it in
> /e/n/i as well. 
I do think of lo as a network, a pretty lonely one. In this case, of
course, the corresponding device connects _only_ to this network, but in
the other cases, the device are usually reused all over the place.

> The mapping thingy in ifupdown can be used to describe networks. But I
> think this is rather a hack than a well designed feature.
I think it is a very nice feature - how else would you configure
different networks that you attace with the same device, independent of
wpasupplicant - same problem with wired networks.

> > With this wpa-action command (which seems like yet an other point during
> > interface upbringing where to run commands), I can no longer
> > differentiate the different physical networks
> > _in_ /etc/network/interfaces, unless of course I did not understand it
> > correctly.
> 
> You can of course differentiate between physical networks. It is a plain
> shellscript, so you can call any command you want, including whereami or
> 'wpa_cli status', which I would suggest to learn your current ssid.
Oh, I see. But there is already a lot of well proven code for all that
in ifupdown - let's continue to use that.

> > A possible further way, which might neatly integrate into ifupdown, just
> > crosses my mind:
> > Why not use wpasupplicant as a mapping script, from ifupdowns POV? For
> > every different WLAN I would want to connect to, I have a separate
> > virtual device in /e/n/i, kind of like with guessnet. ifupdown calls
> > some script as a mapping script, which will fire up wpa_supplicant and
> > wait, until wpa_supplicant could connect to one of these defined
> > networks, and then return to ifupdown the virtual interface name of the
> > associated network. 
> 
> Interesting idea, I never thought about this before. But unfortunately,
> I don't get the point about this setup. In that mapping script, you
> would have to start wpasupplicant as daemon, and then wait for it to
> call the action script to call back (via some state file or other
> facility) and tell you the location wpasupplicant has connected right
> now. This is returned then to ifupdown (what should happen at this point
> if authentication fails or no AP is available?)
The mapping script would just wait for that long time. Not what ifupdown
expects, but should not be a problem, I guess.

> Then ifupdown maps the current location and configures the interface
> described for this mapping. the ifupdown scripts needs to detect that
> the interface has already been set up and only need to configure it.
Which is already the case, with the old mode3 and works

> Is this really worth the efford? To me, it seems that there is a lot of
> efford just to keep this ifupdown mapping feature alive. Whats the
> problem with configuring the interface in the action script? For more
> complicated setups, there is wherami. I'm currently working on decent
> integration with whereami currently.
See above. One would have to reimplement basically all of ifupdown in an
action script. I really think that that's the wrong way.

> > This would have the advantage that is just an extension of mode 1, i.e.
> > if you want to "upgrade" from mode1 to mode3, you just add the mapping
> > line and add interfaces as you wish.
> 
> Instead of keeping the mapping feature of ifupdown alive, I'd rather
> vote for working on a more generic action script, and provide the user
> facilities to configure his location more easily than what we currently
> have today.
> 
> Given that there is work on providing dbus support for wpasupplicant, it
> seems to me that the future lies in writing a roaming daemon, which
> interacts with wpasupplicant in a nice way to learn the current location
> and configure the interface to the location's and user's needs.
> Currently, I know only of network-manager doing something like this, but
> I don't think that there can't be an alternative to that.
Sounds good, as long as I can use /e/n/i to differentiate beween these
configs, and not some roughly hacked script. I hope you can understand
my concern there. But see the other proposal.

Thanks,
Joachim
-- 
Joachim "nomeata" Breitner
Debian Developer
  nomeata at debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: joachimbreitner at amessage.de | http://people.debian.org/~nomeata