Re: [Cerowrt-devel] treating 2.4ghz as -legacy?

[David Lang <david@lang.hm>]

 On Wed, 18 Dec 2013 18:18:59 +0000, Toke Høiland-Jørgensen wrote:
> Michael Richardson <mcr@sandelman.ca> 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