Re: [Cerowrt-devel] Recording RF management info _and_ associated traffic?

[Dave Taht <dave.taht@gmail.com>]

On Sat, Jan 24, 2015 at 9:02 PM, Dave Taht <dave.taht@gmail.com> wrote:
> 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

oops, hit send too early. "Of in-conference tools like webrtc, which
would otherwise seek a direct path, as well as other p2p things like
chat based on that".

> 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



-- 
Dave Täht

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