search

freifunk-berlin / falter-packages

Sources for the falter-packagefeed
GNU General Public License v3.0
12 stars 17 forks source link

ct or not ct? #27

Closed PolynomialDivision closed 3 years ago

PolynomialDivision commented 4 years ago

Candela is a company that has signed an NDA to get the source code for ath10k. A person named Ben then added patches to the firmware. This person always rebase his changes to the latest official firmware.

But now there is the problem that Mesh-Point aka 802.11s is not available for wave1 products. Mesh-Point still works fine with the official firmware. But now the ct firmware has become openwrt default.

Now the weakness is that we only have a "packagefeed", because the user may have to intervene himself. This means that the user has to unselect the ct driver and install the non-ct firmware.

I still think that we can do that in the buildbot and it's good. That automatically compiled images of us have the non-ct firmware.

Akira25 commented 4 years ago

How can we solve this for general purpose? Which commonly used routers in Freifunk Berlin network are affected by this?

So falter-Images will ship with the 802.11s-capable driver by default, right?

kls0e commented 4 years ago

How can we solve this for general purpose? Which commonly used routers in Freifunk Berlin network are affected by this?

There is either IBSS or 802.11s for these chips atm. What is general purpose? I'd say 802.11s by now. All "wave 1" devices are affected by this, such as Archer C7 V2 or AC-Mesh (<- !). I cannot seem to find a complete list of wave 1 devices on openwrt.org atm.

So falter-Images will ship with the 802.11s-capable driver by default, right?

I'd say yes, that would be the best way to push 802.11s distribution. People can always use ct for IBSS as described here: https://wiki.freifunk.net/Ubiquiti_Unifi_AC_Mesh#IBSS.2FAd-Hoc-Mesh-Support_aktivieren_.28kein_802.11s_m.C3.B6glich.29

pmelange commented 4 years ago

I think it would be cool if we could develope a package which would go upstream and provides the firmwares from both ct and non-ct with a mechanism to switch between the two. Then hopefully the user could just select how they would like to mesh (wizard) and the correct firmware is loaded as a result.

I'm just not sure how to implement such a thing.

SvenRoederer commented 4 years ago

I'm just not sure how to implement such a thing.

As you mentioned in https://github.com/freifunk-berlin/firmware/issues/696#issuecomment-502457490 this requires patching OpenWrt Makefiles directly. An other way was mentioned by NeoRaider a bit later, which is extending the OpenWrt-config by a generic "Firmware-type" selection. But this is all about modding OpenWrt or hacking something ugly

Akira25 commented 4 years ago

There might be a third way: https://wiki.freifunk.net/Ubiquiti_Unifi_AC_Mesh#IBSS.2FAd-Hoc-Mesh-Support_aktivieren_.28kein_802.11s_m.C3.B6glich.29

AFAICT, we can write those commands mentioned there into a shell script and provide a nice CLI and GUI.

This should do the job perfectly for falter purposes. Then we can await a superb solution by far more professional upstream developers easily.

Akira25 commented 4 years ago

Sketch for an implementation:

Falter-images will be compiled with non-ct-driver erverytime.

If the wizard runs on a wave1-device and ad-hoc gets selected at the last page, it will configure 11s first. Then it will generate a uci-defaults script, which will run the command-sequence from the wiki at router-startup. In addition this script will switch the meshmode of the interfaces to ad-hoc.

Is that solution agreeable? In that way, we can get a solution fairly fast.

Akira25 commented 3 years ago

Update

Recently, we discussed that subject in our Matrix-room also. Some thoughts on that:

About the ath10k stuff. I think we should stay with the default -ct firmware in our builds. The reason is that -ct supports adhoc, which the closed-source firmware doesn't. If the user wants to switch to 802.11s, then we should provide a way for the change to happen. We should not do it by default. KISS principle (Keep It Simple and Stupid) for the build process.

why should we use ath10k-ct? ath10k-ct reports rx rate Otherwise it remains at 6mbit/s, keeping users nervous

Imho it would be easier to implement a pre-build-hook in the builter script, which checks for presence of packages indicating a wave1 chipset is used and then replaces ath10k-ct and Firmware with-non-ct. If either one of the follwing packages is about to be included:

ath10k-firmware-qca9887 ath10k-firmware-qca988x .. Then replace

kmod-ath10k-ct with kmod-ath10k ath10k-firmware-qca.*-ct with ath10k-firmware-qca.*

Akira25 commented 3 years ago

Solved via https://github.com/Freifunk-Spalter/builter/pull/44.

Wave1-Devices use non-ct driver and firmware by default now.