With EU HalowLink2 hardware (MM8108), version 2.11.8 (kernel 5.15.189, openwrt 23.05.6).
Trying to reduce the TX power on the wlan0 interface (in Access Point configuration) takes no effect. Both LUCI and iw dev wlan0 info report 15dBm at all times. OpenWRT successfully stores the desired configuration level and it survives reboots too but it never takes effect at the driver level.
Attempting iw dev wlan0 set txpower fixed 900 takes no effect either. It appears that the Morse driver completely ignores all attempts to reduce the TX power.
Interesting. I tried it while my AP did not have any associated stations. I doubt that would make a difference but I’d be interested to at least rule out that having stations associated are somehow part of the problem.
Regarding debug, does dmesg or logread show anything after attempting to change the txpower?
It might be worth dumping the netlink command, and seeing if there is any underlying response. In a separate terminal do the following
opkg update
opkg install kmod-nlmon
ip link add nlmon0 type nlmon
ip link set nlmon0 up
tcpdump -i nlmon0 -vv -w /tmp/power.pcap
Let tcpdump run while you set the txpower in a different terminal window. Once done, kill the tcpdump command and share the output pcap here
My apologies, can you try this again but use debug_mask=0xf as a module parameter when you insert the morse driver module.
The netlink commands definitely look like they succeeded. And no, I don’t believe this is specific to the regulatory - I tested in an EU band as well, with the same hardware and software. A bit baffling..
I’m going to need some help here on the right way to do this. The rmmod and insmod approach is short-lived as any attempt to do anything with the interface seems to result in the module being reloaded out from underneath me. I tried using uci add system module to force /etc/modules.d/morse to contain the flag but that doesn’t work either. Using /etc/modules.conf.d/morse.conf is ignored.
That said, on one single attempt at messing about with rmmod and insmod, I had some brief success. I managed to get the driver loaded and set the TX power using iw:
I then modified the interface from LuCI and tried to reduce the power even further, but suddenly it jumped back up to 16dBm, this time by morse_cmd_vendor_set_channel:
Following that, all attempts to change the TX power again using either LuCI or iw now don’t take effect, and no further log lines appear in dmesg when attempting to do so.
Any follow-up attempts to do this, even with the same steps, now don’t appear to work, even after a reboot.
For some reason I forgot you were using OpenWrt, despite answering an OpenWrt specific question above
Add option debug_mask '0xf' to the wifi-device section of type morse and then run reload_config after saving the file. That should insert the module with the correct parameters.
Thanks for this. I decided to reboot just to see what was happening at startup that was resulting in it ignoring my setting. You can see that it starts off setting to 9dBm and then, like above, the morse_cmd_vendor_set_channel comes along and sets it back to 16dBm:
So the morse_cmd_vendor_set_channelshould just be indicating the maximum power for the configured channel, and any power change should be indicated by the morse_mac_set_txpower which you are only seeing once - as it is skipped when the txpower is already set to the provided value.
So what I’m seeing from this log is that the power should be 9dBm, as subsequent calls aren’t triggering additional morse_mac_set_txpower lines. What happens if you try to set the power to 800?
Where I’m a little confused now is why iw is still reporting the 16dBm
Then repeat attempts to set to 900 using iw fail and do not log anything. Switching to 800 using iw succeeds and that is also confirmed by getting info from iw, and then switching from 800 to 900 in the same way succeeds and is also confirmed by iw:
After having tweaked LuCI settings a bit more to experiment with different channel widths, I now find myself unable to set via iw dev wlan0 set txpower fixed again. Last thing I see in the log is:
Excuse the repeat question, but at this point what was iw actually reporting for the power, 16dBm?
This sounds good.
Can you share the exact commands for how you are doing this? Seems like it’s interpreting the value as something too large and is setting it to the regulatory limit.
Note that the txpower value in UCI is specified in dBm, not mBm as is used in iw.
Sorry for the delay getting back to you here, using LuCI and UCI I can reproduce it. There may be a bug with the netifd script (i need to confirm as I was debugging) responsible for converting /etc/config/wireless into an appropriate iw dev call, and it looks like the AP bringup might be unsetting any configuration that is set to the net device prior to starting.
As you have shown as well, there is also something preventing you from setting the txpower to the same value iw had previously set, which is indicating to me that iw is somehow unaware of the intermediate call by (potentially) hostap.
For now, is it possible for you to leave the setting in LuCI to the default txpower, and use the command line to set the txpower after the AP is brought up? As this is functioning as expected.
I will get back to you with workarounds as soon as I can
No problem at all, there’s no real urgency for me to get this working through LuCI, this is all just desk prototyping at this stage. That said I’d be happy to test out workarounds and firmware.
