We have ~130 clients using HAP AC and HAP AC Lite.
The HAP AC customers are on a direct fibre link that can operate at speeds of up to 1Gbps
The HAP AC Lite's are on a wireless network (WISP) with typical link speeds >100Mbps

On a weekly basis we check that the Router OS is the latest release, and upgrade as necessary to make sure that we have all the latest security fixes
At the same time we also upgrade the Routerboard firmware

After the upgrade to RouterOS 6.42.1 we started to receive complaints from customers
- Slow performance over their WiFi connection to the HAP. This problem appears to be intermittent but happens often enough for customers to notice and complain
——连接到本地无线网络——即使是开发问题ices that were previously connected, the connection fails saying password is incorrect. Customer may be able to connect if they reboot the router. or "forget" the SSID on their wireless device and then reconnect, but this does not always work.

A lot of people seem to be using Apple iPhones / iPADS but we do not know yet if the problem is only with Apple.

In desperation we downgraded the Router OS to 6.40.4 (which was available on our Dude so we could use it for a quick fix) and this appears to have fixed the problem (although we are still monitoring the problem)

Configuration - straight out of the box
- Set WiFi country to United Kingdom
- Set 2GHz and 5GHz SSID to different network names
- Set WiFi password
- Implement Fasttrack on Firewall
- Enable NTP
- Improve security:
/ip service disable telnet,www,api,api-ssl
/ip service set ssh port=2200
/tool mac-server ping set enabled=no
/tool bandwidth-server set enabled=no
/ip ssh set strong-crypto=yes

Anyone else suffering the same issues?
Any ideas?

Thanks!

Please consider to report your problem via thesupport@mikrtotik.com, they will respond your problem very soon. In fact, you are helping MikroTik to improve the product performance for each upgrade. By the way, if your customers are happy with their settings, please do not upgrade the devices.

YH

For production systems you should use the bugfix branch, which is currently on 6.40.8

Bugfix includes any security fixes.

Nick

Thanks @yhfung
问题已经引起了——没有回应,但仍然with 3 day SLA.
However, I'm looking for help from the user group to provide a stronger reassurance that we can resolve the problem particularly as we have more general questions being raised about Mikrotik WiFi performance and whether we should be looking for an alternative hardware.

Please consider to report your problem via thesupport@mikrtotik.com, they will respond your problem very soon. In fact, you are helping MikroTik to improve the product performance for each upgrade. By the way, if your customers are happy with their settings, please do not upgrade the devices.

YH

no response yet but still with 3 day SLA.

I am not aware that MikroTik offers any kind of SLA, let alone a 3 day one.

If you want someone to assist you with this problem may I suggest you contact a Certified Consultant in the UK? If you purchased the MikroTik equipment from ourselves we would be very happy to provide you with a limited amount of free support for you, perhaps remotely dialling in and examining the issues and identifying any possible config changes we can recommend to fix the problem. Unfortunately however if you didn't buy from us, maybe your own distributor can help?

For production systems you should use the bugfix branch, which is currently on 6.40.8

Bugfix includes any security fixes.

Nick

Does is support tr069 yet?

Yes it is in the additional packages download.

It never worked securely until 6.42rc5

*) tr069-client - fixed HTTPS authentication process

As far as I'm aware that was never backported. So we eagrly awaited the new "stable".

That said the wireless is ok on 6.42 branch it just take a ridicules amount of tweaking.

Kinda bummed to hear it was OK previously, so much wasted time

Hi dougunder
Can you share the "tweaking" you've used to improve the WiFi performance.
Would be great if you can export the configuration from a working router and post it here
We're still not convinced it's as good as it should be even using an older firmware image
Thanks

It never worked securely until 6.42rc5

*) tr069-client - fixed HTTPS authentication process

As far as I'm aware that was never backported. So we eagrly awaited the new "stable".

That said the wireless is ok on 6.42 branch it just take a ridicules amount of tweaking.

Kinda bummed to hear it was OK previously, so much wasted time

Wireless woes and how to fix em forum

Don't want to take over yours

viewtopic.php?f=7&t=134203&p=661848#p661848

Wireless woes and how to fix em forum

Don't want to take over yours

Here is a full export

set [ find default-name=wlan1 ] adaptive-noise-immunity=none allow-sharedkey=no ampdu-priorities=0 amsdu-limit=256 amsdu-threshold=8192 antenna-gain=0 area="" arp=enabled arp-timeout=auto \
band=2ghz-b/g/n basic-rates-a/g=6Mbps basic-rates-b=1Mbps bridge-mode=disabled channel-width=20/40mhz-Ce compression=no country="united states3" default-ap-tx-limit=0 \
default-authentication=yes default-client-tx-limit=0 default-forwarding=yes disable-running-check=no disabled=no disconnect-timeout=3s distance=indoors frame-lifetime=0 frequency=auto \
frequency-mode=regulatory-domain frequency-offset=0 guard-interval=any hide-ssid=no ht-basic-mcs=mcs-0,mcs-1,mcs-2,mcs-3,mcs-4,mcs-5,mcs-6,mcs-7 ht-supported-mcs=\
mcs-0,mcs-1,mcs-2,mcs-3,mcs-4,mcs-5,mcs-6,mcs-7,mcs-8,mcs-9,mcs-10,mcs-11,mcs-12,mcs-13,mcs-14,mcs-15,mcs-16,mcs-17,mcs-18,mcs-19,mcs-20,mcs-21,mcs-22,mcs-23 \
hw-fragmentation-threshold=disabled hw-protection-mode=none hw-protection-threshold=0 hw-retries=7 interworking-profile=disabled keepalive-frames=disabled l2mtu=1600 mac-address=\
64:D1:54:1A:1A:A7 max-station-count=2007 mode=ap-bridge mtu=1500 multicast-buffering=disabled multicast-helper=disabled name=wlan1 noise-floor-threshold=default nv2-cell-radius=30 \
nv2-downlink-ratio=50 nv2-mode=dynamic-downlink nv2-noise-floor-offset=default nv2-preshared-key="" nv2-qos=default nv2-queue-count=2 nv2-security=disabled nv2-sync-secret="" \
on-fail-retry-time=100ms preamble-mode=both radio-name=REDACTED rate-selection=advanced rate-set=default rx-chains=0,1 scan-list=2412,2422,2432,2442,2452,2462 secondary-channel="" \
security-profile=default ssid=REDACTED station-bridge-clone-mac=00:00:00:00:00:00 station-roaming=enabled supported-rates-a/g=\
6Mbps,9Mbps,12Mbps,18Mbps,24Mbps,36Mbps,48Mbps,54Mbps supported-rates-b=1Mbps,2Mbps,5.5Mbps,11Mbps tdma-period-size=2 tx-chains=0,1 tx-power-mode=default update-stats-interval=\
disabled vlan-id=1 vlan-mode=no-tag wds-cost-range=50-150 wds-default-bridge=none wds-default-cost=100 wds-ignore-ssid=no wds-mode=disabled wireless-protocol=802.11 wmm-support=\
enabled wps-mode=disabled
set [ find default-name=wlan2 ] adaptive-noise-immunity=none allow-sharedkey=no ampdu-priorities=0 amsdu-limit=2048 amsdu-threshold=8192 antenna-gain=0 area="" arp=enabled arp-timeout=\
auto band=5ghz-a/n/ac basic-rates-a/g=6Mbps bridge-mode=disabled channel-width=20/40mhz-Ce compression=no country="united states3" default-ap-tx-limit=0 default-authentication=yes \
default-client-tx-limit=0 default-forwarding=yes disable-running-check=no disabled=no disconnect-timeout=3s distance=indoors frame-lifetime=0 frequency=auto frequency-mode=\
regulatory-domain frequency-offset=0 guard-interval=any hide-ssid=no ht-basic-mcs=mcs-0,mcs-1,mcs-2,mcs-3,mcs-4,mcs-5,mcs-6,mcs-7 ht-supported-mcs=\
mcs-0,mcs-1,mcs-2,mcs-3,mcs-4,mcs-5,mcs-6,mcs-7,mcs-8,mcs-9,mcs-10,mcs-11,mcs-12,mcs-13,mcs-14,mcs-15,mcs-16,mcs-17,mcs-18,mcs-19,mcs-20,mcs-21,mcs-22,mcs-23 \
hw-fragmentation-threshold=disabled hw-protection-mode=none hw-protection-threshold=0 hw-retries=7 interworking-profile=disabled keepalive-frames=disabled l2mtu=1600 mac-address=\
64:D1:54:1A:1A:A6 max-station-count=2007 mode=ap-bridge mtu=1500 multicast-buffering=disabled multicast-helper=disabled name=wlan2 nv2-cell-radius=30 nv2-downlink-ratio=50 nv2-mode=\
dynamic-downlink nv2-preshared-key="" nv2-qos=default nv2-queue-count=2 nv2-security=disabled nv2-sync-secret="" on-fail-retry-time=100ms preamble-mode=both radio-name= REDACTED \
rate-selection=advanced rate-set=default rx-chains=0,1 scan-list=5180,5220,5745,5785 secondary-channel="" security-profile=default ssid= REDACTED station-bridge-clone-mac=\
00:00:00:00:00:00 station-roaming=enabled supported-rates-a/g=6Mbps,9Mbps,12Mbps,18Mbps,24Mbps,36Mbps,48Mbps,54Mbps tdma-period-size=2 tx-chains=0,1 tx-power-mode=default \
update-stats-interval=disabled vht-basic-mcs=mcs0-7 vht-supported-mcs=mcs0-9,mcs0-9,mcs0-9 vlan-id=1 vlan-mode=no-tag wds-cost-range=50-150 wds-default-bridge=none wds-default-cost=\
100 wds-ignore-ssid=no wds-mode=disabled wireless-protocol=802.11 wmm-support=enabled wps-mode=disabled

