I have a problem with ROS version 7.1.1. on wAP ac old devices (RBwAPG-5HacT2HnD on mipsbe). The problem mainly concerns 5G WiFi and is manifested by a decrease in speed towards the upload. The problem does not occur on wAP ac new (RBwAPG-5HacD2HnD on arm). I did not observe the problem on hAP ac3 (RBD53iG-5HacHnD on arm). After downgrading to 6.49.2 the problem disappears and even wAP ac new (RBwAPG-5HacD2HnD on arm) and hAP ac3 (RBD53iG-5HacHnD on arm) work better (more efficiently). The screenshot shows an example of 5G WiFi transfer for a 600/60 Mbps Internet connection. The same problem is in the internal network, e.g. when copying files via WiFi to a NAS in the LAN network (even the WiFi connection is broken / disconnected).

ROS 6.45.9 stay on that one...

... and the "config + registration table values + status & counters" of the 5GHz WLAN interface are ..... what??????

Measuring the outcome is one thing, finding the root cause needs much more information!

It seems to me that if something works on an older version but doesn't work on the new one, the software is the problem.
More in-depth diagnostics is fun when you have knowledge and time.
MT engineers may need to check this with the LAB and make recommendations or improve the software - that's their job.
I indicated the specific MT models with which there is a problem with the new software.
Not only do I have these symptoms after updating these MT models.

The reason for this information question is that MT out of the box uses some "auto" selection mechanisms.
The most disturbing one is the auto wifi channel selection, which is unpredictable and has a major impact on the performance.
Even two identical softwares could give total different performances at different times.
Is the 7.1.1 different from the 6.49.2 in this selection? Who knows? Out-of-the-box MT is set for FCC regulatory domain = USA, not for Poland.

It's like rolling dices, the red one gives 1 the blue one gives 6, the color of the dice is the problem ... ?

@bpwl,

Do you have this RBwAPG-5HacT2HnD available in your arsenal?


@sstybel,

Can you please post screenshots of both devices/firmwares using this speed test https://www.waveform.com/tools/bufferbloat ?

@bpwl,

Do you have this RBwAPG-5HacT2HnD available in your arsenal?

Why ?
viewtopic.php?p=906465#p906465

I have the same problem here on ROS 7.1.1 (also on 7.2rc3). CCR1036-12G-4S with RBwAPG-5HacT2HnD access points via capsman in local forwarding mode. UM5 is running on the router, doing EAP-PEAP for the wireless clients. And there is virtually no other networks around, since this is in a solid swiss bunker basement

Checking the 2G connection if it behaves the same...

When I run the bufferbloat test (for example), download part works perfectly fine, upload part repeatedly kills the connection (not every time, but most of the time). More sporadically this also happens on Teams sessions. It is just more reliably reproducable with the bufferbloat test.

I did netinstall of 7.1.1 on all devices, reconfigured the router manually from scratch. Frankly, I don't know what to do anylonger...

Opening a terminal seems to indicate "large" time adjustments, which I did not have before: Attaching supout and config (hide-sensitive).

Any ideas what could be the problem? This started with 6.49 (or so) and keeps being an issue ever since...

Downgraded all wAP ac devices to long-term 6.48.6 - keeping CCR1036 on 7.1.1 (for UM5 EAP-PEAP).

This seems to work a lot better - Bufferbloat does not kill the connection anymore (at least not the 10 times I tried now). Experienced only one short Teams reconnect. Wireless speeds in download are about 20% less, whereas in upload they are 20% more. Not that it really matters...the connections are a lot more stable. Still not perfect...

I have a problem with ROS version 7.1.1. on wAP ac old devices (RBwAPG-5HacT2HnD on mipsbe). The problem mainly concerns 5G WiFi and is manifested by a decrease in speed towards the upload. The problem does not occur on wAP ac new (RBwAPG-5HacD2HnD on arm). I did not observe the problem on hAP ac3 (RBD53iG-5HacHnD on arm). After downgrading to 6.49.2 the problem disappears and even wAP ac new (RBwAPG-5HacD2HnD on arm) and hAP ac3 (RBD53iG-5HacHnD on arm) work better (more efficiently). The screenshot shows an example of 5G WiFi transfer for a 600/60 Mbps Internet connection. The same problem is in the internal network, e.g. when copying files via WiFi to a NAS in the LAN network (even the WiFi connection is broken / disconnected).
mt-error.jpg

If you think it´s an bug within the firmware I´d suggest to write an email to mikrotik support and provide detailled information about your setup including all configurations files in order to get it fixed in a future release.

