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
_______________________________________________
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel
