Dual-Band Dual-Concurrent

tests for dbdc — dual band dual concurrent operation running two interfaces on two different bands at the same time (for example, an access point on 5 ghz while a client runs on 2 4 ghz) test sequence bring up two interfaces on two different bands simultaneously confirm both operate independently without interference measure throughput on each band with iperf3 test combinations ap + sta, ap + ap, sta + sta across band pairs ❌ test log ap+sta dual band tested and recorded using build 1322 at 25 jun 2026 2 4 ghz ap 5 ghz sta environment debian trixie; made sure that networkmanager , iw and dnsmasq are present in the system set regulatory domain if not set sudo iw reg set hk run to see your wi fi card name nmcli device status | grep wifi in our case it is called wlxb06b11673af2 device type state connection lo loopback connected (externally) lo wlxb06b11673af2 wifi disconnected the ap will live on a second virtual interface named ap0 on the same phy, because one netdev can't be sta and ap simultaneously udev will try to rename a freshly created ap0 to a wlx predictable name, which breaks the nm profile binding pin the name with a link file sudo tee /etc/systemd/network/10 ap0 link >/dev/null <<'eof' \[match] originalname=ap0 \[link] name=ap0 eof apply it sudo udevadm control reload create a lan bridge (nat + dhcp) change 192 168 50 1/24 if it overlaps the upstream ap subnet these two subnets must differ; otherwise, routing collapses sudo nmcli connection add type bridge con name br lan ifname br lan \\ ipv4 method shared ipv4 addresses 192 168 50 1/24 \\ ipv6 method ignore \\ connection autoconnect yes bring it up sudo nmcli connection up br lan verify that the bridge is nm owned (not "externally" managed) nmcli f general state device show br lan # must not say 'externally' ip addr show br lan | grep inet # expect 192 168 50 1/24 pgrep a dnsmasq # expect one bound to br lan in our case $ nmcli f general state device show br lan general state 100 (connected) $ ip addr show br lan | grep inet inet 192 168 50 1/24 brd 192 168 50 255 scope global noprefixroute br lan $ pgrep a dnsmasq 15291 /usr/sbin/dnsmasq conf file=/dev/null no hosts keep in foreground bind interfaces except interface=lo clear on reload strict order listen address=192 168 50 1 dhcp range=192 168 50 10,192 168 50 254,3600 dhcp leasefile=/var/lib/networkmanager/dnsmasq br lan leases pid file=/run/nm dnsmasq br lan pid conf dir=/etc/networkmanager/dnsmasq shared d create an sta uplink replace wlan0 , yourhomewifi , and upstream password with your values sudo nmcli connection add type wifi con name sta uplink ifname wlan0 \\ ssid yourhomewifi \\ wifi sec key mgmt wpa psk wifi sec psk 'upstream password' \\ ipv4 method auto ipv6 method ignore \\ connection autoconnect yes bring it up sudo nmcli connection up sta uplink verify (change wlan0 here first) iw dev wlan0 info we got this output interface wlxb06b11673af2 &#x9;ifindex 5 &#x9;wdev 0x1 &#x9;addr b0 6b 11 67 3a\ f2 &#x9;type managed &#x9;wiphy 0 &#x9;channel 36 (5180 mhz), width 80 mhz, center1 5210 mhz &#x9;txpower 3 00 dbm &#x9;multicast txq &#x9; qsz byt qsz pkt flows drops marks overlmt hashcol tx bytes tx packets &#x9; 0 0 0 0 0 0 0 0 0 create an ap profile sudo nmcli connection add type wifi con name ap downlink ifname ap0 \\ ssid flipperone \\ wifi sec key mgmt wpa psk wifi sec psk 'flipperone' \\ 802 11 wireless mode ap \\ 802 11 wireless powersave 2 \\ master br lan slave type bridge \\ connection autoconnect no bring up helper this is the piece that attempts dbdc it brings the sta up first (so it owns the channel context), reads the sta's channel/width, creates ap0 with a stable mac set atomically at creation, pins the ap chandef to the other band, and activates the ap first, write an /apsta up script sudo tee /apsta up >/dev/null <<'eof' \#!/bin/sh \# attempt a dbdc ap on ap0 on the other band from the sta set eu sta con=sta uplink ap con=ap downlink ap if=ap0 \# 1 resolve the base wifi device (first real wifi; never p2p dev, never ap0) sta=$(nmcli t f device,type device status \\ \| awk f v ap="$ap if" '$2=="wifi" && $1!=ap {print $1; exit}') \[ n "$sta" ] || { echo "apsta no wifi device found" >&2; exit 1; } \# 2 ensure uplink is up; wait for association (channel context owner) nmcli connection up "$sta con" >/dev/null 2>&1 || true i=0 while ; do ch=$(iw dev "$sta" info 2>/dev/null | awk '/channel/{print $2}') \[ n "${ch }" ] && break i=$((i+1)); \[ "$i" ge 30 ] && { echo "apsta sta not associated after 30s" >&2; exit 1; } sleep 1 done wmhz=$(iw dev "$sta" info | sed n 's/ width \\(\[0 9] \\) /\1/p') \[ "$ch" le 14 ] && band=bg || band=a \# 3 stable locally administered mac for the ap vif (distinct from sta on same phy) phy=$(iw dev "$sta" info | awk '/wiphy/{print "phy"$2}') mac=$(cat /sys/class/net/"$sta"/address) apmac="02 ${mac# }" \# 4 (re)create ap0 with the mac set atomically at creation iw dev "$ap if" del 2>/dev/null || true iw phy "$phy" interface add "$ap if" type ap addr "$apmac" \# 5 force ap onto the other band (dbdc) and force the stable mac (disables randomization) \[ "$band" = a ] && { apband=bg; apch=6; apw=20; } || { apband=a; apch=36; apw=80; } nmcli connection modify "$ap con" \\ 802 11 wireless band "$apband" \\ 802 11 wireless channel "$apch" \\ 802 11 wireless cloned mac address "$apmac" \# channel width only exists on nm >= 1 50; ignore failure on older releases nmcli connection modify "$ap con" 802 11 wireless channel width "$apw" 2>/dev/null || true \# 6 activate nmcli connection up "$ap con" echo "apsta $ap if up band=$apband ch=$apch width=$apw mac=$apmac (sta on $sta)" eof set script permissions sudo chmod +x /apsta up run the script sudo /apsta up example output $ sudo /apsta up \<skipped> \[ 705 971837] wlxb06b11673af2 deauthenticating from xx\ xx\ xx\ xx\ xx\ xx by local choice (reason 3=deauth leaving) \[ 706 325902] wlxb06b11673af2 authenticate with xx\ xx\ xx\ xx\ xx\ xx (local address=xx\ xx\ xx\ xx\ xx\ xx) \[ 706 335759] wlxb06b11673af2 send auth to xx\ xx\ xx\ xx\ xx\ xx (try 1/3) \[ 706 338224] wlxb06b11673af2 authenticated \[ 706 341785] wlxb06b11673af2 associate with xx\ xx\ xx\ xx\ xx\ xx (try 1/3) \[ 706 346504] wlxb06b11673af2 rx assocresp from xx\ xx\ xx\ xx\ xx\ xx (capab=0x431 status=0 aid=3) \[ 706 359261] wlxb06b11673af2 associated error connection activation failed 802 1x supplicant took too long to authenticate hint use 'journalctl xe nm connection=d63b4dd9 ea30 4b55 8931 55d12c8267f5 + nm device=ap0' to get more details let's see the journal jun 25 18 33 28 flipperone a9438e build 1322 router target networkmanager\[542] \<warn> \[1782412408 0506] device (ap0) activation (wifi) hotspot network creation took too long, failing activation jun 25 18 33 28 flipperone a9438e build 1322 router target networkmanager\[542] \<info> \[1782412408 0507] device (ap0) state change config > failed (reason 'supplicant timeout', managed type 'full') ❌ test log ap+ap dual band tested and recorded using build 1393 at 26 jun 2026 2 4 ghz ap 5 ghz ap environment debian trixie; made sure that networkmanager , iw and dnsmasq are present in the system set regulatory domain if not set sudo iw reg set hk see your wi fi card name and resolve its phy nmcli device status | grep wifi iw dev wlxb06b11673af2 info | awk '/wiphy/{print "phy"$2}' in our case the card is wlxb06b11673af2 on phy0 device type state connection wlxb06b11673af2 wifi disconnected phy0 ask the radio which interface combinations it allows this settles the question before any ap is brought up iw phy phy0 info | sed n '/valid interface combinations/,/ht capability/p' on this build valid interface combinations &#x9; #{ managed, p2p client } <= 2, #{ p2p go } <= 1, #{ p2p device } <= 1, &#x9; total <= 3, #channels <= 2 &#x9; #{ managed, p2p client } <= 2, #{ ap } <= 1, #{ p2p device } <= 1, &#x9; total <= 3, #channels <= 1 &#x9;ht capability overrides reading it only the second combination contains ap , and it caps #{ ap } <= 1 there is no combination anywhere that permits two ap interfaces that same ap combination is limited to #channels <= 1 (so an ap can only coexist with a sta on the same channel — scc — which is why the ap+sta scc guide docid\ fc3x8ekoysgribtltzm6x pins them together) the first combination is the only one allowing two channels ( #channels <= 2 , i e dbdc), covering managed / p2p client + p2p go only — never a normal ap conclusion two aps are impossible on any band combination — the failure is at the ap count limit, before channels are even considered empirical confirmation (raw iw , no networkmanager) clean slate — remove any leftover vifs for i in ap0 ap1; do sudo iw dev $i del 2>/dev/null; done first ap vif — allowed (this is the one ap the radio permits) sudo iw phy phy0 interface add ap0 type ap addr 02 6b 11 67 3a\ f2 sudo ip link set ap0 up no errors, ap0 is up second ap vif — refused the refusal lands either at interface add or at ip link set up depending on kernel; on this build it is at bring up sudo iw phy phy0 interface add ap1 type ap addr 06 6b 11 67 3a\ f2 sudo ip link set ap1 up$ sudo ip link set ap1 up rtnetlink answers device or resource busy the device or resource busy ( ebusy ) is the combination check rejecting a second ap interface — confirmed before any channel or band is assigned, exactly as the table above predicts tidy up for i in ap0 ap1; do sudo iw dev $i del 2>/dev/null; done conclusion #{ ap } <= 1 — the radio exposes only one ap slot two aps on any band combination are impossible genuine dual band ap requires a second radio or a dbdc ap class chip (mt7915/7916/7986/7996) whose driver exposes an ap combination with #channels <= 2 register readout as of 25 june 2026 and kernel 7 1 1, mt7921 driver does not support dbdc support for dbdc has been added to mt7915 https //github com/openwrt/mt76/commit/b436da4d9d925f6ff80310841d1fbeb25c93b667 and mt7925 (router socs) driver by openwrt project https //github com/openwrt/mt76/issues/315 , but not to other models the check for dbdc support from mt7915 is performed as follows dev >dbdc support = !!(mt7915 l1 rr(dev, mt hw bound) & bit(5)); where mt hw bound = 0x70010020 attempt to read this value on fenvi ax1800 and edup ax3000 7921u modules results in follows /sys/kernel/debug/ieee80211/phy4/mt76# echo 0x70010020 > regidx /sys/kernel/debug/ieee80211/phy4/mt76# cat regval 0x00000020 which means that bit(5) == 1 and dbdc is supported in hardware on 7921u windows drivers there's an evidence from mt7921 qa tool user guideline pdf https //www mouser com/datasheet/2/1074/user manual 5321522 3304019 pdf that windows drivers support dbdc, and the hardware supports it in the following configuration mt7921 support only below dual band dual concurrent (dbdc) mode operation (tab tx/rx) tx0/rx0 transceiver is operating in 5ghz (a band) (tab tx/rx band 1) tx1/rx1 transceiver is operation in 2 4ghz (g band) sta + ap on two bands with a one line driver patch the "driver does not support dbdc" result above refers to the mt7915 style dual chain dev >dbdc support flag, which mainline mt76 never wires up for mt7921 the practical goal (a station uplink on one band and an access point on another) is reachable through a different path cfg80211's multi channel concurrency (mcc) / channel context mechanism what blocked it was the driver's advertised interface combination table, not the hardware (bit(5) above) and not the firmware root cause mainline mt76 lists only p2p go , not a full ap, on the second channel of its multi channel interface combination ( if limits chanctx mcc in mt792x core c ) cfg80211 therefore rejects sta + ap on two channels before the firmware is ever asked this is why the networkmanager attempt above fails with "hotspot network creation took too long" / supplicant timeout the ap0 vif can never be granted a second channel context, so the hotspot never starts the fix add bit(nl80211 iftype ap) next to p2p go in the mcc combo static const struct ieee80211 iface limit if limits chanctx mcc\[] = { { max = 2, types = bit(nl80211 iftype station) | bit(nl80211 iftype p2p client) }, { max = 1, \ types = bit(nl80211 iftype p2p go) \+ types = bit(nl80211 iftype p2p go) | \+ bit(nl80211 iftype ap) }, { max = 1, types = bit(nl80211 iftype p2p device) }, }; after patching, iw phy advertises the ap in the two channel combo #{ managed, p2p client } <= 2, #{ ap, p2p go } <= 1, #{ p2p device } <= 1, total <= 3, #channels <= 2 the firmware then accepts the concurrent ap with no mcu timeout , confirming that the closed firmware already allows it and only the driver's advertised combo was the gate verified end to end tested on an alfa awus036axml (mt7921au, usb 0e8d 7961 ) running the same firmware ( 010000 20260224110949 ) as the flipper one's wxt2am2101 module, so the firmware determined result transfers directly sta associated to an upstream ap on one band while ap0 ran a hotspot on the other band, verified in both cross band orders (sta 2 4 / ap 5 ghz and sta 5 / ap 2 4 ghz) real clients (android, iphone, macbook) associated to the ap, completed dhcp, and passed traffic while the sta simultaneously carried an uplink on the other band both interfaces' byte counters advanced in the same time intervals throughput ( iperf3 ) mode link throughput sta 2 4 ghz ht20 74 ↑ / 60 ↓ mbit/s sta 5 ghz vht80 250 mbit/s ap 2 4 ghz ch1 67 / 59 mbit/s ap 5 ghz ch36, vht80 352 ↓ / 112 ↑ mbit/s sta 2 4 + ap 5 ghz (concurrent) dbdc ap 84 ↑ / 319 ↓ mbit/s under simultaneous sta load this is multi channel concurrency on a single radio under heavy ap load the sta yields airtime (its throughput drops but it stays associated) that is the expected behavior of one radio time slicing two channels it is usable for a travel router (uplink + hotspot), but it is not the independent dual chain (tx0/tx1) operation the windows qa tool describes limits two configurations do not work two simultaneous aps on two different bands (ap + ap) the radio brings up two ap bsses (both reach ap enabled ), but only the first started one beacons; the second stays silent verified with distinct fixed bssids and cache flushed scans from a second radio two aps on the same channel both beacon (one channel context, multi ssid), but on different channels only the first does two ap channels need a sta or p2p client to drive the channel switch arbiter; two passive masters (ap + ap, and also ap + p2p go and go + go, tested) don't trigger it the ceiling is one beaconing ap whenever two channels are in use; the other context must be the client that drives the time share a third bss context, for example sta + 2 aps the third interface comes up in iw but is never granted a channel and stays off air (0 beacons in cache flushed scans) the hardware ceiling is two concurrent bss contexts an earlier ebusy reported here was a wedged device / bssid= config artifact; on a clean driver the third context simply gets no airtime rather than erroring firmware root cause disassembling the wm firmware (tensilica xtensa; capstone 6 cs arch xtensa decodes it despite the custom tie opcodes that make ghidra and objdump fail) locates the mechanism in the firmware's own data model rather than the driver the mcc time share scheduler defines quota and absence roles for sta, p2p go and p2p gc ( mccstaquotatimeinus , mccp2pgoquotatimeinus , cnmgoabsencemargininus ) but no ap/sap role, so a second infrastructure ap context is never granted a concurrent channel this is why sta + ap works (the sta drives the absence schedule, the ap rides its presence windows) while ap + ap does not the dbdc band %d not support in mt7961 string is an id based dbglog (rendered to text off chip by the host log tool) with no pointers found anywhere in the image, so it appears to be a diagnostic print rather than a gate that can be flipped the mt7961 "mobile" sku shares the codebase with the larger mt7972 but runs a reduced profile; ram band num = 1 (single rf) the blob is plaintext, unsigned and crc only (trailer = zlib crc32(fw\[ 4]) , recomputable; loaded via fw scatter + fw start with no signature check), so it is patchable in principle, but there is no single byte to flip for dual ap the limit is a missing scheduler role plus single rf hardware true simultaneous dual band dual ap would need a two radio (mt7915 class) part the same mcc path extends to 6 ghz (wi fi 6e; under etsi/sk only the low 6 ghz sub band 5945–6425 mhz is enabled, indoor), so sta 5 ghz + ap 6 ghz should behave like the 2 4/5 ghz pairs the capability is confirmed via iw phy (band 4 channels enabled); a live 6 ghz sta+ap run has not yet been performed for the full concurrency matrix, see the concurrency support summary docid\ ggxlla0wrihpbea19utyi on the wi fi page