On Fri, 02.09.05 10:34, Jean Tourrilhes ([EMAIL PROTECTED]) wrote: > > Lennart Poettering wrote : > > > > It is simply not true that all current > > network drivers set IFF_RUNNING correctly. ifplugd does the best it > > can to detect the carrier, but is still incompatible out of the box > > with some drivers. To write carrier detection code that works reliably > > on most drivers since kernel 2.4 is a great mess, especially when it > > comes to wireless drivers. > > In my e-mail, I personally acknowledge the issue, and I would > certainly not blame you for this issue. As I said, part of the problem > is the constantly changing APIs, which result in confusion at the > driver level. And I also admited that driver support was not up to > scratch.
Sorry, I didn't want to insult you. I don't even think this is your fault. The API is there, it's just that there re only few drivers that implement this fully. ;-) > Another part of the problem is that the notion of carrier > detection only apply to some technology (mostly Ethernet). With > Wireless, there is no notion of carrier. You can somewhat *emulate* it > using the association, but that work only in Managed mode. If you are > in Ad-Hoc or Master mode, there is simply *no* way to emulate any > carrier sense. I acknowledge that problem. In fact I doubt that ifplugd is the way to go for wireless adapters. It's fine for copper ethernet, but for WLAN it isn't very useful since you need some kind of roaming software. > By the way, at your explicit request I've added support for > Wireless Event detection in Wireless Extension 17 and some wireless > drivers. The patches for drivers are slowly making their way through > the maintainers. Hmm, on normal (i.e. non-WLAN) drivers there is unfortunately no way to detect if IFF_RUNNING reflects the link beat. And ifplugd is primarily intended for copper ethernet. > > In case of wireless LAN, ifplugd uses some kind of heuristics > > depending on the AP address set and the signal quality. This works > > mostly, but is admittedly exceptionally ugly. However ou shouldn't > > complain to me about that, tell it the driver writers! > > Could you tell me which driver are buggy in reporting the AP > address ? The iwconfig man page is pretty explicit about the expected > behaviour (at the bottom). I personally had great success using the AP > address stuff in a project I did, but I admit I've never tested all > drivers. The problem was that the AP address wasn't reset if the association failed or the signal was lost. As soon as a new network became available the new AP address was stored in the AP field. I don't know if this a real bug or if it's not. But it ultimately resulted in that I combined the signal quality with the AP address as a hint if an AP was found and it was still available. On the other hand other drivers didn't update the signal quality when the AP association was lost. It justed freezed. All in all this was ugly and just some kind of "works mostly" heuristics. But anyway, I don't think that ifplugd is the right way to go for WLAN devices, so this issue doesn't matter much. I hope that that wpa_supplicant will become some kind of successor to ifplugd+waproamd when it comes to WLAN. BTW: Ist there now a clearly defined API to disable hardware based roaming? Something similar to hostap's "host_roaming" iwpriv flag? For writing a really good successor to waproamd one would need network drivers that set IFF_RUNNING correctly based on the association status, support scanning and allow disabling of "firmware roaming". > > BTW: In addition that not all APIs work everywhere, some drivers > > require the interface to be UP and some do not. This is really bad > > too, since ifplugd now has to up the interfaces unconditionally to be > > able detect the carrier out-of-the-box. To stay compatible with > > applications ifplugd removes all assigned IP addresses, but I consider > > this still ugly. > > Almost NONE of the wireless drivers do anything until UP. And > the general consensus seems that they should not. And if I bring an > interface down, I expect that it stop any wireless activity at all, > because for driver statically in the kernel that's the only way to do > it. Which means no association when the driver is down. And the > 'ifconfig up' time is the only time where a driver can sanely load > it's firmware (check Jame's e-mail). Therefore, this is not > negociable. I guess you're right with this for WLAN drivers. But what about ethernet drivers? Why shouldn't they allow checking for the link beat with the ethtool or MII ioctls when they are not UP? Lennart -- Lennart Poettering; lennart [at] poettering [dot] de ICQ# 11060553; GPG 0x1A015CC4; http://0pointer.de/lennart/ - 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