For anyone looking for the 'perfect setup' PLEASE do not use this.

For a start, use "scan-list=2412,2437,2462"

The scan-list shown in that post contains a list of 20MHz wide channels on Ch1, Ch3, Ch5, Ch7, Ch9 and Ch11 (which all overlap and interference with each other). Only ever use Ch1, 6 and 11. In very rare greenfield cases where you are the only person using any 2.4GHz within a hundred miles and you are in Europe and thus have access to 13 channels it might be possible to get away with using Ch1, Ch5, Ch9, Ch13. I.e. "scan-list=2412,2432,2452,2472"

But I would still argue that you are better off just using Ch1, 6 and 11 in case a mobile device does not support 13 channels, in which case they will never see, nor be able to connect to an AP on Ch13.

I would also ensure the antenna gain was correctly set. In this case "antenna-gain=2" would be appropriate. This ensures the transmitter is not being over driven and in turn it improves EVM, which improves the chances of reliably connecting at the highest data rates without a high BER.

For anyone looking for the 'perfect setup' PLEASE do not use this.

For a start, use "scan-list=2412,2437,2462"

The scan-list shown in that post contains a list of 20MHz wide channels on Ch1, Ch3, Ch5, Ch7, Ch9 and Ch11 (which all overlap and interference with each other). Only ever use Ch1, 6 and 11. In very rare greenfield cases where you are the only person using any 2.4GHz within a hundred miles and you are in Europe and thus have access to 13 channels it might be possible to get away with using Ch1, Ch5, Ch9, Ch13. I.e. "scan-list=2412,2432,2452,2472"

But I would still argue that you are better off just using Ch1, 6 and 11 in case a mobile device does not support 13 channels, in which case they will never see, nor be able to connect to an AP on Ch13.

I would also ensure the antenna gain was correctly set. In this case "antenna-gain=2" would be appropriate. This ensures the transmitter is not being over driven and in turn it improves EVM, which improves the chances of reliably connecting at the highest data rates without a high BER.

Just showing what works here.

I call BS on the gain statement.
Down rated because Mikrotik did a terrible job on chain 2 antenna design, should have just made the board 1" longer and done 6 integrated, get rid of that and just use the integrated antenna's and gain 0 is stable and best range.

I've got ample testing with this config.
YMMV It's your network YOU are responsible for testing, I'm just sharing what I have tested and is working well for us.
Customers love it.

You can only choose one channel at a time hows that gonna overlap? Have you looked at the default scan list? Basically what i got
Also 2.4g is ALL overlap All the time, more option more likely to find a usable slice.

Ironically enough this is a municipal network in Greenfield MA

P.S for those of us that don't have an encyclopedic knowledge of TLA's (three letter acronyms) he's talking about error vector magnitude, basically a measure of how clean the signal is, and BER (Bit error rate}, or packet loss rate.

My customers would rather GET a signal then NOT GET a perfect signal......

Let me roll the snark back a little.

Gettting a little frustrated with Mikrotik in general and I feel it's spilling over a bit.
With Ruckus, Cisco, Ubqt or any other AP I've dealt with lately you don't touch the channels(or the gain, or any of the tweaks needed).

DFS正常工作频道跳。只是looking at one of the Rucas AP's we use and they def don't stick to 1,6,11 They hop around to the clearest channels. They just work and work well.

In a perfect world I understand why you'd stick to those clearly separated channels when planning a multi AP deployment.
In the real world you'd do a spectral analysis and chose he cleanest channels in that environment, accounting for overlap. Or more likely use decent AP's and not worry about it, given the higher price tolerance of the business world.

In the real world you cant control what channels the TP-links, ASUS, Arris's etcs found in the residential space use. They def don't stick to 1,6,11.
I can't see how ridged channels makes any sense in the crowded residential space. If I'm missing something I'd love to hear what it is. If the logic is sound I'll happily take it on board.

As it is I think going back to all 11 makes the most sense, I had cut it in half when i shifted from 20 to 20/40 on the 2.4ghz.
I only use rigid 5ghz channels due to Mikrotiks poor channel bonding behavior.