Please note: This project is no longer active. The website is kept online for historic purposes only.
If you´re looking for a Linux driver for your Atheros WLAN device, you should continue here .

Ticket #697 (new defect)

Opened 12 years ago

Last modified 8 years ago

roaming between two ap with r1593

Reported by: anonymous Assigned to:
Priority: major Milestone: version 0.9.x - progressive release candidate phase
Component: madwifi: driver Version: trunk
Keywords: minRssi Cc:
Patch is attached: 0 Pending:

Description

I have checked roaming between two ap with r1593 and find that if the station is associated with ap1, the rssi from ap2 is higher than from ap1, the station will not change to associate with ap2. I do not know why? who can tell me with fuction should be checked into? another:

if (se->se_rssi < STA_RSSI_MIN) fail |= 0x100;

I think if rssi is low enough, station should not connect to the ap. but that did happen while I managed to reduce the rssi. would you tell me which fuction I should check into? thanks!

Change History

06/16/06 06:02:19 changed by mrenzmann

  • priority changed from major to minor.
  • version set to trunk.

Why should the STA switch to AP2 when the signal level f AP1 is still sufficient?

However, in order to have a useful report it would be necessary to repeat the test with a more current revision of MadWifi.

06/21/06 03:35:34 changed by anonymous

I have checked the program and found that it is relative to the function sta_age. who can tell me when this function would be activated?

and the following is in the sta_age function:

spin_unlock(&st->st_lock); /*

  • If rate control is enabled check periodically to see if
  • we should roam from our current connection to one that
  • might be better. This only applies when we're operating
  • in sta mode and automatic roaming is set.
  • XXX defer if busy
  • XXX repeater station */

KASSERT(vap->iv_opmode == IEEE80211_M_STA,

("wrong mode %u", vap->iv_opmode));

/* XXX turn this off until the ap release is cut */ if (0 && vap->iv_ic->ic_roaming == IEEE80211_ROAMING_AUTO &&

vap->iv_state >= IEEE80211_S_RUN)

/* XXX vap is implicit */ sta_roam_check(ss, vap);

it seems that sta_roam_check would never run. so MIN_RSSI would never be checked. is that right? who can check that? thanks!

06/21/06 05:43:41 changed by mrenzmann

You might want to use the identifier search on http://lxr.madwifi.org . sta_age is used as default method for scanners to age entries in the scan cache. As you can see, sta_age is used in the wlan_scan_sta and wlan_scan_ap modules. The scan_age method then is called ieee80211_scan_timeout, which is called from the STA timeout timer (as mentioned in the comments for this function).

You can continue the search like this. However, the question I've asked in my first comment is still open... there still is no reason to roam to another AP if the AP the STA is associated to has still a good-enough signal level.

06/27/06 05:26:20 changed by anonymous

Thanks. ofcourse, if the AP which ths STA is associated to has enough good signal level, there is no reason to roam. But I just want to apply roaming with broad band which is related high level signal(RSSI), so I want to disconnect the connected AP with middle RSSI and connect to better AP(high RSSI) with broad band. is that right? can you tell me which is relative to fast roaming with broad band?

(follow-up: ↓ 13 ) 07/26/06 22:00:45 changed by ted bullgam

Hi, Roaming is quite slow with the default drivers because the cache ages to slowly (~15 s until old AP dissapears!).

Imagine a moving machine using a madwifi station. The machine is travelling from one AP to another while you are transferring data with maximum bandwidth (we always need the best results we can get, we want to be perfect, eh?). So it would be best to have a look at the signals of the current assoc, if the signal drops below a threshold it is still soon enough to look for a better AP but stay connected to the old AP. Now we planned the infrastructure to give a better AP at this point. The current driver will stay connected to the old AP resulting in a VERY poor throughput although it would be obviously better to use the AP we are next to.

So a few things to do:

  • make the timer self contained for aging the cache
  • make the timer adjustable
  • start scanning even if data is transmitted continuosly (yes, i call this a bug), only get back to the assoc and process for a while and continue scanning afterwards.
  • add a threshold RSSI that starts to look for a new AP if the signal is not perfect but still sufficent.
  • plan to use enough APs for moving WLAN connected machines

