lime-system: wireless: add option distance_use_auto_if_available

[a-gave]

lime-system: wireless: add option distance_use_auto_if_available

Closes #932

Introduce the wifi option distance_use_auto_if_available by default true
to enforce the value "auto" as distance for radio drivers that supports it
like kmod-ath9k when compiled with CONFIG_PACKAGE_ATH_DYNACK=y

Implement a check if driver supports auto setting.
At firstboot run 'iw phyX set distance auto' relying on the iw error
i.e. 'command failed: Not supported (-95)' if unsupported
Save the result in lime-node in a format like lime-node.radio0.dynack=0
Re run the iw command on the same phy when the macaddress has changed
in case of powering off and plugging a different usb wireless adapter

Implement a check if distance 'auto' is requested for a driver that does not support it.
Use the lime-defaults value as safer option than allowing to set "auto", which could lead
to the minimum being applied at next reboot, potentially compromising long distance wireless links.

If auto is requested for a driver that doesn't support it
iw will fail with 'command failed: Not supported (-95)',
the value auto is not applied and the previous valid value i.e. '1000' is kept
However at next reboot if the value auto was saved in /etc/config/wireless
the coverage will be set to 0 on tested hardware.

To verify the applied coverage on a given phyX:
iw phy phyX info | grep Coverage
In ath9k check the ack timeout in uS, followed by A for auto-determined or S set:
cat /sys/kernel/debug/ieee80211/phy0/ath9k/ack_to

Further resources and links

• "[RFC] API for setting ACK timeout" thread on ml linux wireless
  https://www.spinics.net/lists/linux-wireless/msg43572.html
• Introduction in linux of setting coverage class for long distance wireless links:
  https://linux-wireless.vger.kernel.narkive.com/qo3X9KdF/patch-0-4-setting-coverage-class-and-ack-timeout-and-slot-time
• Introduction in iw of dynack:
  https://git.kernel.org/pub/scm/linux/kernel/git/jberg/iw.git/commit/?id=e642142d68850b7eb161489a984ec6817b10c51b
• Support of dynack in openwrt:
  https://git.openwrt.org/?p=openwrt%2Fopenwrt.git&a=search&s=dynack
• Comments from communities using dynack:
  https://www.arednmesh.org/content/auto-distance-setting-0

Due to different driver implementations, producing a list of wireless drivers
that support different distance/coverage optimizations for outdoor usage could be complex.
Looking at the source code a starting point could be to check drivers that handle NL80211_ATTR_WIPHY_COVERAGE_CLASS
i.e. grep -rl 'distance|coverage' /drivers/net/wireless/
Among those, currently dynack is supported just by ath9k

Tested on these devices running lime master and openwrt 24.10.x or snapshot:

• ubnt_litebeam-m5-xw
• gemtek_wvrtm-127acn
• gemtek_wvrtm-130acn
• cudy_wr3000s-v1
• openwrt_one (usb adapter rtl8192cu)

[ilario]

Thanks!
I consider this as very useful!
Do you know if the auto distance is available on many routers? Only on ath9k?

A doubt on the code:
The function wireless.is_distance_auto_available works trying to set the distance to auto. If a set distance is specified in the options, will it be then applied later or the auto thing will remain? For example, after running lime-config is the active distance the one set in the config files, or the distance remains to auto and the user should reboot for applying the correct distance?

[a-gave]

Thanks! I consider this as very useful! Do you know if the auto distance is available on many routers? Only on ath9k?

A doubt on the code: The function wireless.is_distance_auto_available works trying to set the distance to auto. If a set distance is specified in the options, will it be then applied later or the auto thing will remain? For example, after running lime-config is the active distance the one set in the config files, or the distance remains to auto and the user should reboot for applying the correct distance?

I updated the description. If the distance option contains a valid value it will be applied at next reboot or after running wifi, if the wrong value is wrote in /etc/config/wireless running wifi won't apply it but at next reboot the value will be set to 0.

[ilario]

Ah, now I see :)
So the command iw " .. phy .. " set distance auto gets executed only the first time a radio is installed, not at every execution of lime-config. Nice!!

[a-gave]

I reworked this to use uci and fill lime-node with information on each radio if it supports dynack, like in the example below.
It now stores a more explicit option dynack = 0|1
and an option phy_macaddr to check if it is still the same radio.
These options are then filtered in https://github.com/libremesh/lime-packages/pull/1231/files#diff-285db103765ded7fe3d8db98961c090c19285ca5c1f79b2a4bc7c9edb6f38328R241-R242
to avoid writing them in /etc/config/wireless.
The option to store the macaddress is here named phy_macaddr instead of macaddr
to avoid interfering with possible other configurations for that radio.

