We have a wireless network, created from Meraki CW9164i APs (Current version: MR 30.6). It advertises three SSIDs: Corporate, Guest and IoT on 2.4 and 5GHz. We do not (yet) run 6GHz, though that is our intent in the near future.
In one area of the network, we want to be able to Miracast from a Corporate PC (Main network connection is RADIUS Authenticated by NPS) to a Samsung WM75B Wi-Di screen. The users first press "Windows-k", select the name of the screen and, when the screen connects, we have the choice of "duplicate", "extend" etc. for what we see on the Wi-Di screen.
This works fine for the first time of connection, but if the screen is disconnected and a reconnection attempt is made, the connection fails with no particular message, it just doesn't work. The screen name is shown in the Windows-k selection box, but selecting it does not result in connection or any response. It looks like the control plane is working (can see the name) but the data plane is failing.
We have found a workaround, which is to reboot (power-cycle) the Samsung WM75B screen, after which connection is once again possible, but this is highly suboptimal.
Investigation has shown that if the screen and PC are out of wireless range of the Meraki network, the connection/reconnection works as expected. Searching through this community revealed instances where Rogue suppression by Air Marshall were identified as a possible cause, so a whitelist was configured:
That did not change the behaviour.
The fact that the PC/Screen pair work flawlessly when remote from Meraki APs suggests strongly it is a Meraki issue, but I have been unable to resolve it with whitelist and don't see anything else in Air Marshall or elsewhere that may influence this.
Has anyone seen this kind of behaviour, or even better, resolved it?
Thanks
Roo
Sorry, I guess I didn't explain it too well....what you described above is what would happen if the PC and the screen both connected to the AP, but thats not how it works in this case. What I have is a PC Wireless NIC that is connecting to an AP, then being shared so it associates with the AP AND the screen. The screen broadcasts an SSID ("DIRECT-") which the PC NIC associates with using a virtual adapter (shown below as direct virtual adapter #4) that is only present after Miracast has been initiated.
so the VLANs and so forth are not involved.
I stand by my previous statement that the Samsung Flip isnt Miracast certified and neither is the Intel AX201. Since neithe rof your devices are miracast certified you are likely going to be stuck in driver hell with both OEMS.
For internet content to be displayed on a Miracast-connected device, the source device needs to be already connected to the internet and stream the content directly to the Miracast receiver
