From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 1669221F1DD for ; Sat, 24 Jan 2015 21:04:28 -0800 (PST) Received: by mail-oi0-f52.google.com with SMTP id h136so3174475oig.11 for ; Sat, 24 Jan 2015 21:04:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=HtkxnixVR4+DXbYTon2tYTmp6r18VK9hWPOfKmwMdQA=; b=MXTZNMo2tFaNWMgRo+0lfPJ12BLtrNxJtH7cyY5tgTVIU9eiF/vOeR3zVVMZBJvEDK 8NPfxwwt8j/nUuAqf3DbBvpSK6QfA2+e0iBGtH1773SiJLp/XTljnIRw+iaT2Ak8rAeL z6DDKxWYYbEianReRRTtCkdDgsy0yZwPR07+n7QphPQeh5j2uwxl0dfr0Dt6wr3Yzc1a PDK01LGxyS/71Y6YqSq1IqGo4IHVRLLNvRz5MrJHXsPXQoy/J+ay5fyJpgakmUBOV/HF X6t7ejBo/BskculmUY+1yQ4yFP4r0fkrsGe+WhzPG9tGZZxQ7JHBUy2jAFKK0//EGwCQ LOXA== MIME-Version: 1.0 X-Received: by 10.182.51.165 with SMTP id l5mr9298976obo.56.1422162268060; Sat, 24 Jan 2015 21:04:28 -0800 (PST) Received: by 10.202.51.66 with HTTP; Sat, 24 Jan 2015 21:04:27 -0800 (PST) In-Reply-To: References: <54B5D28A.3010906@gmail.com> <7B1EA8F0-FCB6-4A37-950F-2558FC751DE8@gmail.com> <54C038D0.1000305@gmail.com> <54C0BD22.3000608@gmail.com> <54C13F47.1010203@gmail.com> <1422111577.328132080@apps.rackspace.com> Date: Sat, 24 Jan 2015 21:04:27 -0800 Message-ID: From: Dave Taht To: David Lang Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "cerowrt-devel@lists.bufferbloat.net" Subject: Re: [Cerowrt-devel] Recording RF management info _and_ associated traffic? X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jan 2015 05:04:57 -0000 On Sat, Jan 24, 2015 at 9:02 PM, Dave Taht wrote: > On Sat, Jan 24, 2015 at 8:35 PM, David Lang wrote: >> On Sat, 24 Jan 2015, dpreed@reed.com wrote: >> >>> On Thursday, January 22, 2015 1:19pm, "Richard Smith" >>> 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 dedicat= ed >>>> > 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 kee= p >>>> track of what RF channel things are on. > > My usual use case for using different APs is to find an error in the camp= us. > > When someone tells me that "Lupin-lodge" is down, I know exactly which ma= chine > 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 encry= ption >>> 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 reason= s >>> that routing rather than bridging is better for mesh. >> >> >> The problem with doing this is that all existing TCP connections will br= eak >> when you move from one AP to another and while some apps will quickly no= tice >> this and establish new connections, there are many apps that will not an= d >> 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 chan= ge. > > 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 behav= ior. :/ > >> >> 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 fro= m >> 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 ~280= 0 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 ha= s 3, >> and I'm adding APs this year to cover the hallways better because the on= es >> in the rooms aren't doing well enough at the low power settings I'm usin= g) > > 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=C3=A4ht > > thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks --=20 Dave T=C3=A4ht thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks