MediaTek MT7613BE multiple networks potential bug

I just got my Archer A6 v3, and I am experiencing trouble with the 5GHz radio. Whenever I try to create more than one network, all networks on the 5GHz radio fail to start. This does not happen with the 2.4 GHz radio. Is this a bug, or simply a hardware limitation?

are the 5ghz networks all on the same channel ?

Yes, the channels on the network confígs follow each other and stay in sync

Could you paste you /etc/config/wireless config here? (be aware: hide your ssid password)

config wifi-device 'radio0'
        option type 'mac80211'
        option channel '11'
        option hwmode '11g'
        option path '1e140000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0'
        option htmode 'HT20'
        option cell_density '0'
        option country 'US'

config wifi-device 'radio1'
        option type 'mac80211'
        option hwmode '11a'
        option path '1e140000.pcie/pci0000:00/0000:00:01.0/0000:02:00.0'
        option htmode 'VHT80'
        option cell_density '0'
        option country 'US'
        option channel '44'

config wifi-iface 'wifinet2'
        option device 'radio0'
        option mode 'ap'
        option ssid 'SlowLane'
        option encryption 'none'
        option isolate '1'
        option network 'iot'

config wifi-iface 'wifinet3'
        option device 'radio1'
        option mode 'ap'
        option ssid 'FastLane'
        option encryption 'psk2'
        option key '[redacted]'
        option network 'lan'

config wifi-iface 'iot'
        option device 'wlan1'
        option mode 'ap'
        option network 'iot'
        option ssid 'FastLane-Guest'
        option encryption 'none'

config wifi-iface 'wifinet4'
        option device 'radio0'
        option mode 'ap'
        option ssid 'FastLane-Guest'
        option encryption 'none'
        option network 'iot'

config wifi-iface 'wifinet5'
        option device 'radio1'
        option mode 'ap'
        option ssid 'OpenWrt'
        option encryption 'none'
        option network 'iot'

Here it is

Any idea what could be causing this?

No, but I have it worse. I can't get a 5GHz wifi network up at all. The 2.4 GHz configuration is not a problem. I don't think it is hardware as I reverted to the OEM firmware and the 5GHz network worked fine.

I'm running OpenWrt 22.03.0-rc6 r19590-042d558536.

When I restart radio1 I get:

Aug 22 21:11:41 ap0 hostapd: Configuration file: /var/run/hostapd-phy1.conf (phy wlan1) --> new PHY
Aug 22 21:11:41 ap0 kernel: [ 2424.628062] br-lan: port 7(wlan1) entered blocking state
Aug 22 21:11:41 ap0 kernel: [ 2424.633446] br-lan: port 7(wlan1) entered disabled state
Aug 22 21:11:41 ap0 kernel: [ 2424.639375] device wlan1 entered promiscuous mode
Aug 22 21:11:41 ap0 kernel: [ 2424.644821] br-lan: port 7(wlan1) entered blocking state
Aug 22 21:11:41 ap0 kernel: [ 2424.650183] br-lan: port 7(wlan1) entered forwarding state
Aug 22 21:11:41 ap0 hostapd: wlan1: interface state UNINITIALIZED->COUNTRY_UPDATE
Aug 22 21:11:41 ap0 kernel: [ 2424.658038] br-lan: port 7(wlan1) entered disabled state
Aug 22 21:11:41 ap0 hostapd: ACS: Automatic channel selection started, this may take a bit
Aug 22 21:11:41 ap0 hostapd: wlan1: interface state COUNTRY_UPDATE->ACS
Aug 22 21:11:41 ap0 hostapd: wlan1: ACS-STARTED
Aug 22 21:11:42 ap0 netifd: Wireless device 'radio1' is now up
Aug 22 21:11:42 ap0 netifd: lan (2435): udhcpc: sending renew to server 10.0.0.254
Aug 22 21:11:42 ap0 netifd: lan (2435): udhcpc: lease of 10.0.0.251 obtained from 10.0.0.254, lease time 43200
Aug 22 21:11:57 ap0 hostapd: wlan1: ACS-COMPLETED freq=5260 channel=52
Aug 22 21:11:57 ap0 hostapd: wlan1: interface state ACS->HT_SCAN
Aug 22 21:11:58 ap0 hostapd: wlan1: interface state HT_SCAN->DFS
Aug 22 21:11:58 ap0 hostapd: wlan1: DFS-CAC-START freq=5260 chan=52 sec_chan=1, width=1, seg0=58, seg1=0, cac_time=60s
Aug 22 21:11:58 ap0 hostapd: DFS start_dfs_cac() failed, -1
Aug 22 21:11:58 ap0 hostapd: Interface initialization failed
Aug 22 21:11:58 ap0 hostapd: wlan1: interface state DFS->DISABLED
Aug 22 21:11:58 ap0 hostapd: wlan1: AP-DISABLED

Whereas when I restart radio0 I get

Aug 22 21:14:56 ap0 hostapd: Configuration file: /var/run/hostapd-phy0.conf (phy wlan0) --> new PHY
Aug 22 21:14:56 ap0 kernel: [ 2619.589413] br-lan: port 6(wlan0) entered blocking state
Aug 22 21:14:56 ap0 kernel: [ 2619.594909] br-lan: port 6(wlan0) entered disabled state
Aug 22 21:14:56 ap0 kernel: [ 2619.600997] device wlan0 entered promiscuous mode
Aug 22 21:14:56 ap0 kernel: [ 2619.606114] br-lan: port 6(wlan0) entered blocking state
Aug 22 21:14:56 ap0 kernel: [ 2619.611743] br-lan: port 6(wlan0) entered forwarding state
Aug 22 21:14:56 ap0 kernel: [ 2619.628550] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
Aug 22 21:14:56 ap0 hostapd: wlan0: interface state UNINITIALIZED->ENABLED
Aug 22 21:14:56 ap0 hostapd: wlan0: AP-ENABLED
Aug 22 21:14:57 ap0 netifd: Wireless device 'radio0' is now up
Aug 22 21:14:57 ap0 netifd: Network device 'wlan0' link is up

First of all, be aware that 5 GHz interfaces may take up to one minute (in specific cases up to 10 minutes) to come up, as the router first must scan for potential nearby radars. Your logs suggest that you may have been a little impatient for that.

However, I'm also seeing the DFS scan failing (either because you interrupted it prematurely or because it did find a radar and had to cease interruptions), which may mean that you have to use non-DFS channels.

Be aware that mt7613, as talked about in this topic, does not really cope with DFS, so you do want tobavoid DFS channels for now (potentially forever).

It looks like DFS is broken. If I manually specify a non-DFS channel it works. This is probably not your exact problem, but may be try channel 36. I think you have specified 80MHz starting at channel 44, which is not allowed. It seems the driver fails fairly silently if you give it illegal specs. See Wikipedia for a list of channels.

That entire log is without manual intervention. i.e. it tries to start and then goes to AP-DISABLED before I even have time to become impatient! I don't know what the semantics of start_dfs_cac() is (or is supposed to be) but maybe it is stopping after the first clash when it should keep scanning.

However, it does seem to be DFS related. If I manually set the channel to a non-DFS channel, it works.