Johannes,
Back with som data regarding roaming.
Prerequisites
=============
Just for your knowledge I'm using the following equipment:
- RT61, mini PCI
- rt2x00.git / 1e0b4c51393308a98f2918db424c676cc99cf123
- Managed mode
- Wpa_supplicant 0.5.9
AP deauthentication.
=====================
When any of the ieee80211_rx_mgmt_deauth() or ieee80211_rx_mgmt_disassoc()
are executed, the mac layer takes two actions.
1) Tells wpa_supplicant what had happened.
2) Start reestabliching the connaction again.
The later action will stop or significantly delay the decisions/action taken
by wpa_supplicant as a result of action 1. Normally the supplicant will
start an AP scan.
But the mac layer is busy with reestablishing the link and will not start
any scan action.
My patches simply put the mac layer in IEEE80211_DISABLED state and wait for
the supplicant to decide.
Monitoring of a usable link to the AP.
======================================
The ieee80211_rx_h_sta_process() and ieee80211_associated() are involved in
monitors for dead AP connection. A last_rx value is set to indicate a
working connection.
The porblem is the following lines.
if (!is_multicast_ether_addr(hdr->addr1) ||
rx->sdata->vif.type == IEEE80211_IF_TYPE_STA) {
Any package that arrives to an STA will update the last_rx value and
prohibit a link lost action.
I have noticed in my system that this function receives the following type
of frames:
1) Broad cast frames from my BSS (beacons).
2) Data frames addressed to me ;)
3) Data frames from other STA addressed to other MAC addresses but using the
same BSS.
It is the case 3 that creates the problem. Another STA, closer to my BSS
will update my last_rx value even I do not receive the BSS.
I have made the following change:
if ( compare_ether_addr(hdr->addr2, hdr->addr3) == 0 &&
rx->sdata->vif.type == IEEE80211_IF_TYPE_STA) {
My last_rx will only be updated as long as I can receive frames from my BSS.
I might have to add some frame type validation, but it solved my problems.
Timeout handling
=================
When any of the ieee80211_authenticate() or ieee80211_associate() function
are executed.
The mac silently set its state to IEEE80211_DISABLED and waits for the
wpa_supplicant to timeout its current action.
I think it would be a good idea to signal to the supplicant that the
operation has timeout, and no further action will be taken.
To speed up the timeout response I had squeezed the supplicant timeout.
I have patches for all modification but it might be a good start to verify
that my suggestion is 'usabel'
Regards
Lars
Hi,
I have split my issues ito individual disussions:
> Timeout handling
> =================
> When any of the ieee80211_authenticate() or ieee80211_associate()
> function are executed.
> The mac silently set its state to IEEE80211_DISABLED and waits for the
> wpa_supplicant to timeout its current action.
>
> I think it would be a good idea to signal to the supplicant that the
> operation has timeout, and no further action will be taken.
> To speed up the timeout response I had squeezed the supplicant timeout.
>
> How do you signal that? Make a wext event with the BSSID all-zeroes or
something? Sounds ok.johannes
>
> Yeah, a zero-BSSID event would mean "disconnected" or "association failed"
and the supplicant would take over at that point.
>
I can check if zero-BSSID would do it.
/Lars
Hi,
> First, I was wrong about receiving frames from other STA using same AP. It
> was my fault.
Ok, no worries, just seemed weird to me :)
> Below (see attachment) is a trace from ieee80211_rx_h_sta_process()
> You can see the frames that will update the last_rx field.
So what's the problem with this trace? It means we update the last_rx
field whenever we receive a frame from the AP, no matter whether it's
for us or not. Is that wrong?
> In my code I have added a feature that monitors BEACONS from 'my' AP.
> When number of received beacons drops below 5 / 2 seconds, I assume out of
> range.
> I do not know if this is necessary but it gives faster roaming in the
> out-of-range scenario.
That is indeed a good feature and some hardware even has offload
capabilities for it, would be interested in seeing patches. Of course,
it can't be fixed to 5/2sec, it should be calculated based on the beacon
interval instead.
johannes
> > Does associating actually block scanning?
>
> If it doesn't, it really should. There's been a number of problems over
> the years with scan requests screwing up association because the card is
> on a different channel and misses the association/auth exchanges. To
> ensure that association/authentication is as robust as possible, the
> driver should refuse scans while association is ongoing.
Good point.
> > > My patches simply put the mac layer in IEEE80211_DISABLED state and wait for
> > > the supplicant to decide.
> >
> > That would break supplicant-less operation which we can't do.
>
> Yeah; roaming is an area that's somewhat underdefined right now. Wasn't
> there previous discussion of a knob to tell the driver that userspace
> was going to handle roaming? Could be wrong, but the driver doesn't
> always have all the details for roaming and there are times when
> userspace knows better. Could default to "driver" for roaming and then
> the supplicant could set it to "off" when it takes over.
Well you can set a fixed BSSID so mac80211 won't roam. I think
wpa_supplicant does that, but it still tries to re-auth if it lost the
connection and the AP is in range.
> Which brings up the other issue of auto-association by drivers, which is
> usually the wrong thing. Yeah, it makes 1337 kernel hackers in the
> woods happier because the card will be up automatically and associated
> with their single open AP, but it's pretty much a bad idea anywhere else
> (ipw2200 associate=1 for example). The driver should only be
> associating when it's told to do so, it shouldn't be going out and
> finding APs on it's own ever.
mac80211 never associates on its own afaik.
> > > I think it would be a good idea to signal to the supplicant that the
> > > operation has timeout, and no further action will be taken.
> > > To speed up the timeout response I had squeezed the supplicant timeout.
> >
> > How do you signal that? Make a wext event with the BSSID all-zeroes or
> > something? Sounds ok.
>
> Yeah, a zero-BSSID event would mean "disconnected" or "association
> failed" and the supplicant would take over at that point.
Right, that's a simple patch for somebody willing to dig through
ieee80211_sta.c
johannes
Hi,
I have split my issues ito individual disussions:
> Monitoring of a usable link to the AP.
> ======================================
> The ieee80211_rx_h_sta_process() and ieee80211_associated() are
> involved in monitors for dead AP connection. A last_rx value is set to
> indicate a working connection.
>
> The porblem is the following lines.
> if (!is_multicast_ether_addr(hdr->addr1) ||
> rx->sdata->vif.type == IEEE80211_IF_TYPE_STA) {
>
> Any package that arrives to an STA will update the last_rx value and
> prohibit a link lost action.
>
> I have noticed in my system that this function receives the following
> type of frames:
> 1) Broad cast frames from my BSS (beacons).
> 2) Data frames addressed to me ;)
> 3) Data frames from other STA addressed to other MAC addresses but
> using the same BSS.
>
> It is the case 3 that creates the problem. Another STA, closer to my
> BSS will update my last_rx value even I do not receive the BSS.
>
> I'm pretty sure case 3 can't create a problem there since rx->sta wouldn't
be set to the AP. Can you please print out "rx->sta->addr"
> after the !sta check in ieee80211_rx_h_sta_process and send me the log
indicating that we can actually get into there with sta != our own AP?
> If we can that's a bug elsewhere but I doubt it.
Ok. I will come back with a trace.
/Lars
Hi,
I have split my issues into individual discussions:
> AP deauthentication.
> =====================
> When any of the ieee80211_rx_mgmt_deauth() or
> ieee80211_rx_mgmt_disassoc() are executed, the mac layer takes two
actions.
> 1) Tells wpa_supplicant what had happened.
> 2) Start reestabliching the connaction again.
>
> The later action will stop or significantly delay the decisions/action
> taken by wpa_supplicant as a result of action 1. Normally the
> supplicant will start an AP scan.
> But the mac layer is busy with reestablishing the link and will not
> start any scan action.
>
> Does associating actually block scanning?
>
> If it doesn't, it really should. There's been a number of problems
> over the years with scan requests screwing up association because the
> card is on a different channel and misses the association/auth
> exchanges. To ensure that association/authentication is as robust as
> possible, the driver should refuse scans while association is ongoing.
>
>
> My patches simply put the mac layer in IEEE80211_DISABLED state and
> wait for the supplicant to decide.
>
> That would break supplicant-less operation which we can't do.
>
>
> Good point.
The patch might not work for all use cases,
but might be configurable for the wpa_supplicant.
The following trace is an example before the patch
where the STA roams from 60:00 to 84:20:
===========================================================
<4>[ 513.630484] LaE: ieee80211_associated: bssid=00:0f:24:d1:60:00, diff=
419, bcnt= 9, last: rssi=-78, signa= 23, noise= 0
<7>[ 513.964713] wlan0: RX deauthentication from 00:0f:24:d1:60:00
(reason=2)
<7>[ 513.964761] wlan0: deauthenticated
<7>[ 514.963454] wlan0: authenticate with AP 00:0f:24:d1:60:00
<7>[ 514.965015] wlan0: RX authentication from 00:0f:24:d1:60:00 (alg=0
transaction=2 status=0)
<7>[ 514.965060] wlan0: authenticated
<7>[ 514.965089] wlan0: associate with AP 00:0f:24:d1:60:00
<7>[ 514.975332] wlan0: RX ReassocResp from 00:0f:24:d1:60:00 (capab=0x431
status=0 aid=43)
<7>[ 514.975387] wlan0: associated
<7>[ 514.975429] wlan0: CTS protection enabled (BSSID=00:0f:24:d1:60:00)
<7>[ 515.002555] HW CONFIG: channel=1 freq=2412 phymode=2
<7>[ 515.066225] HW CONFIG: channel=2 freq=2417 phymode=2
<7>[ 515.130252] HW CONFIG: channel=3 freq=2422 phymode=2
<7>[ 515.194672] HW CONFIG: channel=4 freq=2427 phymode=2
<7>[ 515.258189] HW CONFIG: channel=5 freq=2432 phymode=2
<7>[ 515.322688] HW CONFIG: channel=6 freq=2437 phymode=2
<7>[ 515.386038] HW CONFIG: channel=7 freq=2442 phymode=2
<7>[ 515.450156] HW CONFIG: channel=8 freq=2447 phymode=2
<7>[ 515.514878] HW CONFIG: channel=9 freq=2452 phymode=2
<7>[ 515.578011] HW CONFIG: channel=10 freq=2457 phymode=2
<7>[ 515.642574] HW CONFIG: channel=11 freq=2462 phymode=2
<7>[ 515.706186] HW CONFIG: channel=12 freq=2467 phymode=2
<7>[ 515.769983] HW CONFIG: channel=13 freq=2472 phymode=2
<7>[ 515.835163] HW CONFIG: channel=7 freq=2442 phymode=2
<7>[ 515.846340] wlan0: set_encrypt - unknown addr 00:0e:d7:ac:84:20
<7>[ 515.848784] HW CONFIG: channel=1 freq=2412 phymode=2
<7>[ 515.851425] wlan0: Initial auth_alg=0
<7>[ 515.851585] wlan0: authenticate with AP 00:0f:24:d1:60:00
<6>[ 515.858226] phy0 -> rt2x00mac_conf_tx: Info - Configured TX ring 0 -
CWmin: 4, CWmax: 10, Aifs: 2.
<6>[ 515.858287] phy0 -> rt2x00mac_conf_tx: Info - Configured TX ring 1 -
CWmin: 4, CWmax: 10, Aifs: 2.
<6>[ 515.858328] phy0 -> rt2x00mac_conf_tx: Info - Configured TX ring 2 -
CWmin: 4, CWmax: 10, Aifs: 2.
<6>[ 515.858370] phy0 -> rt2x00mac_conf_tx: Info - Configured TX ring 3 -
CWmin: 4, CWmax: 10, Aifs: 2.
<6>[ 515.858411] phy0 -> rt2x00mac_conf_tx: Info - Configured TX ring 4 -
CWmin: 4, CWmax: 10, Aifs: 2.
<6>[ 515.858453] phy0 -> rt2x00mac_conf_tx: Info - Configured TX ring 7 -
CWmin: 5, CWmax: 10, Aifs: 2.
<7>[ 515.859260] wlan0: Initial auth_alg=0
<7>[ 515.859417] wlan0: authenticate with AP 00:0e:d7:ac:84:20
<7>[ 515.865693] wlan0: RX authentication from 00:0e:d7:ac:84:20 (alg=0
transaction=2 status=0)
<7>[ 515.865866] wlan0: authenticated
<7>[ 515.866060] wlan0: associate with AP 00:0e:d7:ac:84:20
<7>[ 515.868272] wlan0: RX ReassocResp from 00:0e:d7:ac:84:20 (capab=0x431
status=0 aid=218)
<7>[ 515.868437] wlan0: associated
<7>[ 515.870163] phy0: Added STA 00:0e:d7:ac:84:20
<7>[ 515.870353] wlan0: WMM queue=2 aci=0 acm=0 aifs=3 cWmin=15 cWmax=1023
burst=0
After the patch it looks as follows:
where the STA roams from 60:00 to 64:f0:
===========================================================
Feb 26 09:07:43 (none) user.debug kernel: [ 1146.008642] wlan0: RX
deauthentication from 00:0f:24:d1:60:00 (reason=2)
Feb 26 09:07:43 (none) user.debug kernel: [ 1146.008691] wlan0:
deauthenticated
Feb 26 09:07:43 (none) user.warn kernel: [ 1146.008712] LaE:
[ieee80211_rx_mgmt_deauth] set IEEE80211_DISABLED
Feb 26 09:07:43 (none) user.debug kernel: [ 1146.146694] HW CONFIG:
channel=1 freq=2412 phymode=2
Feb 26 09:07:43 (none) user.debug kernel: [ 1146.220021] HW CONFIG:
channel=6 freq=2437 phymode=2
Feb 26 09:07:43 (none) user.debug kernel: [ 1146.291429] HW CONFIG:
channel=7 freq=2442 phymode=2
Feb 26 09:07:43 (none) user.debug kernel: [ 1146.368633] HW CONFIG:
channel=11 freq=2462 phymode=2
Feb 26 09:07:43 (none) user.debug kernel: [ 1146.435768] HW CONFIG:
channel=13 freq=2472 phymode=2
Feb 26 09:07:43 (none) user.debug kernel: [ 1146.508241] HW CONFIG:
channel=7 freq=2442 phymode=2
Feb 26 09:07:43 (none) user.debug kernel: [ 1146.520670] wlan0: set_encrypt
- unknown addr 00:0e:d7:ca:64:f0
Feb 26 09:07:43 (none) user.debug kernel: [ 1146.521289] HW CONFIG:
channel=13 freq=2472 phymode=2
Feb 26 09:07:43 (none) user.debug kernel: [ 1146.523450] wlan0: Initial
auth_alg=0
Feb 26 09:07:43 (none) user.debug kernel: [ 1146.528055] wlan0: authenticate
with AP 00:0f:24:d1:60:00
Feb 26 09:07:43 (none) user.info kernel: [ 1146.528888] phy0 ->
rt2x00mac_conf_tx: Info - Configured TX ring 0 - CWmin: 4, CWmax: 10, Aifs:
2.
Feb 26 09:07:43 (none) user.info kernel: [ 1146.528948] phy0 ->
rt2x00mac_conf_tx: Info - Configured TX ring 1 - CWmin: 4, CWmax: 10, Aifs:
2.
Feb 26 09:07:43 (none) user.info kernel: [ 1146.528989] phy0 ->
rt2x00mac_conf_tx: Info - Configured TX ring 2 - CWmin: 4, CWmax: 10, Aifs:
2.
Feb 26 09:07:43 (none) user.info kernel: [ 1146.529030] phy0 ->
rt2x00mac_conf_tx: Info - Configured TX ring 3 - CWmin: 4, CWmax: 10, Aifs:
2.
Feb 26 09:07:43 (none) user.info kernel: [ 1146.529072] phy0 ->
rt2x00mac_conf_tx: Info - Configured TX ring 4 - CWmin: 4, CWmax: 10, Aifs:
2.
Feb 26 09:07:43 (none) user.info kernel: [ 1146.529114] phy0 ->
rt2x00mac_conf_tx: Info - Configured TX ring 7 - CWmin: 5, CWmax: 10, Aifs:
2.
Feb 26 09:07:43 (none) user.debug kernel: [ 1146.540333] wlan0: Initial
auth_alg=0
Feb 26 09:07:43 (none) user.debug kernel: [ 1146.540389] wlan0: authenticate
with AP 00:0e:d7:ca:64:f0
Feb 26 09:07:43 (none) user.debug kernel: [ 1146.542411] wlan0: RX
authentication from 00:0e:d7:ca:64:f0 (alg=0 transaction=2 status=0)
Feb 26 09:07:43 (none) user.debug kernel: [ 1146.542464] wlan0:
authenticated
Feb 26 09:07:43 (none) user.debug kernel: [ 1146.542493] wlan0: associate
with AP 00:0e:d7:ca:64:f0
Feb 26 09:07:43 (none) user.debug kernel: [ 1146.550157] wlan0: RX
ReassocResp from 00:0e:d7:ca:64:f0 (capab=0x431 status=0 aid=164)
Feb 26 09:07:43 (none) user.debug kernel: [ 1146.550210] wlan0: associated
/Lars
Hi Johannes,
Back with the traces.
First, I was wrong about receiving frames from other STA using same AP. It
was my fault.
Below (see attachment) is a trace from ieee80211_rx_h_sta_process()
You can see the frames that will update the last_rx field.
Current version will update on all frames due to the OR condition.
Changing it to and AND condition will strip almost all frames away in the
sample.
The result would be that the STA will PROBE the AP each 2 seconds in the
ieee80211_rx_h_sta_process().
In my code I have added a feature that monitors BEACONS from 'my' AP.
When number of received beacons drops below 5 / 2 seconds, I assume out of
range.
I do not know if this is necessary but it gives faster roaming in the
out-of-range scenario.
/Lars
On Wed, 2008-02-27 at 17:28 +0100, Johannes Berg wrote:
> Hi Lars,
>
> > AP deauthentication.
> > =====================
> > When any of the ieee80211_rx_mgmt_deauth() or ieee80211_rx_mgmt_disassoc()
> > are executed, the mac layer takes two actions.
> > 1) Tells wpa_supplicant what had happened.
> > 2) Start reestabliching the connaction again.
> >
> > The later action will stop or significantly delay the decisions/action taken
> > by wpa_supplicant as a result of action 1. Normally the supplicant will
> > start an AP scan.
> > But the mac layer is busy with reestablishing the link and will not start
> > any scan action.
>
> Does associating actually block scanning?
If it doesn't, it really should. There's been a number of problems over
the years with scan requests screwing up association because the card is
on a different channel and misses the association/auth exchanges. To
ensure that association/authentication is as robust as possible, the
driver should refuse scans while association is ongoing.
This would be a problem for drivers like ipw2200 that always try to
associate with _something_ (see below for rants on that) even though
they haven't been told to. In that case ipw2200 would have to know that
it's autoassociating and let the scan through.
> > My patches simply put the mac layer in IEEE80211_DISABLED state and wait for
> > the supplicant to decide.
>
> That would break supplicant-less operation which we can't do.
Yeah; roaming is an area that's somewhat underdefined right now. Wasn't
there previous discussion of a knob to tell the driver that userspace
was going to handle roaming? Could be wrong, but the driver doesn't
always have all the details for roaming and there are times when
userspace knows better. Could default to "driver" for roaming and then
the supplicant could set it to "off" when it takes over.
Which brings up the other issue of auto-association by drivers, which is
usually the wrong thing. Yeah, it makes 1337 kernel hackers in the
woods happier because the card will be up automatically and associated
with their single open AP, but it's pretty much a bad idea anywhere else
(ipw2200 associate=1 for example). The driver should only be
associating when it's told to do so, it shouldn't be going out and
finding APs on it's own ever.
> > The ieee80211_rx_h_sta_process() and ieee80211_associated() are involved in
> > monitors for dead AP connection. A last_rx value is set to indicate a
> > working connection.
> >
> > The porblem is the following lines.
> > if (!is_multicast_ether_addr(hdr->addr1) ||
> > rx->sdata->vif.type == IEEE80211_IF_TYPE_STA) {
> >
> > Any package that arrives to an STA will update the last_rx value and
> > prohibit a link lost action.
> >
> > I have noticed in my system that this function receives the following type
> > of frames:
> > 1) Broad cast frames from my BSS (beacons).
> > 2) Data frames addressed to me ;)
> > 3) Data frames from other STA addressed to other MAC addresses but using the
> > same BSS.
> >
> > It is the case 3 that creates the problem. Another STA, closer to my BSS
> > will update my last_rx value even I do not receive the BSS.
>
> I'm pretty sure case 3 can't create a problem there since rx->sta
> wouldn't be set to the AP. Can you please print out "rx->sta->addr"
> after the !sta check in ieee80211_rx_h_sta_process and send me the log
> indicating that we can actually get into there with sta != our own AP?
> If we can that's a bug elsewhere but I doubt it.
>
> > Timeout handling
> > =================
> > When any of the ieee80211_authenticate() or ieee80211_associate() function
> > are executed.
> > The mac silently set its state to IEEE80211_DISABLED and waits for the
> > wpa_supplicant to timeout its current action.
> >
> > I think it would be a good idea to signal to the supplicant that the
> > operation has timeout, and no further action will be taken.
> > To speed up the timeout response I had squeezed the supplicant timeout.
>
> How do you signal that? Make a wext event with the BSSID all-zeroes or
> something? Sounds ok.
Yeah, a zero-BSSID event would mean "disconnected" or "association
failed" and the supplicant would take over at that point.
Dan
Hi Lars,
> AP deauthentication.
> =====================
> When any of the ieee80211_rx_mgmt_deauth() or ieee80211_rx_mgmt_disassoc()
> are executed, the mac layer takes two actions.
> 1) Tells wpa_supplicant what had happened.
> 2) Start reestabliching the connaction again.
>
> The later action will stop or significantly delay the decisions/action taken
> by wpa_supplicant as a result of action 1. Normally the supplicant will
> start an AP scan.
> But the mac layer is busy with reestablishing the link and will not start
> any scan action.
Does associating actually block scanning?
> My patches simply put the mac layer in IEEE80211_DISABLED state and wait for
> the supplicant to decide.
That would break supplicant-less operation which we can't do.
> The ieee80211_rx_h_sta_process() and ieee80211_associated() are involved in
> monitors for dead AP connection. A last_rx value is set to indicate a
> working connection.
>
> The porblem is the following lines.
> if (!is_multicast_ether_addr(hdr->addr1) ||
> rx->sdata->vif.type == IEEE80211_IF_TYPE_STA) {
>
> Any package that arrives to an STA will update the last_rx value and
> prohibit a link lost action.
>
> I have noticed in my system that this function receives the following type
> of frames:
> 1) Broad cast frames from my BSS (beacons).
> 2) Data frames addressed to me ;)
> 3) Data frames from other STA addressed to other MAC addresses but using the
> same BSS.
>
> It is the case 3 that creates the problem. Another STA, closer to my BSS
> will update my last_rx value even I do not receive the BSS.
I'm pretty sure case 3 can't create a problem there since rx->sta
wouldn't be set to the AP. Can you please print out "rx->sta->addr"
after the !sta check in ieee80211_rx_h_sta_process and send me the log
indicating that we can actually get into there with sta != our own AP?
If we can that's a bug elsewhere but I doubt it.
> Timeout handling
> =================
> When any of the ieee80211_authenticate() or ieee80211_associate() function
> are executed.
> The mac silently set its state to IEEE80211_DISABLED and waits for the
> wpa_supplicant to timeout its current action.
>
> I think it would be a good idea to signal to the supplicant that the
> operation has timeout, and no further action will be taken.
> To speed up the timeout response I had squeezed the supplicant timeout.
How do you signal that? Make a wext event with the BSSID all-zeroes or
something? Sounds ok.
johannes
On Wed, Feb 27, 2008 at 8:44 AM, Lars Ericsson <[email protected]> wrote:
> AP deauthentication.
> =====================
> When any of the ieee80211_rx_mgmt_deauth() or ieee80211_rx_mgmt_disassoc()
> are executed, the mac layer takes two actions.
> 1) Tells wpa_supplicant what had happened.
> 2) Start reestabliching the connaction again.
>
> The later action will stop or significantly delay the decisions/action taken
> by wpa_supplicant as a result of action 1. Normally the supplicant will
> start an AP scan.
> But the mac layer is busy with reestablishing the link and will not start
> any scan action.
Thanks for reviewing this, some comments below.
> Timeout handling
> =================
> When any of the ieee80211_authenticate() or ieee80211_associate() function
> are executed.
> The mac silently set its state to IEEE80211_DISABLED and waits for the
> wpa_supplicant to timeout its current action.
This doesn't seem to account for pre-authentication, which should
assist roaming. During pre-auth we'd authenticate with local APs even
if we're not going to complete an assoc(), we'd leave the assoc() for
a later time once the signal strength of the new AP is better. I'm not
sure how wpa_supplicant handles with pre-authentication settings
though or if it even supports it but the point here is we should be
able to authenticate many times while we only have one assoc() pre
STA.
Luis
> > My patches simply put the mac layer in IEEE80211_DISABLED state and
> > wait for the supplicant to decide.
> >
> > That would break supplicant-less operation which we can't do.
> The patch might not work for all use cases,
> but might be configurable for the wpa_supplicant.
I suppose we could do that if the current BSSID was set fixed?
> After the patch it looks as follows:
> where the STA roams from 60:00 to 64:f0:
I can't really see much difference but that may be because the lines are
broken weirdly :)
Can you post the actual patch?
johannes