• ubnt_litebeam-m5-xw (supports dynack):

config wifi 'radio0'
	option phy_macaddr 'f0:9f:c2:58:06:10'
	option dynack '1'

• openwrt_one (usb adapter rtl8192cu, doesn't support dynack)

config wifi 'radio0'
	option phy_macaddr '20:05:b7:00:04:82'
	option dynack '0'

config wifi 'radio1'
	option phy_macaddr '20:05:b7:00:04:89'
	option dynack '0'

config wifi 'radio2'
	option phy_macaddr '70:62:b8:96:6b:7d'
	option dynack '0'

[ilario]

I reworked this to use uci and fill lime-node with information on each radio if it supports dynack

Sounds something similar to what lime-hwd-openwrt-wan does, no? lime-hwd-openwrt-wan writes the config in lime-autogen, and if one wants to override it, can add the same section in lime-node.

Question: on the devices where this is possible, does this work with the default OpenWrt kernel selected options? I mean, does it work when creating images with OpenWrt's ImageBuilder or one should enable this feature and create an image with it using the BuildRoot?

[a-gave]

I reworked this to use uci and fill lime-node with information on each radio if it supports dynack

Sounds something similar to what lime-hwd-openwrt-wan does, no? lime-hwd-openwrt-wan writes the config in lime-autogen, and if one wants to override it, can add the same section in lime-node.

Seems the same. In this case i was wondering if writing it in lime-autogen would be better. Are you suggesting it should be so?

Question: on the devices where this is possible, does this work with the default OpenWrt kernel selected options? I mean, does it work when creating images with OpenWrt's ImageBuilder or one should enable this feature and create an image with it using the BuildRoot?

Nope. It should be enabled during the kernel compilation, so:

• yes BuildRoot
• no OpenWrt's ImageBuilder
• yes ImageBuilders compiled with the reduced kernel like https://hub.docker.com/layers/agave0/openwrt-imagebuilder/ath79-generic-24.10.4-alpine-small-flash

[a-gave]

Ok yes converted to write in lime-autogen instead of lime-node

[ilario]

Seems the same. In this case i was wondering if writing it in lime-autogen would be better. Are you suggesting it should be so?

I don't know what is better. But maybe using the same mechanism for this and for lime-hwd-openwrt-wan would make things easier to understand. From a user point of view, I think that it would be much more convenient if both used lime-node. But I suspect that from the technical point of view it makes more sense to keep lime-node for user-written stuff and lime-autogen for autigenerated things...

Question: on the devices where this is possible, does this work with the default OpenWrt kernel selected options? I mean, does it work when creating images with OpenWrt's ImageBuilder or one should enable this feature and create an image with it using the BuildRoot?

Nope. It should be enabled during the kernel compilation, so:

• yes BuildRoot
• no OpenWrt's ImageBuilder
• yes ImageBuilders compiled with the reduced kernel like https://hub.docker.com/layers/agave0/openwrt-imagebuilder/ath79-generic-24.10.4-alpine-small-flash

Argh. We could check how much does the image grow due to this option (e.g. compiling with and without, then checking the size of the stuff in the sysupgrade.bin files using binwalk). Then, if the chame is negligible, we could propose OpenWrt to activate it by default in the future releases (very likely it's too late for including this change in 25.12).

[a-gave]

Seems the same. In this case i was wondering if writing it in lime-autogen would be better. Are you suggesting it should be so?

I don't know what is better. But maybe using the same mechanism for this and for lime-hwd-openwrt-wan would make things easier to understand. From a user point of view, I think that it would be much more convenient if both used lime-node. But I suspect that from the technical point of view it makes more sense to keep lime-node for user-written stuff and lime-autogen for autigenerated things...

Yes, I initially put it under lime-node because it seemed to me more visible, but lime-autogen seems more appropriate.

Argh. We could check how much does the image grow due to this option (e.g. compiling with and without, then checking the size of the stuff in the sysupgrade.bin files using binwalk).

Will do

Then, if the chame is negligible, we could propose OpenWrt to activate it by default in the future releases (very likely it's too late for including this change in 25.12).

We can try, but I don't think it will be very useful. I imagine it was left off by default because it loses its usefulness if the devices are indoors.