HAP lite as an access-point

infabo · Mon Jan 24, 2022 3:50 pm

Is kind of the most unreliable 2.4Ghz AP ever. 5 meters and 2 walls, -77dbm according to registration table. ICMP packet drops en masse. Holy batman. Even an old crappy Asus router on the same channel serves with 1ms ping and 100% realiable ICMP from the same distance.

erlinden · Mon Jan 24, 2022 4:16 pm

Glad you took the opportunity to relief some stress.

Now...please give us the opportunity to give you a hand (and remove all miss configuration from the device).
Can you share the current config: /export hide-sensitive file=anynameyoulike

pe1chl · Mon Jan 24, 2022 4:39 pm

He is right, those devices are sub-standard. I had a hAP mini (freebie on a MUM meeting) for a while as an access point, and never was able to make it work correctly.
E.g. using this site https://packetlosstest.com/ I was able to confirm that regularly there were bursts of packet loss.
Cut/paste of the same config in a hAP AC2 and it worked OK, go figure...

Those old and tiny WiFi devices have problems with recent equipment, and I decided not to spend the effort on reporting it and getting denials. Buying something new was more effective.

bpwl · Mon Jan 24, 2022 5:03 pm

Not my experience

hAP Lite .... 6 meters, 2 brick walls away (in the garage)

Looking at the registration is a great way to diagnose indeed. The signal strength in the registration table for a client is the strength of the client signal !!!
LOW antenna gain , like in most low end hAP, cAP and wAP, does not amplify the client signal like an AP with high antenna gain

Klembord-2.jpg

Both client devices at same location (living room)
First line , smartphone Xiaomi Mi 3 , -71 dBm
Second line , laptop Acer , -62 dBm
Acceptable CCQ , good interface rate (smartphone is sleepy!).

Laptop Speed test (ISP VDSL2 bandwidth wired is around 55/10Mbps, I pay for 100Mbps but it's a long VDSL line)

Klembord-3.jpg

hAP Lite works great even at -86dBm

Compared to ISP modem (same location as hAP Lite in the garage)

Klembord-4.jpg

hAP ac2 in the living room gets full 55/10 Mbps on 5 GHz

Klembord-5.jpg

pe1chl · Mon Jan 24, 2022 5:21 pm

Try that packetloss site. E.g. when using low-latency audio the performance is not acceptable. At least in my case and that of the OP.

Mon Jan 24, 2022 6:12 pm

2GHz is very very vulnerable to interference, and there is plenty of it. You can run a wireless Scan or Snopper and see what frequencies are used nearby. My guess - it's all full

anav · Mon Jan 24, 2022 6:20 pm

All of the above are correct.
Bpwl will help you ensure that your settings are optimized for a good chance at success! You should achieve adequate connectivity but not really good connectivity.
Normis is bang on, in that ensure any devices are far away from electrical interference such as ballisters for tube lighting etc....
and further interference from already EXISTING wifi networks. So do a site survey to see what other channels are being used for 2.4 ghz networks.
Typically you want to be 3 away from the closest chanel( IE if 6 is used, then move to 1 or 12)........
Pe1chi - is correct MT wifi 5 is based on proprietary programming which has been proven to have a. lower speeds and b. less stability than other vendor wifi 5 products. For example I have
tplink eap245s (also vlan capable and cheap) which are superior.

bpwl · Mon Jan 24, 2022 6:25 pm

Try that packetloss site. E.g. when using low-latency audio the performance is not acceptable. At least in my case and that of the OP.

Nice test site. I used Germany.
No problems detected.
Wifi through 2 walls can be problematic. E.G. CCQ can look good, but deteriorate when doing stress tests or other high speed load. It will struggle with other transmitters on the same channel.
And all the other possible wifi disturbancies that we learn to know in detail with MT with it's mandatory manual tuning. It can be done, no, one has to do it, and the "default" is a very good starting point.
People learning "great tuning hacks" like on this forum, mostly get very far away from that good starting point. Every setup is so different. Only act after checking.

Klembord-2.jpg

bpwl · Mon Jan 24, 2022 11:49 pm

2GHz is very very vulnerable to interference, and there is plenty of it. You can run a wireless Scan or Snopper and see what frequencies are used nearby. My guess - it's all full

I like these tools.
"Scan" and "Snooper" are very powerfull. I even add "freq usage" and recently started using "Sniff." as well.

Scan is what most will do, but has too limited information for the RF spectrum.

Let's verify why the hAP Lite did not go to full speed. CCQ of 81% is a first reduction of the throughput.

Scan shows a rather free channel 6 (2437) on yet another MT (wAP ac , 2 wall's separated from living and garage, but this is OK to "listen")
Neighbors are also active in channel 1 and 11

Klembord-2.jpg

So this is OK ! or not ? Well the higher noise floor on channel 6 is an indication of some RF activity.

"Snooper" shows more ...

Klembord-3.jpg

Not so clean anymore (1-6-11). But the most important disturbance is the channel 5 (2432). That's a lot of activity there, and no recognised network or stations.
I don't know where this comes from. Is this non-802.11 ?? If NV2 it would be recognised by MT. This will rise the noise floor for 2437 ?? It will be destructive adjacent channel interference.

The channel 5 usage is confirmed with "Freq usage.."

Klembord-4.jpg

"Sniff." shows no beacon or other packets for 2432 at all. And wow the ISP and neighbors devices send a lot of 1Mbps beacons. (this consumes 3% airtime per SSID, but on non overlapping channels, so no problem for the hAP Lite)

Klembord-5.jpg

infabo · Tue Jan 25, 2022 2:09 am

Haha, eating Popcorn.

This device is 6.48.6 and Default configuration. I Just use it because Chateau is out for RMA.
I saw plenty WiFi disconnect in log. But did not investigate further, because my Teams meeting was a mess. I had to cut the line and throw in another backup device.

Wifi channel usage you say?? Like none!!! I live here on a landslide area. Next neighbors 200m left, the other one 500m. There is only one AP on the first floor on channel 1. I use channel 11 for my AP.
But I will do a snooper to just check.
But funny that this magic Asus router running Tomato is running stable on the "crowded" channel.

Export follows.

I usually use this device in wireless station bridge mode for my TV devices. Twice the distance away from the usual Chateau AP. Never had an issue. At least did not notice.

infabo · Tue Jan 25, 2022 2:34 am

# jan/24/2022 07:08:00 by RouterOS 6.48.6
#
# model = RB941-2nD
/interface bridge
add admin-mac=08:55:31:E4:E4:C5 auto-mac=no comment=defconf name=bridge
/interface wireless
set [ find default-name=wlan1 ] band=2ghz-b/g/n channel-width=20/40mhz-XX country=austria disabled=no distance=indoors frequency=auto installation=indoor mode=ap-bridge ssid=jupiter wireless-protocol=\
    802.11
/interface list
add comment=defconf name=WAN
add comment=defconf name=LAN
/interface wireless security-profiles
set [ find default=yes ] authentication-types=wpa-psk,wpa2-psk mode=dynamic-keys supplicant-identity=MikroTik
/ip pool
add name=dhcp ranges=192.168.88.10-192.168.88.254
/ip dhcp-server
add address-pool=dhcp disabled=no interface=bridge name=defconf
/interface bridge port
add bridge=bridge comment=defconf interface=ether2
add bridge=bridge comment=defconf interface=ether3
add bridge=bridge comment=defconf interface=ether4
add bridge=bridge comment=defconf interface=pwr-line1
add bridge=bridge comment=defconf interface=wlan1
/ip neighbor discovery-settings
set discover-interface-list=LAN
/interface list member
add comment=defconf interface=bridge list=LAN
add comment=defconf interface=ether1 list=WAN
/ip address
add address=192.168.88.1/24 comment=defconf interface=bridge network=192.168.88.0
/ip dhcp-client
add comment=defconf disabled=no interface=ether1
/ip dhcp-server network
add address=192.168.88.0/24 comment=defconf gateway=192.168.88.1
/ip dns
set allow-remote-requests=yes
/ip dns static
add address=192.168.88.1 comment=defconf name=router.lan
add address=192.168.88.244 name=zelenka.home.arpa
/ip firewall filter
add action=accept chain=input comment="defconf: accept established,related,untracked" connection-state=established,related,untracked
add action=drop chain=input comment="defconf: drop invalid" connection-state=invalid
add action=accept chain=input comment="defconf: accept ICMP" protocol=icmp
add action=accept chain=input comment="defconf: accept to local loopback (for CAPsMAN)" dst-address=127.0.0.1
add action=drop chain=input comment="defconf: drop all not coming from LAN" in-interface-list=!LAN
add action=accept chain=forward comment="defconf: accept in ipsec policy" ipsec-policy=in,ipsec
add action=accept chain=forward comment="defconf: accept out ipsec policy" ipsec-policy=out,ipsec
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" connection-state=established,related
add action=accept chain=forward comment="defconf: accept established,related, untracked" connection-state=established,related,untracked
add action=drop chain=forward comment="defconf: drop invalid" connection-state=invalid
add action=drop chain=forward comment="defconf: drop all from WAN not DSTNATed" connection-nat-state=!dstnat connection-state=new in-interface-list=WAN
/ip firewall nat
add action=masquerade chain=srcnat comment="defconf: masquerade" ipsec-policy=out,none out-interface-list=WAN
/system clock
set time-zone-name=Europe/Vienna
/system package update
set channel=long-term
/system routerboard settings
set auto-upgrade=yes
/tool mac-server
set allowed-interface-list=LAN
/tool mac-server mac-winbox
set allowed-interface-list=LAN

infabo · Tue Jan 25, 2022 2:35 am

Bildschirmfoto 2022-01-25 um 01.29.34.png

infabo · Tue Jan 25, 2022 2:38 am

This is possibly the most crowded area ever.

Bildschirmfoto 2022-01-25 um 01.38.14.png

bpwl · Tue Jan 25, 2022 10:26 am

Haha ... wasting my time ? The error log or the message is missing. Is it disconnect reason 3 or reason 8 , or something else? Somebody sending 40MHz intolerant bit ?

You are not just using channel 11 , it's on auto (never trust that with MT), and you have overlapping channels anyway. Adjacent channel destructive interference.

Your one AP on channel 1, beeïng 40 MHz wide (20-Ce) , cannot coexist with your 40 MHz very wide (b-enabled) auto channel (band=2ghz-b/g/n channel-width=20/40mhz-XX), even if it is using channel 11, it will overlap.

In Europe we could have 2 times 40 MHz in 2.4 GHz only when no b-protocol is enabled and channel 1 (Ce) and channel 13 (eC) is used. But 20 MHz is a better option for 2.4GHz in most cases. (higher spectral density for this low gain antenna)

It's not your friendly far away neighbors that are interfering. (500m interference is otherwise quite common, I have sites where 750m away neighbors have a stronger signal than my own AP's)

Solving this will probably not be enough to have a smooth working hAP Lite. (What is in the LOG?) But the Haha dropped my interest in this case.

infabo · Tue Jan 25, 2022 10:39 am

I am just ranting.

And it is in auto mode, because I now run it to see if it gets better. It was dropping packets like a boss, when on frequ 2462.

infabo · Tue Jan 25, 2022 10:43 am

And all these theories about intolerant bits and interference.

Then: why is an Tomato router with the same country settings, channel 11 and 40mhz working so reliably? I even do not have issues with Chateau that sits usually on the same place as this hap lite does. It is clearly the limited hardware that obviously needs tweaking, otherwise it is working this poor way.

nichky · Tue Jan 25, 2022 10:46 am

@normis

we need ctrl+f options for the wireless snooper

infabo · Tue Jan 25, 2022 10:47 am

[admin@MikroTik] > interface wireless monitor 0
                 status: running-ap
                channel: 2452/20-Ce/gn(18dBm)
      wireless-protocol: 802.11
            noise-floor: -116dBm
         overall-tx-ccq: 72%
     registered-clients: 6
  authenticated-clients: 6
            wmm-enabled: yes
      current-tx-powers: 1Mbps:15(15/18),
                         2Mbps:15(15/18),

So watching now. Channel 9 and 20mhz. Should be super awesome in theory

infabo · Tue Jan 25, 2022 11:07 am

OnPaste.20220125-100643.png

quite some loss. but not alle the time. I can do 9 tests that have 0% loss, then another test with these results. Can't say what causing this.

infabo · Tue Jan 25, 2022 11:13 am

registration table on hap lite:

[admin@MikroTik] /interface wireless registration-table> print stats where mac-address=A8:7E:EA:55:9F:10
 0 interface=wlan1 mac-address=A8:7E:EA:55:9F:10 ap=no wds=no bridge=no rx-rate="57.7Mbps-20MHz/2S/SGI" 
   tx-rate="54Mbps-40MHz/1S" packets=30382,17788 bytes=33627218,3559003 frames=24035,17792 frame-bytes=33816306,3452725 
   hw-frames=43019,18298 hw-frame-bytes=56935646,4208593 tx-frames-timed-out=0 uptime=10m13s last-activity=0ms 
   signal-strength=-75dBm@6Mbps signal-to-noise=41dB signal-strength-ch0=-79dBm signal-strength-ch1=-79dBm 
   strength-at-rates=-70dBm@1Mbps 41s350ms,-75dBm@6Mbps 550ms,-77dBm@24Mbps 6m20s950ms,-75dBm@36Mbps 2m22s900ms,-
                  75dBm@48Mbps 4m43s890ms,-75dBm@HT20-0 14s230ms,-75dBm@HT20-1 10s250ms,-76dBm@HT20-2 2s420ms,-75dBm@HT20-3 
                  0ms,-74dBm@HT20-4 14s880ms,-78dBm@HT40-0 2m22s830ms,-79dBm@HT40-1 2m23s40ms,-77dBm@HT40-2 2m24s30ms,-
                  77dBm@HT40-3 2m40s570ms,-77dBm@HT40-4 2m41s80ms 
   tx-ccq=71% p-throughput=43455 last-ip=192.168.88.240 802.1x-port-enabled=yes authentication-type=wpa2-psk 
   encryption=aes-ccm group-encryption=aes-ccm management-protection=no wmm-enabled=yes 
   tx-rate-set="CCK:1-11 OFDM:6-54 BW:1x-2x SGI:1x-2x HT:0-15"

Connection stats on my client:

OnPaste.20220125-101318.png

infabo · Tue Jan 25, 2022 11:19 am

Pings tend to be flaky too:

OnPaste.20220125-101809.png

Usually low pings around 1-2ms. Then it suddenly increases at seq 100 and leads to a loss of 104-107.

pe1chl · Tue Jan 25, 2022 11:21 am

Infabo: that is whay I mean and what I encounter as well, you need to set a longer testing time in that app to always catch it.

infabo · Tue Jan 25, 2022 11:25 am

ping 192.168.88.1
PING 192.168.88.1 (192.168.88.1) 56(84) bytes of data.
64 bytes from 192.168.88.1: icmp_seq=1 ttl=64 time=1.30 ms
64 bytes from 192.168.88.1: icmp_seq=2 ttl=64 time=21.7 ms
64 bytes from 192.168.88.1: icmp_seq=3 ttl=64 time=33.3 ms
64 bytes from 192.168.88.1: icmp_seq=4 ttl=64 time=48.8 ms
64 bytes from 192.168.88.1: icmp_seq=5 ttl=64 time=92.9 ms
64 bytes from 192.168.88.1: icmp_seq=6 ttl=64 time=1.36 ms
64 bytes from 192.168.88.1: icmp_seq=7 ttl=64 time=1.34 ms
64 bytes from 192.168.88.1: icmp_seq=8 ttl=64 time=1.32 ms
64 bytes from 192.168.88.1: icmp_seq=9 ttl=64 time=0.981 ms
64 bytes from 192.168.88.1: icmp_seq=10 ttl=64 time=1.30 ms
64 bytes from 192.168.88.1: icmp_seq=11 ttl=64 time=1.35 ms
64 bytes from 192.168.88.1: icmp_seq=12 ttl=64 time=2.10 ms
64 bytes from 192.168.88.1: icmp_seq=13 ttl=64 time=1.28 ms
64 bytes from 192.168.88.1: icmp_seq=14 ttl=64 time=34.3 ms
64 bytes from 192.168.88.1: icmp_seq=15 ttl=64 time=62.7 ms
64 bytes from 192.168.88.1: icmp_seq=16 ttl=64 time=4.20 ms
64 bytes from 192.168.88.1: icmp_seq=17 ttl=64 time=13.0 ms
64 bytes from 192.168.88.1: icmp_seq=18 ttl=64 time=6.95 ms
64 bytes from 192.168.88.1: icmp_seq=19 ttl=64 time=19.9 ms
64 bytes from 192.168.88.1: icmp_seq=20 ttl=64 time=1.29 ms
64 bytes from 192.168.88.1: icmp_seq=21 ttl=64 time=1.45 ms
64 bytes from 192.168.88.1: icmp_seq=22 ttl=64 time=0.918 ms
64 bytes from 192.168.88.1: icmp_seq=23 ttl=64 time=1.33 ms
64 bytes from 192.168.88.1: icmp_seq=24 ttl=64 time=3.33 ms
64 bytes from 192.168.88.1: icmp_seq=25 ttl=64 time=4.88 ms
64 bytes from 192.168.88.1: icmp_seq=26 ttl=64 time=2.10 ms
64 bytes from 192.168.88.1: icmp_seq=27 ttl=64 time=9.75 ms
64 bytes from 192.168.88.1: icmp_seq=28 ttl=64 time=8.58 ms
64 bytes from 192.168.88.1: icmp_seq=29 ttl=64 time=1.29 ms
64 bytes from 192.168.88.1: icmp_seq=30 ttl=64 time=1.30 ms
64 bytes from 192.168.88.1: icmp_seq=31 ttl=64 time=29.7 ms
64 bytes from 192.168.88.1: icmp_seq=32 ttl=64 time=1.23 ms
64 bytes from 192.168.88.1: icmp_seq=33 ttl=64 time=11.3 ms
64 bytes from 192.168.88.1: icmp_seq=34 ttl=64 time=61.0 ms
64 bytes from 192.168.88.1: icmp_seq=35 ttl=64 time=30.0 ms
64 bytes from 192.168.88.1: icmp_seq=36 ttl=64 time=0.851 ms
64 bytes from 192.168.88.1: icmp_seq=37 ttl=64 time=1.31 ms
64 bytes from 192.168.88.1: icmp_seq=38 ttl=64 time=0.888 ms
64 bytes from 192.168.88.1: icmp_seq=39 ttl=64 time=1.32 ms
64 bytes from 192.168.88.1: icmp_seq=40 ttl=64 time=3.28 ms
64 bytes from 192.168.88.1: icmp_seq=41 ttl=64 time=104 ms
64 bytes from 192.168.88.1: icmp_seq=42 ttl=64 time=104 ms
64 bytes from 192.168.88.1: icmp_seq=43 ttl=64 time=1011 ms
64 bytes from 192.168.88.1: icmp_seq=44 ttl=64 time=1001 ms
64 bytes from 192.168.88.1: icmp_seq=45 ttl=64 time=603 ms
64 bytes from 192.168.88.1: icmp_seq=46 ttl=64 time=195 ms
64 bytes from 192.168.88.1: icmp_seq=47 ttl=64 time=14.6 ms
64 bytes from 192.168.88.1: icmp_seq=48 ttl=64 time=15.2 ms
64 bytes from 192.168.88.1: icmp_seq=49 ttl=64 time=1.36 ms
64 bytes from 192.168.88.1: icmp_seq=50 ttl=64 time=1.29 ms
64 bytes from 192.168.88.1: icmp_seq=51 ttl=64 time=1.35 ms
64 bytes from 192.168.88.1: icmp_seq=52 ttl=64 time=1.35 ms
64 bytes from 192.168.88.1: icmp_seq=53 ttl=64 time=0.884 ms
64 bytes from 192.168.88.1: icmp_seq=54 ttl=64 time=1.32 ms
64 bytes from 192.168.88.1: icmp_seq=55 ttl=64 time=1.30 ms
64 bytes from 192.168.88.1: icmp_seq=56 ttl=64 time=1.29 ms
64 bytes from 192.168.88.1: icmp_seq=57 ttl=64 time=1.28 ms
64 bytes from 192.168.88.1: icmp_seq=61 ttl=64 time=12.9 ms
64 bytes from 192.168.88.1: icmp_seq=62 ttl=64 time=35.6 ms
64 bytes from 192.168.88.1: icmp_seq=63 ttl=64 time=0.851 ms
64 bytes from 192.168.88.1: icmp_seq=64 ttl=64 time=47.0 ms
64 bytes from 192.168.88.1: icmp_seq=65 ttl=64 time=20.2 ms
64 bytes from 192.168.88.1: icmp_seq=66 ttl=64 time=1.48 ms
64 bytes from 192.168.88.1: icmp_seq=67 ttl=64 time=1.31 ms
64 bytes from 192.168.88.1: icmp_seq=68 ttl=64 time=0.864 ms
64 bytes from 192.168.88.1: icmp_seq=72 ttl=64 time=1.41 ms
64 bytes from 192.168.88.1: icmp_seq=73 ttl=64 time=0.869 ms
64 bytes from 192.168.88.1: icmp_seq=74 ttl=64 time=4.44 ms
64 bytes from 192.168.88.1: icmp_seq=75 ttl=64 time=22.9 ms
64 bytes from 192.168.88.1: icmp_seq=76 ttl=64 time=21.5 ms
64 bytes from 192.168.88.1: icmp_seq=77 ttl=64 time=1.28 ms
64 bytes from 192.168.88.1: icmp_seq=78 ttl=64 time=1.30 ms
64 bytes from 192.168.88.1: icmp_seq=79 ttl=64 time=1.36 ms
64 bytes from 192.168.88.1: icmp_seq=80 ttl=64 time=1.36 ms
64 bytes from 192.168.88.1: icmp_seq=81 ttl=64 time=1.61 ms
64 bytes from 192.168.88.1: icmp_seq=82 ttl=64 time=1.38 ms
64 bytes from 192.168.88.1: icmp_seq=83 ttl=64 time=6.85 ms
64 bytes from 192.168.88.1: icmp_seq=84 ttl=64 time=1.05 ms
64 bytes from 192.168.88.1: icmp_seq=85 ttl=64 time=1.24 ms
64 bytes from 192.168.88.1: icmp_seq=86 ttl=64 time=1.37 ms
64 bytes from 192.168.88.1: icmp_seq=87 ttl=64 time=2.08 ms
64 bytes from 192.168.88.1: icmp_seq=88 ttl=64 time=1.31 ms
64 bytes from 192.168.88.1: icmp_seq=89 ttl=64 time=33.6 ms
64 bytes from 192.168.88.1: icmp_seq=90 ttl=64 time=20.1 ms
64 bytes from 192.168.88.1: icmp_seq=91 ttl=64 time=43.3 ms
64 bytes from 192.168.88.1: icmp_seq=92 ttl=64 time=51.9 ms
64 bytes from 192.168.88.1: icmp_seq=93 ttl=64 time=0.956 ms
64 bytes from 192.168.88.1: icmp_seq=94 ttl=64 time=1.27 ms
64 bytes from 192.168.88.1: icmp_seq=95 ttl=64 time=25.7 ms
64 bytes from 192.168.88.1: icmp_seq=99 ttl=64 time=1.65 ms
64 bytes from 192.168.88.1: icmp_seq=100 ttl=64 time=4.76 ms
^C
--- 192.168.88.1 ping statistics ---
100 packets transmitted, 91 received, 9% packet loss, time 99335ms
rtt min/avg/max/mdev = 0.851/43.558/1010.933/159.414 ms, pipe 2

My client is just idling and sending pings. But despite this, there are these weird packet losses.

infabo · Tue Jan 25, 2022 11:37 am

For things to test, I "downgraded" the AP channel-width from first floor to 20mhz. The same I did for my hap lite (channel: 2452/20/gn(18dBm)). Channel 1 and channel 9 - both on 20mhz. No chance to have any overlapping channels. Just not possible.

Now watching how things are going

infabo · Tue Jan 25, 2022 11:38 am

Uff, that didnt take long to find out - does not help anything.

 inf  ~  ping 192.168.88.1
PING 192.168.88.1 (192.168.88.1) 56(84) bytes of data.
64 bytes from 192.168.88.1: icmp_seq=1 ttl=64 time=16.3 ms
64 bytes from 192.168.88.1: icmp_seq=2 ttl=64 time=39.2 ms
64 bytes from 192.168.88.1: icmp_seq=3 ttl=64 time=1.21 ms
64 bytes from 192.168.88.1: icmp_seq=4 ttl=64 time=14.0 ms
64 bytes from 192.168.88.1: icmp_seq=5 ttl=64 time=1.20 ms
64 bytes from 192.168.88.1: icmp_seq=6 ttl=64 time=3.91 ms
64 bytes from 192.168.88.1: icmp_seq=7 ttl=64 time=1.20 ms
64 bytes from 192.168.88.1: icmp_seq=8 ttl=64 time=13.1 ms
64 bytes from 192.168.88.1: icmp_seq=9 ttl=64 time=1.23 ms
64 bytes from 192.168.88.1: icmp_seq=14 ttl=64 time=267 ms
64 bytes from 192.168.88.1: icmp_seq=15 ttl=64 time=85.2 ms
64 bytes from 192.168.88.1: icmp_seq=16 ttl=64 time=48.6 ms
64 bytes from 192.168.88.1: icmp_seq=23 ttl=64 time=22.1 ms
64 bytes from 192.168.88.1: icmp_seq=24 ttl=64 time=84.0 ms
64 bytes from 192.168.88.1: icmp_seq=25 ttl=64 time=1.99 ms
64 bytes from 192.168.88.1: icmp_seq=26 ttl=64 time=1.81 ms
64 bytes from 192.168.88.1: icmp_seq=27 ttl=64 time=21.1 ms
64 bytes from 192.168.88.1: icmp_seq=28 ttl=64 time=26.6 ms
64 bytes from 192.168.88.1: icmp_seq=29 ttl=64 time=1.29 ms
64 bytes from 192.168.88.1: icmp_seq=30 ttl=64 time=1.27 ms
64 bytes from 192.168.88.1: icmp_seq=31 ttl=64 time=15.1 ms
64 bytes from 192.168.88.1: icmp_seq=32 ttl=64 time=1.26 ms
64 bytes from 192.168.88.1: icmp_seq=33 ttl=64 time=1.19 ms
64 bytes from 192.168.88.1: icmp_seq=34 ttl=64 time=53.2 ms
64 bytes from 192.168.88.1: icmp_seq=35 ttl=64 time=1.31 ms
64 bytes from 192.168.88.1: icmp_seq=36 ttl=64 time=74.3 ms
64 bytes from 192.168.88.1: icmp_seq=37 ttl=64 time=18.9 ms
^C
--- 192.168.88.1 ping statistics ---
37 packets transmitted, 27 received, 27.027% packet loss, time 36166ms
rtt min/avg/max/mdev = 1.194/30.272/266.800/53.018 ms

infabo · Tue Jan 25, 2022 11:43 am

While I am pinging and seing the losses, all other clients seem to be idling.

[admin@MikroTik] /interface wireless> registration-table print interval=1
 # INTERFACE                             RADIO-NAME       MAC-ADDRESS       AP  SIGNAL-STRENGTH TX-RATE UPTIME              
 0 wlan1                                                  A8:7E:EA:55:9F:10 no  -71dBm@HT20-5   24Mbps  8m19s               
 1 wlan1                                 2CC81B432764     2C:C8:1B:43:27:64 no  -86dBm@1Mbps    26Mb... 8m18s               
 2 wlan1                                                  FC:49:2D:10:BE:1A no  -72dBm@1Mbps    72.2... 8m17s               
 3 wlan1                                                  68:A4:0E:23:A9:69 no  -70dBm@1Mbps    5.5Mbps 8m16s               
 4 wlan1                                                  76:6E:4F:6A:81:57 no  -73dBm@1Mbps    26Mb... 8m2s                
 5 wlan1                                                  B8:C3:85:AA:5E:2E no  -56dBm@1Mbps    11Mbps  5m45s

infabo · Tue Jan 25, 2022 11:48 am

I assume, the hap is taking a deep breath. Because of all the work he has to get done. Limited hardware.

OnPaste.20220125-104711.png

erlinden · Tue Jan 25, 2022 12:00 pm

Have you tried configuring it as an accesspoint instead of a router? Might take some workload away from the device.
Could you set encryption to wpa2-aes only?

37 packets transmitted, 27 received, 27.027% packet loss, time 36166ms
rtt min/avg/max/mdev = 1.194/30.272/266.800/53.018 ms

Where is the loss (I would expect to see it in one of the 37 lines as well...)?

pe1chl · Tue Jan 25, 2022 12:02 pm

That is the kind of pattern I saw as well. Not a problem when just browsing, but very irritating when doing audio chat and conferencing.
As my hAP mini was a freebie from the MUM and I did not want to spend too much time on this, I just ordered a hAP ac2 and it was fixed.
Of course I am now on 5 GHz but I think it works OK on 2 GHz as well, will try to test that later.

infabo · Tue Jan 25, 2022 12:27 pm

Just for reference, the other AP rocking the wifi.

OnPaste.20220125-111314.png

infabo · Tue Jan 25, 2022 12:59 pm

37 packets transmitted, 27 received, 27.027% packet loss, time 36166ms
rtt min/avg/max/mdev = 1.194/30.272/266.800/53.018 ms
Where is the loss (I would expect to see it in one of the 37 lines as well...)?

sequence 10, 11, 12, 13 is missing.

erlinden · Tue Jan 25, 2022 1:03 pm

sequence 10, 11, 12, 13 is missing.

Indeed...now I see, and more is missing.

Did you read my other remarks as well?

infabo · Tue Jan 25, 2022 1:44 pm

That is the kind of pattern I saw as well. Not a problem when just browsing, but very irritating when doing audio chat and conferencing.

Doing video conferencing or even just audio calls, this is hardly possible with such a) lost packets and b) packets arriving out of order.

