How to suppress messages from a Wifi driver?

Troubleshooting
1

I have a TP-Link Archer T4U v3. I just compiled the RTL88X2BU driver for ARCH=arm64, copied 88x2bu.ko to /lib/modules/3.16.85+/kernel/drivers/net/wireless/, ran sudo depmod -a, sudo modprobe 88x2bu, then lsmod to ensure that the driver is working. Here is the drivers from the official site:

I also attached the driver itself that I compiled.

So the wifi works well, the only problem is it spams my Odroid board with messages:

[Album] imgur.com

If I connect my odroid to hdmi and view the screen, it’ll always show what I’m guessing is wifi status messages. If I log in to any user/switch user, I’ll still get these messages. But if I SSH into it, I don’t seem to get any messages. Is there any way to fix this?
88x2bu.zip (984 KB)

2

Depending on system defaults and settings, it is normal that kernel messages are printed to the local console, i.e. /dev/tty1, not SSH which is connected through /dev/pts/0. You can control the log level via: dmesg -n X with X being the level from 1 to 8 that must be understood by the message. So dmesg -n 1 will disable console log basically, dmesg -n 8 will show all messages, dmesg -n 4 should be default and show errors only. Interestingly the WiFi messages don’t look like errors, as they are not red coloured. Please try with 4 first and see whether it disables them already, else use 1 and see if that does it. So either something on the Odroid changes the default kernel log level or the WiFi diver prints its status in a wrong log level, in which case the drivers maintainer should be asked to change that.

3

Yeah it just looks like idle messages. dmesg -n 4 worked, so I guess it wasn’t default? I put it in rc.local.

4

Jep then the default was unexpected, while it’s still not great of a driver regularly creates expected kernel messages. I’ll have a look into it, probably the default can be changed via boot.ini cmdline options right in the first place.

5

If my wifi keeps dropping randomly such that I have to unplug and plug it back in to get connection, I’m assuming it has to deal with power management.

I went into /etc/modprobe.d/dietpi-disable_wifi_powersaving.conf
And added the line:
options 88x2bu rtw_power_mgnt=0

Do I need to do anything else? Should I use either of these?
rtw_enusbss=0
rtw_ips_mode=0

6

iwconfig wlan0 power off should actually do it. It only lasts until reboot but is called automatically when the interface is configured by the wireless-power off line in /etc/network/interfaces.

7

Running that command gives me

Error for wireless request “Set Power Management” (8B2C) :
SET failed on device wlan0 ; Operation not permitted.

I ran sudo modprobe 88x2bu ps_enable=0 and it didn’t give me an error or anything but I’m also not sure if it works.

8

You used sudo for iwconfig as well, right?

Another test:

sudo iw wlan0 set power_save off
9

Yes I did run it with sudo. If I didn’t use sudo, it would say the command iwconfig doesn’t exist.
I ran this:
sudo iw wlan0 set power_save off
and it ran without any errors/or any other message for that matter.

I’m guessing sudo modprobe 88x2bu ps_enable=0 didn’t work because I was unable to connect again until I plugged the wifi adapter back in.

Either that or I have a different issue. Is there a better way to diagnose my connectivity issues?

Edit: I’m wondering if it’s either a bad adapter or bad drivers, sometimes I’ll connect to it and it’ll be super laggy (10mbps or lower, down from a normal ~200mbps) before disconnecting me completely.

10

Here’s a dmesg log after I got a disconnect. Can you tell me why it disconnected/why I can’t reconnect?
dmesg.zip (56.4 KB)

11

Sorry for the missing reply, I just found this topic in my bookmarks. Have you been able to find a solution for the disconnects?

The first part of the log shows this every quite precisely 10 seconds:

[ 2724.238493] RTW: rtw_set_ps_mode(wlan0) Leave 802.11 power save - WIFI-LPS_CTRL_LEAVE
[ 2724.238528] RTW: rtl8822b_set_FwPwrMode_cmd(wlan0): FW LPS mode = 0, SmartPS=2, HW port id=0
[ 2724.963221] RTW: rtw_set_ps_mode(wlan0) Enter 802.11 power save - WIFI-TRAFFIC_IDLE
[ 2724.963282] RTW: rtl8822b_set_FwPwrMode_cmd(wlan0): FW LPS mode = 2, SmartPS=2, HW port id=0

So like the adapter exists power save mode for less than a second, then enters it again directly. But then it enters a re-connection attempt loop which fails, until the end of the log. I also see “cfg80211_rtw_set_power_mgmt(wlan0) enabled:1, timeout:-1” in there, so at some level power management is enabled.

The first disconnect shows:

[ 2794.587528] RTW: OnDeAuth(wlan0) - Start to Disconnect
[ 2794.587538] RTW: OnDeAuth(wlan0) reason=7, ta=a0:63:91:eb:9b:e8, ignore=0
[ 2794.587543] RTW: receive_disconnect

Checking those “reason” codes: 802.11 Association Status, 802.11 Deauth Reason codes - Cisco Community

7 | Class 3 frame received from nonassociated station | NOT SUPPORTED

Then repeatedly:

[ 3418.793872] RTW: OnDeAuth(wlan0) - Start to Disconnect
[ 3418.793926] RTW: OnDeAuth(wlan0) reason=15, ta=a0:63:91:eb:9b:e8, ignore=0
[ 3418.793960] RTW: receive_disconnect



15 | 4-Way Handshake timeout | NOT SUPPORTED

Which fits to those between the connection attempts:

[ 3422.804213] RTW: link to Broadcom AP
[ 3422.804220] RTW: start auth
[ 3422.804233] RTW: issue_auth
[ 3423.096541] RTW: link_timer_hdl: auth timeout and try again
[ 3423.096625] RTW: issue_auth
[ 3423.396543] RTW: link_timer_hdl: auth timeout and try again
[ 3423.396611] RTW: issue_auth
[ 3423.696528] RTW: link_timer_hdl: auth timeout and try again
[ 3423.696575] RTW: issue_auth
[ 3423.996521] RTW: link_timer_hdl: auth timeout and try again
[ 3423.996563] RTW: issue_auth
[ 3424.296529] RTW: report_join_res(-1)
[ 3424.297788] RTW: =>mlmeext_joinbss_event_callback - End to Connection without 4-way

To me it looks like a driver or firmware issue, probably incompatibility with the Odroid C2 (?) kernel, that power management cannot be turned off and that it re-enters power save mode less than a second after exiting it.

The Makefile of the driver has some CONFIG_POWER_SAVING = y config, probably setting it to CONFIG_POWER_SAVING = n disables the power save feature for the driver module.