Drop support for IBSS Mesh

[mweinelt]

The scheduled domain switching is now in place and v2019.1 will be the last Gluon major release with support for IBSS Mesh.

Support for IBSS Mesh will be dropped in master as soon as v2019.1 is branched.

[kaechele]

If so target mvebu-cortexa9 can be removed and #1730 can be closed. No device in that target can currently do 802.11s.

[belzebub40k]

@kaechele That target was also not capable to do IBSS. It was originally added because there was a statement they are going to work on 802.11s support which was later revoked. But I don't like the idea of dropping it as we have a few devices running in our community.

[rubo77]

I checked with my site-conf scraper: https://github.com/rubo77/site-conf-scraper which uses all sites in the wiki site-conf page and found only 19 sites still using IBSS: ffruhr-site-ffalpen, ffruhr-site-ffher, ffruhr-site-ffhnx, ffruhr-site-ffniers, ~site-ff3l~, ~site-ffa~, site-ffac, site-ffbs, site-ffgoe, site-ffhb, site-ffhl, site-ffhmue, site-ffl, site-ffms, site-ffniers, site-ffrgb, site-ffrn, site-fftr, site-neuss

not sure if any of them are still active and not all of them must still be true, I just used

grep -r ibss *|grep =|grep -v GLUON_|grep ibss

on the tmp folder with the downloaded sites created by the script.

[rotanid]

@rubo77 your way to create this list may be broken, as for example we (site-ffa) don't use IBSS.

[rubo77]

@rotanid I just downloaded the default branches (mostly master) so, yes, the list is outdated, if they don't update their default branch. but it is the best we can get automatically so far, I guess. I am open for ideas, how to analyze all sites differently in my https://github.com/rubo77/site-conf-scraper

One Idea was to add a link to the site.conf in the Freifunk API: https://github.com/freifunk/api.freifunk.net/pull/146

[rotanid]

@rubo77 we have no branch "master" and the default branch uses 802.11s. check before writing please. but this gets off-topic, feel free to contact me via IRC on this matter.

[kpanic23]