Thanks for this topic.
I can also confirm that 7.1.* works very bad with old WAP AC. Download speed is OK unless you start huge data upload and than transmission in both sides just freezes.
Rollback of AP to 6.49.2 fixes issues.

I'm suffering from this issue as well on RouterOS v7.1.1. I have RB4011 as capsman and RBwAPG-5HacT2HnD as caps. When uploading occurs, the client freezes. You can reproduce it easily with iperf.

I tried clean setup the capsman and caps. It doesn't help. I tried literally every channel/extensional channels, not helping.I tried to use RBwAPG-5HacT2HnD as the fat ap, it works as expected. I guess it's the issue of capsman.

I have sent a email to the MT support. Hope they will fix it soon.

ROS 6.45.9 stay on that one...

This small comment is very underrated ! I had a lot of problems on a large multifloor building using a lot of cap ac's and hap ac's (6.48.x) managed by capsman (6.48.x) with 40 Mhz channels like: wireless speed dropping to <10 Mbits on some devices after a lot of traffic or days online, speeds under 100Mbits even if channel is clear, about 5 cap ac's constantly locking wireless clients from the bridge ( accepting wireless clients but no traffic). I read the config on the devices with problems 2-3 times and everything was correctly configured : vlans, tx power, acl's etc.
I installed in half of them 6.45.6 software, including all the ap's with problems and all the nuissances are gone. I have a month now without restarting the ap's who had problems in the past, download is allways about 200 Mbits/s, upload 100-200 Mbits (speedtest, 5ghz band, 40 Mhz channels, clients with decent laptop hardware and 2 channel wifi). I can even compare them now with ubiquity's/openwrt in the term of speed and reliability.

ROS 6.45.9 stay on that one...
This small comment is very underrated !

I have very good results on 6.45.6 (the LT 6.45.8 was not at that level), 6.45.9 may be good again, but not fully tested.
On small MT (SMIPS) the performance degardation is clear. Does it happen on the stronger units, and at what version?

viewtopic.php?t=182565#p908464

ROS 6.45.9 stay on that one...
This small comment is very underrated !

I have very good results on 6.45.6 (the LT 6.45.8 was not at that level), 6.45.9 may be good again, but not fully tested.
On small MT (SMIPS) the performance degardation is clear. Does it happen on the stronger units, and at what version?

viewtopic.php?t=182565#p908464

All the devices with problems are ARM based : cap ac and hap ac2, flashed with the long term firmware as soon as was available, all doing a lot of traffic because of a badly programmed software (500 GB to 2TB dw / 200-300 GB up transfer / month). Also one MIPSBE, after i verified. I don't know for sure at what long term version these devices started to become a real problem as i extended the number of ap's more and more and sometimes problems where missconfigurations during deployment. One thing for sure is that at 6.47 version i stopped deployments the configs was reverified, played with some settings found on mikrotik forums like disabling hardware offlload for interfaces on bridges, enabling/disabling adaptive noise on the wireless interfacess and problems still appeared.
I tested only one device with 6.45.9 and one with 6.45.6 and they seem better at speedtest and stable for 3 days. After i read your comment on a previous topic regarding to your good experience with 6.45.6, i followed your advice, downgraded to 6.45.6 on half of them, configured few wireless settings like antena gain, indoor install on the wireless interfaces (the settings i changed are loaded even if i join capsman ?!) and problems are gone (at least for a month now). I have now the opportunity to say Thank you!

ROS 6.45.9 stay on that one...

This small comment is very underrated ! I had a lot of problems on a large multifloor building using a lot of cap ac's and hap ac's (6.48.x) managed by capsman (6.48.x) with 40 Mhz channels like: wireless speed dropping to <10 Mbits on some devices after a lot of traffic or days online, speeds under 100Mbits even if channel is clear, about 5 cap ac's constantly locking wireless clients from the bridge ( accepting wireless clients but no traffic). I read the config on the devices with problems 2-3 times and everything was correctly configured : vlans, tx power, acl's etc.
I installed in half of them 6.45.6 software, including all the ap's with problems and all the nuissances are gone. I have a month now without restarting the ap's who had problems in the past, download is allways about 200 Mbits/s, upload 100-200 Mbits (speedtest, 5ghz band, 40 Mhz channels, clients with decent laptop hardware and 2 channel wifi). I can even compare them now with ubiquity's/openwrt in the term of speed and reliability.

