On Fri, 02.09.05 11:40, Jiri Benc ([EMAIL PROTECTED]) wrote: > On Thu, 1 Sep 2005 10:04:22 -0700, Stephen Hemminger wrote: > > By the way, last time I looked at the ifplugd source it was using > > outdated and incorrect ways to detect carrier. It should just > > open a netlink socket and wait for carrier event. Instead it seems > > to muck around looking at MII, wireless API and other ways > > that only work on some devices. In current kernels, all > > network devices report carrier the same way. > > Thanks for clarifying that. I suspected this, but wasn't sure. > > Are there any plans to improve ifplugd?
If you look on the ifplugd source code closely you'll see that it *does* make use of netlink. However, due to compatibility reasons it doesn't rely on it exclusively. 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. The worst thing about it, is that there is no way to detect if IFF_RUNNING works correctly so that one can disable all those kludges and hacks if a sane network driver is present. And even if all drivers in the newest kernels would support IFF_RUNNING correctly, it would be a bad idea for ifplugd to drop compatibility with kernels 2.4. If ifplugd doesn't work on some type of hardware I usually get the bug reports, altough I encourage people to report the bugs upstream I guess people seldomly do that. Even newer projects such as HAL don't rely on netlink/IFF_RUNNING exclusively, but use SIOCDEVPRIVATE, SIOCGMIIPHY and friends. Yes, it would be nice if IFF_RUNNING would be supported everywhere, but sorry, still isn't the case right now. 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! And why do you say that ifplugd uses "incorrect" ways to detect the carrier? ifplugd currently supports five ways to detect carrier: - SIOCGMIIPHY - SIOCDEVPRIVATE - SIOCETHTOOL - IFF_RUNNING - some heuristics based on the AP and the signal quality If the user doesn't specify which API to use the methods are checked are checked in this order: 1. SIOCETHTOOL 2. SIOCGMIIPHY 3. WLAN 4. IFF_RUNNIING (unfortunately not detectable) SIOCDEVPRIVATE is not used, because it is nowadays seldomly needed. So, please tell me, which of these ways is "incorrect"? 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. Just recently I implemented a netlink/IFF_RUNNING only solution to detect network carriers for my free mDNS/DNS-SD implementation called Avahi (http://www.freedesktop.org/Software/Avahi). (Avahi has to make sure that all its resource records are still unique whenever a network cable is plugged in) It didn't take a single day for the first bug report about that. (the offender was some kind of WLAN driver) So I had to disable checking for IFF_RUNNING and everything was bright again. The situation really sucks, but ifplugd still makes the best of it. 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
