BPI-R4 kernel 6.14 WiFi interfaces on BE14 not discovered

I have encountered quite a strange issue. I built the 6.14-main branch from @frank-w (GitHub - frank-w/BPI-Router-Linux: Linux kernel 4.14+ for BPI-R2, 5.4+ for R64, 6.1+ for R2Pro and R3). During boot only the 2.4GHz wlan is being populated. Firmware seems to be loaded correctly. Used the same build script as for the 6.12-main branch from the same repo. If I switch back to 6.12 everything is fine. Any ideas of what I’m doing wrong?

It is possible that there was a beeaking change in 6.13/6.14. as i focused on rss+lro in last 2 versions and some upstreaming i have not tested wifi there.

@frank-w, I have now tried the 6.15-rc branch from your repo too (commit: d24e6b92c8895e7d019fdf62b8cf4fa9baebb88e) and the bug seems to still be there. Would you mind checking that the BE14 interfaces are all brough up ok on your device when you get a chance? On both of mine I am still only getting the 2.4GHz and don’t seem to be able to see what the cause is :frowning:.

Possibly i miss a patch or 2 from 6.12 in later branches.

Have you set regdomain right? 6ghz needs wpa3-sae which requires selfcompiled hostapd in debian/ubuntu. The distribution version does not support that. What os do you use?

I’m on ArchLinux, but this bug is kernel/firmware related. Has nothing to do with the regdomain as far as I can tell. The phy1 (5 GHz) and phy2 (6GHz) simply don’t get populated. See below my output related to mt7996e.

Apr 23 11:09:14 kernel: mt7996e_hif 0001:01:00.0: vgaarb: pci_notify
Apr 23 11:09:14 kernel: mt7996e_hif 0001:01:00.0: assign IRQ: got 124
Apr 23 11:09:14 kernel: mt7996e_hif 0001:01:00.0: enabling device (0000 -> 0002)
Apr 23 11:09:14 kernel: mt7996e_hif 0001:01:00.0: enabling bus mastering
Apr 23 11:09:14 kernel: mt7996e_hif 0001:01:00.0: vgaarb: pci_notify
Apr 23 11:09:14 kernel: mt7996e 0000:01:00.0: vgaarb: pci_notify
Apr 23 11:09:14 kernel: mt7996e 0000:01:00.0: assign IRQ: got 114
Apr 23 11:09:14 kernel: mt7996e 0000:01:00.0: enabling device (0000 -> 0002)
Apr 23 11:09:14 kernel: mt7996e 0000:01:00.0: enabling bus mastering
Apr 23 11:09:14 kernel: mt7996e 0000:01:00.0: HW/SW Version: 0x8a108a10, Build Time: 20240809122254a
Apr 23 11:09:14 kernel: mt7996e 0000:01:00.0: WM Firmware Version: ____000000, Build Time: 20240809122249
Apr 23 11:09:14 kernel: mt7996e 0000:01:00.0: DSP Firmware Version: ____000000, Build Time: 20240809121650
Apr 23 11:09:14 kernel: mt7996e 0000:01:00.0: WA Firmware Version: ____000000, Build Time: 20240809122214
Apr 23 11:09:14 kernel: mt7996e 0000:01:00.0: registering led 'mt76-phy0'
Apr 23 11:09:14 kernel: mt7996e 0000:01:00.0: vgaarb: pci_notify

If using my image, it is still experimental. It uses dangowrt’s kernel for R4, I recently updated, so you may want to update the kernel package (linux-bpir4-git). I do not have a wificard for the R4, so this is not tested.

The main purpose of the script it to build an archlinuxarm mainline image, for R4 this is a bit early, so not everything is tested. It may also be missing firmware files, if they are not in the standard linux-firmware package. Etc etc… Still in development.

Edit:

As far as wpa3 in archlinux’s hostapd:

https://gitlab.archlinux.org/archlinux/packaging/packages/hostapd/-/blob/main/config?ref_type=heads#L175

Seems to be enabled in the standard hostapd package (this package archlinux == archlinuxarm, but this is not always the case).

Anyway, any help on getting the wificard running on archlinuxarm would be greatly appreciated.

Thanks for the details @ericwoud, but I am using my own image, which I have been tweaking over the past 10 years :slight_smile:.

I have wifi fully working on the R4 with the 6.12.23 kernel from @frank-w (ap mode on all 3 phys, mesh pending tests). I’d like to move to the 6.14 or the 6.15, which is the problem outlined here, but everything works fine on the 6.12.

I am happy to share any (build-)configs I use if you are strugling with anything related to the wifi on the R4. I am building my own hostapd and use a slightly different kernel config than both yours and franks-w’s.

i made a quick test and can confirm that in 6.14-main only one phy is detected. 6.13-main is ok. in 6.14-main both pcie-“cards” are recognized, so it does not look like pcie is broken. It looks like mt76 driver issue (using same firmware).

found the breaking commit: “wifi: mt76: mt7996: switch to single multi-radio wiphy”, but possibly it is working as designed and we have to use different hostapd-config to serve all 3 bands with 1 hostapd-process. afaik MLO requires running 5ghz and 6ghz over 1 phy

I’ve wrote a bit with felix and the “issue” is no issue like i guessed after reading commit message.

the one wiphy instead of 3 is a requirement for MLO but can be handled like this:

# iw list | grep -A 2 'interface combination'                                   
        valid interface combinations:                                           
                 * #{ AP } <= 16, #{ managed } <= 19,                           
                   total <= 19, #channels <= 1, STA/AP BI must match, radar det}
# iw dev wlan0 interface add wlan1 type managed
# iw dev wlan0 interface add wlan2 type managed

# iw dev wlan1 info                                                             
Interface wlan1                                                                 
        ifindex 11                                                              
        wdev 0x2                                                                
        addr 00:0c:43:26:60:10                                                  
        type managed                                                            
        wiphy 0                                                                 
        multicast TXQ:                                                          
                qsz-byt qsz-pkt flows   drops   marks   overlmt hashcol tx-bytes
                0       0       0       0       0       0       0       0      0

after that wlan1+wlan2 appear and they should work like before (not tested yet, as my current system misses the hostapd configs). curently searching a way to create these interfaces with systemd-networkd. maybe like this:

https://bbs.archlinux.org/viewtopic.php?pid=2126424#p2126424

tried adding a /etc/systemd/network/wlan1.netdev

[NetDev]
Name=wlan1
Kind=wlan

[WLAN]
PhysicalDevice=0
Type=managed

but seems not working

PhysicalDevice=wlan0
Type=ap

Perhaps?

But shouldnt the extra interface be created by hostapd, by specifying a second bss?

See bottom of

https://w1.fi/cgit/hostap/plain/hostapd/hostapd.conf

I’ve used that to create a second virtual interface for guest wifi. I think it is the same, but then changing the channel for the second bss.

Last digit if mac address wlan0 set to 0.

Felix told me that the interfaces could/should be created this way to keep the current configs.

It seems to work when created with iw,but systemd does not create this interface.

Tried also with wlan0 as physical device and type=ap because systemd documentation does not list managed type. and enabled debug in networkd service override…only see

Dec 01 13:44:44 bpi-r4-v11 systemd-networkd[3537]: wlan1: loaded "wlan"
Dec 01 13:44:44 bpi-r4-v11 systemd-networkd[3537]: wlan2: loaded "wlan"

created question in german debian forum about this: systemd-networkd: virtuelle wifi interfaces - debianforum.de

But wlan0 is normally not managed by systemd-networkd

i have a 31-wlan0.network (later) to assign ip-adress and dhcp-server, maybe i need a link-file too to let systemd-networkd handle the wlan0 interface and handle the wlan1/2 netdev-files?

https://wiki.archlinux.org/title/software_access_point#Wireless_client_and_software_AP_with_a_single_Wi-Fi_device

For virtual interface with syatemd

Yeah saw the service way for creating the Interface with iw,but it could result in timing issues (wlan0 has to be present after firmware-load and systemd-networkd must run later). So imho doing all in networkd would be the best way…based on doc it should be possible since 251 and i have 252.

BindsTo=sys-subsystem-net-devices-%i.device

Or

BindsTo=sys-subsystem-net-devices-wlan0.device

Perhaos?

To add on the preveous post

I guess i also need this:

[Unit]
Before=systemd-networkd.service

To make sure networkd is started after this,not nice but if networkd cannot handle this alone

thanks @frank-w for sorting this out. it’s been really helpful. just tried now the systemd netdev config and the following is working perfectly for me on your 6.15-rc branch and systemd 257.5-2 on Arch. I’m leaving my network names to make it a bit less confusing. Also I’m adding both the 5 GHz and the 6 GHz (not sure if it matters), and I am now back to the 6.12 functionality.

[NetDev]
Name=wl5G
Kind=wlan

[WLAN]
PhysicalDevice=phy0
Type=ap
[NetDev]
Name=wl6G
Kind=wlan

[WLAN]
PhysicalDevice=phy0
Type=ap
1 Like

Thanks for testing. Any idea how i can debug it? I guess my systemd version is buggy as it is new feature. But next debian should be released soon.

Your first wifi interface is wlan0 too,right? I wonder about phy0 descriptor.

As far as felix told me it does not matter because all 3 interfaces target same phy and driver selects the band based on channel/mode,not based on vif.

Does managed works too? But i guess not as it is not listed in documentation

Not really. I am renaming that to wl2G using udev. But the nice thing about this is that it does not matter. Everyting is relative to phy0 (or sits on top of phy0) as far as I gather.

I used the info from: https://www.freedesktop.org/software/systemd/man/latest/systemd.netdev.html#[WLAN]%20Section%20Options

Not sure about debugging. I have had mixed experience with systemd. Usually I run it with systemd.log_level=debug kernel commandline and use journalctl or serial to look through. But it’s quite tedious.

If I was you I would just build a systemd latest package for Debian. That is what I usually do on Arch when things don’t work as I want (also why I am not using Debian, as I still haven’t figured out how write a package recipe :blush:).