Thank you for high lighting this comment, I rolled back all of my wap-ac(RBwAPG-5HacT2HnD,mipsbe based) to 6.45.9, but keep the my router(as capsman, RB4011,arm based) at 7.1.1. The wireless glitches are magically gone. The wifi in the house is as smooth as butter.

+1 have huge issues with 5Ghz and smaller ones for 2.4Ghz for my 1st gen HAP ac after upgrade to 7.1. Reset to defaults didn't help at all.

But instead of bad performance what I see is jsut 100% package loss under "load" until re-connect to AP (which is only recover method).

So seems like some generic flaw in packages for old wireless package...

I am having this problem with the hAP ac and hAP ac lite. It is easily reproducible by doing a speedtest. During the upload test, the device will stop communicating on wireless completely. When this happens if you kick the device from the Wireless->Registrations tab it will immediately reconnect and start communicating again like everything was normal. Otherwise there will be a 30 second or so delay until the device times out and drops offline by itself and then reconnects.

RB4011 and Audience seem fine, so the issue appears to be mipsbe related. It doesn't seem to happen with any 6.x version so it is specific to v7. Again, once the traffic hits a certain level, the device appears to "freeze" on wireless, and then it is a zombie where it can't receive or transmit everything but thinks it is still connected. It takes some time to realize that it is a zombie and disconnect, and upon reconnect everything is fine again.

Upon the disconnect of the zombie client, the AP log shows things like this: wlan1: disconnected, received deauth: authentication not valid (2), signal strength -47

It doesn't appear to matter whether the device is acting as the AP or the station, it happens either way.

Error (2) is clear: 2 Previous authentication no longer valid Client has associated but is not authorised. https://aboutcher.co.uk/2012/07/linux-w ... son-codes/

Device is still connected but lost authentication. (?)

Question is where did the deauthentication request come from? "received deauth". Self induced? Management protection? Time-out in re-authentication (distance=dynamic?)?
But there is no authentication error. No re-authentication attempt? Client unaware of the de-authentication ?

It becomes hard to find the "good" ROS releases. For hAP Lite the last good performer seems to be 6.47.9. For hAP ac Lite, wAP ac, hAP ac2 it seems to go with higher version numbers.
ARM devices only started to work good after 6.44.
Looking for the "Highest version, still capable ROS" (we already design for the "Most important, Least Capable Device" )

Interim report. The "old" wAP ac (MIPSBE) devices on 6.48.6 are solid for days now, no issues, at least nothing a user can "feel". Router on 7.1.1. Capsman tested with local forwarding on and off.

Interim report. The "old" wAP ac (MIPSBE) devices on 6.48.6 are solid for days now, no issues, at least nothing a user can "feel". Router on 7.1.1. Capsman tested with local forwarding on and off.

Yes, this is not a surprise, I have many old wAP ac mipsbe models out there running 6.48.6 and 6.49.2 with no issues. These problems are new in v7.

I would like thank you for this discussion but i've got a question to vendor. Are you going to resolve this problem and modify firmware 7.x series for models with mipsbe chip or not?

I've tested v7.1 v7.2rc2 and v7.2rc3 with wAP - each of them have the same 5GHz WiFi upload problem with capsman. The devices used in tests RouterBOARD wAP G-5HacT2HnD

Same problem reported here with a 5Km ptp link and 921UAGS-5SHPacD NetMetal mipsbe. Uprading to 7.1.1 the data rate was poor and unstable with continuous interruptions. Downgrading to 6.49.2 the data rate is perfectly stable again.

Mauro

Does anybody cheked the 7.1.2 version?

A bit scared to do it, since it reads...
... and there are no hints that it should be fixed.

Disconnection under heavy could be due to the AP's beacons are held off by the medium being busy for too long; you can do an air capture to confirm this. If more than a few beacons aren't received, say for 400ms, the client will disconnect.

For the throughput issues, it would be useful to see the output of "/system resource cpu print interval=1s without-paging" on one of the APs during when issues are experienced on RouterOS v7.1.2+ vs v6. Some throughput will be lost if any single processor core is above 70% usage.

If and when /system/routerboard/settings cpu-frequency is set to auto, the transition to a high frequency takes a bit of time (the order of 100us I guess), but it allows a higher max frequency on some devices (eg 896MHz on cAP ac vs 716MHz fixed). It's worthwhile testing auto, the nominal and max processor frequencies to see if the problem relates to processor load.

Dan

Does anybody cheked the 7.1.2 version?

