Microsoft Surface, just not compatible with Ruckus?

  • 2
  • Question
  • Updated 6 days ago
  • Answered
Seeing this at three different locations - customers show up with an MS Surface device and they simply cannot log in. No interesting logs in the ZD, I'll see one log of "too many authentication failures" and then even hours or days later ZERO logs for the client. And on the client side, this incredibly unhelpful error:



All the networks shown there are served from the same APs.

We even see this on clients running Unleashed setups.

How is there not a KB article about this?
Photo of Charles Sprickman

Charles Sprickman

  • 31 Posts
  • 10 Reply Likes
  • like checking out aruba

Posted 3 months ago

  • 2
Photo of Andrew Giancola

Andrew Giancola

  • 121 Posts
  • 40 Reply Likes
 This isn't a Ruckus specific issue. BUT it might be an issue specific to your WLAN design.
Do you have the driver versions on that Surface? I'll bet it's Roaming/Neighbor K/802.11r incompatibility. I would create a testing SSID with as simple a WLAN setting as you can create, try seeing if your device still won't connect.
We have a sizable population of SP's which failed to connect to our networks post latest windows firmware updates.
Hope that helps!
(Edited)
Photo of Mathew sutton

Mathew sutton

  • 3 Posts
  • 2 Reply Likes
Turning off:

Fast BSS Transition:
Enable 802.11r FT Roaming

For the SSID resolves the issue.  
Photo of Andrew Giancola

Andrew Giancola

  • 121 Posts
  • 40 Reply Likes
Very True. In our company, roaming is VERY important. So it was better for us to remediate the client.
Photo of Charles Sprickman

Charles Sprickman

  • 31 Posts
  • 10 Reply Likes
Holy crap, does MS not support 802.11r and k?

That would suck, as this co-working space has people that are super picky about being able to run softphone voip, facetime, skype, and other random stuff while wandering around the office, and I thought all the roaming assistance stuff was a net positive for that kind of usage...
Photo of Andrew Giancola

