Google Meets video calls keep freezing on WiFi

mdagen · January 9, 2026, 3:45am

Hi all - First time posting here.
Experiencing ongoing issues with calls freezing on Google Meets / Corporate VPN over Mikrotik WiFi. Please note the following regarding this problem and the troubleshooting done to date:

Running CAPsMAN on HAP Ax3 and remote CAP on CAP Ax (See configs below)
Mikrotik APs connected to Unifi Gateway Max
Client Device is Windows 11 on HP Laptop connecting to Corporate network over VPN
Problem started with new Mikrotik WiFi implementation. No issues with client device with previous ASUS Router running as AP over same Unifi Gateway.
Client has no issues when connecting directly via ethernet on Unifi Gateway.
Enabled Debug log level on wireless (See attached logs for device) but video freezing events do not seem to be correlated with events in the Mikrotik logs. For example, in the provided logs the user experienced multiple video freezing events between 8:00 and 9:00 but only her disconnecting from WiFi at 9:01 shows up in the logs.
Currently running 7.21rc5 to see if it would resolve the issue but was experiencing the exact same problems on 7.20.6
Disabled all Access List rules - Did not resolve the issue
Disabled WPA 3 - Did not resolve the issue.

Please advise regarding further troubleshooting given that wireless logs aren’t pointing to root cause. Thanks for your help!

# 2026-01-08 16:55:49 by RouterOS 7.21rc5
# software id = SQBF-L1PS
#
# model = C53UiG+5HPaxD2HPaxD
# serial number =
/interface bridge
add admin-mac=04:F4:1C:8E:2D:BC auto-mac=no comment=defconf name=bridgeLocal
/interface wifi datapath
add bridge=bridgeLocal comment=defconf disabled=no name=capdp \
    traffic-processing=on-cap
/interface wifi security
add authentication-types=wpa2-psk disabled=no encryption="" ft=yes \
    ft-over-ds=yes name=kmdnetsecurity
/interface wifi configuration
add channel.band=2ghz-ax country=Canada datapath.bridge=bridgeLocal \
    .traffic-processing=on-cap disabled=no name=kmdnet_2G_LowPower security=\
    kmdnetsecurity ssid=kmdnet tx-power=3
add channel.band=5ghz-ax .skip-dfs-channels=10min-cac country="United States" \
    datapath=capdp datapath.traffic-processing=on-cap disabled=no name=\
    kmdnet_5G security=kmdnetsecurity ssid=kmdnet tx-power=30
add channel.band=2ghz-ax country=Canada datapath.bridge=bridgeLocal \
    .traffic-processing=on-cap disabled=no name=kmdnet_2G_HighPower security=\
    kmdnetsecurity ssid=kmdnet tx-power=17
add channel.band=2ghz-ax country=Canada datapath=capdp \
    datapath.client-isolation=no disabled=yes name=kmdnet_2G security=\
    kmdnetsecurity ssid=kmdnet
/interface wifi
# operated by CAP 192.168.10.25, traffic processing on CAP
add configuration=kmdnet_5G disabled=no name=cap-wifi1 radio-mac=\
    F4:1E:57:E7:F8:35
# operated by CAP 192.168.10.25, traffic processing on CAP
add configuration=kmdnet_2G_HighPower disabled=no name=cap-wifi2 radio-mac=\
    F4:1E:57:E7:F8:36
set [ find default-name=wifi1 ] configuration=kmdnet_5G disabled=no
set [ find default-name=wifi2 ] configuration=kmdnet_2G_LowPower \
    configuration.mode=ap disabled=no
/interface wifi steering
add disabled=no name=kmdsteering neighbor-group=dynamic-kmdnet-34113543 rrm=\
    yes wnm=yes
/interface bridge port
add bridge=bridgeLocal comment=defconf interface=ether1
add bridge=bridgeLocal comment=defconf interface=ether2
add bridge=bridgeLocal comment=defconf interface=ether3
add bridge=bridgeLocal comment=defconf interface=ether4
add bridge=bridgeLocal comment=defconf interface=ether5
/interface wifi access-list
add action=reject comment="Reject Kala on 2G Main" disabled=yes interface=\
    wifi2 mac-address=18:26:49:91:35:CA
add action=reject comment="Reject Kala on 2G CAP" disabled=yes interface=\
    cap-wifi2 mac-address=18:26:49:91:35:CA
add action=accept comment="Accept 2G Main" disabled=yes interface=wifi2 \
    signal-range=-60..0
add action=accept comment="Accept 2G CAP" disabled=yes interface=cap-wifi2 \
    signal-range=-78..0
add action=reject comment="Reject 2G Main" disabled=yes interface=wifi2 \
    signal-range=-120..-61
add action=reject comment="Reject 2G CAP" disabled=yes interface=cap-wifi2 \
    signal-range=-120..-77
/interface wifi cap
set caps-man-addresses=127.0.0.1 discovery-interfaces=bridgeLocal \
    slaves-datapath=capdp
/interface wifi capsman
set enabled=yes package-path="" require-peer-certificate=no upgrade-policy=\
    none
/interface wifi provisioning
add action=create-enabled disabled=no master-configuration=kmdnet_2G_LowPower \
    radio-mac=04:F4:1C:8E:2D:C2 supported-bands=2ghz-ax
add action=create-enabled disabled=no master-configuration=kmdnet_5G \
    supported-bands=5ghz-ax
add action=create-enabled disabled=no master-configuration=\
    kmdnet_2G_HighPower radio-mac=F4:1E:57:E7:F8:36
add action=create-enabled disabled=yes master-configuration=kmdnet_2G
/ip dhcp-client
add comment=defconf interface=bridgeLocal
/system clock
set time-zone-name=America/Edmonton
/system logging
set 3 action=memory
add topics=wireless,debug

# 2026-01-08 16:56:46 by RouterOS 7.21rc5
# software id = ELV4-U0TK
#
# model = cAPGi-5HaxD2HaxD
# serial number =
/interface bridge
add admin-mac=F4:1E:57:E7:F8:33 auto-mac=no comment=defconf name=bridgeLocal
/interface ethernet switch
set 0 cpu-flow-control=yes
/interface wifi datapath
add bridge=bridgeLocal comment=defconf disabled=no name=capdp
/interface wifi
# managed by CAPsMAN 192.168.10.15, traffic processing on CAP
# mode: AP, SSID: kmdnet, channel: 5220/ax/eeCe
set [ find default-name=wifi1 ] configuration.manager=capsman datapath=capdp \
    disabled=no
# managed by CAPsMAN 192.168.10.15, traffic processing on CAP
# mode: AP, SSID: kmdnet, channel: 2417/ax/Ce
set [ find default-name=wifi2 ] configuration.manager=capsman datapath=capdp \
    disabled=no
/interface bridge port
add bridge=bridgeLocal comment=defconf interface=ether1
add bridge=bridgeLocal comment=defconf interface=ether2
/interface ovpn-server server
add mac-address=FE:46:A9:78:43:EC name=ovpn-server1
/interface wifi cap
set caps-man-addresses=192.168.10.15 enabled=yes slaves-datapath=capdp
/ip dhcp-client
add comment=defconf interface=bridgeLocal
/system clock
set time-zone-name=America/Edmonton
/system package update
set channel=testing

2026-01-07 21:51:38 wireless,info 18:26:49:91:35:CA@wifi1(kmdnet) disconnected, connection lost, signal strength -76
 2026-01-07 21:51:38 wireless,debug 18:26:49:91:35:CA@wifi1(kmdnet) disassociated, connection lost, signal strength -76
 2026-01-07 21:51:39 wireless,debug 18:26:49:91:35:CA@wifi1(kmdnet) associated, signal strength -75
 2026-01-07 21:51:39 wireless,info 18:26:49:91:35:CA@wifi1(kmdnet) connected, signal strength -75
 2026-01-08 07:27:13 wireless,info 18:26:49:91:35:CA@wifi1(kmdnet) disconnected, connection lost, signal strength -64
 2026-01-08 07:27:13 wireless,debug 18:26:49:91:35:CA@wifi1(kmdnet) disassociated, connection lost, signal strength -64
 2026-01-08 07:27:55 wireless,debug 18:26:49:91:35:CA@wifi1(kmdnet) associated, signal strength -64
 2026-01-08 07:27:55 wireless,info 18:26:49:91:35:CA@wifi1(kmdnet) connected, signal strength -64
 2026-01-08 09:01:07 wireless,info 18:26:49:91:35:CA@wifi1(kmdnet) disconnected, connection lost, signal strength -65
 2026-01-08 09:01:07 wireless,debug 18:26:49:91:35:CA@wifi1(kmdnet) disassociated, connection lost, signal strength -65

