On Thu, 2005-09-01 at 16:48 +0200, Jiri Benc wrote:
> On Thu, 01 Sep 2005 11:09:16 +0100, Pedro Ramalhais wrote:
> > The scheme looks good to me. Wireless cards mostly map to a regular
> > network card. Only difference is that you need to do something to
> > configure the link to have "carrier detected" and DHCP should only be
> > started after "carrier detected" (IFF_RUNNING IIRC).
>
> The fact that DHCP should be only started when carrier is detected is
> not wireless-specific.
>
Sorry, english is not my natural laguange. I was just stating the
obvious. Not related to the diference i was talking about.
> > Regarding association only on explicit userspace request, that's fixable
> > in the drivers (some drivers automatically associate once they're
> > ifconfig'ed up, the ipw2x00 drivers have a module parameter to change
> > this behaviour).
>
> ipw drivers are broken in this manner as they try to associate right
> after modprobe. No card should do anything unless it is explicitly told
> so - policy is the matter of user-space, not the kernel. Startup scripts
> in distributions are the right place for instructing a card to
> associate.
scripts, daemons, apps, whatever the distro/user wants to use.
>
> Sure, this is fixable in drivers. And it really needs to be fixed. Even
> more, I think it should be forced by ieee80211 layer.
>
You mean something like not allowing the driver to send an event
association through the ieee80211 layer or accept traffic until the
layer is configured correctly? That would probably work.
> > > 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.
> >
> > Why is it the "wrong way"? I don't see a big problem with this, the card
> > is only going to be used after it's UP. The only problem i see is that
> > it doesn't behave exactly like most network drivers, where they are able
> > to detect a link even when they're DOWN. Is there a good reason for a
> > card to do anything even when it's DOWN?
>
> You seem to agree with me :-) A card in DOWN state should do nothing. In
> particular, it shouldn't associate.
>
At least i don't see any reason why it should do anything. If someone
knows of something that could be useful during the DOWN state i'd like
to hear it.
> But it should be configurable. And it is really necessary that we can
> tell a card that we are done with configuration so it can associate. The
> easiest place for doing this is bringing the card to UP state.
>
I fail to see why configuration needs to be done in the ifconfig up
stage.
I tend to think of a wireless card as a normal ethernet network device.
And you can map one to the other easily.
In the case of a normal network card, link state means the state of the
path between the card and another equipment (a switch or another card
with a crossover cable) and successful ethernet negotiation.
In the case of a wireless card, it means the successful association with
an access point, ad-hoc network (always link up?) or master mode (always
link up?).
There are user configurable things in both cards regarding the link: in
network cards you have the cable, in wireless cards you have wireless
association configuration AND policy.
After saying that, think about this: in a network card you can ifconfig
the card UP and connect the cable later (bringging the link up), so you
should be able to do the same thing with a wireless card: ifconfig up
and then configure the card so that it establishes a link.
> > Right, that would need a new interface where all parameters are passed
> > at once,
>
> Then you will lose the possibility of having default parameters.
>
Not really, there can be default parameters like channel=0 or -1,
essid_len=-1, AP bssid=00:00:00:00:00:00 or FF:FF:FF:FF:FF:FF, etc... or
a bitfield with flags for each parameter being set. The bitfield would
be nice so that you wouldn't need to pass all the parameters (even the
default ones) like the radiotap headers.
> > or keep the existing interface and add another just to
> > explicitly associate.
>
> Is there any reason not to do this by bringing the card up ("ifconfig up")?
Yes, i might want to bring the card UP so that it can scan, but don't
want to associate. Or bring the card UP and configure the card in
Monitor mode. Or bring the card UP and configure the card in Master
mode. Maybe ad-hoc too, not sure.
>
> > Besides that, there should also be a way to configure if you want to
> > auto-associate to new access points if the old access point becomes
> > unavailable or with a weaker signal than the new one, or if you want to
> > manually associate, ex: association is done once and never tried again
> > until you tell it to do so. The manual association would be a good thing
> > for a wireless managed, where it would have the work of handling new
> > networks, APs becoming unavailable and available again, etc.
>
> Yes. If the new AP is in the same ESS, that should be done automatically
> (if not explicitly disabled e.g. by setting of explicit BSSID).
> Of
> course you may sometimes want to force reassociation manually - and
> there should be some call available for this. (Maybe setting BSSID while
> the card is running should force reassociation?)
That's the kind of hackish solution that brings confusion. We should
separate things: wireless configuration and wireless association. This
way you won't have to do those hackish approaches and special cases.
What i mean is that if you want to associate, tell the card to do so,
don't send -1 as the channel or send 0 as the essid_len, or resend the
previously configured essid.
>
> If you want to change SSID (i.e. associate to a completely new network)
> I can imagine that you will be forced to bring the card down, change
> settings and bring it up again (but I don't insist on it as it is not
> necessary - bringing the card down and up again can be done internally
> by ieee80211 layer in such case).
>
>
I would prefer: set the ESSID and then tell the card to associate again.
EX:
iwconfig eth0 essid NEWESSID
# oooops, wrong ESSID
iwconfig eth0 essid NEWESSID2
iwconfig eth0 associate
And it could also be possible to do it all at once:
iwconfig eth0 essid NEWESSID3 channel 11 bssid 11:22:33:44:55:66
associate
Maybe you could configure it with the default association policy you
want with the new association:
iwconfig eth0 associate auto
This would automatically select the best AP continuosly between APs
compatible with the active configuration (same bssid, better signal
strength, etc..). I'm not sure that this is good to have in the kernel,
i've seen ideas to have a daemon that complements the kernel iee80211
stack similar to hostapd, maybe it would be better to be there in
userspace.
or:
iwconfig eth0 associate manual
which would be useful for using userspace daemons/apps to manage
associations and association policy.
Just ideas...
--
Pedro Ramalhais <[EMAIL PROTECTED]>
-
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
