WLC 9800-L version 17.12.4 and Microsoft surface connectivity issue

[adamscottmaster2013]

Hi,

I successfully migrated from Cisco Airwave OS to 9800-L IOS versoin 17.12.4, and everything is working fine with the exception of the Microsoft surface pro.  All of my PCs (windows 10) and Apple Iphone devices are working great and they are using protocol 11ax(5), but the Microsoft Surface pro is connecting using 11ac.  I've already updated the driver on these microsoft surface to the latest Intel 23.140.0 (latest) but I am still having issues.  The surface receives an IP address but that's about it.  When I move the AP back to the old Airwave, it is working again.  Does it mean in the NIC settings on the MS surface, I need to set the 802.11ac to 802.11?

Anyone running into this issue before?  TIA

[adamscottmaster2013]

This is the bug ID:  https://bst.cloudapps.cisco.com/bugsearch/bug/CSCwo92511

Confirmed by Cisco TAC that it affects version 17.9.5 through 17.17.1.  Last updated 08/04/2025 which is today.

[Mark Elsen]

  - @adamscottmaster2013     Does the Workaround help ?

  M.

[adamscottmaster2013]

---

@Mark Elsen wrote:

  - @adamscottmaster2013     Does the Workaround help ?

  M.

---

Hi @Mark Elsen, Yes.... BUT this is still an issue with UDP traffics, and confirmed by Cisco.  TCP MSS only applies to TCP traffics.

If you want to fix this issue with both TCP and UDP traffics, it is best to change the MTU on the client side to 1200.  That being said, not everyone has admin access to the endpoint to make this change.  

[Mark Elsen]

  - @adamscottmaster2013               Ok, good to know.

  M.

[Rich R]

Thanks for the update @adamscottmaster2013 

Note that this bug is specific to foreign/anchor mobility scenario - a key point which is why you have seen this problem but nobody else here has.  This is somethng you should have mentioned in your description of the problem.

Also note that the bug is open since April 2025 with only one customer case attached so you might want to check that your TAC engineer has attached your case to the bug.   This confirms that the unique circumstances of this setup are not encountered by many other customers as per your original question ("Anyone running into this issue before?") - it seems only 1 other customer has reported the issue to TAC before you!

Regarding UDP - even if you set your clients' MTU that won't help the server side which is always likely to be 1500 (and you can't expect to control guest WiFi client devices), so the only way around this is path MTU discovery (which is almost universally blocked on the internet these days) or other higher layer mechanisms otherwise you'll be reliant on IP fragmentation happening in the right places (which I suspect is not happening). QUIC is supposed to fall back to TCP if the initial fully padded negotiation fails (due to path MTU limits).

[adamscottmaster2013]

---

@Rich R:  What makes you think that there is only TAC case before me?  I spoke at length with the TAC engineer, and there are several tickets open for this.  

[Rich R]

It's not what I think it's what the bug search tool shows currently:

Only 1 case is attached to the bug.  It's pretty common for TAC engineers these days to forget to attach a case to a bug even when they have quoted the bug as a root cause.  When you view the CASE SUMMARY it should show under Related Bugs. If it doesn't then the case has not been linked to the bug.

[adamscottmaster2013]

---

@Rich R wrote:Only 1 case is attached to the bug.  It's pretty common for TAC engineers these days to forget to attach a case to a bug even when they have quoted the bug as a root cause. 

---

 That's the issue.