Skip to main content

32 Messages

 • 

590 Points

Thu, Sep 19, 2019 7:17 PM

Answered

Microsoft Surface, just not compatible with Ruckus?

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?

Responses

232 Messages

 • 

4K Points

a year ago

 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!

3 Messages

 • 

120 Points

Turning off:

Fast BSS Transition:
Enable 802.11r FT Roaming

For the SSID resolves the issue.  

232 Messages

 • 

4K Points

Very True. In our company, roaming is VERY important. So it was better for us to remediate the client.

32 Messages

 • 

590 Points

a year ago

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...

232 Messages

 • 

4K Points

a year ago

 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.

32 Messages

 • 

590 Points

a year ago

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!

232 Messages

 • 

4K Points

a year ago

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! 

32 Messages

 • 

590 Points

a year ago

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.

232 Messages

 • 

4K Points

a year ago

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!

232 Messages

 • 

4K Points

a year ago

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.

60 Messages

 • 

1.1K Points

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?

3 Messages

 • 

120 Points

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.  

60 Messages

 • 

1.1K Points

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#

4 Messages

 • 

134 Points

Can anyone confirm which version of this driver works correctly?

Employee

 • 

604 Messages

 • 

10K Points

a year ago

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

Regards,

Syamantak Omer

1 Message

 • 

60 Points

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.

232 Messages

 • 

4K Points

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 


1 Message

 • 

60 Points

a year ago

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.

232 Messages

 • 

4K Points

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)

32 Messages

 • 

590 Points

a year ago

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).