The same.
When U start a high speed upload, the Wap AC's Rx Speed would decrese to a very low class, and the transmit speed woud drop to zero or disconnect from the Wap AC.

Just here to add to this issue. I have a hAP AC and while downloading is fine (around 225 Mbps), uploading starts normal but then drops to zero within seconds. Connection then hangs and I get disconnected from Winbox. I monitored the AP's system resources and the CPU maxes out until it hangs and I get disconnected. The AP is managed by Capsman. I've only noticed this after ROS 7.x.x upgrade. I'm on 7.1.2 now. I've busted out my old Asus AC66U router to temporarily remedy the issue. Hopefully, Mikrotik is aware of this and has a fix.

Yes, I see this same behavior when my iPhone connects to my hAP ac and I do a speedtest.

I've temporarily reverted my hap ac lite back to v6 as it is in station-bridge connecting my home entertainment center back to my RB4011 wifi (running v7). Got sick of connectivity dropping off every 10-20 minutes while watching Netflix.

FYI,

From my testing this issue seems to be gone from 7.2rc4, although there are no changes in the changelog mentioning this at all. Can others confirm?

Confirmed. I would even say improved over 6.4x - at least to what I can read from a few repeated iperf3 measurements.

Also, issue is still present in 7.1.3 - checked it before upgrading to 7.2rc4.

I will testdrive 7.2rc4 for a while - I have the feeling that over time, latency increases when heavy upload is going on from about 6-12ms to 60-120ms - which was not the case in 6.4x. - but this is only a feeling and not confirmed by any thorough measurements.

I had this issue with hAP AC with Hex S on the edge as Capsman after upgrading both to 7.x.x. Nothing fixed the CPU usage and disconnection issues even upgrading to the latest 7.1.3. I'll have to resign to the fact that ROS 7 might be best for newer multi-core CPU/ARM devices only. I'm still getting around 340 Mbps stable after downgrading to ROS 6.49.4 and turning it into an AP bridge. Keeping hAP AC on ROS 6 release stream.

I had this issue with hAP AC with Hex S on the edge as Capsman after upgrading both to 7.x.x. Nothing fixed the CPU usage and disconnection issues even upgrading to the latest 7.1.3. I'll have to resign to the fact that ROS 7 might be best for newer multi-core CPU/ARM devices only. I'm still getting around 340 Mbps stable after downgrading to ROS 6.49.4 and turning it into an AP bridge. Keeping hAP AC on ROS 6 release stream.

You need to compare with 7.2rc4.
I can get easily over 400Mbps on hAP AC2 and AC3.
Using 7.1.3 I couldn't get there (mostly around 300Mbps).
As indicated above by mducharme, "something" was done w.r.t. wifi in 7.2rc4.

I had this issue with hAP AC with Hex S on the edge as Capsman after upgrading both to 7.x.x. Nothing fixed the CPU usage and disconnection issues even upgrading to the latest 7.1.3. I'll have to resign to the fact that ROS 7 might be best for newer multi-core CPU/ARM devices only. I'm still getting around 340 Mbps stable after downgrading to ROS 6.49.4 and turning it into an AP bridge. Keeping hAP AC on ROS 6 release stream.

You need to compare with 7.2rc4.
I can get easily over 400Mbps on hAP AC2 and AC3.
Using 7.1.3 I couldn't get there (mostly around 300Mbps).
As indicated above by mducharme, "something" was done w.r.t. wifi in 7.2rc4.

Whats funny i got better speeds with 7.2rc4. and old wave driver than new wave2 drivers on HAP AC3, this is ideal conditions 2m from AP, S21 Ultra, pretty amazing if you ask me.

Whats funny i got better speeds with 7.2rc4. and old wave driver than new wave2 drivers on HAP AC3, this is ideal conditions 2m from AP, S21 Ultra, pretty amazing if you ask me.

I initially wanted to add that comment as well but didn't because I thought it was irrelevant. But now you mention it ...
My findings were prior to installing wifiwave2 on my hAP AC3. And I have to admit I am NOT that impressed after installing.
Mind you, it's certainly not underperforming but from all the noise that has been made about it, I was expecting a lot more.
On 2GH it is DEFINITELY a remarkable improvement. I've seen speeds regularly reaching +100Mbps were before it was 70-80 max.
On 5GHz however it is more or less the same. Again, that's what I see.

I'm not making a big deal out of it anyhow since my ISP only gives me 200/20. Who cares then if that 5GHz connection hovers around 400-450Mbps ?