Currently it is impossible to have moving machines with madwifi cards because the signals has to get so bad that no data can be transfered anymore. Only now the scan request does not get interrupted and it can look for new APs. This scan takes ages if you do not limit channels (athchans is your friend). The current madwifi will drop the signal for at least 1-5 seconds, and with these times you can call yourself lucky, often it is even worse :-(

I would be happy if someone likes to fix this. I am to stupid for those things and so i am using two radios and switch routes between them.

07/28/06 19:07:14 changed by ted bullgam

Please also read [1] to believe that roaming needs an improvement and how it can be done.

[1] www.cs.ucsd.edu/~iramani/sync_scan.pdf

07/29/06 03:21:57 changed by kelmo

Patches to MadWifi are welcome.

07/31/06 10:08:12 changed by Ted Bullgam

Can you please set the priority to a higher level to refelct the importance of this issue? I can not fix this issue on my own, so i am really sorry i can not write a patch. But if the priority gets higher i hope that we get someone able to do it?

07/31/06 11:03:52 changed by kelmo

  • priority changed from minor to major.
  • owner changed.
  • component changed from madwifi: other to madwifi: driver.
  • milestone set to version 0.9.x - progressive release candidate phase.

Yes, that is a good idea. Mike has already stated that scanning issues are on the agenda for 0.9.3, so that is may be an extra bonus if someone has the time to also address the issue (but not critical if they do not). I promoted the priority to major.

Kel.

09/28/06 04:33:30 changed by anonymous

do we have any knowledge of this feature being implemented in hardware, or would all the buffering be done in userspace?

10/30/06 23:15:32 changed by anonymous

There is some work done by CoNS that may be of use here. Beta code can be found for a seamless handoff tool build for MadWiFi at: http: //crewman.uta.edu/corenetworking/projects/handoff/software.tar.gz. Description of how it works can be found here: http: //crewman.uta.edu/corenetworking/projects/handoff/newhandoff.html#people.

Also, there may be some work going on the the 802.11r group that would relate to this topic, though that spec is still a ways out.

11/15/06 10:35:03 changed by ted bullgam

The published solution looks very promising. But they work with madwifi-old and my tests failed due to not supported (to new) hardware. So, to make things clear, i want to point out, that CoNS did not just write a tool. They made a fork of the madwifi-old driver + tool. This inherits the issues you have if you want to use recent hardware that is not supported by madwifi-old.

(in reply to: ↑ 5 ) 04/26/07 12:28:41 changed by anonymous

Hello, Ted, you state that you are using madwifi with 2 radios? Could you please, detail it a bit more? Are you doing that with a piece of code that control 2 madwifi drivers? Your hardware has interference between the 2 radios? Are you using PCI or PCMCIA radios? Many thanks, Pedro Replying to ted bullgam:

Hi, Roaming is quite slow with the default drivers because the cache ages to slowly (~15 s until old AP dissapears!). Imagine a moving machine using a madwifi station. The machine is travelling from one AP to another while you are transferring data with maximum bandwidth (we always need the best results we can get, we want to be perfect, eh?). So it would be best to have a look at the signals of the current assoc, if the signal drops below a threshold it is still soon enough to look for a better AP but stay connected to the old AP. Now we planned the infrastructure to give a better AP at this point. The current driver will stay connected to the old AP resulting in a VERY poor throughput although it would be obviously better to use the AP we are next to. So a few things to do: * make the timer self contained for aging the cache * make the timer adjustable * start scanning even if data is transmitted continuosly (yes, i call this a bug), only get back to the assoc and process for a while and continue scanning afterwards. * add a threshold RSSI that starts to look for a new AP if the signal is not perfect but still sufficent. * plan to use enough APs for moving WLAN connected machines Currently it is impossible to have moving machines with madwifi cards because the signals has to get so bad that no data can be transfered anymore. Only now the scan request does not get interrupted and it can look for new APs. This scan takes ages if you do not limit channels (athchans is your friend). The current madwifi will drop the signal for at least 1-5 seconds, and with these times you can call yourself lucky, often it is even worse :-( I would be happy if someone likes to fix this. I am to stupid for those things and so i am using two radios and switch routes between them.

11/27/07 17:19:05 changed by solis@airbaud.net

Has a fix been implemented for the roaming issue?

07/05/08 08:37:50 changed by vipintm@au-kbc.org

What is the status of roaming implementation now ? How fast it roam between two APs?

(follow-up: ↓ 17 ) 03/01/10 09:34:19 changed by peiweijun@21cn.com

The handoff(roam) time is so long!

(in reply to: ↑ 16 ) 06/10/10 14:20:49 changed by peiweijun@21cn.com

Help! How do it with current driver? Very well at rest, but So bad on the move.

07/16/10 23:39:44 changed by sirgeorge@raps-shop.de

Hi folks,

thumbs up for your overall efforts with atheros hardware. The hardware support and performance (at rest) is amazing. However, there remains this major turn-off... roaming issues as described herein - even in svn trunk (last test in ~May). Why, for god's sake hasn't that problem been adressed in the last couple of years(!)? I had to switch over to windoze, where roaming works like a charm - after setting the roaming aggressiveness parameter in the windoze atheros driver to "very high". That switch over, of course, has brought me all sorts of other problems here (administrative and security concerning).

I would really, really appreciate some efforts on this topic.

Sir George

P.S.: Maybe I'm wrong and there are changes done in ath5k (however the Ubuntu10.04 module didn't show better results) or some other svn branch. Please correct me if I'm wrong.