Information for 8723bu on Fedora 40

[apnix-uk]

Hi,

I just upgraded my laptop with rtl8723bu to Fedora 40 pre-release. I did have some trouble compiling on the 6.8 kernel so I'm currently running with 6.7.4. But after upgrading I couldn't connect to any wifi network. Bit of log searching shows there's probably been some changes in network manager that it wants to set a random MAC address by default and rtl8723bu seems to have trouble with that...

Mar 03 17:31:31 my_hostname NetworkManager[1365]: <info>  [1709487091.7338] manager: NetworkManager state is now CONNECTING
Mar 03 17:31:32 my_hostname kernel: RTL871X: RTW_ADAPTIVITY_EN_
Mar 03 17:31:32 my_hostname kernel: AUTO, chplan:0x20, Regulation:0,0
Mar 03 17:31:32 my_hostname kernel: RTL871X: RTW_ADAPTIVITY_MODE_
Mar 03 17:31:32 my_hostname kernel: NORMAL
Mar 03 17:31:32 my_hostname kernel: RTL871X: nolinked power save leave
Mar 03 17:31:33 my_hostname NetworkManager[1365]: <warn>  [1709487093.0211] device (wlp0s21f0u7i2): set-hw-addr: new MAC address C2:27:06:04:E5:64 not successfully set-cloned (stable-ssid)
Mar 03 17:31:33 my_hostname NetworkManager[1365]: <info>  [1709487093.0216] device (wlp0s21f0u7i2): state change: prepare -> failed (reason 'config-failed', sys-iface-state: 'managed')
Mar 03 17:31:33 my_hostname NetworkManager[1365]: <info>  [1709487093.0223] manager: NetworkManager state is now CONNECTED_LOCAL
Mar 03 17:31:33 my_hostname gnome-shell[2817]: Trying to re-add source System
Mar 03 17:31:33 my_hostname NetworkManager[1365]: <warn>  [1709487093.1301] device (wlp0s21f0u7i2): set-hw-addr: new MAC address AA:D2:AB:A1:17:5E not successfully set (scanning)
Mar 03 17:31:33 my_hostname NetworkManager[1365]: <warn>  [1709487093.1311] device (wlp0s21f0u7i2): Activation: failed for connection 'my_ssid'
Mar 03 17:31:33 my_hostname NetworkManager[1365]: <info>  [1709487093.1313] device (wlp0s21f0u7i2): supplicant interface state: inactive -> interface_disabled
Mar 03 17:31:33 my_hostname NetworkManager[1365]: <info>  [1709487093.1313] device (p2p-dev-wlp0s21f0u7i2): supplicant management interface state: inactive -> interface_disabled
Mar 03 17:31:33 my_hostname NetworkManager[1365]: <info>  [1709487093.1317] device (wlp0s21f0u7i2): state change: failed -> disconnected (reason 'none', sys-iface-state: 'managed')
Mar 03 17:31:33 my_hostname NetworkManager[1365]: <info>  [1709487093.1385] device (wlp0s21f0u7i2): supplicant interface state: interface_disabled -> inactive
Mar 03 17:31:33 my_hostname NetworkManager[1365]: <info>  [1709487093.1388] device (p2p-dev-wlp0s21f0u7i2): supplicant management interface state: interface_disabled -> inactive
Mar 03 17:31:35 my_hostname kernel: RTL871X: nolinked power save enter

The solution is to fix the MAC address in the 'Identity' tab of the connection through Gnome Settings and set 'Cloned Address' to 'Preserve'. Then it works just fine.

So I am not sure about the 6.8 compile issue or whether this is an issue in the driver or a problem with network manager/changes in Gnome/Fedora etc. but I hope this helps anyone who has this issue because there's a workaround at least and I thought this worth a mention.

Best regards, Matthew

[lwfinger]

Thanks for the report. I have no idea why NetworkManager in Fedora wants to substitute a random address when the card has a perfectly good MAC address.

I fixed to problem with the v6.8 build - the API changed. Do a 'git pull' and it should build correctly.

[apnix-uk]

Indeed, it does have a perfectly good MAC address but there seems to be a trend for randomising MAC addresses in the name of security (which personally I don't really agree with or understand why this is supposedly more secure).

Thanks for the 6.8 fixes, I'll give that a try. Appreciate your response and work on this driver over the years :+1:

[apnix-uk]

Yep, compiles fine with 6.8 now, thanks very much!

I might add, I'm not one to get upset about compiler warnings, but it seems either gcc in 14 or Fedora have chosen to use -Wmissing-prototypes as a default now so there are a lot more compiler warnings than there were previously. Works just fine even so but wouldn't surprise me someone would raise a ticket about that.

Best regards, Matthew.