Who cares then if that 5GHz connection hovers around 400-450Mbps ?

The better half of yours trying to stream all the movie series you have on your DLNA server to her iPAD ... all at the same time?

The hacker outside your window who hacked into your wireless and is now trying to get into your NAS/gaming server/whatever valuable?

Quick update:

6.49.5 - good, no issues
7.1.5 - bad, issue persists
7.2rc5 - good, no issues

So far found no evidence of wifi parameter changes to explain the better 7.2rc4 performance.
Compared 7.1.3 with 7.2rc4 and the beacon content is absolute totally identical. (Expected bigger A-MSDU, but no, still 3839 bytes)
inSIDDer only captures beacons, no other managament or control packets.
So needed better sniffer to see what's going on. Windows10 64bit on my laptop did not allow me to start a full packet sniffer.
After looking for proper hardware and software, and ordering: Now I can start, with a Edimax AC1750 Wi-Fi USB Adapter and "CommView for Wifi" (free trial).

Capturing A-MSDU is piece of cake. Capturing A-MPDU is not straightforward, as the disassembly already happens in hardware.
It's counting packets between block-ack control packets. https://wifiwiki.wordpress.com/2019/11/ ... -captures/
So far I only used hAP ac Lite as modified AP, which has only one stream in 5GHz.

Some interesting first observations .... (load was only with smartphone and Fast.com or Speedtest.net)

MT AP sends typical 3072byte A-MSDU. Under load this went up to 11 packets for every block-ack. So throughput is limited by 11*3072 byte A-MPDU size. (I just guessed 8*3839 before)
viewtopic.php?t=165698&hilit=3839#p912622
No major difference with 7.2rc4 but sometimes there was 16*3072. (To be verified under heavier load conditions)
While testing, also did setup the hAP ac Lite as "CAPsMAN on CAP" , and measured 1440byte packets, the number varied but it went up to 11 between block-ack. CAPsMAN throughput was limited by 11 (maybe can even be 16) or 11*1440 A-MPDU size. (My guess was 8*2048 for CAPsMAN) But it seems CAPsMAN never used A-MSDU aggregation, just using the original packet size.

In theory A-MPDU can collect up to 64 packets. So CAPsMAN could give higher speed if that would happen. But with this captured information if confirmed, it is clear CAPsMAN would be severely handicapped in potential maximum data rate. A-MSDU as single 1440 packet size could be because 2 packets don't fit in 2048.

EDIT: with higher dual stream interface rates and heavy load the number of MPDU in A-MPDU goes up till 32 for non-CAPsMAN. (At least the A-MSDU sequence number jumps by 32 in the sniffer, which only displays the first MPDU in an A-MPDU at these high speeds). But still the A-MSDU size is sometimes 3088 sometimes 1544 for no apparent reason between different HW setups (hAP ac2, wAP ac, SXTsq ac, PC) or ROS versions when using Btest. This is giving corresponding net data rates. (CAPsMAN was not tested here). A-MSDU size apparently depends on both sides HW and ROS version.

For reference (AMSDU/MPDU - AMPDU) max sizes for HT 802.11n and VHT 802.11ac as seen in beacon.
Mikrotik HT (3839 - 65535) , VHT (3895 - 262143)
OpenWRT HT (7935 - 65535) , VHT (11434 - 1048575)
max AMPDU=64*MPDU packets. AMPDU size defines max throughput % for a given interface rate.

Quick update:

7.2rc5 - ok (avg. 289MB/s over 10 iperf3 runs)
7.2rc6 - ok (avg. 270MB/s over 10 iperf3 runs)
7.2rc7 - ok (avg. 281MB/s over 10 iperf3 runs)

Qupdate:

7.2 - ok (avg. 302MB/s over 10 iperf3 runs)

Hi,
I confirm that version 7.2 (stable) works correctly with the following models:
- wAP ac old devices (RBwAPG-5HacT2HnD on mipsbe)
- wAP ac new (RBwAPG-5HacD2HnD on arm)
- hAP ac3 (RBD53iG-5HacHnD on arm)
- hEX S (RB760iGS on mmips)

- hEX S (RB760iGS on mmips)

???
File a Nobel prize request in category Physics if you really have wifi working on Hex S without radio ...

- hEX S (RB760iGS on mmips)

???
File a Nobel prize request in category Physics if you really have wifi working on Hex S without radio ...

More probably @sstybel simply got so excited with successful upgrade that he simply missed the right thread to express the excitement.

7.2.1 is ok!