[hAP ax S / MT7916+MT7976] tx-rate stuck at band minimum with excellent signal — multiple client devices affected

[mdj2000]

Hardware & Software

• Router: MikroTik hAP ax S (model E62iUGS-2axD5axT)
• Chipset: MT7916 (2.4 GHz), MT7976 (5 GHz)
• RouterOS: tested on 7.21.5 (long-term) and 7.23.1 (latest stable) — behavior identical on both

---

Problem description

After a variable amount of time (minutes to hours), the tx-rate for one or more clients gets stuck at the absolute minimum rate for the band:

• 1 Mbps on 2.4 GHz (802.11b floor)
• 6 Mbps on 5 GHz (OFDM floor)

This is not an idle artifact. The tx-bits-per-second value matches the stuck rate, confirming real traffic is bottlenecked. Signal is excellent at the time of the issue.

Example from registration-table during active download:

interface=wifi2(5) signal=-50 band=5ghz-ac
tx-rate=6.0Mbps tx-bits-per-second=5.8Mbps rx-rate=54.0Mbps

interface=wifi1(2.4) signal=-41 band=2ghz-n
tx-rate=1000.0kbps tx-bits-per-second=975kbps rx-rate=72.2Mbps

Note the asymmetry: rx-rate (client→AP direction) is always normal. Only the tx-rate (AP→client) gets stuck.

---

Affected clients

The issue is not client-specific — it affects completely different hardware:

• Samsung Galaxy A55 (Android 16, both bands)
• Sony Bravia TV (802.11 a/b/g/n, both bands)
• Asus laptop with Intel Dual Band Wireless-AC 7260 (Windows 11, both bands)

---

Workaround

Manually removing the client from the registration table always resolves the issue immediately:

/interface wifi registration-table remove [find where mac-address=XX:XX:XX:XX:XX:XX]

After reconnection, the rate returns to normal. The issue reappears after a variable amount of time.

---

What has already been ruled out

• RouterOS version: tested on 7.21.5 and latest stable — same behavior
• Client-side power management: disabled on all affected devices, no improvement
• Intel 7260 driver settings: "Packet Coalescing" disabled, all power-saving options off — temporary improvement only, after all default setting are restored
• Channel interference: fixed channels verified as clean with a spectrum analyzer app — no improvement
• Signal strength: issue occurs with signal between -41 and -56 dBm — clearly not a coverage problem

---

Additional issue

The Sony TV (connected and authorized, shown in registration-table) occasionally becomes completely unresponsive: no ping reply, no traffic, yet still listed as connected. Only a manual remove resolves it.

---

Hypothesis

The rate adaptation algorithm in the MediaTek driver (wifi-mediatek package) appears to enter a corrupted state where it drops to the minimum rate and fails to recover, regardless of signal quality. The state resets only on client reconnection. Since this affects clients with entirely different chipsets and operating systems, the issue appears to be AP-side.

Is this a known issue with MT7916/MT7976 on hAP ax S? Is there a workaround or a planned fix?

---

Configuration (minimal, reproduced on factory-reset unit):

/interface wifi
set [ find default-name=wifi1 ] arp-timeout=auto channel.band=2ghz-ax .reselect-time=03:00:00..04:00:00 configuration.country=Italy .mode=ap .ssid=\
    *** disabled=no mac-address=*** mtu=1500 name="wifi1(2.4)" radio-mac=*** security.authentication-types=\
    wpa2-psk
set [ find default-name=wifi2 ] arp-timeout=auto channel.band=5ghz-ax .reselect-time=03:00:00..04:00:00 configuration.country=Italy .mode=ap .ssid=\
    *** disabled=no mac-address=*** mtu=1500 name="wifi2(5)" radio-mac=*** security.authentication-types=wpa2-psk
#for guest
add arp-timeout=auto configuration.mode=ap .ssid=*** disabled=no mac-address=*** master-interface="wifi1(2.4)" name=\
    "wifi3(2.4)-virtual" security.authentication-types=wpa2-psk,wpa3-psk
