roaming between two ap with r1593

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.

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!

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.

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?

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.

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

Patches to MadWifi are welcome.

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?

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.

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

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.

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.

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.

Has a fix been implemented for the roaming issue?

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

The handoff(roam) time is so long!

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

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.