From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bifrost.lang.hm (mail.lang.hm [64.81.33.126]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id 76BD821F19A for ; Wed, 18 Dec 2013 11:24:16 -0800 (PST) Received: from asgard (asgard.lang.hm [10.0.0.100]) by bifrost.lang.hm (8.13.4/8.13.4/Debian-3) with ESMTP id rBIJOEmX002540 for ; Wed, 18 Dec 2013 11:24:14 -0800 Received: from lang.hm (localhost [127.0.0.1]) by asgard (Postfix) with ESMTP id 4D3561383E2 for ; Wed, 18 Dec 2013 11:24:14 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Wed, 18 Dec 2013 11:24:14 -0800 From: David Lang To: In-Reply-To: <874n66yqcs.fsf@toke.dk> 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> Message-ID: <4400ed3b15245d06d0bf73d22f7a7692@lang.hm> X-Sender: david@lang.hm User-Agent: Roundcube Webmail/0.5.1 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 19:24:16 -0000 On Wed, 18 Dec 2013 18:18:59 +0000, Toke Høiland-Jørgensen 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. 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. I don't do IP management (DHCP in my case) on the individual APs, I do it on the box that is the router/firewall to the rest of the networks. in this sort of system, what we would need is a system that would do something along the lines of: APs report signal strength of stations they hear to a central location (probably via UDP so that the messages can't queue and be stale when they arrive, but also allowing use of multicast MAC to turn this into a multicast) some process decides what the 'best' AP to respond would be and records it in some sort of database (not SQL, possibly memcache) when an AP gets a connection request, it checks the client against the database, if it doesn't respond, doesn't have any info on the client, or says that this AP is the best AP, allow the connection now, there is a race condition here that APs could be checking as the data is changing, but since the client will retry a couple of times, this should give time for the data to stabilize. 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 address) the data can be sent to all the APs and they can do their own calculations. The problem would be that this would increase the risk of running into race conditions. David Lang