add arp-timeout=auto configuration.mode=ap .ssid=WL-GUEST-DS disabled=no mac-address=*** master-interface="wifi2(5)" name=\
    "wifi4(5)-virtual" security.authentication-types=wpa2-psk,wpa3-psk
/interface wifi access-list
#only for reminder
add action=accept comment="KEY-TPLink-Wireless (wifi5)" disabled=no interface="wifi2(5)" mac-address=***
add action=accept comment="KEY-TPLink-Wireless (wifi2.4)" disabled=no interface="wifi1(2.4)" mac-address=***
...
add action=accept comment="PORT-Asus-CDV (wifi5)" disabled=no interface="wifi2(5)" mac-address=***
add action=accept comment="PORT-Asus-CDV (wifi2.4)" disabled=no interface="wifi1(2.4)" mac-address=***
...
add action=accept comment="PORT-Asus-MDS (wifi5)" disabled=no interface="wifi2(5)" mac-address=***
add action=accept comment="PORT-Asus-MDS (wifi2.4)" disabled=no interface="wifi1(2.4)" mac-address=***
add action=accept comment="PORT-Lenovo-MDS (wifi5)" disabled=no interface="wifi2(5)" mac-address=***
add action=accept comment="PORT-Lenovo-MDS (wifi2.4)" disabled=no interface="wifi1(2.4)" mac-address=***
add action=accept comment="PHONE-SamsungGA55-MDS (wifi5)" disabled=no interface="wifi2(5)" mac-address=***
add action=accept comment="PHONE-SamsungGA55-MDS (wifi2.4)" disabled=no interface="wifi1(2.4)" mac-address=***
add action=accept comment="PHONE-SamsungGA35-CDV (wifi5)" disabled=no interface="wifi2(5)" mac-address=***
add action=accept comment="PHONE-SamsungGA35-CDV (wifi2.4)" disabled=no interface="wifi1(2.4)" mac-address=***
add action=accept comment="PHONE-SamsungGA16-ADS (wifi5)" disabled=no interface="wifi2(5)" mac-address=***
add action=accept comment="PHONE-SamsungGA16-ADS (wifi2.4)" disabled=no interface="wifi1(2.4)" mac-address=***
add action=accept comment="TABLET-Teclast-EDS (wifi5)" disabled=no interface="wifi2(5)" mac-address=***
add action=accept comment="TABLET-Teclast-EDS (wifi2.4)" disabled=no interface="wifi1(2.4)" mac-address=***
add action=accept comment="TV-SonyB-DS (wifi5)" disabled=no interface="wifi2(5)" mac-address=***
add action=accept comment="TV-SonyB-DS (wifi2.4)" disabled=no interface="wifi1(2.4)" mac-address=***
add action=accept comment="WATCH-Garmin-MDS (wifi5)" disabled=no interface="wifi2(5)" mac-address=***
add action=accept comment="WATCH-Garmin-MDS (wifi2.4)" disabled=no interface="wifi1(2.4)" mac-address=***
add action=accept comment="IOT-Lamp MDS (wifi5)" disabled=no interface="wifi2(5)" mac-address=***
add action=accept comment="IOT-Lamp MDS (wifi2.4)" disabled=no interface="wifi1(2.4)" mac-address=***
/interface wifi cap
set enabled=no
/interface wifi capsman
set enabled=no

Access-list rules with signal-range have been added to mitigate band instability but do not affect the rate-stuck issue.

[tadawson]

Is there any consistency of the frequency in use when this occurs?

[infabo]

try 7.24rc4. And if it does not improve then copy and paste your text and please send it to support@mikrotik.com.

[mdj2000]

@tadawson

Is there any consistency of the frequency in use when this occurs?

Yes, it appears quite frequently, sometimes even frequent manual removals don't solve the situation.

[mdj2000]

@infabo

try 7.24rc4. And if it does not improve then copy and paste your text and please send it to support@mikrotik.com.

At the moment, I'd like to wait to see if anyone else has a solution. I've already tried the stable version and I don't think the beta version will solve the problem. If I get a response here, I'll try contacting MikroTik. I'm really frustrated at owning cutting-edge wireless products and not being able to use them.

[infabo]

