James Ketrenos wrote :
>
> When last we looked at this, step 4 was being handled by ifplugd only
> after IFF_RUNNING or carrier_detect indicated link, which with wireless
> is potentially not possible until after step 7.
So, basically you want to change all wireless driver and all
distro scripts to accomodate the need of ifplugd. Hmm...
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.
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.
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.
> Although I believe some hardware can't detect MAC until after the fw is
> loaded. So, we might want to require that hotplug scripts not attempt
> to rename the interface until after it has been opened. The rub there
> being that (IIRC) ifrename requires the interface to be down in order to
> rename it...
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.
For example :
----------------------------------------
ipw* driver ipw2100
----------------------------------------
would work properly on your driver even if you don't read the
MAC address until open().
If you have another idea for a nice selector that could
replace the MAC address (I don't know, serial number, or whatever), I
can add that to ifrename.
Jiri Benc wrote :
>
> As we definitely don't want to add a new
> WE (or some other) call to perform this, the only call we can use for
> telling the driver "ok, now it's the time to associate" is ifconfig up.
> So opening the card should follow its configuration.
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.
> And yes, this brings up the problem with firmware loading. It should
> really be solved, but trying to solve it by requiring to bring the card
> up before it is configured is the bad way.
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.
> Today, some cards require to be brought up before they are configured
> and some require it in the other order.
The network scripts of every single distribution configure the
card before bringing it up, and every single driver I've worked on
support that. Cards that require being up before configuration just
won't work.
There is even a few driver that don't support configuration
after beeing brought up (ray_cs).
> And when the unification is performed, why not do this the
> right way?
Actually, it's already unified, and the right way. And it
works today for a wide range of cards/drivers.
> (*) Because it's not good idea to start association before wireless is
> fully configured.
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.
Peter Jones <[EMAIL PROTECTED]> wrote :
>
> I don't think that's really right either. For one thing, things like
> DHCP's timeout start counting at about the same time as "ifconfig up",
> and association can take some time.
That's a bug in DHCP, and DHCP should be fixed.
A nice analogy is Ethernet. The Ethernet layer doesn't enforce
that the user has plug the Ethernet cable in the right port at bootup,
or any port at all, for that matter. Actually, I would like my
Ethernet connection to work even if I plug the Ethernet cable a few
minutes after having booted the box. DHCP should not time out so
easily.
Even better, I should be able to plug my laptop in any
Ethernet port when I want and move from one port to another without
having to reboot the laptop or to mess with the network stuff.
Also, maybe I'm connected to my switch, but Oops, I forgot to
connect the switch to the network. It would be nice if it would work
when I eventually connect my switch to the network.
The situation with IEEE802.11 is not any different, the
"cable" just takes a bit more time to be plugged that the average
Ethernet. But, 802.11 is hardly the worse, DHCP over BlueTooth or
ZigBee is not going to happen instantly.
> But why don't we want to add a call to do this? I'd agree that it
> shouldn't be a WE call.
I know quite a few people still using Red-Hat 9. How are you
going to retrofit already deployed distro with your new call ?
> There seemed to be general agreement at OLS
> last month that we should really be using netlink for this stuff anyway,
> and it doesn't seem like adding a netlink call is all that painful.
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.
Have fun...
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
