Meraki

Jeroenvdd

Hi everyone,

After several conversations with Microsoft support, our ISPs, and Meraki support, we’re still stuck — so I’m hoping someone here might have additional insights.

Environment

MX95 security appliance
3 × MS210-24P switches (stacked)
9 × MR44 access points

Wireless configuration

Two SSIDs:
- Internal network: DNS over VPN
- Guest network: Direct Internet with 8.8.8.8 DNS (Meraki DHCP for both)
5 GHz only
AP uplinks at full 1 Gbps / full duplex
RF profile: min Tx power 10 / max 19
Meraki dashboard reports 100/100 on RF metrics (no interference or channel overlap)

The problem

Screen sharing in Teams or WebEx from Wi-Fi clients is:

Grey/black screens
Severely delayed (10–15+ seconds)
Often unusable
- Guest network devices (no VPN, no filtering) → same screen-sharing issue

Meanwhile, wired clients have zero issues — instant screen rendering and smooth cursor movement.

What is working perfectly

Voice/video in calls
General Wi-Fi performance
Streaming 4K YouTube
Speed tests ~500 Mbps over Wi-Fi (latency 10–15 ms, sometimes up to ~45 ms)
Ping to Google averages ~10 ms with tight percentiles
Other company sites with identical hardware + configuration → no issues

RaphaelL

What firmware version are you using for all products ?

What is the SSID configuration look like ? Bridge mode , NAT ?

Are the issues with Teams only P2P calls or bridged calls also suffer ?

Have you taken any pcaps ? Teams video , screensharing is easy to see in a pcap.

Jeroenvdd

The latest stable on all products.
have upgraded the MR and MX to the beta and RC too but also no change

the guest network is Meraki AP assigned NAT

the data network is 'External DHCP server assigned' and bridged.

Teams calls themselve have no issues, as in voice or webcam.
Sharing content like screens is where the hiccups start going
(on wifi only)

Ryan_Miles

Do you have MR44s at other sites? If yes are they having the same issue?

Jeroenvdd

same switches, same mx, same mr's same setup = zero issues at other sites

Ryan_Miles

Have you tested with an AP connected to a different switch? Or the switch connected directly to the MX?

Have you tested with an AP connected directly to the MX to bypass the switch?

Is your switch stack functioning properly? Both stack ports are up on all switches in the stack?

PhilipDAth

Anything configured under Wireless traffic shaping?

Jeroenvdd

I've set this now as test:

RaphaelL

You can configure a port range.

Jeroenvdd

yeah wierd if i tipe a range it translates it to host 50040-500059 if is type port 50040-50059 it translates this to host port 50040-50059

but I've entered them one by one, shouldn't make a difference

PhilipDAth

Can you temporarily turn off "Shape traffic on this SSID" to either prove this is or is not the issue.

If it is the issue - how does it compare to other working sites?

Jeroenvdd

I've turned it of at every level in previous attempts to figure out what's going on, to no avail.
I've now done a 'pressure test' with multiple people doing speedtests to differing sources.

the speed is lowered, which doesn't bother me the only thing i do find really high is that download latency.
Then again it's content shared 'from this site' to others that is the problem so upload latency which isn't great but not to the extent..

PhilipDAth

This is a really long shot - I have had issues with MS12x and MS13x switches intermittently failing to resolve DNS (or taking a long time) on MS 17.2.x code.

You could try going back to 16.x, or jumping to 18.x.

This is listed in the 18.1.1 MS release notes - but it definitely affects more than just the MS130.