infabo · Tue Jan 25, 2022 2:07 pm

Have you tried configuring it as an accesspoint instead of a router? Might take some workload away from the device.
Could you set encryption to wpa2-aes only?

How can I set it as AP instead of router? I unchecked the "Firewall Router" checkbox on Quickset. That apparently removed all firewall filter rules. Did you mean that?

I just disabled WPA and left only WPA2. Lets see.

/interface wireless security-profiles
set [ find default=yes ] authentication-types=wpa2-psk eap-methods="" mode=dynamic-keys supplicant-identity=MikroTik

pe1chl · Tue Jan 25, 2022 2:12 pm

In my case the AP was operating in bridge mode (no NAT or routing) on a VLAN on the ethernet link to the main router.
This did not influence the behavior I think, which appears to be in the WLAN interface. I will try this evening if the 2GHz WLAN interface of the hAP ac2 (which is at the same location) exhibits this same behavior. The 2 GHz WLAN on my RB2011 did not have this problem.

erlinden · Tue Jan 25, 2022 2:25 pm

How can I set it as AP instead of router? I unchecked the "Firewall Router" checkbox on Quickset. That apparently removed all firewall filter rules. Did you mean that?

Quickset is not the proper way to make changes to your config, either use CLI, Webfig or Winbox.

In case of accesspoint, it is sufficient to have a bridge, add all interfaces to it and that's it.

