the wizard should not allow the user to select adhoc when the driver does not support it

[pmelange]

With the introduction of 802.11s, and the need to allow users to select if they want adhoc or 802.11s, we have been introduced with a new issue. Not all drivers support adhoc mode. The wizard should be changed so that adhoc is listed only when it is supported.

To know if a device supports a certain protocol, the following command can be used. iw phy phyX info

Here is the result of a device which supports adhoc (look for IBSS)

    valid interface combinations:
         * #{ managed } <= 2048, #{ AP, mesh point } <= 8, #{ P2P-client, P2P-GO } <= 1, #{ IBSS } <= 1,
           total <= 2048, #channels <= 1, STA/AP BI must match, radar detect widths: { 20 MHz (no HT), 20 MHz, 40 MHz }

Here is the result of a device which does not support adhoc

    valid interface combinations:
         * #{ AP, mesh point } <= 8, #{ managed } <= 1,
           total <= 8, #channels <= 1, STA/AP BI must match, radar detect widths: { 20 MHz (no HT), 20 MHz, 40 MHz, 80 MHz }

This idea was first introduced https://github.com/freifunk-berlin/firmware-packages/pull/180#issuecomment-472177729

Upstream in OpenWRT, adhoc is also in the list of modes even if the device doesn't support it. Therefore there is also an issue upstream https://github.com/openwrt/luci/issues/2628

[SvenRoederer]

what about creating a tools-function "getMeshModes()" which returns a list like:

• {"2GHz": {"IBSS"}, "5GHz":{"Mesh"}}
• {"2GHz": {"IBSS", "Mesh"}}
• {"5GHz": {"Mesh"}}
• ... depending on the supported mode of the board. In the first implementation, we can put a lookup-table for static list based on the board. this can then switch to dynamic code, as it's avail. With this wrapped function, the implementation can change without having to change the wizards code.

[SvenRoederer]

just drafted a wiki-page: https://github.com/freifunk-berlin/firmware/wiki/IBSS-vs.-802.11s to collect boards and their supported WiFi-modes

[pmelange]

I have been doing some experimenting using the imagebuilder (vanilla openwrt snapshot).

If I build an image with make image PROFILE=ubnt_unifiac-mesh I get the ct drivers. With these drivers IBSS is supported but 802.11s is not.

if I build an image with make image PROFILE=ubnt_unifiac-mesh PACKAGES="-ath10k-firmware-qca988x-ct ath10k-firmware-qca988x -kmod-ath10k-ct kmod-ath10k" I get the non-ct drivers. With these drivers 802.11s is supported but IBSS is not.

NOTE: This only affects AC-gen1 devices. With AC-gen2 devices, IBSS and 802.11s are both supported with the ct drivers.

One possible option would be to have the both the ct and the non-ct ipk files stored in the squashfs and have the wizard install the driver depending on the desired protocol. The ipk files can be added to the squashfs filesystem by following these instructions: https://openwrt.org/docs/guide-developer/build-system/use-buildsystem#custom_files

[pmelange]

I have done a bit of testing with a d-link dir-842-c3. This is an AC-gen2 device.

With the -ct driver, both IBSS and 802.11s are supported.

With the non-ct driver, 802.11s is supported but IBSS is not supported.

[SvenRoederer]

Imho it's ok to not support IBSS . It's commonly agreed that IBSS is deprecated, so when new boards no supporting IBSS in coexistence with 802.11s natively, we just not offer IBSS-support. Is it really worth to add additional code complexity for such a "feature".

Is it know, how much boards are affected?