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

[David Lang]

On Sat, 24 Jan 2015, Dave Taht wrote:

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

It can't preserve the ipv4 address if you end up on a different network address 
range (and trying to have lots of separate networks with the same IP addresses 
would mean that you have to do NAT at each network, and if you did that, then 
when you ended up on a different AP with the same IP address, the NAT tables 
would not have records of your connections and they would terminate the 
connections when you tried to send the next packets.

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

True, it also blocks some abuse. People who really want direct connectivity can 
establish it as an ad-hoc network.

For the normal user that we are trying to support at a conference, it's a win.

I'll note that we also block streaming sites (which has the side effect of 
blocking some useful sites that share the same IPs, Amazon for example) to help 
make things better for everyone else, even at the cost of limiting what some 
people are able to do. Bandwidth is limited compared to the number of people we 
have, and we have to make choices.

We do provide a local mirror of the debian based distros so that people can do 
the updates that they always tend to do at the conference (we would do the same 
for Fedora, but they make it too hard to do so)

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

We have been offering IPv6 routable addresses for a few years.

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

I'm running OpenWRT on the APs but haven't done anything in particular to 
activate it. I'll check what we have on the firewall (a fairly up to day Debian 
build)

What's the best way to monitor the queues?

David Lang