I just disabled WPA and left only WPA2. Lets see.

/interface wireless security-profiles
set [ find default=yes ] authentication-types=wpa2-psk eap-methods="" mode=dynamic-keys supplicant-identity=MikroTik

This will do good

infabo · Tue Jan 25, 2022 2:30 pm

In my humble eyes this is a quite OK signal. It has a a good SNR and OK signal strength as well. So why do I see all these issues then?

2022-01-25_13-28.png

infabo · Tue Jan 25, 2022 2:33 pm

Disabling Firewall router MAYBE not the best idea in my case. Someone already trying to login from outside. ROFL

2022-01-25_13-32.png

infabo · Tue Jan 25, 2022 2:38 pm

Despite all adjustments, packet loss is still unchanged.

# jan/25/2022 13:36:52 by RouterOS 6.48.6
#
# model = RB941-2nD
/interface bridge
add admin-mac=08:55:31:E4:E4:C5 auto-mac=no comment=defconf name=bridge
/interface wireless
set [ find default-name=wlan1 ] band=2ghz-onlyn country=austria disabled=no distance=indoors frequency=2452 installation=indoor mode=\
    ap-bridge ssid=jupiter wireless-protocol=802.11
/interface list
add comment=defconf name=WAN
add comment=defconf name=LAN
/interface wireless security-profiles
set [ find default=yes ] authentication-types=wpa2-psk eap-methods="" mode=dynamic-keys supplicant-identity=MikroTik
/ip pool
add name=dhcp ranges=192.168.88.10-192.168.88.254
/ip dhcp-server
add address-pool=dhcp disabled=no interface=bridge name=defconf
/interface bridge port
add bridge=bridge comment=defconf interface=ether2
add bridge=bridge comment=defconf interface=ether3
add bridge=bridge comment=defconf interface=ether4
add bridge=bridge comment=defconf interface=pwr-line1
add bridge=bridge comment=defconf interface=wlan1
/ip neighbor discovery-settings
set discover-interface-list=LAN
/interface list member
add comment=defconf interface=bridge list=LAN
add comment=defconf interface=ether1 list=WAN
/ip address
add address=192.168.88.1/24 comment=defconf interface=bridge network=192.168.88.0
/ip dhcp-client
add comment=defconf disabled=no interface=ether1
/ip dhcp-server network
add address=192.168.88.0/24 comment=defconf gateway=192.168.88.1
/ip dns
set allow-remote-requests=yes
/ip dns static
add address=192.168.88.1 comment=defconf name=router.lan
add address=192.168.88.244 name=zelenka.home.arpa
/ip firewall filter
add action=accept chain=forward comment="defconf: accept in ipsec policy" ipsec-policy=in,ipsec
add action=accept chain=forward comment="defconf: accept out ipsec policy" ipsec-policy=out,ipsec
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" connection-state=established,related
add action=accept chain=forward comment="defconf: accept established,related, untracked" connection-state=\
    established,related,untracked
