Hi Everybody,
I'm new on linux-wireless mailing list.
In the recent past I completed my diploma thesis, which included some software implementations with the Madwifi driver. In future the compact-wireless driver (with ath5k) will be used for Atheros Chipsets.
So - I'm very interessted to keep an eye on the development of the compact-wireless driver.
Maybe I can be a part in enhancing the driver in the future.
But first, I have a few questions to you:
How does the compact-wireless driver handle the case, when a connection of a STA to an AP gets lost?
Is there a solution for "fast handovers" between two APs?
Are there any activities to implement something like a "background scanning" in STA Mode?
A background scanning will allow a STA to observe the neighbourhood for new APs.
There are a few drivers that provide this functionality today.
The intention is to reduce Handover latency of a mobile STA, when it switches from one AP to an other AP.
What do you think:
Is it interessting for you, to work jointly on these challenges?
Jens
On Mon, 2008-07-14 at 10:13 +0200, [email protected] wrote:
> Hi Everybody,
> I'm new on linux-wireless mailing list.
>
> In the recent past I completed my diploma thesis, which included some software implementations with the Madwifi driver. In future the compact-wireless driver (with ath5k) will be used for Atheros Chipsets.
> So - I'm very interessted to keep an eye on the development of the compact-wireless driver.
I think you mean "compat-wireless", right? In any case, we'll just take
that to mean mac80211-based drivers really since that's what we can
actually control.
> Maybe I can be a part in enhancing the driver in the future.
>
> But first, I have a few questions to you:
>
> How does the compact-wireless driver handle the case, when a connection of a STA to an AP gets lost?
Right now, the lowest-common-denominator is that the driver sends a
disconnection event to userspace, and userspace handles reconnection as
it sees fit. Some drivers may attempt to reconnect to the AP
periodically until told not to.
I personally think the driver/stack should try a few reconnections to
the AP (without sending the SIOCSIWAP disconnect event) and only if
those all fail, send the disconnect event. But if the reconnection was
successful, send the SCIOCSIWAP event for the AP even if it matches the
old AP's BSSID just so userspace knows that something happened.
wpa_supplicany may need to know this to rekey the connection or
something.
But really, the connection loss could be for any number of reasons, like
the AP is out of resources, out of range, missed a few beacons because
somebody turned a microwave on, etc. A few reconnection attempts might
help out some of these but at some point you just have to pick a new AP
to associate with.
> Is there a solution for "fast handovers" between two APs?
Do you mean two BSSs in the same ESS? In any case, roaming between to
BSSes of the same SSID is currently highly driver dependent and it's
pretty much assumed that drivers can choose which BSS to associate to
within the same ESS
Roaming between two APs _not_ in the same ESS is currently left to
userspace.
> Are there any activities to implement something like a "background scanning" in STA Mode?
Some drivers already do this (ipw for example), but I don't think
background scanning is really implemented in mac80211 at this time.
mac80211 certainly will handle beacons and probe responses _on the same
channel_, but I don't believe there is any sort of multi-channel
background scanning going on, nor should there really be unless it can
be made _very_ fast. You don't want the driver doing a multi-channel
background scan while you're using VOIP.
> A background scanning will allow a STA to observe the neighbourhood for new APs.
Right.
> There are a few drivers that provide this functionality today.
> The intention is to reduce Handover latency of a mobile STA, when it switches from one AP to an other AP.
Again, within the same ESS?
> What do you think:
> Is it interessting for you, to work jointly on these challenges?
Personally I think anything we can do to make intra-ESS handover faster
is a good thing. wpa_supplicant in userspace is obviously required here
for WPA roaming and it can handle things like preauth and other bits of
fast reauth defined in the WPA specs. Since that's where things are
going, it's going to need coordination between both the driver and the
supplicant to get right.
Dan
Dan Williams <[email protected]> writes:
>> How does the compact-wireless driver handle the case, when a
>> connection of a STA to an AP gets lost?
>
> Right now, the lowest-common-denominator is that the driver sends a
> disconnection event to userspace, and userspace handles reconnection as
> it sees fit. Some drivers may attempt to reconnect to the AP
> periodically until told not to.
Are you talking about mac80211 drivers here? I haven't seen any
mac80211 driver do that.
> I personally think the driver/stack should try a few reconnections to
> the AP (without sending the SIOCSIWAP disconnect event) and only if
> those all fail, send the disconnect event.
Actually I disagree with this, because it might slowdown roaming too
much. The logic should be either in user space or in mac80211, but not
in both. Now it's implemented in user space and, in my opinion, that's
the best place.
> But if the reconnection was successful, send the SCIOCSIWAP event
> for the AP even if it matches the old AP's BSSID just so userspace
> knows that something happened. wpa_supplicany may need to know this
> to rekey the connection or something.
Yes, we have to send SIOCSIWAP event after every association.
>> Are there any activities to implement something like a "background
>> scanning" in STA Mode?
>
> Some drivers already do this (ipw for example), but I don't think
> background scanning is really implemented in mac80211 at this time.
My understanding is that mac80211 assumes user space to do this. I
think wpa_supplicant doesn't do that currently, it only issues a scan
if it receives a disassociation event.
(Please correct me if I'm wrong.)
> mac80211 certainly will handle beacons and probe responses _on the
> same channel_, but I don't believe there is any sort of
> multi-channel background scanning going on, nor should there really
> be unless it can be made _very_ fast. You don't want the driver
> doing a multi-channel background scan while you're using VOIP.
If the STA is stationary, then background scanning isn't that
beneficial, that's true. But if STA is moving, when there are benefits
from background scanning because of faster roaming. I haven't measured
it ever, but I assume that background scanning and roaming to an
another AP beforehand is always faster than loosing a connection.
The way I see this is that mac80211 should follow the connection
quality (RSSI, transmission failures, beacon losts, etc) and signal
userspace if the connection quality gets low and the signal would then
trigger background scanning in user space. If the signal gets better,
mac80211 would send a signal stating so and user space would turn off
background scanning.
If background scanning affects the normal data transfer too much
we can always try to optimise the scan, for example by scanning every
third channel at a time or something similar.
>> A background scanning will allow a STA to observe the neighbourhood
>> for new APs.
>
> Right.
>
>> There are a few drivers that provide this functionality today. The
>> intention is to reduce Handover latency of a mobile STA, when it
>> switches from one AP to an other AP.
>
> Again, within the same ESS?
I think he is talking about roaming in same ESS here.
>> What do you think: Is it interessting for you, to work jointly on
>> these challenges?
>
> Personally I think anything we can do to make intra-ESS handover faster
> is a good thing. wpa_supplicant in userspace is obviously required here
> for WPA roaming and it can handle things like preauth and other bits of
> fast reauth defined in the WPA specs. Since that's where things are
> going, it's going to need coordination between both the driver and the
> supplicant to get right.
I'm very interested about this as well. I expect to work on this more
in a month or two.
--
Kalle Valo
On Thu, Jul 17, 2008 at 8:42 AM, Kalle Valo <[email protected]> wrote:
> Dan Williams <[email protected]> writes:
>
>>> How does the compact-wireless driver handle the case, when a
>>> connection of a STA to an AP gets lost?
>>
>> Right now, the lowest-common-denominator is that the driver sends a
>> disconnection event to userspace, and userspace handles reconnection as
>> it sees fit. Some drivers may attempt to reconnect to the AP
>> periodically until told not to.
>
> Are you talking about mac80211 drivers here? I haven't seen any
> mac80211 driver do that.
>
>> I personally think the driver/stack should try a few reconnections to
>> the AP (without sending the SIOCSIWAP disconnect event) and only if
>> those all fail, send the disconnect event.
>
> Actually I disagree with this, because it might slowdown roaming too
> much. The logic should be either in user space or in mac80211, but not
> in both. Now it's implemented in user space and, in my opinion, that's
> the best place.
>
>> But if the reconnection was successful, send the SCIOCSIWAP event
>> for the AP even if it matches the old AP's BSSID just so userspace
>> knows that something happened. wpa_supplicany may need to know this
>> to rekey the connection or something.
>
> Yes, we have to send SIOCSIWAP event after every association.
>
>>> Are there any activities to implement something like a "background
>>> scanning" in STA Mode?
>>
>> Some drivers already do this (ipw for example), but I don't think
>> background scanning is really implemented in mac80211 at this time.
>
> My understanding is that mac80211 assumes user space to do this. I
> think wpa_supplicant doesn't do that currently, it only issues a scan
> if it receives a disassociation event.
>
> (Please correct me if I'm wrong.)
>
>> mac80211 certainly will handle beacons and probe responses _on the
>> same channel_, but I don't believe there is any sort of
>> multi-channel background scanning going on, nor should there really
>> be unless it can be made _very_ fast. You don't want the driver
>> doing a multi-channel background scan while you're using VOIP.
>
> If the STA is stationary, then background scanning isn't that
> beneficial, that's true. But if STA is moving, when there are benefits
> from background scanning because of faster roaming. I haven't measured
> it ever, but I assume that background scanning and roaming to an
> another AP beforehand is always faster than loosing a connection.
>
> The way I see this is that mac80211 should follow the connection
> quality (RSSI, transmission failures, beacon losts, etc) and signal
> userspace if the connection quality gets low and the signal would then
> trigger background scanning in user space. If the signal gets better,
> mac80211 would send a signal stating so and user space would turn off
> background scanning.
>
> If background scanning affects the normal data transfer too much
> we can always try to optimise the scan, for example by scanning every
> third channel at a time or something similar.
>
>>> A background scanning will allow a STA to observe the neighbourhood
>>> for new APs.
>>
>> Right.
>>
>>> There are a few drivers that provide this functionality today. The
>>> intention is to reduce Handover latency of a mobile STA, when it
>>> switches from one AP to an other AP.
>>
>> Again, within the same ESS?
>
> I think he is talking about roaming in same ESS here.
>
>>> What do you think: Is it interessting for you, to work jointly on
>>> these challenges?
>>
>> Personally I think anything we can do to make intra-ESS handover faster
>> is a good thing. wpa_supplicant in userspace is obviously required here
>> for WPA roaming and it can handle things like preauth and other bits of
>> fast reauth defined in the WPA specs. Since that's where things are
>> going, it's going to need coordination between both the driver and the
>> supplicant to get right.
>
> I'm very interested about this as well. I expect to work on this more
> in a month or two.
>
I think Cisco APs implements fast roaming ... intra-ESSI think they
made it also to 802.11r. So there is no much invention
just implement the spec :) http://en.wikipedia.org/wiki/IEEE_802.11r.
For regular roaming you need background scanning. Such scanning should
be rather limited to not hurt performance.
The best known approach to me is using direct scan scan to known
possible AP. Yet there is no notion
of a profile in mac80211 or wext. So you cannot set bunch of SSIDs to
be scanned for to find appropriate roaming candidate in background.
Iwlwifi HW has this infrastructure but it's not used.
The other approach is limit number of channels in each round of the scan.
Tomas