@rubo77 Well, we (ff3l) do use the master branch and have dropped IBSS support in March 2017 (https://github.com/ff3l/site-ff3l/commit/187f6834537ce0eb1a03cafa2113b2cc82046fea). I have no idea what your scraper does, but it definitively is wrong. Maybe it clashes with multi-domain sites having neither nor in site.conf?

[yanosz]

Hello,

we're still using IBSS in cologne. We've had some discussions about moving to 802.11s but I'm not sure, if this is a good way way to go.

Many broadcom chipset do not support 11s, but they go for IBSS. Some controller based installations (e.g. Ubiquity ones) can do ap-client only. I don't think, that our network is going to be homogeneous in the near future. There will be different wlan-modes running batman-adv on top of it. Multisite setups are a nice way to go (let the user decide what mode to use), although packet selection (e.g. ath10k variant) cannot be done on a site basis.

I don't know, to what extent dropping IBSS will make gluon smaller. Maybe 841n devices could profit from smaller softmacs, but I don't know the actual implications. Having IBSS-meshing in a dedicated, external package appears reasonable to me, but I'm not sure about the implications.

Greetz, yanosz

[kevin-olbrich]

Hi @yanosz,

can you please share which ubnt hardware you mean? I did a lot of large migrations recently for various domains / communities and did not meet any hardware, that would be lost after moving to 11s.

[yanosz]

Hello,

@kevin-olbrich I don't get your question. IMHO the hardware is irrelevant, since the wifi-mode has to be configured at the controller. From my knowledge, Ubiquity's mesh feature is not compatible with 802.11s.

Greetz, yanosz

[kevin-olbrich]

@yanosz What exactly has a controller to do with gluon? Do you connect to IBSS with 3rd party / non-gluon devices? If yes, why? Maybe you can give me some more details to understand your setup / problem.

[yanosz]

@kevin-olbrich: I don't think, that this discussion is about dropping IBSS anymore. We can have it on IRC if you like.

[kevin-olbrich]

@kevin-olbrich: I don't think, that this discussion is about dropping IBSS anymore. We can have it on IRC if you like.

Sure it is but I've just joined #gluon.

[rubo77]

to what extent dropping IBSS will make gluon smaller?

That is an interesting question

[Adorfer]

@yanosz you state "Many broadcom chipset do not support 11s": Which BCM device is currently supported by gluon? (or is there any FOSS-driver for BCM available in the near future?)

Or to say it straight up: i don't see that closed source/blob-devices should influence our design decision in a different way than "do not spend any consideration about them"

[yanosz]

@yanosz you state "Many broadcom chipset do not support 11s": Which BCM device is currently supported by gluon?

None - such devices are listed as broken, since 11s is a must-have by definition.

(or is there any FOSS-driver for BCM available in the near future?)

The RaPi community would love it, I guess. But I'm not aware of any.

Or to say it straight up: i don't see that closed source/blob-devices should influence our design decision in a different way than "do not spend any consideration about them"

I'm interested in Pico Peering and not in telling people what devices to use.

[kevin-olbrich]

@kevin-olbrich: I don't think, that this discussion is about dropping IBSS anymore. We can have it on IRC if you like.

We had a long talk about this change. What is the disadvantage of leaving IBSS support in Gluon? I don't use IBSS, only Mesh 11s for all setups and don't plan to but it is a valid argument to drop / don't introduce support for IBSS-only hardware.

[rubo77]

to what extent dropping IBSS will make gluon smaller?

That is an interesting question

Those were points mentioned in IRC:

• dropping ibss gets us another mac address we can use (i.e. for OWE #1586)
• at the moment we drop IBSS, it would become possible to use more of the 11s functionality (which would that be???)

also I think:

• the removed code frees up some disk space: https://github.com/freifunk-gluon/gluon/search?q=ibss&type=

[CodeFetch]

it is a valid argument to drop / don't introduce support for IBSS-only hardware

Yes, because WLAN modules which do not support 802.11s don't, because the hardware isn't good enough or the Linux driver and firmware isn't maintained properly. Furthermore if someone buys a router supported by Gluon and moves to another community network which does not support it, that's a problem.

The point against introducing devices only supporting IBSS is that it's not really a mesh like 802.11s. It's more like a hack used for mesh. There will never be mesh-specific amendments if any. With IBSS you're stuck as it is. WIth 802.11s you'll get updates like MCCA in the future. 802.11s is still emerging while IBSS is a dead, fixed specification.

[CodeFetch]

(or is there any FOSS-driver for BCM available in the near future?)

The RaPi community would love it, I guess. But I'm not aware of any.

Will likely never happen as the driver is open-source, but the chip is running a closed-source binary blob. When we have the capabilities to reverse-engineer this thing, you'll already see them in museums.

The Mediatek/mt76 chipsets also run a closed-source binary blob, but fortunately it supports 802.11s in its minimal specification, but this is also not a really future-proof chip.

The Atheros/ath9k chipsets don't run a firmware blob. They are more like a software-defined radio controlled by the open-source Linux driver. So you can do some cool things with them (like a TDMA implementation like Ubiquiti AirOS, Mikrotik and TP-Link Pharos APs and a Russian company http://www.netshe.ru/tdma offer), but they are near EOL.

The Qualcomm/ath10k chipsets have a closed-source binary blob and a very, very powerful RISC-processor, but fortunately you can sign an NDA with Qualcomm using their open-source-project to get access to all the specifications and software needed to write your own firmware. The only person I know who wrote a custom firmware is Ben Greear from Candelatech who develops the IBSS firmware we have used so far (Ubiquiti also has a custom firmware for their AirOS TDMA). If you want a specific feature you can pay him or maybe also Kalle Valo (who is likely more expensive and busy, because he officially works for Qualcomm).

So when it comes to proper, future-proof 802.11s support, there is no way around ath10k.

EDIT: By the way NETSHe uses an old B.A.T.M.A.N. Advanced version, but as far as I understood it does not really have mesh-capabilities.

[rubo77]

@CodeFetch: great post, you should move this into the Wiki, as it is most important for others, tho know, where the journey goes. Maybe also add some more example-routers for each target.

[yanosz]

Well, it feels like this discussion gets slightly out-of topic.

I'm not interested in arguing whether to use 802.11s or IBSS, whether a migration to 802.11s makes sense or not or whether ath9k is better than ath10k due to Open Source firmware, or whether, if using 11s instead of IBSS you can have a nicer setup due to more features or not. This is just OT.

I tried to outline the consequences of removing IBSS support in Gluon at my site. IMHO the upside of removing IBSS support in gluon is a rather small simplification in gluon's DSL and Makefiles (-> less maintenance work) and possible less flash space on devices. Assuming, that Gluon continues to transform site-configurations to uci settings and that OpenWRT itself continues to support IBSS, I expect this advantage to be rather negligible.

IMHO the downside of removing IBSS support is forcing users to abandon devices and communities to migrate the network. I don't like that.

I guess, that moving IBSS-support to an external package is somewhat easy to do: The package will probably contain a single update script changing the wifi-Type, similar to #1719 - This will probably reduce the complexity of Gluon's core, while allowing communities to use IBSS, still.

I also think, that a more diverse network structure including various macs (e.g. Unifi-Stock-Firmware MAC) is out there anyway and there isn't gained much from homogenizing different MACs in use in a single network. IMHO it'd be better to have more macs (e.g. an additional client ap-mac configuration to peer with unifi-networks) and a concise strategey, than less (i.e. removing IBSS).

[CodeFetch]

Using IBSS, because of a few Broadcom devices is not a good idea. Please show me a community with more than 2 of those devices. Gluon never officially supported these. They were always marked as broken.

[CodeFetch]

@yanosz Aside from that you seem to be the only one here from a community which still uses IBSS, about what devices are we talking here?

A5 V11 A long EoL USB-stick 1x1 MIMO sized router with an outdated chip - very unlikely that this one is used productively anywhere. Aside from that it has only 4/32 MB and support will be dropped this way or that way.

D-Link DIR-615 H1 and D1-D4 There are about 30 revisions of this router - unlikely that someone has one of these. Aside from that these devices are 4/32 MB and support will be dropped this way or that way.

VoCore 1 is a development board and thus not really used anywhere

Raspberry Pi Aside from that these don't have proper antennas to be used as a router the WLAN chip never worked properly, did it?

Lamobo r1 an overprized Banana Pi clone - does anyone own this? And how should this support IBSS with a Realtek WLAN chip, at all?

Just assume we we're professionals here getting paid with a wage of third-world computer specialists (about 20-30€ per hour) -> This discussion already costs much more than replacing all these devices with proper ones. Every minute we spend on keeping IBSS working or even thinking about IBSS is a wasted minute.

[kaechele]

Trying to be pragmatic: Would it be possible to offer IBSS as a module/package and hand that over to the community for supporting? Then whoever is still using IBSS can keep maintaining it and do all the maintenance fix-ups when a new release breaks anything?

I believe a PR that drops IBSS support could be used by any interested party as a starting point to craft a separate package to re-introduce support. That way everyone should get what they want (maintainers lose burden of maintenance and IBSS users can continue using future gluon releases).

[CodeFetch]

Trying to be pragmatic: Would it be possible to offer IBSS as a module/package and hand that over to the community for supporting?

I think it's not worth it. The mesh protocol is interwoven with many other packages. It's a big effort to make all these packages mesh-protocol-agnostic. We wouldn't consider dropping IBSS if it would not be effort to maintain it, because dropping it is also effort...

[T-X]

Last week I've had the opportunity to talk with @yanosz afk.

IMHO the downside of removing IBSS support is forcing users to abandon devices
and communities to migrate the network. I don't like that.

And from the talk I got the impression that not the former but especially the latter would be an issue for (some people at?) Freifunk KBU.

It seems to me that for Freifunk KBU the overall situation is a bit different compared to most other communities using Gluon. In that the updating process there is not as unified/centralized, meaning there are multiple people building and publishing firmwares, and there are many routers with the autoupdater disabled. Which means that for this community the coordination for a migration is a way bigger effort than for most other communities, if I understood correctly.

Maybe it'd make sense to discuss this in a next Gluon developer mumble? Would be great if some people from Freifunk KBU could join.

[yanosz]

@T-X - thanks for jumping in and inviting me to mumble.

I'm not that happy with continuing this discussion - it appears to escalate in time and effort. If IBSS is removed, I'll write a package - if not, I won't. If there's time to kill, I'll implement a client-based peering mac.

[CodeFetch]

@yanosz I understand your situation. The only thing I can do is to give you the advice to not try to fix an issue by a workaround. Your community needs to get it done sooner or later. People disabling the autoupdater are aware that this might have consequences. This is their own problem, their own fault. Many people writing firmware? It's their fault and of those who install their custom firmware. I was in the same situation like you and always tried to get it working, adding new device support etc. When I was talking to people from a well-maintained community I realized that sometimes things have to break to wake people up. Don't try to do a workaround. This is not leading to the goal you wish it would.

[yanosz]

@CodeFetch: thank for the empathy, but I don't think, that you're seeing what I'm up to. However, this is completly OT and I don't think, that we can settle things using github's bug tracker.

[kevin-olbrich]

We also had a talk and it‘s not a question about technology, it’s more about decentralization. With AutoUpdate on, you trust the admins to do the right things. Who guarantees that the next update does not contain SSH keys?

From technology point of view, I second the opinion of @CodeFetch. All the setups that I have access to, use 11s only.

From the Freifunk point of view (everyone can contribute), @yanosz is right.

Currently there are no good reasons why support should be dropped. The whole point about it is, that 11s suites better.

I don‘t plan to use IBSS anymore but what do we win by dropping it?

[CodeFetch]

We also had a talk and it‘s not a question about technology, it’s more about decentralization. With AutoUpdate on, you trust the admins to do the right things. Who guarantees that the next update does not contain SSH keys?

So you should better put your router in a DMZ and behind a firewall if you're concerned. Who guarantees that your OS does not have a backdoor? Nobody. At some point you always have to trust. This has nothing to do with decentralization. (A least it seems you don't question trusting Gluon)

From the Freifunk point of view (everyone can contribute), @yanosz is right.

Yes, of course he can do, but only if he's willing to maintain this all alone, because Gluon dev's won't contribute to something which requires more work, more testing, more abstraction without any gain and won't merge something that nobody maintains.

Currently there are no good reasons why support should be dropped. The whole point about it is, that 11s suites better. I don‘t plan to use IBSS anymore but what do we win by dropping it?

Of course there are many reasons... As you see yanosz is the only one here still using IBSS, so he's also the only one able to test if something breaks. The IBSS driver for ath10k is not the mainstream ath10k driver. It's the custom driver from Candelatech. If something there breaks we won't notice and the communities will complain, that suddenly all their mesh-only routers have gone forever... Then we'll say "It's your own fault if you don't test the firmware you built beforehand" and they'll say "But you officially support IBSS" and we'll say "Yes and no. There is only one person maintaining this thing. Gluon does not offer any support.". We don't want to do testing for a wireless protocol we don't use.

Next thing is that if you always try taking the work out of the hands of the communities, they won't be able to do it themselves anymore, they get used to Gluon always doing everything for them. There was already a discussion about offering scripts for site migration on Gluon updates. Hell, no! They should read the changelog and understand what they're doing. Gluon is not a project for delivering installation-ready images for mesh routers like LibreMesh... Gluon is a project to join efforts in software development for a framework with which you can build your own firmware. Gluon's aim is joining development effort and not taking the work out of the hands of the community.

Considering IBSS in new packages is work, considering IBSS when changing packages is work, considering IBSS when testing is work. We neither have the will, nor the time, nor the financial resources nor the aim to support this, because we don't see any gain.

@kevin-olbrich you were talking about decentralization. This (being able to build your own firmware) is decentralization and not distrusting people who are willing to lighten your work for providing you with updates and infrastructure. What the infrastructure people do is mostly selfless, so it's an pessimistic assumption to turn off autoupdates. If you're concerned about your private networks security, put the router in a DMZ. If your're concerned the router could do something nasty with your internet connection, put it behind a firewall and only allow connections with the VPN port.

If you really don't want to trust these infrastructure people, you should neither use their firmware nor their infrastructure. But that means, you need to run your own supernode, exitnode and your own firmware. This means you'll also need to keep your firmware up-to-date and if you see that Gluon drops IBSS you need to respect that or involve in the project and convince others that there is a good reason for spending free-time on an outdated, restricted protocol. So it's a matter of technology again.

Technologically neither that communities have to update their firmware and migrate to 802.11s nor that people want to distrust the firmware builders, but don't want to keep their firmware up-to-date convinces me even a little bit to think it is a good idea to keep supporting IBSS.

Another example: Socially and ecologically it makes sense to upgrade 32/4 MB devices to 64/16 MB, but technologically you can't expect Gluon devs to be convinced to maintain the needed patches to build firmware for customized devices. As long as these customized devices make sense for the Freifunk Hannover community, they'll provide Gluon patches, but nobody there expects it to become part of Gluon. Similary yanosz can expect people to understand that for some communities it is not possible to keep nodes in their network running which don't have autoupdates enabled without providing IBSS mesh, but from a technological perspective this is a failure by the people running these nodes.

[CodeFetch]

@yanosz I really understand your point when I look at your map. Half of your network has the autoupdater deactivated. Sorry, but if people are not aware that they need to do updates manually, then this was just a really, really bad idea (not only security-wise).

[christf]

The scheduled domain switching is now in place and v2019.1 will be the last Gluon major release with support for IBSS Mesh.

Support for IBSS Mesh will be dropped in master as soon as v2019.1 is branched.

What is the rush? Why not simply wait until the devices are EOL?

[neocturne]

The two main reasons are:

• Simplification of config generation / reduction of number of combinations to test
• Reduction of number of MAC addresses reserved per radio, allowing to use 3 or even 4 radios in a node without increasing the probability for MAC address collisions

[christf]

I do not think the simplification alone is significant.

How significant is support for 3 or 4 radios? How can we weigh this against abandoning existing devices?

Plainly put: If we do not get significant benefit I would not like to see functionality broken elsewhere.

[mweinelt]

We're not abandoning any devices by dropping support for IBSS, not any that I know of at least.

It's very clear at this time that 802.11s links are the future for mesh networks and we also offer the means for communities to do a reasonable migration towards it. And in return they'll even get support for mt76 based devices.

We'll also need additional MAC addresses for OWE (Enhanced Open) and its transition mode. New features await.

Edit: We have a limited amount of MAC addresses per device, especially mt76 devices are limited in that regard. We have currently have two MAC addresses allocated to ibss0 and ibss1, which could for example be relocated to OWE transition VAPs.

[christf]

as discussed on irc #1658 would benefit from dropped IBSS support. Are there others?

[blocktrron]

@christf https://github.com/freifunk-gluon/gluon/pull/1666 can also benefit from this change.

[mweinelt]

as discussed on irc #1658 would benefit from dropped IBSS support. Are there others?

I think you mean #1586. Because #1658 is about the encryption of 11s mesh links through a preshared key, nothing related to additional MAC addresses.