add action=drop chain=forward comment="defconf: drop invalid" connection-state=invalid
add action=drop chain=forward comment="defconf: drop all from WAN not DSTNATed" connection-nat-state=!dstnat connection-state=new \
    in-interface-list=WAN
add action=accept chain=input protocol=icmp
add action=accept chain=input connection-state=established
add action=accept chain=input connection-state=related
add action=drop chain=input in-interface-list=!LAN
/ip firewall nat
add action=masquerade chain=srcnat comment="defconf: masquerade" ipsec-policy=out,none out-interface-list=WAN
/system clock
set time-zone-name=Europe/Vienna
/system package update
set channel=long-term
/system routerboard settings
set auto-upgrade=yes
/tool mac-server
set allowed-interface-list=LAN
/tool mac-server mac-winbox
set allowed-interface-list=LAN

erlinden · Tue Jan 25, 2022 2:44 pm

Disabling Firewall router MAYBE not the best idea in my case. Someone already trying to login from outside. ROFL

Lol...so you want it to behave as router, and not as access-point (which you mentioned in the title).
Reset config and start configuring again...sorry for my advise.

bpwl · Tue Jan 25, 2022 2:47 pm

frames=24035,17792 frame-bytes=33816306,3452725 hw-frames=43019,18298 hw-frame-bytes=56935646,4208593