hAP ax S Quick Set internet interface issue

Now the main bug is that clients WiFi download speed drops down from 70-250 Mbps to 1000 kbps or even less for Tx rate, but Rx rate remain at good level (about 70-250 Mbps depending on the distance). Distance between laptop with Intel(R) Dual Band Wireless-AC 3165 adapter and router is about 1-2m (not possible to use wired connection unfortunately). The lowest used bands iz 2 GHz N and 5GHz AC This happens for both 2.4GHz and 5GHz channels.

Qualcomm Atheros AR956x Wireless Network Adapter 2.4GHz WiFi interface with low TX rate

Good morning I'm writing to you because I having a small problem with one device. I have an ASUS laptop with a Qualcomm Atheros AR956x Wireless Network Adapter (PCI\VEN_168C&DEV_0036&SUBSYS_213A1A3B). When I connect to the MikroTik hAP ax S (model = E62iUGS-2axD5axT), I see a high RX rate (72Mbps) and a low TX rate (6Mbps) in the registration table. When the TX rate reaches 1Mbps, I lose connection to my router. The ping works, but averages 1500ms. However, there's no link with WinBox, and obvi…

MikroTik hAP ax S CAPsMAN: 5 GHz client downlink often stuck at 54 Mbps while another client on same AP is fast

Hi all, I am troubleshooting a MikroTik WiFi/CAPsMAN issue and would like input from people with real RouterOS WiFi experience. The summary below is summarised by an LLM but it is really me looking for answers. Hope somebody can help me find this culprit... Setup • ⁠hEX S as router and WiFi CAPsMAN controller • ⁠ hAP ax S as CAPs • ⁠Local forwarding, traffic processing on CAP • ⁠FT enabled • ⁠FT-over-DS enabled • ⁠GHz fixed channel layout per AP • ⁠AX enabled • ⁠Steering enabled with …

You're welcome.

Please report it to Mikrotik. People apparently experiencing these issues for many months. I can't report the issue for you, because I don't own that device and don't have a way to reproduce. Please, for all the hap ax s owners, someone has to do it.

[tadawson]

Uh, "frequency" as is "radio frequency the AP is using" not how often it happens . . . .

(I've seen cases where AX devices may choose "edge" frequencies that non-AX devices don't handle well . . . . esp with wider channels.)

[luxyves]

I had a similar issue for all clients which roamed to my hAP ax S. The hAP ax S is one of my 4 CAPs (1 hAP ax lite, 2 wAP ax, 1 hAP ax S) managed by CAPsMAN running on a hEX S 2025. After reconnecting the clients (disabling and re-enabling Wi-Fi) their speed instantly turned fine. I eventually solved the issue by disabling ft-over-ds on the CAPsMAN. Now all clients roam fine to the hAP ax S and get good speed (around 500-550 MBps).

[infabo]

@luxyves

by disabling ft-over-ds

Looks like OP does not have FT enabled at all.

[massinia]

I don’t understand the purpose of this access list. Have you tried not using it?

[infabo]

@mdj2000

/interface wifi access-list
#only for reminder

Maybe only for reminder

[tadawson]

The access-list looks to be to restrict the wifi devices that can access a radio by MAC address. (I do this as well, but not by band/radio . . . never a problem, and it prevents the riff-raff from trying to connect to your AP.)

[mdj2000]

@tadawson

esp with wider channels

i try with .width=20mhz. I don't think that's the problem anyway

@luxyves

I eventually solved the issue by disabling ft-over-ds

by default it is disabled but now I set it to manual .ft-over-ds=no. I try it

@massinia

access list. Have you tried not using it?

It is only used to understand which clients are registered, I also tried to disable it but the result does not change

@tadawson

it prevents the riff-raff from trying to connect to your AP.

I also have a wifi network password anyway

I thank everyone for participating

[tadawson]

@mdj2000

I also have a wifi network password anyway

As do I (24+ chars), but it won't stop folks from trying to connect/discover it. The MAC access list does . . . there is a place for both is desired and/or needed.

[CGGXANNX]

