From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by huchra.bufferbloat.net (Postfix) with ESMTP id C4B6721F13F for ; Wed, 18 Dec 2013 12:07:33 -0800 (PST) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id 601942024D; Wed, 18 Dec 2013 16:21:36 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 122A063B89; Wed, 18 Dec 2013 15:07:16 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 0273263848; Wed, 18 Dec 2013 15:07:16 -0500 (EST) From: Michael Richardson To: David Lang In-Reply-To: <4400ed3b15245d06d0bf73d22f7a7692@lang.hm> References: <52AF797E.6030600@imap.cc> <18972.1387302855@sandelman.ca> <1387319157.48330794@apps.rackspace.com> <20131217154345.0e91b65f@nehalam.linuxnetplumber.net> <1387379970.401720581@apps.rackspace.com> <18235.1387385681@sandelman.ca> <874n66yqcs.fsf@toke.dk> <4400ed3b15245d06d0bf73d22f7a7692@lang.hm> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Cc: cerowrt-devel@lists.bufferbloat.net Subject: Re: [Cerowrt-devel] =?utf-8?q?treating_2=2E4ghz_as_-legacy=3F?= 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: Wed, 18 Dec 2013 20:07:34 -0000 David Lang wrote: >> Michael Richardson writes: >> >>> As for having identical ESSID on the same layer-2... I think that >>> perhaps cerowrt/openwrt/homenet should consider a wireless AP >>> discovery attribute in the routing protocol, and given that, run GRE >>> over IPv6 ULA between APs. >> >> I was thinking something like that would be neat. I seem to recall that >> the homenet effort at IETF is in the process of specifying standard(s) >> for how multiple routes that get plugged into each other in random >> fashions should auto-configure themselves. In the meantime, perhaps a >> poor-mans version could be to have cero check, when the wan interface >> comes up, whether the upstream router is also running cero, and if so >> setup the appropriate GRE tunnels and, basically, turn off all other >> functionality. >> >> Some sort of negotiation would be needed, but a lua script running in >> the (upstream) web configuration (or even an inetd-powered pipe to a >> shell script) could work I guess. This could be authenticated by a >> shared secret (which the cero firmware would ship with), to prevent the >> most obvious abuse. >> >> Any reason why the above wouldn't work? > doing a lot of GRE tunnels could be a lot of overhead. True. For the average home, there might be two APs (one tunnel). For three APs, we have either two or three tunnels (three if we support STP). > What I would like is something that would be easier to scale (I run the > wireless network for the Southern California Linux Expo and so I am a bit > biased towards figuring out the large scale problem) > What I do there is to have all the APs on the same ESSID, but them have them > all bridge the wireless to the wired network (a different VLAN for 2.4 and 5) > and then the wireless VLANs get run through a router to connect them to the > wired networks. Yes, all that's great in a managed network, particularly one where one has a proper router that can filter out the unwanted multicast from the wired network. The IETF does that. > If there is no central system, this gets a little uglier. By using multicast > (either explicitly or by turning the UDP unicast address into a MAC > multicast There is no central system, except that homenet will provide a routing protocl which will allow a system to elect itself master. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [