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.
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.
But, if nobody agrees on the future direction, it's not going
to get any better.
> 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.
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.
For example, on my box (Aironet+Prism54), I have :
------------------------------------------------------------
# iwlist event
eth0 Wireless Events supported :
0x8B04 : Set Frequency/Channel (kernel generated)
0x8B06 : Set Mode (kernel generated)
0x8B13 : Spy threshold crossed
0x8B15 : New Access Point/Cell address - roaming
0x8B19 : Scan request completed
0x8B1A : Set ESSID (kernel generated)
0x8B2A : Set Encoding (kernel generated)
0x8C00 : Tx packet dropped - retry exceeded
prism0 Wireless Events supported :
0x8B04 : Set Frequency/Channel (kernel generated)
0x8B06 : Set Mode (kernel generated)
0x8B13 : Spy threshold crossed
0x8B15 : New Access Point/Cell address - roaming
0x8B1A : Set ESSID (kernel generated)
0x8B2A : Set Encoding (kernel generated)
0x8C02 : Custom driver event
------------------------------------------------------------
If you want to try looking into that, give me a shout. Adding
support for that in a driver is really trivial. Once this is settled,
I think it will make your code more robust.
Actually, you may want to add in your code a big FAT warning
for wireless drivers that don't support the feature. That will reduce
your bug reports and motivate drivers authors to support it.
> 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.
On the other hand, I agree that using signal quality is not
going to work reliably, because it was not designed for that.
> 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 don't know why you consider that ugly. If the network layer
allow you to UP an interface without an IP address, it means that you
are expected to us it. DHCP need to UP the interface without an IP
address to send requests. If I want to tcpdump or use monitor mode, I
need UP the interface. I don't understand why you would want an
exception to the rule for ifplud, where both DHCP and tcpdump have
none.
Have fun, and keep up the good work.
Jean
-
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
