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

["Moritz Möller" <mmoeller@mxs.de>]

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