On Wed, 18 Dec 2013 18:18:59 +0000, Toke Høiland-Jørgensen wrote:
Michael Richardson <[email protected]> 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
_______________________________________________
Cerowrt-devel mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/cerowrt-devel