ferferga · January 9, 2026, 4:29am

Do you have capsman forwarding? I’d try disabling it. You can attach the config as a code block.

mdagen · January 9, 2026, 5:41am

Thanks - I’ve updated the initial posts with configs and log.

CAPsMAN forwarding is already disabled.

ferferga · January 9, 2026, 6:36am

Try disabling switch’s CPU flow control, why do you have it enabled? If it doesn’t work, the config of the capsman controller would also be good.

mdagen · January 9, 2026, 3:17pm

I did not manually enable CPU flow control on the CAP Ax. The CAP Ax was added to the network by resetting and automatically adopting CAPsMAN. As such, CPU flow control seems to have been enabled by default either initially or when the firmware was updated. Is disabling CPU Flow Control the correct default settings for the CAP Ax ?

In any case, I’ve disabled it - Still experiencing same problem. Note that the Windows device is experiencing problems when connected to the HAP Ax3 (CAPsMAN) local WiFi interfaces.

ToTheFull · January 9, 2026, 3:32pm

I've had my Cap AX from day 1 and never touched such a setting, it's enabled when checking.

gotsprings · January 9, 2026, 5:58pm

I have run current caps-man at home for about 2 months with cap AX or wap AX. I notice some dropped frames and sometimes several seconds of freezing, when I look at my old camera. Voice calls are solid.

I pulled them yesterday for 1 X7-35X. Which now covers the whole house by itself.

Calls are good. Frames from camera are not dropped. It used to have serious problem with my Ring. Waiting for that issue to pop up again.

jaclaz · January 9, 2026, 6:47pm

Made from a company that I won't name (if not to say it's Cambium) that manages to sell them for a mere 850-900 €/$ apiece.

In other news, a Porsche 718 is noticeably faster than a Fiat Panda (but carries less baggage) .

mdagen · January 9, 2026, 7:00pm

Ok well I’m not here to switch out any hardware but I would like to figure out how to get my Mikrotik WiFi devices to perform as well as the ASUS router/AP that I was running a week ago.

Given that the wireless logs don’t seem to be providing any insights, are there any other logs that I should be looking at for troubleshooting ?

gotsprings · January 9, 2026, 7:03pm

You realize I have had that cambium AP for 18 months and deployed NONE of them, because of their glitches?

However… I have run a XV2-21X in the exact same spot and it covered the whole house. Didn’t drop frames. Didn’t have freezing. No problems with wifi calling. And costs me less than 2 cap AX or 2 wAP AX.

Now as I stated in another thread… the AX series APs with the latest caps-man (not the hAP AX S, that mediatek chip is causing a whole different set of issues) has been the BEST performance I have seen from a Mikrotik radio serving clients.

The fact that Mikrotik radios are still bested by Cambium and Ruckus isn’t a “gotcha” for me. No sir. I would like nothing better if I could use Tik radios and have them not cause me service calls and pissed clients.

Let me give a perfect example… the hAP AX s would be the perfect replacement for the Ruckus H550 I use. I would only be giving up one managed switch port… but getting a 3x3 Radio on the 5Ghz radio. The best price I have gotten of Amazon for that Ruckus was $400 with an MSRP of $850. You don’t think I would be thrilled to only pay $90? Why do you think that hAP AX s is sitting unplugged next to my desk???

If its doesn’t work… it doesn’t matter what it costs.

gotsprings · January 9, 2026, 7:05pm

That’s the point I was making. It might not be able too.

I have wasted a lot of time trying thou…

mdagen · January 9, 2026, 8:56pm

Here’s the output of ping from a different device (MacBook) over WiFi when connected to HAP Ax3 (CAPsMAN) at -50 dB signal level on wifi1 interface (See below). As you can see, there is significant packet loss and spikes in latency over WiFi in what should be ideal conditions. This could cause the problem reported in the original post given the sensitivity of Google Meets (and other videoconferencing apps) to packet loss and latency.

I also tested ping directly from HAP Ax3 (CAPsMAN) to Gateway and everything was fine with latency under 1 ms and no packet loss.

PING 192.168.10.1 (192.168.10.1): 56 data bytes
64 bytes from 192.168.10.1: icmp_seq=0 ttl=64 time=4.327 ms
64 bytes from 192.168.10.1: icmp_seq=1 ttl=64 time=4.649 ms
64 bytes from 192.168.10.1: icmp_seq=2 ttl=64 time=3.733 ms
64 bytes from 192.168.10.1: icmp_seq=3 ttl=64 time=9.277 ms
64 bytes from 192.168.10.1: icmp_seq=4 ttl=64 time=3.372 ms
64 bytes from 192.168.10.1: icmp_seq=5 ttl=64 time=4.600 ms
64 bytes from 192.168.10.1: icmp_seq=6 ttl=64 time=3.255 ms
64 bytes from 192.168.10.1: icmp_seq=7 ttl=64 time=4.215 ms
64 bytes from 192.168.10.1: icmp_seq=8 ttl=64 time=3.320 ms
64 bytes from 192.168.10.1: icmp_seq=9 ttl=64 time=25.192 ms
64 bytes from 192.168.10.1: icmp_seq=10 ttl=64 time=3.324 ms
64 bytes from 192.168.10.1: icmp_seq=11 ttl=64 time=7.245 ms
64 bytes from 192.168.10.1: icmp_seq=12 ttl=64 time=7.012 ms
64 bytes from 192.168.10.1: icmp_seq=13 ttl=64 time=5.632 ms
64 bytes from 192.168.10.1: icmp_seq=14 ttl=64 time=3.536 ms
Request timeout for icmp_seq 15
Request timeout for icmp_seq 16
Request timeout for icmp_seq 17
64 bytes from 192.168.10.1: icmp_seq=18 ttl=64 time=7.969 ms
64 bytes from 192.168.10.1: icmp_seq=19 ttl=64 time=7.151 ms
64 bytes from 192.168.10.1: icmp_seq=20 ttl=64 time=3.220 ms
64 bytes from 192.168.10.1: icmp_seq=21 ttl=64 time=3.097 ms
64 bytes from 192.168.10.1: icmp_seq=22 ttl=64 time=4.695 ms
64 bytes from 192.168.10.1: icmp_seq=23 ttl=64 time=3.719 ms
64 bytes from 192.168.10.1: icmp_seq=24 ttl=64 time=7.104 ms
64 bytes from 192.168.10.1: icmp_seq=25 ttl=64 time=7.216 ms
64 bytes from 192.168.10.1: icmp_seq=26 ttl=64 time=3.309 ms
64 bytes from 192.168.10.1: icmp_seq=27 ttl=64 time=6.424 ms
64 bytes from 192.168.10.1: icmp_seq=28 ttl=64 time=7.226 ms
64 bytes from 192.168.10.1: icmp_seq=29 ttl=64 time=3.356 ms
64 bytes from 192.168.10.1: icmp_seq=30 ttl=64 time=7.202 ms
64 bytes from 192.168.10.1: icmp_seq=31 ttl=64 time=7.331 ms
64 bytes from 192.168.10.1: icmp_seq=32 ttl=64 time=7.043 ms
64 bytes from 192.168.10.1: icmp_seq=33 ttl=64 time=7.649 ms
64 bytes from 192.168.10.1: icmp_seq=34 ttl=64 time=7.209 ms
64 bytes from 192.168.10.1: icmp_seq=35 ttl=64 time=7.198 ms
64 bytes from 192.168.10.1: icmp_seq=36 ttl=64 time=7.255 ms
64 bytes from 192.168.10.1: icmp_seq=37 ttl=64 time=7.238 ms
64 bytes from 192.168.10.1: icmp_seq=38 ttl=64 time=7.573 ms
Request timeout for icmp_seq 39
Request timeout for icmp_seq 40
Request timeout for icmp_seq 41
64 bytes from 192.168.10.1: icmp_seq=42 ttl=64 time=3.403 ms
64 bytes from 192.168.10.1: icmp_seq=43 ttl=64 time=11.083 ms
64 bytes from 192.168.10.1: icmp_seq=44 ttl=64 time=8.305 ms
64 bytes from 192.168.10.1: icmp_seq=45 ttl=64 time=7.284 ms
64 bytes from 192.168.10.1: icmp_seq=46 ttl=64 time=3.438 ms
64 bytes from 192.168.10.1: icmp_seq=47 ttl=64 time=7.790 ms
64 bytes from 192.168.10.1: icmp_seq=48 ttl=64 time=4.621 ms
64 bytes from 192.168.10.1: icmp_seq=49 ttl=64 time=22.057 ms
^C
--- 192.168.10.1 ping statistics ---
50 packets transmitted, 44 packets received, 12.0% packet loss
round-trip min/avg/max/stddev = 3.097/6.610/25.192/4.228 ms

