[ath9k-devel] Virtual AP spanning multiple radios for transparent roaming?

[ath9k-devel] Virtual AP spanning multiple radios for transparent roaming?

[Moritz Möller]

Hi everybody!
I'm having issues with roaming - switching from one AP to another AP (different bssid, same ssid) takes in the order of seconds, which disturbs voice over ip calls and streaming.
I'm quite new to 802.11 networking and did a bit of reading and fiddling around sending/receiving frames in monitor mode, and had the following idea (not sure if good or bad though):
- all access points are tuned to the same channel
- all access points use the same bssid
- the access points use a wired network to interchange association information: which AP is responsible to what STAs (by mac address).
- handling authentication frames is done centralized
- the access point responsible for a STA will ACK and pass a received frame
- frames to be transmitted are forwarded to the AP handling the STA and send there.
- all APs see all frames in their range, and keep a list of the RSSI for each STA, if a station moves another AP can take over the responsibility for a station.
The expected result is that a station only sees one access point which is always nearby and always has good signal strength.

Now there are some problems:
1. first of all, sending ACK/CTS/RTS frames seems to be done in the driver firmware (I'm using ath9k), at least nothing that can be handled using monitor mode.
2. using the same channel could increase contention
3. as said I'm not really familiar with 802.11, there are probably other things i've missed.

Has anyone an idea for me how to get started or why to leave it altogether?

I'm not subscribed to this list, please include my email in answers.

Thank you very much,

Moritz
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4127 bytes
Desc: not available
Url : http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20131016/c3dab018/attachment.bin 

[ath9k-devel] Virtual AP spanning multiple radios for transparent roaming?

[Moritz Möller]

Hi Kyle,
for this scheme to work it would be required that all access points operate
on the same channel.
Changing the channel would require a different bssid so the station would
reassociate, which is what I want to avoid, as it causes the network
connectivity to be unavailable for nearly 5 seconds (which I still do not
understand; reassociation should only take a couple of ms)
Thank you!
Moritz

On 16.10.2013, at 16:24, Kyle Bassett <kylebassett@gmail.com> wrote:

Same channel configurations are evil.

Make one change: assign the APs to different channels and report back.

Do you have a physical topography diagram to scale?  What brand APs?  What
is the average range with only one unit turned on?

Good luck!
On Oct 16, 2013 9:09 AM, "Moritz M?ller" <mmoeller@mxs.de> wrote:

> Hi everybody!
> I'm having issues with roaming - switching from one AP to another AP
> (different bssid, same ssid) takes in the order of seconds, which disturbs
> voice over ip calls and streaming.
> I'm quite new to 802.11 networking and did a bit of reading and fiddling
> around sending/receiving frames in monitor mode, and had the following idea
> (not sure if good or bad though):
> - all access points are tuned to the same channel
> - all access points use the same bssid
> - the access points use a wired network to interchange association
> information: which AP is responsible to what STAs (by mac address).
> - handling authentication frames is done centralized
> - the access point responsible for a STA will ACK and pass a received frame
> - frames to be transmitted are forwarded to the AP handling the STA and
> send there.
> - all APs see all frames in their range, and keep a list of the RSSI for
> each STA, if a station moves another AP can take over the responsibility
> for a station.
> The expected result is that a station only sees one access point which is
> always nearby and always has good signal strength.
>
> Now there are some problems:
> 1. first of all, sending ACK/CTS/RTS frames seems to be done in the driver
> firmware (I'm using ath9k), at least nothing that can be handled using
> monitor mode.
> 2. using the same channel could increase contention
> 3. as said I'm not really familiar with 802.11, there are probably other
> things i've missed.
>
> Has anyone an idea for me how to get started or why to leave it altogether?
>
> I'm not subscribed to this list, please include my email in answers.
>
> Thank you very much,
>
> Moritz
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20131016/89a2d734/attachment-0001.htm 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2535 bytes
Desc: not available
Url : http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20131016/89a2d734/attachment-0001.bin