Development issues regarding the cerowrt test router project
 help / color / mirror / Atom feed
From: Dave Taht <dave.taht@gmail.com>
To: David Lang <david@lang.hm>
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 21:02:50 -0800	[thread overview]
Message-ID: <CAA93jw4VuOpdwRMBgg0T=uiOUZkTDeFcQUBMRsEWinjgakRtag@mail.gmail.com> (raw)
In-Reply-To: <alpine.DEB.2.02.1501242029320.19609@nftneq.ynat.uz>

On Sat, Jan 24, 2015 at 8:35 PM, David Lang <david@lang.hm> wrote:
> 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.

My usual use case for using different APs is to find an error in the campus.

When someone tells me that "Lupin-lodge" is down, I know exactly which machine
to check. If everything was named Lupin, I'd have to check far more
than one AP, and
to ask approximately where on the campus they were.

>>
>>
>>
>> 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.

I am under the impression that network-manager and linux, at least,
tend to renegotiate
IPv6 addresses on an down/up, and preserve ipv4.

>
> Bridgeing allows the connections to remain intact. The wifi stack
> re-negotiates the encryption, but the encapsulated IP packets don't change.

While I actually agree with dlang on having all the same ssid and
bridging, and not routing, on a conference, as well as with the idea
of disabling broadcast (and I assume direct connectivity between two
people seated side by side), it is a pita:

More than once I've wanted to share a git tree with someone right next
to me. I try to hand them my ip to grab the tree, and they can't even
ping me, so I end uploading it somewhere, and he or she downloading it
from there. Similarly, breaking interconnectivity precludes sane usage
of in-conference

In my case, since choosing to live in a routed, rather than bridged
world, I have modified the nailed up tools I use to be more
connectionless. Instead of ssh (tcp), I use mosh-multipath (udp),
which is far superior for interactive shells in lousy wifi
environments. For vpns, I switched to tinc, which will attempt direct
connections over udp, and tcp on both ipv4 and ipv6. For access to
google, I adopted quic in my chrome browser. Since doing all these
things I rarely notice losing a nailed up connection or migrating from
AP to AP. Additionally I use babel (where I control the network) and
ad-hoc wifi to transparently migrate from AP to AP, and (often) from
AP to wired to AP to wired as I change locations, also with no loss in
connectivity.

I don't expect the scale userbase to have made these adjustments in behavior. :/

>
> 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

I will look into some tools bismark and others have.

Will you attempt to deploy ipv6?

> 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)

I am of course interested in how fq_codel performs on your ISP link, and
are you planning on running it for your wifi?

> David Lang
>
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel



-- 
Dave Täht

thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks

  reply	other threads:[~2015-01-25  5:02 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
2015-01-25  5:02                 ` Dave Taht [this message]
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='CAA93jw4VuOpdwRMBgg0T=uiOUZkTDeFcQUBMRsEWinjgakRtag@mail.gmail.com' \
    --to=dave.taht@gmail.com \
    --cc=cerowrt-devel@lists.bufferbloat.net \
    --cc=david@lang.hm \
    /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