On Wed, 31 Aug 2005 10:52:54 -0700, Jean Tourrilhes wrote: > I personally consider that a bug in ifplugd. For example, the > hp100 Ethernet driver will start media sensing only in the open() > call, which means that ifplugd won't work on the hp100 driver. > It would be trivial to fix ifplugd to open the device without > an IP configuration before doing media sensing. If the device doesn't > have an IP config, it won't be used by the networking > layer. Similarly, when ifplugd doesn't want anymore to use an > interface, it remove the IP address from it and leave it up.
I thought this was done by not passing the -a parameter to ifplugd. > The other problem is that not all drivers/technologies > implement media sensing. The media-sensing API is part of the specific > Ethernet API, not the generic network API, which make sense. If you > think about it 2sec, media sensing does not make sense in 802.11 > Ad-Hoc mode, neither in Master mode. Having tools or distro depending > on it at this stage seems quite foolish to me. It does make sense in ad-hoc mode. AP mode is indeed a special case - and not only in media sensing. Startup scripts have to deal with AP mode specifically anyway. > Anyway, it seems that ifplugd itself see media sensing has not > trivial and has many options to do media sensing, and had many changes > in that part, so they don't see that as totally clear and > straightforward. Because there is no common standard? Every driver should do this the same way. > Having the MAC address before open() is not mandatory. I > specifically designed ifrename with a *wide* variety of selectors, so > that user could address trivially cases where the device doesn't have > a MAC address at boot up, and the man page makes it clear that the MAC > address is not always present. But (at least part of) distributions recognize cards by MAC addresses. And I'm not sure there exists something better than MAC address to distinguish cards. > For example : > ---------------------------------------- > ipw* driver ipw2100 > ---------------------------------------- > would work properly on your driver even if you don't read the > MAC address until open(). And if you have two ipw2100 cards? > Correct, however the problem is not WE per say. We are not > going to change the networking scripts of all existing distribution to > add a specific call to associate wireless devices. And then change all > the existing wireless drivers. I'm not for specific call for association. But I don't think that the problem you described is really a problem - when the device is opened without performing association call, association can be requested automatically by ieee80211 layer before driver's open method is called. > And the actual solution is quite trivial, the driver just > needs to cache the wireless settings if the card is not up. A few > driver do that already, such as orinoco.c, airo.c, atmel.c and > ray_cs.c. And the Wireless Extension provides a bit of help through > the "commit" mechanism. > Personally, I don't see what the fuss is about. It's about the problem with MAC address availability. > Actually, it's already unified, and the right way. And it > works today for a wide range of cards/drivers. Great to hear it. Unfortunately it doesn't seem that everybody agrees. > By the way, how do you define "fully configured" ? If I want > to connect at home or at a random hotspot, the default configuration > of most device (mode=managed ; essid=any ; wep=off ; ip=dhcp) is just > what I want, and therefore I don't need to "configure" the device. So you have the card fully configured (i.e. the default configuration is enough for you) and you can just do ifconfig up. > There are patches on my web page adding Wireless Extensions > over RtNetlink, which seems exactly like what everybody is clamoring > about. They have been sent a couple of time to this mailing list. To > date, I've received *zero* feedback on those. We will take a look. -- Jiri Benc SUSE Labs - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