Andrew Giancola

  • 121 Posts
  • 40 Reply Likes
 I did our companies initial analysis via Wireshark (because the rejection happens on the client's end, without attempting to authenticate to the network, hence no logs), and found that the devices were essentially saying we support R but only part of it. so I simply removed roaming from the sites with affected clients and asked for Local IT to remediate by Rolling drivers back. I spoke to one of them a few minutes ago, and he said " uninstall the wireless NIC, delete the driver when it prompts me to, then reboot. Works after that."
I do not recall putting R back on the SSID's his SP's are on, so his guidance may or may not be flawed.
(Edited)
Photo of Charles Sprickman

Charles Sprickman

  • 31 Posts
  • 10 Reply Likes
OK, this is very helpful. Going to try the config changes. I'm about 90% sure the onsite tech already removed the device and re-added. We don't like touching client devices too much, so we didn't have the option to sniff with wireshark, but glad you did!
Photo of Andrew Giancola

Andrew Giancola

  • 121 Posts
  • 40 Reply Likes
You can grab Wireshark directly from the AP. 
  • Log in to the AP
  • run command 'get wlanlist'
  • id your WLAN number (in my case it's wlan33)
  • run command 'set capture wlan33 stream' remember, your WLAN may be different. using a copy of Wireshark, or favorite equivalent
  • open interfaces, remote interfaces, hit the plus or 'add'
  • type in the IP of the target AP, the port is 2002 (globe)
  • a list of new interfaces will appear, select wlan33 and leave out everything else for the moment.
  • Hit start.
  • Profit! 
(Edited)
Photo of Charles Sprickman

Charles Sprickman

  • 31 Posts
  • 10 Reply Likes
Wow. OK, I didn't even know there was a CLI available on the individual APs.  So yeah. :)

A few quick questions if you'll indulge me:

  • you noted that there were no logs of the Surface because it had given up attempting to auth to an "incompatible" network - just confirming in this case the sniffing at the AP would NOT give me the info I need, correct?
  • in the above example, the "set capture ..." command is telling the AP to open a socket (which defaults to 2002) and it's dumping a tcpdump-like stream to whatever connects to that socket?
  • this is a good argument for a testing WLAN that's turned on for just this sort of troubleshooting I suppose
I need to get someone to drop a raspberry pi or something at these sites so I have a remote "base of operations" for something like this.
Photo of Andrew Giancola

Andrew Giancola

  • 121 Posts
  • 40 Reply Likes
you noted that there were no logs of the Surface because it had given up attempting to auth to an "incompatible" network - just confirming in this case the sniffing at the AP would NOT give me the info I need, correct?

Incorrect. in the following screencap, you can see the Wlan.addr filter used to specify the mac address of an android mule used primarily to test cloud path onboarding.  The SONY is not connected to this R610 in any way, instead, it's attached to my personally owned R500.


in the above example, the "set capture ..." command is telling the AP to open a socket (which defaults to 2002) and it's dumping a tcpdump-like stream to whatever connects to that socket?
yes, Here is a screencap of my Mule AP's remote interfaces after running the set capture command.



this is a good argument for a testing WLAN that's turned on for just this sort of troubleshooting I suppose

Yes, everyone makes mistakes, even M$oft. And when it does happen, it's always a doozie.

Depending on your load, PI might be a touch lightweight for any REAL diagnostic. In my experience (PI3 B +) Drive write times leave too much to be desired, and as such make poor IPERF servers. as for tcpdump, my setup only seems to be only able to do about 25-30mb/s before losing packets. That said, there is a new PI4 out with PoE. as soon as the USB-C stuff is fixed on the boards, I plan to restart my Pi projects with that platform (4gb for the win!)

Good luck with Aruba!
(Edited)
Photo of Andrew Giancola

Andrew Giancola

  • 121 Posts
  • 40 Reply Likes
Just wanted to update and say we have an executive who's unable to access the network this morning due to his Surface Pro updating last night at home.

We've ripped and replaced the Marvel Star driver and the unit is back online.
Photo of Bway NOC

Bway NOC

  • 42 Posts
  • 10 Reply Likes
Hi Andrew,

Can you elaborate as to what you mean by "ripped" and replaced the Marvell driver? Di you just uninstall and reinstalled the driver or did you replaced the Marvell Chipset?
Photo of Mathew sutton

Mathew sutton

  • 3 Posts
  • 2 Reply Likes
Quickest way is to go to Device Manager, Network, Select the Rollback option on the Marvel driver and reboot.  WIFI will work as soon as it restarts.  
Photo of Bway NOC

Bway NOC

  • 42 Posts
  • 10 Reply Likes
Does this roll it back to the Marvell Win 8 Drivers? Which seems to be the last update they had for their Marvell Drivers.
https://www.marvell.com/support/downloads/search.do#

Photo of Michael Mogren

Michael Mogren

  • 1 Post
  • 0 Reply Likes
Can anyone confirm which version of this driver works correctly?
Photo of Syamantak Omer

Syamantak Omer, Employee

  • 20 Posts
  • 2 Reply Likes
Hi All,

It is a known issue with Surface pro WiFi driver running 15.68.17013.110

Ruckus already documented this in below KBA, please refer the same.

https://support.ruckuswireless.com/articles/000009828
Photo of Zach Smith

Zach Smith

  • 1 Post
  • 0 Reply Likes
I tried to access this link, There seems to be an issue with the page. I get the following error when trying to access. Is there an ETA on when this will be resolved? I would really like to see the release from Ruckus on this.

Photo of Andrew Giancola

Andrew Giancola

  • 115 Posts
  • 38 Reply Likes
The heart of the Issue isn't Ruckus' to resolve. the issue presents its self on Meraki Wi-Fi  too. 
Here is the URL listed at the bottom of the KB.
https://answers.microsoft.com/en-us/surface/forum/surfbook-surfnetwork/marvell-semiconductor-inc-net-156817013110-wifi/033b3613-135e-430a-952f-46440c764f58 


(Edited)
Photo of Thorsten Behrens

Thorsten Behrens

  • 1 Post
  • 0 Reply Likes
That support link won't load as of 12/4/2019.
Tested on my Surface Pro 5: 15.68.17015.112 fixes it; 15.68.17015.110 broke it.
Photo of Andrew Giancola

Andrew Giancola

  • 116 Posts
  • 38 Reply Likes
Yup, that's exactly what Microsoft said in their advisory. 
Marvell Semiconductor, Inc. – Net – 15.68.17013.110 WiFi driver breaks 5GHz connection on the Surface Book (1st Gen i5 with dGPU 256 GB)
Photo of Charles Sprickman

Charles Sprickman

  • 31 Posts
  • 10 Reply Likes
That Ruckus error is misleading, it really just means you're not logged-in (or not logged-in with an account with privileges to see the KB entry).