From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bifrost.lang.hm (mail.lang.hm [64.81.33.126]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id CF3F321F1D4 for ; Sat, 24 Jan 2015 20:35:44 -0800 (PST) Received: from asgard.lang.hm (asgard.lang.hm [10.0.0.100]) by bifrost.lang.hm (8.13.4/8.13.4/Debian-3) with ESMTP id t0P4Ze7n006393; Sat, 24 Jan 2015 20:35:41 -0800 Date: Sat, 24 Jan 2015 20:35:41 -0800 (PST) From: David Lang X-X-Sender: dlang@asgard.lang.hm To: dpreed@reed.com In-Reply-To: <1422111577.328132080@apps.rackspace.com> Message-ID: References: <54B5D28A.3010906@gmail.com> <7B1EA8F0-FCB6-4A37-950F-2558FC751DE8@gmail.com> <54C038D0.1000305@gmail.com> <54C0BD22.3000608@gmail.com> <54C13F47.1010203@gmail.com> <1422111577.328132080@apps.rackspace.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: "cerowrt-devel@lists.bufferbloat.net" Subject: Re: [Cerowrt-devel] Recording RF management info _and_ associated traffic? 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: Sun, 25 Jan 2015 04:36:13 -0000 On Sat, 24 Jan 2015, dpreed@reed.com wrote: > On Thursday, January 22, 2015 1:19pm, "Richard Smith" said: > > >> On 01/22/2015 04:18 AM, David Lang wrote: >> >> >> Recently, we picked up the 11th floor as well and moved many people up >> >> there. I got a 3rd AP (another TP-Link AC1750) and set that one up on >> >> a free channel with a different ESSID. >> > >> > I like to put all the APs on the same ESSID so that people can roam >> > between them. This requires that the APs act as bridges to a dedicated >> > common network, not as routers. >> >> That's the ultimate plan but for convenience of being able to easily >> select what AP I'm talking to or to be able to tell folks to move from >> one to another I've got them on different ESSIDs. It also helps me keep >> track of what RF channel things are on. > > > A side comment, meant to discourage continuing to bridge rather than route. > > There's no reason that the AP's cannot have different IP addresses, but a > common ESSID. Roaming between them would be like roaming among mesh subnets. > Assuming you are securing your APs' air interfaces using encryption over the > air, you are already re-authenticating as you move from AP to AP. So using > routing rather than bridging is a good idea for all the reasons that routing > rather than bridging is better for mesh. The problem with doing this is that all existing TCP connections will break when you move from one AP to another and while some apps will quickly notice this and establish new connections, there are many apps that will not and this will cause noticable disruption to the user. Bridgeing allows the connections to remain intact. The wifi stack re-negotiates the encryption, but the encapsulated IP packets don't change. I do this with the wifi on it's own VLAN (actually separate VLANs for 2.4 and 5GHz) and have the APs configured not to relay broadcast traffic from one wireless user to another. This cuts down a LOT on the problems of broadcasts. In about a month I'm going to be running the wireless network for SCaLE again, and I would be happy to instrament the network to gather whatever info anyone is interested in. I will be using ~50 APs to handle the ~2800 or so devices that show up, with the footprint of each AP roughly covering a small meeting room (larger rooms have 2 APs in them, the largest room has 3, and I'm adding APs this year to cover the hallways better because the ones in the rooms aren't doing well enough at the low power settings I'm using) David Lang