gotsprings · January 10, 2026, 12:18am

That jibes with my camera freezing then suddenly advancing several seconds.

optio · January 10, 2026, 1:05pm

Did you try to change WiFi channel? Maybe there are interferences on frequencies used by current channel.

I have at home Chateau 5G R17 ax which has same Wifi chip and I don’t have such issues. Since I’m working from home I have many daily video calls (mostly Teams but also over other apps), screen sharings, remote desktop controls, etc. and for me it is crucial that is all working without glitches, so far this MT device is doing fine job.

mdagen · January 10, 2026, 5:26pm

Yes, I did test forcing a different channel and I completely disabled DFS challenges which were working fine with my previous router. Looking for any additional suggestions regarding how to further troubleshoot this issue before going to MT support.

optio · January 10, 2026, 6:16pm

Try to temporarily disable ft for test to check if this is causing issues, no other ideas for now…

mdagen · January 12, 2026, 1:01am

Thanks. I tried disabling FT and unfortunately video is still freezing. I’ve also confirmed that the freezing is occuring simultaneously with ping timeouts as per above.

gotsprings · January 14, 2026, 1:49pm

Just to give @jaclaz the update…

3 days later the Ring at my house is off the X7-35x. Requires cutting the power to the Ring at the breaker. Then I can put back the cap AX, wAP AX, XV2-21X, XV2-2, XE3-4 and that will get it back online.

Sent the support file to Cambium and they actually have it at engineering now. But still 18 months I have had that thing and wouldn’t dare put it out in the field.

jaclaz · January 14, 2026, 2:29pm

What everytime surprises me is how these "leading" (and pricey) manufacturers (still) have issues with "common" devices, your Ring is not exactly a "rare" device, particularly in the US, nor - I believe - a particularly fast one (needing particularly high bandwitdh/resources).

No matter if the fault is on Cambium or on Amazon side, I simply cannot believe that your setup is extremely rare or never attempted before,

Even if most probably the large majority of Rings connect to el-cheapo consumer routers (just fine) they should work with enterprise level AP's without issues, and viceversa enterprise level AP's should be capable of keeping a connection to the Amazon Ring.

The rebooting or power cycling should never be needed on either.

gotsprings · January 15, 2026, 3:07am

Because the expensive stuff isn’t 100%… that’s why I expect the Mikrotik not to work. And it has never disappointed… Well I mean the performance disappoints constantly… cost us thousands when the AC units couldn’t do the job and MIKROTIK confirmed the issue was their radios in my enviornments.

My job revolves around chasing down the bugs before we deploy anything.

I can put a mikrotik router in and have it work for 10+ years, with little to no maintenance.

A Mikrotik Switch will lose 1 bank of ports for no good reason until rebooted. And they keep shipping that piece with a known flaw for 5 years. (CRS354 series)

The CRS328 and 326… I can put those in and forget about them for a few years. Before that… I have Ubnt Edge Switches that are probably around 15 years in the field at this point.

But with everything on the wireless… I spend a lot of time working on radios. And right now… Its Cambium or it’s Ruckus (WiFi6) if its on our bid sheets.