But especially for WiFi the MAC address access list is useless. Any low-tech attacker in the proximity is able to see the MAC addresses of everyone, because they are all in clear text in the air (no need to tap a wire or hack a switch like with wired ethernet), see this or this, and then can just spoof one of the MAC addresses they found talking to your BSSID.

And there is more work to maintain an access list in the age of "privacy" MAC address randomization on modern devices.

[tadawson]

Works fine for me . . . . (Does exactly what I want it to do - add a layer of isolation not necessarily from an attacker, but from idiots).

I simply refuse random MACs . . . If you run one, you don't belong on my network . . . period.

All "legit" users also have a static IP from DHCP, so IP collisions from a duplicated MAC will also be apparent, because things will stop working. (And you still need to get past the long complex password(s) . . . ) Also, without the MAC restriction, if someone did get the password, they would be a lot harder to notice, since there would be no other impact to existing devices.

As an added benefit (and the static DHCP does this as well), it gives me a definite name to whatndevice a MAC goes to.

So, it offers enough value to me to be worth the minimal workload needed to manage it.

(This case is at home . . . not what I would do on a more public site.)

[jaclaz]

@tadawson

I simply refuse random MACs . . . If you run one, you don't belong on my network . . . period.

Out of curiosity, do you also have an x-ray machine and a metal detector at your main entrance to the home?

[tadawson]

@jaclaz

Out of curiosity, do you also have an x-ray machine and a metal detector at your main entrance to the home?

No, but we are on our 3rd German Shepherd . . . (if you don't belong in the house, you will know it!)

Most likely see my security plan as excess, but I have worked for a number of startups, and consequently have had things on (or travelling across) my network that are far more sensitive that typical home network noise . . .

I also live in a university town, and there is some student housing nearby, and while likely not that "gifted" yet, I still have no desire to be used as a public ISP, so make things hard enough that the will (hopefully) go look at a homeowner still running defaults instead.

And a background working with the Fortune 100 kinda formed a lot of my mindset . . .

[CGGXANNX]

If you need more security, implement WPA 2/3 Enterprise in your home WiFi. User Manager works well as RADIUS server for this purpose. Assign separate accounts to your phones/tablets/laptops.

Both EAP-TLS (each client device has a certificate, which will make sure that those students won't be able to attempt to do anything), as well as EAP-PEAP/MSCHAPv2 or EAP-TTLS/MSCHAPv2 (each user doesn't need a certificate, but have their own username and password, which is still much more secure than normal WPA2/WPA3, because both the username and password have to be guessed, instead of only the passphrase) work well. The RADIUS server side (User Manager) can authenticate itself with a Let's Encrypt certificate, so no custom CA certificate needs to be added to the client devices.

Another big advantage, beside greatly improved security, is that you can easily identify and classify (put in different VLANs to apply all kind of restrictions) each device / user without having to rely on things like the MAC address. The MAC addresses can stay random, you don't have to care about them. And no risk of accidental passphrase sharing / leaking with QR code.

I just wrote about this in another thread:

Does capsman support vlans?

I don't use MikroTik WiFi offers so I can not talk about RouterOS specific configuration, but having multiple VLANs per SSID is very useful. For phones/laptops/tablets you can setup WPA (2/3) Enterprise and with a single SSID put each clients in their custom VLAN based on their individual credentials or certificates. No need to worry about random MAC addresses. Especially for kids' devices because you can gives individual scheduled restrictions per kid, without fearing them sharing password with…

[mdj2000]

WPA2/WPA3 implementations with enterprise are certainly better security solutions, but in this thread I want to address the connection speed issue first. For now, the current solution is fine for a home connection, and at most I'll try using the Radius server in the future. As an update, I can say that the ft-over-ds function along with ft, even though they are disabled by default and manually set to disabled, hasn't had any positive effect ( WiFi - RouterOS - MikroTik Documentation ). I'm trying channel width to see if it helps, and I'll update you later ( WiFi - RouterOS - MikroTik Documentation ). I'm using it with 20Mhz on 2.4Ghz and currently 20/40/80Mhz on 5Ghz with further modifications on the latter.

Updates will follow but at the moment there is still no solution