Support multiple client ESSIDs

[jplitza]

I think there are valid reasons for a community (not a single node owner) to have multiple ESSIDs for clients on their nodes, be it they want to announce a local "<community>.freifunk.net" as well as the currently advocated "Freifunk", or be it that their usual ESSID is dual-band but they want to have another one only for 5 GHz.

Since the last change, the site.conf reads:

wifiX = { ap = { ssid = "foo" }, ... }

This could easily be changed to either of the following:

wifiX = { ap = [ "foo", "bar" ], ... }
wifiX = { ap = [ { ssid = "foo" }, { ssid = "bar" } ], ... }

So questions are: Is this a feature that would be merged, and which of the site.conf formats is preferred? Also, what implications if any does this have on airtime consumption?

[FreifunkUFO]

if we would have more ESSIDs it would be nice to have them in seperate network-enviroments (different ips, subnet ...) . so config would be more complex :-o
btw: in leipzig our meshkit-firmware we are running 2 batman-adv networks on each node (with 2 essids, separated by wifi-vlan), its nice. atm our compatible gluon-firmware is only meshing with one of them.

[FreifunkUFO]

siehe auch #458 und weitere dort verlinkte ähnlichen tickets..

[jplitza]

#458 is about something completely different, namely configuring more ESSIDs in Luci, not via the site.conf as I'd like to have it.

And having separated networks also is something far more complicated and thus not in the scope of what I proposed. You need not only different ESSIDs for the clients, but also different IBSS/802.11s connections, fastd tunnels and batman interfaces.

[A-Kasper]

If I'm right, this is the most frequent requested feature. So I really
would suggest to implement it.
It would be nice to merge these ideas:
Setting multiple ESSIDs in the site.conf and add an option "configurable"
to an additional ESSID to make it free configurable over Luci.

2015-09-03 13:08 GMT+02:00 Jan-Philipp Litza notifications@github.com:

#458 #458 is about
something completely different, namely configuring more ESSIDs in Luci,
not via the site.conf as I'd like to have it.

And having separated networks also is something far more complicated and
thus not in the scope of what I proposed. You need not only different
ESSIDs for the clients, but also different IBSS/802.11s connections, fastd
tunnels and batman interfaces.

—
Reply to this email directly or view it on GitHub
#474 (comment)
.

[jplitza]

Do you propose to have a fixed SSID and en- or disable it in Luci? I can't think of any usecase for it, but I'll happily learn one. Or do you propose to have a freely configurable SSID in Luci? That simply won't happen upstream, no matter how often it is requested.

[wusel42]

Question: are all currently supported devices capable of doing up to three AP (2 open ones for Freifunk, one secured one for private WiFi) alongside ad-hoc and/or 802.11s? Can this be detected at run time, so e. g. private WiFi isn't offered when two Feifunk SSIDs are to be used and two is the limit?

[jplitza]

Obviously I cannot answer that question definitely for every supported device, but I am pretty sure the answer is "yes".

You can list the configurations supported by your chip by running iw phy and looking for "valid interface combinations". For TP-Link devices, those look like

* #{ managed, WDS } <= 2048, #{ AP, mesh point } <= 8, #{ P2P-client, P2P-GO } <= 1, #{ IBSS } <= 1,

meaning that we can have up to 8 AP or mesh interfaces, independent of the IBSS interface. So even if private WiFi is enabled and the community uses 802.11s (each eating one of those cells), the community could still use up to 6 client ESSIDs.

I can only speculate what the supported combinations for other devices are, but I am pretty sure every supported device supports more than two {AP, mesh point} interfaces. The other way round, we already require the devices to support AP and mesh point simultaneously.

---

Now a whole lot of people have commented here, but I still would like to hear word from @NeoRaider and @tcatm if this could get merged if I implemented it. So... ping?

[neocturne]

I'd like to avoid supporting multiple ESSIDs.

The only usecase I've heard so far (a unified "Freifunk" ESSID) is inherently broken as it completely breaks roaming in "border regions" where nodes of multiple communities are nearby. Please re-read the definition of a ESSID if you think this might be a good idea.

[wusel42]

There's one valid use case I think: migrating away from an old to a new SSID setting without kicking hundreds of users over night (e. g. »guetersloh.freifunk.net« => (possibly) »gt.freifunk.net«, to accomodate those parts of an administrative district that don't like to be summarized under it's lead city's name). See also Münster, Göttingen, ...

I totally agree with the argument against one unified ESSID; but that one is used anyway already, despite being broken by design.

[jplitza]

The only usecase I've heard so far (a unified "Freifunk" ESSID) is inherently broken as it completely breaks roaming in "border regions" where nodes of multiple communities are nearby. Please re-read the definition of a ESSID if you think this might be a good idea.

What about the one I mentioned in my first post, namely having a separate SSID for 5 GHz (to make it possible for devices that support it to force 5 GHz) while still having a unified one in 2.4 GHz as well as 5 GHz, so that 5 GHz is used at least sometimes?

Also, I know the definition of an ESSID. And that in the Freifunk context, it often simply does not apply. As far as I know, none of the currently existing Layer 3 mesh protocols support roaming (which is why @tcatm is developing it), and thus all communities not using B.A.T.M.A.N. advanced shouldn't use a single ESSID according to your argument.

[bittorf]

@jplitza we support roaming in weimar.freifunk.net with OLSR1