43019 transmits for 24035 frames ! Quite some retransmits. Hidden node problem ?

1 wlan1 2CC81B432764 2C:C8:1B:43:27:64 no -86dBm@1Mbps

Interface throughput is defined by the slowest talker. One client at 56Mbps, one client at 5 Mbps, both have throughput at (5*56)/(5+56) or 5 Mbps !

A ping >3ms should be considered a problem.
Wifi seldom drops a packet, it retries and retries for 3 seconds to deliver it. (tx-frames-timed-out=0) and drops connection when it fails (reason: extensive data loss)

Something is disturbing the 2.4GHz spectrum at random times. Or something else is disturbing the network (spanning tree?). Or some priority process (Firewall hits?) is taking all the CPU.

infabo · Tue Jan 25, 2022 3:01 pm

As my testing device is a notebook I decided to place it near the AP. Same room, 2m distance to HAP.

Guess what? Packet loss. What is so terribly wrong here? Should I search for crazy 2.4ghz interference somewhere?

bpwl · Tue Jan 25, 2022 3:07 pm

Yes, but it may be something else than the wifi.

I would isolate the problem further (disconnect the hAP Lite from the network) and do a standalone test.

What is the wireless "Sniff." telling? That one shows all the packets it can decode (beacons included). It will not show any non 802.11 packet, like in my mystery case. (channel 5 signal)

"/Interface wireless spectral-history" and "/interface wireless spectral-scan" might show evolution over time.

infabo · Tue Jan 25, 2022 3:18 pm

I decided to upgrade to 6.49.2 and see. So I swiched channels and hit Download&Install button on Winbox.
Then after 30% progress of download I decided to hit the CANCEL button, because I did not want it to upgrade now.
I want to reboot manually. So I just want DOWNLOAD. But now it complains about not enough free disk space, because ROS does not clean up cancelled downloads.
I hope I can download after a reboot and do not need a netinstall. That would be ridiculous.

infabo · Tue Jan 25, 2022 3:45 pm

Upgraded to 6.49.2. Went fine.

I have not used the wifi spectrum analyzer before. What does it tell me?

pe1chl · Tue Jan 25, 2022 3:48 pm

It says "use channel 1 or 6, not channel 11".

bpwl · Tue Jan 25, 2022 3:49 pm

Hidden download area. Difficult to clean up.

I did it once , but forgot. When the upgrade runs ROS removes the file in the hidden area. So multiple reboots cleaned it up. But actually I forgot how I did it. (Adding the old npk manually to force an upgrade at reboot that is not executed because of the hidden area file ???)

Maybe upgrade is scheduled "/system package print" and "/system package unschedule" should help then.

I will not upgrade my hAP Lite. (looses functionality with higher ROS versions because of memory constraints).
Upgrading some versions is a problem due to memory. Workaround is to downgrade far enough to have a smaller ROS, or stay above the ROS version corrected for upgrade memory.

infabo · Tue Jan 25, 2022 3:51 pm

Another scan gave me a different result

bpwl · Tue Jan 25, 2022 3:55 pm

Spectrum-history also shows non-802.11 RF signals, I assume.
Spectrum-scan is 802.11 only ???? Not sure of this.

Spectrum scan should be run long enough. You are looking for this PING test moment where it fails. Other tests were OK. So it is something that appears at a specific time.

The signals above 2472MHz are not in our wifi range channel 1-13.
Black is silence, see legend at the top. Fairly quiet right now. Wifi should be OK.

Source can be USB 3.0 : https://www.usb.org/sites/default/files/327216.pdf

infabo · Tue Jan 25, 2022 4:07 pm

Channel 6 did not improve stability.

But pretty reasonable on channel 1: no ICMP packet loss, no packet loss on the test-website within a range of 3min.
Never thought that channel 1 would be performing best, as on ground floor is an AP using that channel already.

infabo · Tue Jan 25, 2022 4:12 pm

The is definitely something goiing on, that is VERY strange.

While the last testrun, it behaved - as you can see from the screenshots - very reliable.

Now, minutes later again the packet losses:

2022-01-25_15-09.png

I am pretty clueless what other non wifi devices here are crowding the 2.4ghz spectrum.
And more clueless, why I did not see these issues on a Chateau LTE12 and on my ASUS router - where I use the 2.4 range too.
Are there differences in how wifi-cards can protect against interferences???

bpwl · Tue Jan 25, 2022 4:56 pm

Is this a wifi problem or another problem?

- Is this standalone?
- Anything in the LOG?? (/system logging add topics=wireless)
- "/tool profile"
- USB3 RF signal?

