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

[David Lang <david@lang.hm>]

On Wed, 18 Dec 2013, Michael Richardson wrote:

> Date: Wed, 18 Dec 2013 15:07:15 -0500
> From: Michael Richardson <mcr@sandelman.ca>
> To: David Lang <david@lang.hm>
> Cc: cerowrt-devel@lists.bufferbloat.net
> Subject: Re: [Cerowrt-devel] treating 2.4ghz as -legacy?
> 
>
> David Lang <david@lang.hm> 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.
>
> 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).

actually, the _average_ home system probably only has a single AP :-)

But if we are going to do something like this, it needs to be able to scale to 
something much larger than just a small home system.

>    > 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.

Well, in our case the cerowrt devices should be able to do this.

I believe that Linux allows having both tagged and untagged packets on the samy 
physical interface, so the APs could communicate on a VLAN and one could be the 
gateway to the rest of the network (similar type of overhead in this case to GRE 
tunnels in that all traffic would get routed through one system, but I think it 
would still be less)

Also, if you use multicast MAC, it only is multicast on the local subnet, to 
something the other side of a router it looks like unicast traffic.

>    > 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.

once a system has elected itself master, we now have a central system :-)

David Lang