Development issues regarding the cerowrt test router project
 help / color / mirror / Atom feed
From: David Lang <david@lang.hm>
To: dpreed@reed.com
Cc: "cerowrt-devel@lists.bufferbloat.net"
	<cerowrt-devel@lists.bufferbloat.net>
Subject: Re: [Cerowrt-devel] Recording RF management info _and_ associated traffic?
Date: Sat, 24 Jan 2015 20:35:41 -0800 (PST)	[thread overview]
Message-ID: <alpine.DEB.2.02.1501242029320.19609@nftneq.ynat.uz> (raw)
In-Reply-To: <1422111577.328132080@apps.rackspace.com>

On Sat, 24 Jan 2015, dpreed@reed.com wrote:

> On Thursday, January 22, 2015 1:19pm, "Richard Smith" <smithbone@gmail.com> 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

  parent reply	other threads:[~2015-01-25  4:35 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-14  2:20 Richard Smith
2015-01-20 16:59 ` Rich Brown
2015-01-21 23:40   ` Richard Smith
2015-01-21 23:58     ` David Lang
2015-01-22  9:04       ` Richard Smith
2015-01-22  9:18         ` David Lang
2015-01-22 18:19           ` Richard Smith
2015-01-22 22:09             ` David Lang
2015-01-22 22:55               ` Roman Toledo Casabona
2015-01-24 14:59             ` dpreed
2015-01-24 15:30               ` Kelvin Edmison
2015-01-25  4:35               ` David Lang [this message]
2015-01-25  5:02                 ` Dave Taht
2015-01-25  5:04                   ` Dave Taht
2015-01-25  6:44                   ` David Lang
2015-01-25  7:06                     ` David Lang
     [not found]                     ` <CAA93jw64KjW-JjLxB3i_ZK348NCyJYSQACFO34MaUsBBWyZ+pA@mail.gmail.com>
2015-01-25  7:59                       ` Dave Taht
2015-01-25  9:39                       ` David Lang
2015-01-25 15:03                         ` Chuck Anderson
2015-01-25 20:17                 ` dpreed
2015-01-25 23:21                   ` Aaron Wood
2015-01-25 23:57                   ` David Lang
2015-01-26  1:51                     ` dpreed
2015-01-26  2:09                       ` David Lang
2015-01-26  4:33                         ` Valdis.Kletnieks
2015-01-26  4:44                           ` David Lang
2015-01-27  0:14                             ` dpreed
2015-01-27  0:23                               ` David Lang
2015-01-26  2:19                       ` Dave Taht
2015-01-26  2:43                         ` David Lang
2015-01-26  2:58                           ` Dave Taht
2015-01-26  3:17                             ` dpreed
2015-01-26  3:32                               ` David Lang
2015-01-26  3:45                               ` Dave Taht
2015-01-27  0:12                                 ` dpreed
2015-01-27  0:31                                   ` David Lang
2015-01-27  0:36                                   ` Dave Taht
2015-01-26  3:19                             ` David Lang
2015-01-26  4:25                     ` Valdis.Kletnieks
2015-01-26  4:39                       ` David Lang
2015-01-26 16:42                         ` Valdis.Kletnieks
2015-01-25  8:07             ` Outback Dingo
2015-01-30 16:14               ` Richard Smith

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=alpine.DEB.2.02.1501242029320.19609@nftneq.ynat.uz \
    --to=david@lang.hm \
    --cc=cerowrt-devel@lists.bufferbloat.net \
    --cc=dpreed@reed.com \
    /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