Co-Channel interference (Coexistence) is much better than adjacent channel interference. (Both AP's should use same channel, same bandwidth and sam control channel)

There is a noise handling parameter you can try: "adaptive noise immunity".
There is even "Noise Floor Treshold" to handle everything below that level as noise (no coexistence, no waiting for clear channel, transmit anyway). Careful here!

Klembord-2.jpg

infabo · Tue Jan 25, 2022 5:58 pm

Maybe I'll catch up tomorrow again. Meanwhile I upgraded to 7.1.1 and began with Default Configuration. Did not really improve.

In the meanwhile I enjoy the beauty of an old Asus RT-AC56U (this is already ARMv7 and has 128MB RAM - look Mikrotik!).

Not a single packet loss in ICMP. Nor (beside a single on) on the packetlosstest.com site. It just performs.

For reference, on the ASUS using the bad-bad-bad-boy channel 11, that is so crowdy according to wireless sniffer:

2022-01-25_16-59.png

The ASUS does not give a f**. It just delivers.

infabo · Tue Jan 25, 2022 6:05 pm

There is a noise handling parameter you can try: "adaptive noise immunity".

I'll give this a try later. Sounds promising.

infabo · Tue Jan 25, 2022 7:36 pm

Spectrum-history also shows non-802.11 RF signals, I assume.
Spectrum-scan is 802.11 only ???? Not sure of this.

Spectrum scan should be run long enough. You are looking for this PING test moment where it fails. Other tests were OK. So it is something that appears at a specific time.

The signals above 2472MHz are not in our wifi range channel 1-13.
Black is silence, see legend at the top. Fairly quiet right now. Wifi should be OK.

Source can be USB 3.0 : https://www.usb.org/sites/default/files/327216.pdf

Not a single USB 3.0 source any near the HAP lite. My client I use for testing all this in the thread, has some USB 3.0 ports. But no USB3 in the same room as HAP lite and not within 5meters. I barely have any devices with USB3 in my household.

Maybe it is all related to the chipset. My client has a Intel AX200 m2 wifi card. Kind of "new". Compared to the ancient chipset inside the HAP lite.

pe1chl · Tue Jan 25, 2022 8:05 pm

As promised I have tested with the hAP ac2 running RouterOS 7.2rc1 on both 2 and 5 GHz (temporarily disabled 5 GHz to force the laptop to use 2 GHz).

Of course it works fine on 5 GHz (0% packet loss), on 2 GHz it had 1.2-2% packet loss which was still way less than I experienced with the hAP mini, which was more like what is shown above (long periods with no traffic at all).

So yes, it likely is related to interference and occupied band, but still it seems to affect the hAP mini much more than the hAP ac2, and maybe both of them more than competing products.

Unfortunately, the hAP ac2 cannot do spectral scan (ARM device)... so no way to see if there are strong interfering signals.

bpwl · Wed Jan 26, 2022 12:34 am

Looks like I have been there before

Just forgot: hAP Lite has a limited TX power that may come into play whenever an obstruction, like walls, has to be passed.
viewtopic.php?t=171070

infabo · Wed Jan 26, 2022 1:32 am

OK, I set adaptive-noise-immunity to ap-client-mode.

Different testing device. Now on a Macbook Pro, distance about 5m and one wall. Usually I have a very strong signal here and a stable connection.

Packetloss test is repeating itself. Mucho loss. And these awkward peaks, where no traffic passes.

Bildschirmfoto 2022-01-26 um 00.23.11.png

Signal on Macbook says -60dbm. Really like. thats a good value.

Bildschirmfoto 2022-01-26 um 00.28.00.png

Doesnt look IMHO bad on registration either.

Bildschirmfoto 2022-01-26 um 00.30.41.png

But still I know: packet loss happens. One can use this AP for maybe low-end internet-surfing or basic googling. But it is impossible to do video calls, audio calls or anything that needs some stable connection that does not have timeouts several times a minute.

TLDR;

I give up. This HAP lite is not going to be anywhere useable as AP for me. I really had the idea, to temporarily replace my usual Chateau LTE12 - which is on RMA currently - with another Mikrotik device. But this was a big mistake and disaster. The HAP lite is going back to its usual task: wireless-ethernet bridge to my livingroom TV. There it works well, never had issues with 4K streaming. But video-streams use quite some buffer - so packet losses may not be visible for me.

And finally thanks to all members who gave advice here. Especially to bpwl, who always wants to help troubleshooting wifi issues (I know several other threads

).
Despite I could not resolve the problem, I still learned something new like about spectrum-history and so on. Could be useful in the future on other devices too.

bpwl · Wed Jan 26, 2022 10:53 am

Well getting hAP-Lite to work well is quite a challenge.
It didn't work out here. (and previous case with hAP Lite neither).
I'm the one here who is learning a lot. I like digging in these "remote cases", it gives a larger test field.

Still packet loss in wifi does not exist, unless the "Frame Lifetime" is filled in, it ends with disconnect after all the trials. The ICMP reply can come late, the max RTD by default is 2000ms, the wifi retry time in MT is 3000ms.
Not the first time I suspect performance problems with newer ROS versions either. If not Internet facing I stick with "proven" versions, and that is even 6.44.5 for the hAP Lite. (Might go to 6.45.6 one day)

infabo · Wed Jan 26, 2022 11:32 am

It gave me no rest this night. So just one parameter I did not check: the power supply. It could explain these massive drops.

So I tried 3 different 5v power supplies - but unfortunately the issue is the same.

To completely exclude any interference with devices around, I unplugged every device in the same room. Nope, not helping either.

So I moved the HAP lite to the other end of my house, so I could exclude interference at a particular location. Nope, did not help.

I could see some random improvement where packet loss did not occur several minutes, to just come back over and over again.

Trying out ROS 6.44.5 is probably the last thing I will give a try. I am still too interested in getting this somehow "fixed".
The hardware may be old, outdated and with crappy specs - but it still should give a reliable link when sitting 2m aside the device.
I am not expecting 300MBit throughput and complaining about something like this. I just expect it to not drop any packets and give me a reliable connection. Just that.

bpwl · Wed Jan 26, 2022 12:03 pm

Still curious about what's in the log (/system logging topics=wireless)
And I suspect "lack of memory" as a possible shortcoming. Never used my hAP Lites with more than 2 clients connected (free memory 6.2MB), there are several VPN links on this VPN server as this is my management connection to remote installations.

infabo · Wed Jan 26, 2022 12:29 pm

Now downgraded from 7.1.1 to 6.44.5. Did a "reset configuration" just to be sure.
Currently pinging like a boss. No losses yet.

# jan/26/2022 11:25:03 by RouterOS 6.44.5
# model = RB941-2nD
/interface bridge
add admin-mac=08:55:31:E4:E4:C5 auto-mac=no comment=defconf name=bridge
/interface wireless
set [ find default-name=wlan1 ] antenna-gain=2 band=2ghz-b/g/n channel-width=20/40mhz-XX country=austria disabled=no distance=indoors \
    frequency=auto frequency-mode=regulatory-domain installation=indoor mode=ap-bridge ssid=jupiter wireless-protocol=802.11
/interface list
add comment=defconf name=WAN
add comment=defconf name=LAN
/interface wireless security-profiles
set [ find default=yes ] authentication-types=wpa-psk,wpa2-psk mode=dynamic-keys supplicant-identity=MikroTik
/ip pool
add name=dhcp ranges=192.168.88.10-192.168.88.254
/ip dhcp-server
add address-pool=dhcp disabled=no interface=bridge name=defconf
/interface bridge port
add bridge=bridge comment=defconf interface=ether2
add bridge=bridge comment=defconf interface=ether3
add bridge=bridge comment=defconf interface=ether4
add bridge=bridge comment=defconf interface=pwr-line1
add bridge=bridge comment=defconf interface=wlan1
/ip neighbor discovery-settings
set discover-interface-list=LAN
/interface list member
add comment=defconf interface=bridge list=LAN
add comment=defconf interface=ether1 list=WAN
/ip address
add address=192.168.88.1/24 comment=defconf interface=ether2 network=192.168.88.0
/ip dhcp-client
add comment=defconf dhcp-options=hostname,clientid disabled=no interface=ether1
/ip dhcp-server network
add address=192.168.88.0/24 comment=defconf gateway=192.168.88.1
/ip dns
set allow-remote-requests=yes
/ip dns static
add address=192.168.88.1 name=router.lan
/ip firewall filter
add action=accept chain=input comment="defconf: accept established,related,untracked" connection-state=established,related,untracked
add action=drop chain=input comment="defconf: drop invalid" connection-state=invalid
add action=accept chain=input comment="defconf: accept ICMP" protocol=icmp
add action=drop chain=input comment="defconf: drop all not coming from LAN" in-interface-list=!LAN
add action=accept chain=forward comment="defconf: accept in ipsec policy" ipsec-policy=in,ipsec
add action=accept chain=forward comment="defconf: accept out ipsec policy" ipsec-policy=out,ipsec
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" connection-state=established,related
add action=accept chain=forward comment="defconf: accept established,related, untracked" connection-state=\
    established,related,untracked
add action=drop chain=forward comment="defconf: drop invalid" connection-state=invalid
add action=drop chain=forward comment="defconf: drop all from WAN not DSTNATed" connection-nat-state=!dstnat connection-state=new \
    in-interface-list=WAN
/ip firewall nat
add action=masquerade chain=srcnat comment="defconf: masquerade" ipsec-policy=out,none out-interface-list=WAN
/system clock
set time-zone-name=Europe/Vienna
/system routerboard settings
set auto-upgrade=yes
/tool mac-server
set allowed-interface-list=LAN
/tool mac-server mac-winbox
set allowed-interface-list=LAN

infabo · Wed Jan 26, 2022 12:48 pm

Did not observe RAM shortcomings. On 7.1.1 I saw7-9MB free memory and I did not see anything lower than 5MB free. Alike in 6.48.6.

I really suspect a performance related issue here.

I did a Tools/Profile on 6.48.6 and on 7.1.1. While running my ICMP tests I had low CPU - BUT I could see CPU spikes between 10-20%. It may correlate to the dropouts.

While here on 6.44.5 I am running packetlosstest.com and a simple ping-to-router in parallel. And I can see no more than 2.5% cpu0 usage in the profiler. wireless 1.0, mostly going cpu0 between 0.5 and 2.5. For me this is a VERY CLEAR hint, that there is something wrong in newer ROS versions.

PS:
so far 6.44.5 has been reliable. Only 0.17% packet loss on 565 transmitted packets. That's a single lost packet.

I don't want to shout out too early, but it looks like it is all related to newer ROS version.

infabo · Wed Jan 26, 2022 1:52 pm

Long running PING in the background the last hour while I was using the device too. Just 4 packet losses in over 3k packets sent.

2022-01-26_12-51.png

Video/Audio calls work like a charm.

I mark this as the solution: ROS 6.44.5

infabo · Wed Jan 26, 2022 3:08 pm

Does ROS 6.44.5 have any security issues?

Mikrotik should really make up their minds how to improve ROS quality/stability.

bpwl · Wed Jan 26, 2022 4:17 pm

From changelogs

MAJOR CHANGES IN v6.45.1:
----------------------
!) dot1x - added support for IEEE 802.1X Port-Based Network Access Control;
!) ike2 - added support for EAP authentication methods (eap-tls, eap-ttls, eap-peap, eap-mschapv2) as initiator;
!) security - fixed vulnerabilities CVE-2019-13954, CVE-2019-13955;
!) security - fixed vulnerabilities CVE-2019-11477, CVE-2019-11478, CVE-2019-11479;
!) security - fixed vulnerability CVE-2019-13074;
!) user - removed insecure password storage;

