Quantum Fiber W1700k support

lightingghost · June 4, 2026, 5:34am

Executing this gpio config

ResetTarget.YELLOW: GpioResetConfig(
        chip="/dev/gpiochip0",
        chip_type=None,
        pattern=[
            GpioPattern(pins={24: True,  25: True},  delay_after=0.1),
            GpioPattern(pins={24: False, 25: False}, delay_after=0.1),
            GpioPattern(pins={24: False, 25: True},  delay_after=0.1),
            GpioPattern(pins={24: True,  25: True},  delay_after=0.0),
        ],
    ),

Will reset the chip and boot into application, but not bootloader.

Spacebar · June 4, 2026, 6:29am

If anyone is interested, I've created a STEP of the W1700k unit and a simple floor stand.

longnt2007 · June 4, 2026, 7:42pm

I don't know if mt7990 has the same behavior as mt7992 (both use mt7996e code), but I've fixed the tx power setting in luci by merging mtk patches for the mt76 driver and the iw tool to support per-radio txpower setting. Then I edited mac80211.sh (in wifi-scripts) to set TX power per radio, and it works.

function setup_phy(phy, config, data) {
...
system(`iw phy ${phy} set txpower ${config.txpower} radio ${config.radio}`);

Log show

[  379.842012] mt7996e 0000:01:00.0: BSS_CHANGED_TXPOWER -> mt7996_mcu_set_txpower_sku: info->txpower = 20
[  379.862771] mt7996_mcu_set_txpower_sku: txpower_setting = 20
[  379.868437] mt7996_get_power_bound: txpower = 26
[  379.873046] mt7996_mcu_set_txpower_sku: txpower_limit = 26
[  379.878535] mt7996_mcu_set_txpower_sku: mt7996_update_max_txpower_cur = 26
[  379.885404] mt7996_update_max_txpower_cur: tx_power = 26
[  379.890712] mt7996_update_max_txpower_cur: e2p_power_limit = 26
[  379.897630] mt7996_mcu_set_txpower_sku: mt76_mcu_skb_send_msg ret = 0

Spacebar · June 4, 2026, 7:57pm

Interesting. Care to share your work on git?

longnt2007 · June 4, 2026, 11:45pm

Here is my repo. It's for Mediatek mt7988d with mt7992 card, I've merged all mtk patches to fix mt7992 issues: WED error, broken TX power and even MLMR support. However, the mt7992 doesn't have a 6 GHz channel, so I can't test MLMR.

Spacebar · June 5, 2026, 4:11am

Thanks for sharing

Spacebar · June 5, 2026, 4:12pm

I tried your changes to make txpower work, but I believe as many has posted before that we need to set sku_idx etc (or something else) to tell the radio that we want individual control instead of "global".

longnt2007 · June 5, 2026, 5:06pm

I just checked again with my mt7992 card. After a clean firmware flash, the TX power of the 2.4 GHz channel was stuck at 6 dBm as usual. Then I went to LuCI and set the country code and TX power to 20 dBm, and the iw tool could then set whatever value I wanted. More commands, dmesg logs, and mt76 information are available here.

Spacebar · June 5, 2026, 5:37pm

I don't have that stuck at 6dBm issue, it's more like full power and not able to lower it. It's by design from MT.

Twingo · June 5, 2026, 5:40pm

Can confirm the full power issue here, I have HW 1.1, both 2.4G and 5G are always max transmission power.

pbodq2 · June 5, 2026, 6:06pm

May I know which software did you use finally to send the chainloader into RAM?

I tried Windows built-in tftp client under -i binary mode, still same error result as you mention.

Other TFTP clients such as Tftpd64 also fails, it logs the session as octect mode already.

My device is HW1.1 with 05.00.30.82.

---------------

The problem is solved.

These two lines are just only warnings checked by new version AXON boot loader. Ignore them and go on, I can successfully finish the whole flashing.

Unexpected image

Verify image!!!

However, the RAM address allocated through command

ECNT> setenv loadaddr 0x89000000

sometimes are not equal to the address in result.

Load address: 0x81800000

Please start over until these values are the same.

cookiemonster · June 5, 2026, 8:31pm

Considering that with 7996 everything reported in userspace is a lie, you should not trust it either; however, it does appear you have it enabled for 7992:

cat /sys/kernel/debug/ieee80211/phy0/mt76/band0/txpower_sku

SKU: disable
sku_index:  0

@Spacebar

Spacebar · June 5, 2026, 8:38pm

I concur. But I can't find any information how to enable it for OpenWrt. I wish someone knew or guide us, so we could use txpower.

I did ask Ansuel about how, but no response...

github.com/openwrt/mt76

wifi: cfg80211/mac80211: Add support to get radio index (#1020)

master ← Ansuel:kernel-6.18-support

opened 12:04PM - 30 Nov 25 UTC

Ansuel

+53 -35

Currently, per-radio attributes are set on per-phy basis, i.e., all the radios p…resent in a wiphy will take attributes values sent from user. But each radio in a wiphy can get different values from userspace based on its requirement. To extend support to set per-radio attributes, add support to get radio index from userspace. Add an NL attribute - NL80211_ATTR_WIPHY_RADIO_INDEX, to get user specified radio index for which attributes should be changed. Pass this to individual drivers, so that the drivers can use this radio index to change per-radio attributes when necessary. Currently, per-radio attributes identified are: NL80211_ATTR_WIPHY_TX_POWER_LEVEL NL80211_ATTR_WIPHY_ANTENNA_TX NL80211_ATTR_WIPHY_ANTENNA_RX NL80211_ATTR_WIPHY_RETRY_SHORT NL80211_ATTR_WIPHY_RETRY_LONG NL80211_ATTR_WIPHY_FRAG_THRESHOLD NL80211_ATTR_WIPHY_RTS_THRESHOLD NL80211_ATTR_WIPHY_COVERAGE_CLASS NL80211_ATTR_TXQ_LIMIT NL80211_ATTR_TXQ_MEMORY_LIMIT NL80211_ATTR_TXQ_QUANTUM By default, the radio index is set to -1. This means the attribute should be treated as a global configuration. If the user has not specified any index, then the radio index passed to individual drivers would be -1. This would indicate that the attribute applies to all radios in that wiphy. Link: https://patch.msgid.link/20250615082312.619639-2-quic_rdevanat@quicinc.com

cookiemonster · June 5, 2026, 9:10pm

(https://github.com/longnt2007/openwrt_mt7988d_wed/blob/8b19d7cf44f2b8338477926858f8e7394ba38399/package/kernel/mt76/patches/1042-wifi-mt76-mt7915-Add-support-for-lpi-and-duplicate-m.patch#L62)

The only mention of sku_index and its for 7915.

int radio_idx appears to require 6.16 kernel to work:

(https://github.com/Kenji776/rtl8812au-kernel-6.19-patched)
(https://cybersafe-hub.blogspot.com/2026/05/how-i-fixed-alfa-rtl88xxau-driver-on.html)

Have you tried out that @Ansuel patch? Testing kernel appears to have 6.18 ready.

pbodq2 · June 6, 2026, 4:05am

The label in the photo states that it only works under 100-120v AC, How dare you plug it as 230V??

You just damaged it and you are lucky that you did not get burnt.

Spacebar · June 6, 2026, 5:10am

Thanks, I'll have a look. The patches from @longnt2007 for txpower and radio do work, but for the mt7996 radio we are stuck in "global mode" so it wont listen to our changes.

I did try ansuels patches earlier and it didn't do much. I think they are already implemented in the mt package from wrt.

Txpower patches:

sebko200 · June 6, 2026, 6:52am

Some of the psu supports higher voltage, it was just not certified.

So I tested mine. With some precautions and under continuous monitoring. So the test simply failed. It was working fine for about 15 minutes. 12 V voltage was stable. But then it was getting simply too warm.

mietekn · June 6, 2026, 12:32pm

One topic with many parallel threads. It's very difficult to read, and it's unclear where the discussion is going. Furthermore, over 3,500 posts, some things are repeated. I suggest splitting the topic into smaller ones.

frollic · June 6, 2026, 1:20pm

Feel free to tag the posts.

junky · June 6, 2026, 7:19pm

Hello, I decided to buy a W1700K and join the game as well.

While testing it, I've run into two issues.

The first issue is that traffic from the STA to the AP does not appear to be offloaded. My test client is a PC equipped with a FastConnect 7800. Using OpenSpeedTest running on nginx with HTTP/2 enabled, I observed that during AP-to-STA traffic (download), the AP's CPU remains almost idle. However, during STA-to-AP traffic (upload), CPU usage increases significantly. I see the same behavior both on a NATed network and when the device is configured as an unmanaged Layer 2 bridge AP.

Download:

ATOP - OpenWrt                              2026/06/06 18:35:00                                      -----------------7                                3s elapsed
PRC | sys    0.56s  | user   0.08s | #proc    194  | #trun      2 |  #tslpi   157 | #tslpu     0  | #tidle    53 | #zombie    0  | clones    10 |  no  procacct |
CPU | sys      19%  | user      2% | irq       2%  | idle    378% |  wait      0% | steal     0%  | guest     0% |               | avgf 1.40GHz |  avgscal 100% |
cpu | sys      12%  | user      0% | irq       1%  | idle     87% |  cpu002 w  0% | steal     0%  | guest     0% |               | avgf 1.40GHz |  avgscal 100% |
cpu | sys       4%  | user      2% | irq       0%  | idle     94% |  cpu003 w  0% | steal     0%  | guest     0% |               | avgf 1.40GHz |  avgscal 100% |
cpu | sys       2%  | user      0% | irq       1%  | idle     97% |  cpu000 w  0% | steal     0%  | guest     0% |               | avgf 1.40GHz |  avgscal 100% |
cpu | sys       1%  | user      0% | irq       0%  | idle     99% |  cpu001 w  0% | steal     0%  | guest     0% |               | avgf 1.40GHz |  avgscal 100% |
CPL | numcpu     4  |              | avg1    0.30  |              |  avg5    0.28 | avg15   0.16  |              | csw    39671  |              |  intr   29333 |
MEM | tot     1.8G  | free    1.6G | avail   1.6G  | cache  48.4M |  dirty   0.0M | buff    0.0M  |              | slab   47.8M  | slrec   8.2M |               |
MEM | numnode    0  |              | shmem   1.9M  | shrss   0.0M |  shswp   0.0M | tcpsk   0.0M  | udpsk   0.0M | pgtab   1.2M  |              |               |
SWP | tot     0.0M  | free    0.0M | swcac   0.0M  |              |  zswap   0.0M | zstor   0.0M  |              |               | vmcom  35.3M |  vmlim 912.3M |
PAG | scan       0  | steal      0 | compact    0  | numamig    0 |  migrate    0 | pgin       0  | pgout      0 | swin       0  | swout      0 |  oomkill    0 |
NET | transport     | tcpi      26 | tcpo      51  | udpi      14 |  udpo      14 | tcpao      0  | tcppo      0 | tcprs      0  | tcpie      0 |  udpie      0 |
NET | network       | ipi       43 | ipo       53  | ipfrw      0 |  deliv     43 |               |              |               | icmpi      3 |  icmpo      3 |
NET | wan      31%  | pcki  830555 | pcko   35252  | sp   10 Gbps |  si 3141 Mbps | so 6060 Kbps  | erri       0 | erro       0  | drpi       0 |  drpo       0 |
NET | lan3      0%  | pcki      27 | pcko      52  | sp 1000 Mbps |  si   19 Kbps | so  142 Kbps  | erri       0 | erro       0  | drpi       0 |  drpo       0 |
NET | br-lan  ----  | pcki      28 | pcko      38  | sp    0 Mbps |  si   18 Kbps | so  139 Kbps  | erri       0 | erro       0  | drpi       0 |  drpo       0 |
NET | lo      ----  | pcki      14 | pcko      14  | sp    0 Mbps |  si    3 Kbps | so    3 Kbps  | erri       0 | erro       0  | drpi       0 |  drpo       0 |
NET | phy0.2- ----  | pcki       5 | pcko       4  | sp    0 Mbps |  si    0 Kbps | so    1 Kbps  | erri       0 | erro       0  | drpi       0 |  drpo       0 |
NET | ap-mld0 ----  | pcki       0 | pcko       3  | sp    0 Mbps |  si    0 Kbps | so    0 Kbps  | erri       0 | erro       0  | drpi       0 |  drpo       0 |
NET | phy0.1- ----  | pcki       0 | pcko       1  | sp    0 Mbps |  si    0 Kbps | so    0 Kbps  | erri       0 | erro       0  | drpi       0 |  drpo       0 |

  PID    SYSCPU     USRCPU     RDELAY    BDELAY      VGROW      RGROW     RUID        EUID         ST     EXC      THR    S     CPUNR      CPU     CMD        1/5
 1278     0.19s      0.00s      0.00s     0.00s         0B         0B     root        root         --       -        1    S         2       6%     napi/phy0-0

Upload

ATOP - OpenWrt                              2026/06/06 18:35:15                                      -----------------7                                3s elapsed
PRC | sys    2.82s  | user   0.18s | #proc    193  | #trun      1 |  #tslpi   157 | #tslpu     0  | #tidle    53 | #zombie    0  | clones    20 |  no  procacct |
CPU | sys      99%  | user      7% | irq       7%  | idle    288% |  wait      0% | steal     0%  | guest     0% |               | avgf 1.40GHz |  avgscal 100% |
cpu | sys      72%  | user      1% | irq       1%  | idle     26% |  cpu002 w  0% | steal     0%  | guest     0% |               | avgf 1.40GHz |  avgscal 100% |
cpu | sys       4%  | user      2% | irq       3%  | idle     92% |  cpu000 w  0% | steal     0%  | guest     0% |               | avgf 1.40GHz |  avgscal 100% |
cpu | sys      19%  | user      0% | irq       1%  | idle     80% |  cpu001 w  0% | steal     0%  | guest     0% |               | avgf 1.40GHz |  avgscal 100% |
cpu | sys       5%  | user      3% | irq       3%  | idle     89% |  cpu003 w  0% | steal     0%  | guest     0% |               | avgf 1.40GHz |  avgscal 100% |
CPL | numcpu     4  |              | avg1    0.31  |              |  avg5    0.29 | avg15   0.17  |              | csw   525990  |              |  intr  585726 |
MEM | tot     1.8G  | free    1.6G | avail   1.6G  | cache  48.4M |  dirty   0.0M | buff    0.0M  |              | slab   47.8M  | slrec   8.2M |               |
MEM | numnode    0  |              | shmem   1.9M  | shrss   0.0M |  shswp   0.0M | tcpsk   0.0M  | udpsk   0.0M | pgtab   1.2M  |              |               |
SWP | tot     0.0M  | free    0.0M | swcac   0.0M  |              |  zswap   0.0M | zstor   0.0M  |              |               | vmcom  35.3M |  vmlim 912.3M |
PAG | scan       0  | steal      0 | compact    0  | numamig    0 |  migrate    0 | pgin       0  | pgout      0 | swin       0  | swout      0 |  oomkill    0 |
NET | transport     | tcpi      28 | tcpo      51  | udpi      14 |  udpo      14 | tcpao      0  | tcppo      0 | tcprs      0  | tcpie      0 |  udpie      0 |
NET | network       | ipi       56 | ipo       53  | ipfrw     12 |  deliv     44 |               |              |               | icmpi      2 |  icmpo      2 |
NET | wan       8%  | pcki   61418 | pcko  204089  | sp   10 Gbps |  si   11 Mbps | so  824 Mbps  | erri       0 | erro       0  | drpi       0 |  drpo       0 |
NET | lan3      0%  | pcki      29 | pcko      51  | sp 1000 Mbps |  si   19 Kbps | so  141 Kbps  | erri       0 | erro       0  | drpi       0 |  drpo       0 |
NET | phy0.2- ----  | pcki  203088 | pcko      40  | sp    0 Mbps |  si  819 Mbps | so    9 Kbps  | erri       0 | erro       0  | drpi       0 |  drpo       0 |
NET | br-lan  ----  | pcki      36 | pcko      41  | sp    0 Mbps |  si   18 Kbps | so  139 Kbps  | erri       0 | erro       0  | drpi       0 |  drpo       0 |
NET | lo      ----  | pcki      14 | pcko      14  | sp    0 Mbps |  si    3 Kbps | so    3 Kbps  | erri       0 | erro       0  | drpi       0 |  drpo       0 |

  PID    SYSCPU     USRCPU     RDELAY    BDELAY      VGROW      RGROW     RUID        EUID         ST     EXC      THR    S     CPUNR      CPU     CMD        1/5
 1279     1.64s      0.00s      0.00s     0.00s         0B         0B     root        root         --       -        1    S         2      65%     napi/phy0-0
  546     0.64s      0.00s      0.00s     0.00s         0B         0B     root        root         --       -        1    S         3      25%     napi/qdma_eth-
 1641     0.15s      0.11s      0.00s     0.00s      16.0K         0B     root        root         --       -        1    S         3      10%     rpcd

Other than setting Routing/NAT Offloading to Hardware Offloading, is there anything else that needs to be enabled?

The second issue is that the AP crashes when a client connects while MLO is enabled.

Using the image from:

2.4 GHz, 5 GHz, and 6 GHz all work fine individually. However, when a client connects to an AP with MLO enabled, the AP crashes and outputs the following log:

Sat Jun  6 17:43:22 2026 daemon.info hostapd: ap-mld0: STA c4:13:75:3e:be:fb IEEE 802.11: associated (aid 1)
Sat Jun  6 17:43:22 2026 daemon.notice hostapd: ap-mld0: AP-STA-CONNECTED c4:13:75:3e:be:fb auth_alg=sae
Sat Jun  6 17:43:22 2026 daemon.info hostapd: ap-mld0: STA c4:13:75:3e:be:fb RADIUS: starting accounting session 5089C54CC878A146
Sat Jun  6 17:43:22 2026 daemon.info hostapd: ap-mld0: STA c4:13:75:3e:be:fb WPA: pairwise key handshake completed (RSN)
Sat Jun  6 17:43:22 2026 daemon.notice hostapd: ap-mld0: EAPOL-4WAY-HS-COMPLETED c4:13:75:3e:be:fb
[13571.718570] mt7996e 0000:01:00.0: Message 00130022 (seq 7) timeout
Sat Jun  6 17:43:24 2026 kern.err kernel: [13571.718570] mt7996e 0000:01:00.0: Message 00130022 (seq 7) timeout
[13629.618392] rcu: INFO: rcu_sched self-detected stall on CPU
[13629.623985] rcu:     2-....: (5999 ticks this GP) idle=26d4/1/0x4000000000000000 softirq=321002/321002 fqs=2999
[13629.633819] rcu:     (t=6000 jiffies g=479749 q=2251 ncpus=4)
[13629.639310] CPU: 2 UID: 0 PID: 1148 Comm: napi/phy0-0 Tainted: G           O        6.18.34 #0 NONE
[13629.639324] Tainted: [O]=OOT_MODULE
[13629.639328] Hardware name: Gemtek W1700K (OpenWrt U-Boot layout) (DT)
[13629.639333] pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[13629.639342] pc : skb_pull+0x0/0x40
[13629.639355] lr : mt7996_mcu_rx_event+0x3c4/0x7dc [mt7996e]
[13629.639403] sp : ffffffc0818d3b20
[13629.639406] x29: ffffffc0818d3b20 x28: ffffff8006e12160 x27: 0000000000000000
[13629.639421] x26: ffffff8006e12160 x25: 0000000000000428 x24: 0000000000000007
[13629.639433] x23: 0000000000000000 x22: 0000000000000428 x21: ffffff8006e12060
[13629.639445] x20: ffffff80119770b9 x19: ffffff8001d3ce00 x18: 0000000000000000
[13629.639457] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000081ac6fb6
[13629.639469] x14: 0000000000000157 x13: 0000000000000157 x12: 0000000000000000
[13629.639480] x11: 00000000000000c0 x10: ffffff800101d0b8 x9 : 0000000000000000
[13629.639492] x8 : ffffff8001006350 x7 : 0000000000000008 x6 : 0000000000000000
[13629.639504] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000
[13629.639515] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffffff8001d3ce00
[13629.639527] Call trace:
[13629.639531]  skb_pull+0x0/0x40 (P)
[13629.639542]  mt7996_queue_rx_skb+0x4fc/0xd60 [mt7996e]
[13629.639570]  mt76_dma_rx_poll+0x474/0x710 [mt76]
[13629.639602]  __napi_poll+0x34/0x180
[13629.639612]  napi_threaded_poll_loop+0xa4/0x148
[13629.639622]  napi_threaded_poll+0x70/0x7c
[13629.639631]  kthread+0xe4/0x1ac
[13629.639643]  ret_from_fork+0x10/0x20

Using the image from:

the build by @iCare does not crash and appears to advertise the network as an MLO network correctly.

However, when I connect to an MLO-enabled SSID, performance is actually worse than when using 5 GHz or 6 GHz alone.

For reference, I can achieve around 2.1 Gbps on 5 GHz (160 MHz) and around 3 Gbps on 6 GHz (320 MHz) individually. Based on that, I would expect something closer to 5 Gbps with MLO enabled. Instead, throughput drops to around 300 Mbps.

I understand that MLO is still a very new technology and may not yet be stable, but I would appreciate any information or insights anyone may have.

Thank you.