From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from MAIL1.WPI.EDU (MAIL1.WPI.EDU [130.215.36.91]) by huchra.bufferbloat.net (Postfix) with ESMTP id E35F021F19A for ; Wed, 18 Dec 2013 06:18:31 -0800 (PST) Received: from MAIL1.WPI.EDU (MAIL1.WPI.EDU [130.215.36.91]) by MAIL1.WPI.EDU (8.14.7/8.14.7) with ESMTP id rBIEIUEw019062; Wed, 18 Dec 2013 09:18:30 -0500 X-DKIM: Sendmail DKIM Filter v2.8.3 MAIL1.WPI.EDU rBIEIUEw019062 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wpi.edu; s=_dkim; t=1387376310; bh=4sTy3XQ8CZN+F69BunfZOZa+k/SKS/cO90odp6QejjI=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:In-Reply-To; b=TcLLdKLrqz76tKExQTNd/xkFFc9hJz0zkUVNoz7qKZSSgT38svLLuqgOdC+xB5W4O r3fhtfp6uijF42UxfUWdAW15vym5S635c+BhLt8kugXrQoddGOajgD7WMYx3gdNPry tHiYLiaL2RjouPFSQA+lf65Yj8ks6dyLvRZdAe28= Received: from SMTP.WPI.EDU (SMTP.WPI.EDU [130.215.36.186]) by MAIL1.WPI.EDU (8.14.7/8.14.7) with ESMTP id rBIEIUHV019056; Wed, 18 Dec 2013 09:18:30 -0500 Received: from angus.ind.WPI.EDU (ANGUS.IND.WPI.EDU [130.215.130.21]) by SMTP.WPI.EDU (8.14.4/8.14.4) with ESMTP id rBIEHv2r013531; Wed, 18 Dec 2013 09:17:58 -0500 (envelope-from cra@WPI.EDU) Received: from angus.ind.WPI.EDU (localhost [127.0.0.1]) by angus.ind.WPI.EDU (8.14.4/8.14.4) with ESMTP id rBIEHv82014744; Wed, 18 Dec 2013 09:17:57 -0500 Received: (from cra@localhost) by angus.ind.WPI.EDU (8.14.4/8.14.4/Submit) id rBIEHv8P014743; Wed, 18 Dec 2013 09:17:57 -0500 X-Authentication-Warning: angus.ind.WPI.EDU: cra set sender to cra@WPI.EDU using -f Date: Wed, 18 Dec 2013 09:17:57 -0500 From: Chuck Anderson To: "Theodore Ts'o" Message-ID: <20131218141756.GC10689@angus.ind.WPI.EDU> References: <52AF797E.6030600@imap.cc> <18972.1387302855@sandelman.ca> <1387319157.48330794@apps.rackspace.com> <20131217154345.0e91b65f@nehalam.linuxnetplumber.net> <20131218013303.GA19261@thunk.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20131218013303.GA19261@thunk.org> User-Agent: Mutt/1.5.20 (2009-12-10) Cc: "cerowrt-devel@lists.bufferbloat.net" Subject: Re: [Cerowrt-devel] treating 2.4ghz as -legacy? X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Dec 2013 14:18:32 -0000 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."