MAJOR CHANGES IN v6.45.7:
----------------------
!) lora - added support for LoRaWAN low-power wide-area network technology for MIPSBE, MMIPS and ARM;
!) package - accept only packages with original filenames (CVE-2019-3976);
!) package - improved package signature verification (CVE-2019-3977);
!) security - fixed improper handling of DNS responses (CVE-2019-3978, CVE-2019-3979);

Very very personal gut feeling:

My next "proven" ROS after 6.44.5 is 6.45.6 (yes stable, not LT). Things got bad in 6.45.8, improved again in .9 and might be OK.
Next in my list is 6.47.10, but now I have seen things missing in the export file (like WLAN freq) for that release. Damn.
6.48.5 started as a real mess, don't trust 6.48 yet enough for production deployment.
Running all latest @home.

infabo · Wed Jan 26, 2022 4:56 pm

I might upgrade (and reset) step by step. And check after each upgrade how it behaves.

- 6.44.6
- 6.45.6
- 6.45.9
- 6.46.8
- 6.47.10

I believe this issue is related to the architecture. -> SMIPS

My mAP lite (MIPSBE) runs 6.48.6 as a "printer-wireless-bridge". Located on another floor of my house and a weak signal (around -81 to -84dbm). But the connection is reliable and solid. Not that fast - but not a single issue there.

infabo · Thu Jan 27, 2022 12:32 am

Yo, as announced I upgraded step by step and made a ping test each time.

I found it.

First misbehaving ROS is 6.47.10.

Downgraded to 6.47.9 and pinging without packet loss again.

So looking at the changelog of 6.47.10:

What's new in 6.47.10 (2021-May-31 09:54):

MAJOR CHANGES IN v6.47.10:
----------------------
!) wireless - fixed all affecting 'FragAttacks' vulnerabilities (CVE-2020-24587, CVE-2020-24588, CVE-2020-26144, CVE-2020-26146, CVE-2020-26147);

bpwl · Thu Jan 27, 2022 12:36 am

Thanks! Very interesting !!

pe1chl · Thu Jan 27, 2022 11:19 am

That is interesting ideeed! I remember that it used to work better when I just had that hAP mini, but no hard data. Of course it was regularly updated.
Now the next interesting experiment would be to check if other device types exhibit some performance degradation (maybe smaller) at that particular update.

Of course it would not be the first time that computer users experience a permanent performance degradation of their equipment due to the fixes issued for an academic vulnerability... In the literal sense, as these usually originate from research projects run by universities in an attempt to gain visibility and money.

anav · Thu Jan 27, 2022 2:15 pm

Awesome detective work, now I wonder if the coders at MT, can unravel what they did?

anav · Sun Jan 30, 2022 2:17 am

frames=24035,17792 frame-bytes=33816306,3452725 hw-frames=43019,18298 hw-frame-bytes=56935646,4208593
Something is disturbing the 2.4GHz spectrum at random times. Or something else is disturbing the network (spanning tree?). Or some priority process (Firewall hits?) is taking all the CPU.

Yes poor coding!

infabo · Wed Feb 09, 2022 1:10 pm

This stuff is happening again. Even on the older ROS I thought they were OK.
Sure, I tinkered with the configuration in the meanwhile (enabled WMM, add DOH, ...).
But nothing I could suspect to have such an impact.

I now either have some mysterious 2.4ghz noise disturbing my wifi - or this device is just underpowered.

anav · Wed Feb 09, 2022 1:32 pm

You are a slow learner, post#7 gave you the pathway to success. Must like banging your head against the wall. MT wifi like lemmings jumping off a cliff.

infabo · Wed Feb 09, 2022 2:13 pm

Yes, this is how it feels like. Banging my head against a wall, while having a MS Teams meeting and I can barely hear anyone.

So then suggest me some alternative besides some china-trojan wifi AP from TP-link. Which does not cost 500EUR like the ones from Cambium and co. Maybe I should have a look at Zyxel devices. At least Taiwan. I would like to have some device from a manufacturer residing in a non-autocratic country and not selling me some cloud thingy like Ubiquiti does.

anav · Wed Feb 09, 2022 2:25 pm

Dont be silly now. Even MT products are manufactured/assembled in China etc.
TP link is a no fancy low cost, vlan capable APs that simply work and have worked well in wifi 5 for many many years.
I use them in stand alone mode and they are great.

infabo · Wed Feb 09, 2022 2:40 pm

Yes, hap lite is made in china. But devices like Chateau LTE12 are made in Latvia.

But I am talking about software. Or is MT under the control of Chinese party or NSA to include backdoors?

And before someone asking, why I still use this hAP lite: Chateau is on RMA. I have a printer on my wifi connected via map lite in station-bridge mode. And this mode is some Mikrotik proprietary shizzle. Well, need to look for another solution in the meantime I guess.

edit:
I just use station-pseudobridge instead of station-bridge. This kind of works with the ASUS AP running Tomato.
Funny enough, running the ASUS with 2.4ghz only (disabled 5ghz) on the exact same location - works like Dr. STABLE. Not a sign of a packet loss anywhere.
I assume the hAP lite wireless chipset is kind of crap and/or having problems with whatever.
Put back into the box. What could I expect from a device costing 20EUR. I must have been truly a lemming going over the cliff. Thinking I could use MT 2.4ghz wifi.

Who is online