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 [EMAIL PROTECTED] | ICQ# 74513189 | GPG-Keyid: 4743206C JID: [EMAIL PROTECTED] | http://people.debian.org/~nomeata -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
