Development issues regarding the cerowrt test router project
 help / color / mirror / Atom feed
From: Chuck Anderson <cra@WPI.EDU>
To: "Theodore Ts'o" <tytso@mit.edu>
Cc: "cerowrt-devel@lists.bufferbloat.net"
	<cerowrt-devel@lists.bufferbloat.net>
Subject: Re: [Cerowrt-devel] treating 2.4ghz as -legacy?
Date: Wed, 18 Dec 2013 09:17:57 -0500	[thread overview]
Message-ID: <20131218141756.GC10689@angus.ind.WPI.EDU> (raw)
In-Reply-To: <20131218013303.GA19261@thunk.org>

On Tue, Dec 17, 2013 at 08:33:03PM -0500, Theodore Ts'o wrote:
> I don't mind using multiple routers, if at some point CeroWRT were to
> gain the advanced feature of talking to other routers and forcing a
> disassociation when the signal strength talking to a particular client
> gets significantly weaker than compared to the signal strength from
> another AP.  Is there any special hardware support needed to do this
> kind of AP-to-AP handoff, or is it just really complicated and no one
> has bothered to do it in an open source implementation?

It is always the Wi-Fi client that decides when/where to roam to in a
multi-AP environment based on whatever criteria it chooses--usually
the signal strength.  The APs don't generally influence the clients'
roaming decisions, except for some advanced enterprise systems which
can sometimes use "tricks" like playing with transmitted
signal-strength or Beacon timing or forced disassociation to "steer"
clients to a certain band or AP, usually for capacity or policy
reasons.  These are imperfect solutions because the AP can't know what
the client's signal strength actually is--it can only infer it from
the AP's received signal strength of a particular client which is
imprecise due to the different antenna and radio characteristics of
each end.  This gets more complicated with MIMO on 802.11n, since
different paths could be used in each direction of transmission.

Simply setting the same ESSIDs on all APs and making sure they are all
connected to the same wired layer 2 network (so IP connectivity wont't
be broken after roaming) is all you should need to do to have a basic,
working multi-AP environment.  Clients usually have a configurable
"roaming aggressiveness" setting that determines how sensitive they
are to changes in the signal srength and how "sticky" they are to one
AP before deciding to roam to another one.

In the context of CeroWRT specifically, a multi-AP environment
presents problems because CeroWRT explicity does NOT come configured
to do layer 2 switching between networks.  In order to support proper
Wi-Fi roaming, though, it would have to provide some solution for the
client to keep working with the same IP address after roaming to
another AP.  This could be as simple as configuring the same layer 2
network between APs, or using a tunneling technology such as Mobile IP
or GRE as some advanced enterprise systems do.

Here is a good paper on how Wi-Fi roaming works;

http://www.revolutionwifi.net/2011/12/wi-fi-roaming-analysis-part-1.html

Here is a relavent quote:

"Wi-Fi network connection establishment and roaming is decentralized,
being controlled almost entirely by the client. The 802.11 standard
explicitly places control of wireless connection establishment in the
hands of clients by defining various logical services and breaking
implementation out between clients and access points."

  parent reply	other threads:[~2013-12-18 14:18 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-16 19:46 Dave Taht
2013-12-16 20:19 ` Sebastian Moeller
2013-12-16 20:25 ` Toke Høiland-Jørgensen
2013-12-16 20:48 ` Kelvin Edmison
2013-12-16 21:28 ` David Lang
2013-12-16 22:06   ` Fred Stratton
2013-12-17 17:54     ` Michael Richardson
2013-12-17 18:51       ` Jim Gettys
2013-12-17 22:25         ` dpreed
2013-12-17 22:32           ` Jim Gettys
2013-12-17 23:43             ` Stephen Hemminger
2013-12-18  1:33               ` Theodore Ts'o
2013-12-18  3:04                 ` David Lang
2013-12-18  5:05                   ` Theodore Ts'o
2013-12-18  5:49                     ` David Lang
2013-12-18 14:17                 ` Chuck Anderson [this message]
2013-12-18 15:19               ` dpreed
2013-12-18 16:54                 ` Michael Richardson
2013-12-18 18:18                   ` Toke Høiland-Jørgensen
2013-12-18 19:24                     ` David Lang
2013-12-18 20:07                       ` Michael Richardson
2013-12-18 20:14                         ` David Lang
2013-12-19  9:31                           ` Toke Høiland-Jørgensen
2013-12-19 14:32                             ` Michael Richardson
2013-12-19 20:05                             ` David Lang
2013-12-19 21:01                               ` Chuck Anderson
2013-12-20  0:50                 ` Theodore Ts'o
2013-12-20  5:18                   ` dpreed
2013-12-18 14:06           ` Michael Richardson
2013-12-27 23:56 ` Maciej Soltysiak

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.bufferbloat.net/postorius/lists/cerowrt-devel.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20131218141756.GC10689@angus.ind.WPI.EDU \
    --to=cra@wpi.edu \
    --cc=cerowrt-devel@lists.bufferbloat.net \
    --cc=tytso@mit.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox