Wireless Access

Hi All,

 

We are experiencing “random” disconnection issues with some of our users who have Surface Book and Surface Pro devices.

 

When the issue occurs the clients will lose *all* network connectivity yet still stay “connected” to the IAP. The issue will correct itself after a certain amount of time.

 

While in this “connected- not connected” state the client can successfully ping the loopback address, however, cannot ping the gateway/router address or any other servers etc. The client cannot access any network drives, printing, the internet, etc.

 

These issues first occurred after we have replaced our wireless infrastructure with IAP-315's and IAP-325's approximately two months ago.

 

We did not experience this issue using the HP Procurve equipment.

 

We have over 1100 devices connected at any time during the day concurrently across 80+ IAPs, where 98% of these all use the Intel 7260 AC wireless network card. None of these Intel-based clients display the issue. My thoughts would be that this confirms that there is nothing wrong with our wireless infrastructure.

 

We have tried turning off 802.11r, 802.11k, 802.11v, 802.11x (temp SSID that used shared WPA2), client match, turned on/off airtime fairness, turned off UPSAD on the main SSID via the IAP cli, tried enabling further power settings for the Microsoft device to manually force the wireless power settings to “maximum”.

 

IAP’s are currently running the latest build 6.5.4.0 (2017-08-04 22:04:48 UTC (build 60834))

 

About the client:

• Six Surface Book (2015) and three Surface Pro 4 devices which all exhibit the issue
• Devices have been in use for almost six months as part of a trial
• Clients are using Windows 10 64-bit, 1703, build. 15063.483
• Client is using latest Surface driver for network card (15.68.9112.23)
• Clients are can be connected to the same radio, where the client device never leaves the desk.

 

During the issue:

• Clients will lose network connectivity but never drop the actual wireless connection once issued occurred (windows still has the wireless connection active/connected state)
• Clients could still ping loopback address successfully
• Clients could *not* ping any other IP addresses on network
• Clients can *not* connect to network drives
• Confirm that the local IAP via the CLI sh clients -> lists the user device as still being "connected" to the local IAP where the client displays the issue.
• Cannot ping the client from the local IAP CLI

 

 

As a workaround:

• To reconnect back to the LAN client had to be placed in “airplane” mode to manually disconnect/disable the wireless connection to force a reconnection or restart device. Both of these workarounds are extremely disruptive.
• Once reconnected client entered a “connected” state on the *same* radio and can again browse network drives, check email, internet access etc

 

Cheers,

Aaron

 

 

Thank you.

 

Please keep us up to date on any TAC findings from Aruba or Microsoft, so that others can learn from this.

yes very much interested in learning more a bout this issue


#AirheadsMobile

yes very much interested in learning more a bout this issue


#AirheadsMobile

Does disabling scanning under RF options helps by any chance ?

Hi Nitesh,

 

Confirming that disabling scanning under RF as per your suggestion does not resolve the issue.

 

Thanks,

Aaron

Hi Aaron,

 

Interesting thread, we're also in a similar position whereby we've been experiencing random disconnects for Surface devices, in order to resolve on the client we have to disable and enable the wifi connection, the device then instantly reconnects. We have a mixture of client devices; Windows 7 and 10 HP laptops that dont seem to experience any issues, MACs which again are solid once they're connected, it's just our Surface Book and Pro devices that are giving us the headaches.

 

We obtained some slightly newer drivers from Microsoft, 15.68.9114.29, which we have rolled out on to some machines, but unfortunately we're still seeing issues on those devices.

 

From a wireless perspective we have 325 APs, with the SSID in question only running 802.11a. On the back-end we have 7210 controllers running 6.4.4.11 managing the APs.

 

On the controllers we have made the following changes so far:

Enable 'Drop Broadcast and Unknown Multicast
Disable 80Mhz and VHT Throughout enable
Wireless Multimedia U-APSD (WMM-UAPSD) Powersave Diasbled
802.11a VHT Enable - Disabled

 

Whilst this has had a noticeable improvement for us, we are still seeing the disconnects. Be interested in seeing the feedback on this thread to see others experiences.

Hi danderson79,

 

As we are using a mix of Surface Book and Surface Pro 4 devices, we also have deployed 15.68.9114.29 to our Surface Pro 4 devices with no success regarding the disconnection issue.

 

Version 15.68.9112.23, is the latest available for the Surface Book from Microsoft.

 

Have you opened a support ticket with Microsoft and the Aruba TAC?

 

Thanks,

 

Aaron

 

 

My main aim with the drivers was to try and get a consistent Version in use across our buildings, we probably have about 3 or 4 different version in use, which wasn't helping us with troubleshooting.

 

We have a ticket open with Aruba, and I'm also in the process of opening up a new ticket with Microsoft in order to try and pull some more client side data when the drops occur.

 

We have some user debugs enabled on the controllers, but they're not giving us all that much information at the moment.

Latest feedback I've had from TAC is to disable the following within the the High-throughput profile within the SSID in question

 

no 40MHz-enable
no very-high-throughput-enable
no high-throughput-enable

 

I think I understand the reason for the 1st and 2nd option, but the 3rd option seems like quite a significant backward step. Would this be a normal step for troubleshooting the issues we're seeing?

---

@AaronIt84 wrote:

During the issue:

• Clients will lose network connectivity but never drop the actual wireless connection once issued occurred (windows still has the wireless connection active/connected state)
• Clients could still ping loopback address successfully
• Clients could *not* ping any other IP addresses on network

 

---

Aaron,

 

Bizarre question - but if you ping the default gateway or another IP Address from one of the affected clients during the issue - do you see any of those pings/packets via show datapath session table or packet-capture? I ran into a very bizarre issue last week where an older Windows 10 (Version 1703) netbook was connected, could ping the loopback address, but couldn't reach anything else from the client's perspective.

During the datapath session/packet capture - I could see my affected clients pings reaching my wired computer, my wired computer responding, and those packets being sent to the netbook. (I wasn't able to do a packet-capture on the netbook at the time due to lack of admin rights). The issue resolve itself once I roamed to another Access Point. Extremely unusual behavior.

 

I have read multiple reports of multiple symptoms, some reporting a solution or improvement with various steps

- driver updates

- disable power saving on the device

 

Focusing on symptoms where the device loses association, sometimes re-associates, and sometimes not.  if one does not look carefully, one might not notice the device actually disconnected from the AP.

 

From the symptoms reported by a large number of users, in multiple threads and other forums, would be interesting to know the following:

 

Assumptions:

the Surface Pro has the latest drivers.

The surface Pro has power saving disabled, or this has been eliminated as a possible cause.

 

when user-debug is enabled for the Surface Pro device, do we see the client send a DEAUTH ?

 

Does disabling VHT and HT solve the issue ? If yes, we're on the right thread.

 

If you have 6.5.4.0 running, look at the ht-ssid-profile and disable RX-AMPDU (new parameter added in 6.5.4.0)

 

Very curious to know the results.

 

Thanks

 

 

 

 

Hi Shawn,

 

Through the TAC ticket that we raised previously, TAC/Engineering team have told us to disable RX-AMPDU for the SSID as a possible workaround.

 

I can confirm that this week we have had no reports from our Surface device pilot users regarding wireless disconnections.

 

Tentatively, I think it may be safe to assume the “workaround” has been successful although I will still be monitoring this issue to confirm and report back.

 

For anyone else who wants to test:

From the virtual controller, use putty to connect and then run the below for each SSID:

 

IAP(config) # wlan ssid-profile test

IAP(SSID Profile "test") # rx-ampdu-agg-disable 

IAP (SSID Profile "test") # exit

IAP (config) # exit

IAP# commit apply 

committing configuration...

configuration committed.

 

Cheers,

 

Aaron

 

 

Hi All,

 

In addition to Aaron's comment, the rx-ampdu can be disabled only

from 6.5.4.x IAP releases.

We are also facing the same issue with Surface Pro here at Viacom18 India. It would be great if some valable next steps are shared here for us to act upon.

 

Thanks,

Sajesh

I believe an issue has been identified.  Watch this space and I will post in this thread when the fix is in a production build.

 

Thanks for the update - I wasn't aware a fix was in flight within Aruba. I'm assuming this will be released as part of a code upgrade for the WLCs?

If it is a fix, yes it would.

 

 

Hi, danderson79 & sajesh_s,

 

Were you able to try the workaround I posted previously?

 

We have had success with this at our site after turning off this feature on our IAPs.

 

Cheers,

Aaron

We hit a similar issue in an environment with 7220 controller running 6.4.4.15 and AP325.

 

It seems that rx-ampdu-agg-disable is for IAP. Is there any similar workaround for our environment?

 

@Colin - you mentioned that the fix is in flight, does it include AOS 6.4 series?

All AOS with AP3xx should be affected by this particular issue.

rx-ampdu config parameter exists in AOS 6.5.4.x only, there is no other
workaround.


The fix will be propogated to all currently supported AOS versions 6.4,
6.5, 8.x







--




*SHAWN ADAMS*
*PRINCIPAL NETWORK ENGINEER |**ACMP/ACCP/CWNA | **CEUR**
*T: +49 (0) 151 1265 4997 | M: +49 (0) 151 1265 4997
Baumschulenallee 21-22 | 30625 Hannover - GERMANY
*ARUBA NETWORKS****www.arubanetworks.com*

Thanks Shawn - any ETA?

I will update this thread as soon as we have exact target release and dates.



--




*SHAWN ADAMS*
*PRINCIPAL NETWORK ENGINEER |**ACMP/ACCP/CWNA | **CEUR**
*T: +49 (0) 151 1265 4997 | M: +49 (0) 151 1265 4997
Baumschulenallee 21-22 | 30625 Hannover - GERMANY
*ARUBA NETWORKS****www.arubanetworks.com*

Thanks for the feedback Shawn. 

I (sort of) apologize for the cross post. I have what appears to be a very similar, if not identical issue with iPad4's. I did create a new post (Link) but noticed this command does not seem to work in a controller environment (v6.5.3.2). Either I got the syntax wrong, or it's only for IAP.

 

Any further advice?

All,

 

I have been told that Aruba TAC has published a fix for this issue Bug ID 157287.

 

New firmware was released this week - upgrade to version: 6.5.3.3 or 6.5.4.2

 

Thanks all for the help and suggestions along the way :)

 

Cheers,

 

Aaron

 

Will it be available in 6.4x? I just checked the release note of 6.4.4.16 and can't find this bug fix.

I'm told it's fixed in 6.4.4.16, but as yet, the release notes haven't been updated with the bug fix information.

Any customers apply the bug fix and see this issue go away?

 

We're running 6.5.4.2 and not quite sure that some of our users aren't reporting the same problem.

We upgraded from 6.4.4.11 to 6.4.4.16 last night. We've been experiencing the Surface drops on quite a few devices - Will report back in a few days once we've had time to verify client behaviour.

Sorry, the patch did not make 6.5.4.2. It is in 6.5.4.3.

Sorry I retract my previous post. Looks like this fix did make 6.5.4.2. My mistake.

Please bear in mind, this fix is for one specific issue that might occur in conjunction with Surface Pro devices.

It seems unlikely that the bug is purely surface-specific, based on our troubleshooting and a few other customers reporting similar problems.

---

@philliplyle wrote:
That seems unlikely, based on our troubleshooting and a few other customers reporting similar problems.

---

The fix in the release notes above is a "narrow" fix, in narrow circumstances.  If everyone would post their TAC case numbers in this thread, we can start defining problems and sorting them into their proper buckets.

Hi Guys,

 

I can confirm that after two weeks running with the new firmware and disabling the workaround, that this issue has been resolved for our site.

 

We have around 50+ Surface Books running happily on our wireless with no disconnection issues.

 

Cheers,

 

Aaron 

---

@philliplyle wrote:
That seems unlikely, based on our troubleshooting and a few other customers reporting similar problems.

---

philliplyle,

 

Please clarify what you are seeing, because this thread is about surface disconnection issues.  If it is about something different, or additional, let's open up another thread so that it can get the attention it deserves.

TAC case #5322484848

 

The exact same symptoms as the OP.   The bug fix release notes don't specifically reference that this is a surface only problem/fix.  We have a much larger environment, and have seem a client mix exhibit the described behavior (Mac, iPhone, Android, Windows), where they remain associated but don't pass traffic for a period of time to a particular AP.   Our senior TAC engineer seemed to think it was applicable.  

 

It's still possible it may have also solved our problem, but it's just harder for us to tell  quickly with 8500 concurrent devices connected, as reports don't always make their way back in a timely fashion.  I'm glad the OP at least has reported an improvement, as it gives us hope.  

Okay.

 

Then it is not a surface-specific issue, then.  It is something larger.

I'm not seeig confirmation from the field that the fix actually had a positive impact on the issue.  Maybe no news is good news???  We are currently experiencing similar issues to those articulated, however we are a mixed environment of sites with Cisco Autonomous APs and Aruba 315's.  We had been getting reports from both types of sites, but have been focused on resolving the Aruba sites.  We recently upgraded to 6.5.4.2, but I haven't heard from my users either to see if this has resolved the issue.  I'm circling back around to them now.  We use Surface Pro4's as our primary workstation.

I have just been reading this thread, it's now 1 month since last post.  I have noticed the same issue in our wireless network.  I have upgrade our IAPs to 6.5.4.3 but I cannot apply the "disable RX-AMPDU" line to the CLI as our IAPs are manged with Airwave.  I have not been able to see a place in Airwave to set this parameter.

 

Anyone got any ideas?  Is the a way to enter CLI commands and push them out via Airwave.  Do I still need to enter these commands to get the fix?

 

IAP(config) # wlan ssid-profile test

IAP(SSID Profile "test") # rx-ampdu-agg-disable

IAP (SSID Profile "test") # exit

IAP (config) # exit

IAP# commit apply

Hi Remsat - I cant give any feedback on the issues you're experiencing with regards making the IAP update.

 

With regards an update on the original case, we originally upgraded our controllers from 6.4.4.11 to 6.4.4.16 to try and resolve the connectivity drops with Surface devices. We are unfortunately still seeing drops for client Surface Pro/Book devices. We have an ongoing case with Aruba TAC to try and resolve.

I have reports of several Microsoft Surface with Marvell Avastar AC chipsets.

 

Currently my environment is running 6.5.3.4, previously 6.5.3.3 (a few weeks ago). The issue persists. 

 

Is there any confirmation that the issue is resolved 6.5.4.3 track?

 

Thanks.

What are the exact symptoms seen with 6.5.3.4 in production ?

 

6.4.4.17 and 6.5.4.2 contained a fix for a every specific condition that is likely to affect Surface devices. We have several confirmations that this has alleviated the symptoms as expected.

 

6.5.3.4 contains several additional MPDU related fixes that could affect surface devices. We have 2 reports of these fixes

having alleviated problems reported to have affected surface devices.

 

Client driver versions play a critical role here.

 

I'd suggest opening  a TAC case to pursue detailed troubleshooting.

 

 

Shawn,

 

Thank you for the quick response. 

 

So far the reports are from Microsoft Surface devices (Pro, Laptop, Pro 4, Surface Book) with the Marvell Avastar Wireless-AC chipsets. 

Previously we ran code version 6.5.3.3. The update was performed late December 2017 to 6.5.3.4.

 

However, there are still complaints for the surface. 

 

Based on your comments this was fixed in 6.5.3.4 or there were 2 reports of issues? 

 

Thanks

 

Hi Shawn,

 

Quick question on the Marvell AC driver - Which version have Aruba found the most stable during the investigative work that you've been doing on the Surface connectivity issues?

 

Thanks,

 

Dan

Separately, although it may or may not help you, we've heard there's another release coming in the next week or two (delayed, apparently) that is supposed to address some remaining stability issues we've been seeing (6.5.4.5).  Not sure if it will help you specifically, but you may want to wait and see what's in the release.

 

@philliplyle are you referring to device stability issues on other devices beside the Surface Pro or specifically the Surface Pro models?

---

wrote:

Separately, although it may or may not help you, we've heard there's another release coming in the next week or two (delayed, apparently) that is supposed to address some remaining stability issues we've been seeing (6.5.4.5).  Not sure if it will help you specifically, but you may want to wait and see what's in the release.

 

---

 

@ab_Unet -

 

How can you differentiate an issue with a surface versus non-surface specific items?  I don't have a homogenous environment, so it's not possible to know when a Surface user has an issue, it's because of this bug or that bug, when the symptoms are similar.

 

I'm also skeptical that this was a Surface-only issue.   Is the wireless chipset in the Surface so unique that the bugs would only be recreated on that platform?  Seems unlikely, given the huge variety of devices available on the market.

 

What I do know, is that we had a long-running problem with similar symptoms across a lot of device platforms, and supposedly the final fixes are coming this week.  We will see.

 

For us, we have 3 fairly unique sets of devices connecting to our wireless network; MACs, HP Elitebook laptops and Surface Pro/Books.

 

From Day One (go live was mid 2017) the MACs have been solid and given us no issues with disconnects. Early on we had an issue with a few HP devices (5 at most), but most of those impacted were running quite old device drivers (2014), a driver upgrade resolved those issues.

 

Over that time, its the Surface devices (all running the Marvell AC Wireless card) which have given us the issues with the random disconnects. We have tried a multitude of device driver versions, along with controller changes to try and resolve their connectivity issues, but to no avail so far. I'll be quite the happy boy if the new releases resolve our Surface issues.

Hi Philliplyle,

 

If you looked at my original post (first one) - you would see the below key information when I was describing the issue.

  

"These issues first occurred after we have replaced our wireless infrastructure with IAP-315's and IAP-325's approximately two months ago.

 

We did not experience this issue using the HP Procurve equipment.

 

We have over 1100 devices connected at any time during the day concurrently across 80+ IAPs, where 98% of these all use the Intel 7260 AC wireless network card. None of these Intel-based clients display the issue. My thoughts would be that this confirms that there is nothing wrong with our wireless infrastructure."

 

In summary, the issue was identified by a level 3 TAC engineer and a firmware developer who works on the IAP code, we then implemented a workaround by disabling the RX-AMPDU feature (needs to be done from the IAP "controller" for the SSID) and it was resolved in a later update which was 6.5.4.2.

 

We ran this firmware for two weeks with the RX-ampdu feature turned back on, then I reported back that this is confirmed as a solution which is why it was marked as such for the IAP issue that affects IAP-315/IAP-325 models.

 

We were running about 60 SurfaceBook (1st Gen) and 1150 Dell, 100 HP laptops in that same testing period.

 

My suggestion would be to upgrade to the latest version of Windows, ensure all the Surface firmware + driver packs are installed, set up a device in the office, disable any power setting policies (MS recommend that you do not use GPO to manage power settings/plans on Surface devices), plug into power and then fire up a ping test to see if it drops out.

Once it drops out - do a loopback ping test to verify that the TCP/IP stack is still ok, then use another computer to ping the local IP of the IAP its attached too.

 

Then open a TAC case. :)

 

Cheers,

 

Aaron

 

 

 

You might be responding to the wrong person, Aaron.  I'm simply informing those who may have had issues that additional fixes are coming soon.  Separately, I noticed that it was never clarified what exactly was the issue with the Surface that made it unique from every other device.  Is the Marvel chipset only found on the Surface?   I have about 100 different device manufacturers on my 1500+ AP deployment, so it's a bit different situation.   And yes, we've already worked with TAC on this, and had their ACE team onsite, and they thought the same Surface fixes would help with our other issues.

 

In any case, I expect the 6.4.5.5 release to  have some specific hardware fixes for the AP-315 and AP-325 line specifically, which may or may not fix issues that cause similar symptoms.  Some were talking about version releases and still having issues, so I'm simply letting everyone know to be on the lookout for the next release.  Things have gotten a lot better with the 6.5.4.2-4 releases for us, but we're hoping the next one will contain the final batch of fixes.

 

 

@phil

 

I had also opened a support case with Microsoft which wasn't too helpful.

 

This isn't an official explanation. But From what I understand, the MS driver or combo of the Marvel chipset they use + the MS implemented driver was doing something it "shouldn't do", which normally doesn't affect wireless vendors... however, the Aruba APs were also not "ignoring" whatever the issue was from the MS surface devices. Turning off that RX feature was telling the Aruba APs to ignore the SB devices essentially. 

 

I would try to replicate the same test setup as I mentioned before to verify this is the same issue I originally started this post with... just to make sure its the same one.

 

I have also read some issues with random disconnects in Windows 1703/1709 builds due to Windows patch updates... might not be relevant but deff something I considered when investigating the issue.

 

Cheers,

Aaron

 

The 6.5.4.5 release came out..over 56 described bug fixes and even more internal cases.  Something for everyone, it seems.

Has any group been able to upgrade firmware to 6.5.4.5. And has it resolved your respective bugs / issues?

 

I would like to gather feedback.

 

Thanks.

The question is. Where do we find the v6.5.4.5?

Thanks

@ab_Unet We're planning to upgrade our controllers on Tuesday evening of next week. We're going to 6.5.4.5, I think we'll know in a couple of days whether the upgrade has resolved our Surface issues. Will feed back accordingly.

 

@mathla That Aruba OS is available via the normal methods - support.arubanetwork.com - In the Downloads sections.

Can you please confirm the results of the upgrade for the group ?

 

Thanks !

 

As detailed in an earlier post, we've upgraded our environment; 7210 and 7030 controllers managing 325 APs, from 6.4.4.16 to 6.5.4.5 in early March on the back of recommendations from Aruba TAC.

 

We're happy to report that following the upgrades, we've had no reports of any disconnects from our user population who are running with Surface devices. We've had about 5 users who we've been working closely with, and none have reported any issues since the upgrade.

 

Thanks to everyone for their input within this thread.

https://support.arubanetworks.com/DownloadSoftware/tabid/75/DMXModule/510/EntryId/29020/Default.aspx

 

You need to have account in aruba support site

We upgraded on Wednesday and have no reported issues thus far. The upgrade went well.

I think things were much improved with 6.5.4.4 but this one hopefully squashes bugs for good. In particular we were having some AP crashes described in the notes. There are also bug fixes related to clients not being able to pass traffic which would mirror the symptoms of the surface issue.

Are these fixes in 6.4.4.17 as well? 

@danderson79 @philliplyle Thanks.

 

We are planning for next Tuesday. Also noted the release notes were updated on March 2nd.

I appear to be experiencing this exact issue with 6.4.4.17.  It only happens when on 5ghz, if I force the client in the driver settings to use 2.4 it works fine.  It will affect both of my surface pro 3s at the same time, then just disapear a day later.  Not sure what causes that.  Client associates and won't pass any traffic - yellow bang on adapter.

 

** update **

 

I found drivers from August:  DriverVer = 08/24/2017,15.68.9120.47

I installed this version on 2 surface pro 3s and the problem went away... for now.  Hopefully that's the fix. 

I thought I'd resurrect this post - as I'm seeing this issue with a client who is using the latest Microsoft SurfaceBook Pro (Marvell Avastar AC) with Aruba IAP515.

 

The client is seeing very poor performance in streaming applications to their projector using AirTame. On other devices (tested with Macbook, MBP, Lenovo Yoga X1) and they're buttery smooth. On the Microsoft device, we often lose video performance and lose audio altogether.

 

In a promiscious packet capture, we're seeing repeated block acks for the same sequence number... 

In one of the packet captures, we had 524ms there’s just block ack requests from the Surface Book 2 for SSN 1319, and block acks for SSN 1319 from the Aruba 515 ( see screenshot below)

 

Also, we have experienced wireless performance decline :

• Surface with Aruba APs
• For some reason, APs send BAs with Block Ack Bitmap all zeroed against BARs and Data Frames received from Surface.

This thread was opened more than two years ago and there have not been replies for a year before yours.  Many things have changed and you are using an 802.11ax access point, which is different from the OP that first opened this thread.  Please open a separate thread with your specifics, and open a TAC case in parallel.

 

---Closing this thread

Hi,

 

When you said "We did not experience this issue using the HP Procurve equipment." it rings a bell to me as SurfacePro wifi is using Marvell chipset.

 

I remember long time ago Marvell chipset had issue with transmitting LDPC frame, even at very low phy rate to the HP Procurve the AP (Atheros) is having trouble to decode those LDPC frames, causing lost of retransmit.  The client is still connected but no real traffic (no dhcp, ping drop...) as those are transmitted using Data frame at HT rates, where as keep-a-live are mostly send at legacy rate (nulldata) so from the AP and client they are still connected.

 

We simply did a simple work around by disabling LDPC on the AP to prevent clients devices to tx to AP frame with LDPC coding.  This has solved connectivity issue back then.

 

LDPC is an optional feature to improve FEC, but if you cannot even use MCS0 there is no point to have that enabled.

 

I believe by default Aruba AP has LDPC enable by default.

 

From this thread, I found most intel chipset are fine, same as MAcbook (Broadcom), I am quite surprise to see Microsoft to choose neither QCA or Broadcom for such high end "Pro" device.

 

Give it a try by disable LDPC (for HT and VTH).

 

The ultimate test would be to analyze the quality of the SurfacePro wifi signal under VSA when the connectivity issue happened. 

 

Just a thought.

 

[H_Matrix]

I also had the problem. After upgrading from Intel AC-8260 to AC-9260 with ArubaInstant_Hercules_6.5.4.4_62887
Although connected, no data flows anymore. At undefined intervals. Disconnecting and reconnecting will fix the problem for a while.

AC-8260 -> 6.5.4.4_62887 no problem

AC-9260 -> 6.5.4.4_62887 problem!

"Downgrade" IAP-325 to 6.5.3.4_62857 -> AC-9260 No more problems!

Being a very new chipset, impossible to say if this is related to any of the previous problems categorized and fixed in the ArubaOS/IAP code.

 

Would be ideal to have packet captures and comparative tech-support data

during the problem with the AC-9260 problem.

 

---

@danderson79 wrote:

I'm told it's fixed in 6.4.4.16, but as yet, the release notes haven't been updated with the bug fix information.

---

 

https://support.arubanetworks.com/DownloadSoftware/tabid/75/DMXModule/510/Command/Core_Download/Default.aspx?EntryId=27397

 

6.4.4.16 release notes have been updated with the bug fix:

Same issue here. We have AP-325's with a 7010 controller running 6.5.3.3 and the issues are continual with Surface Pro 3 and 4's. We are also a 5GHz only environment. 

 

I took a SP4 into the Microsoft store after updating our controller to 6.5.3.3 and still experiencing these issues. I had the MS Tech reimage the SP4 and even with a clean image and the latest driver updates from MS we are still having issues with connectivity on the SP4. 

 

The issues are; 

 

• Sometimes the SP3 or 4 will not connect to the dot1X SSID. 
• If connected it will lose connection throughout the day and the only fix is to restart the WLAN adapter or reboot. 
• Sometimes the connection is there but the icon shows a yellow flag and access to the network is nonfunctional. The status on the client shows APIPA address but correct DNS and no gateway. 
• Often the user reports they are using a website and they lose access to the site. The Wi-Fi shows connected but they can no longer browse that or other websites. Restarting the WLAN adapter resolves the issue (sometimes). 
• If the SP goes to sleep and you have to relogin the Wi-Fi does not automatically reconnect to the dot1X SSID. The only way to reconnect is to go to the connection and click the SSID and choose connect. 
• The user table in the controller shows the device connected. It shows it aging and having an IP even thought the device does not have an IP. The IP does not respond to a PING. 

The SP 3 and 4's come with a Marvell Avastar AC adapter and are running driver version 15.68.9114.29.

 

I have opened TAC case # 5324278164 and they have asked me for various logs and packet captures when the issue(s) occurs again which I will provide them.  

 

We have other laptops in the office; Dell Latitudes with Intel 7265 NICs, Macbooks and a Lenovo Yoga with an Intel 8265 NIC and none of them report any of these issues. 

Hi mmcnamee,

 

Forgive my ignorance as i am not using a controller (IAP here) but have you tried to disable the RX-AMPDU feature for each SSID?

 

i.e.

IAP(config) # wlan ssid-profile test

IAP(SSID Profile "test") # rx-ampdu-agg-disable 

IAP (SSID Profile "test") # exit

IAP (config) # exit

IAP# commit apply 

 

 

This was a confirmed workaround for us and may help confirm it's the *same* issue but isn't patched out in the ArubaOS (controller).

 

Cheers,

 

Aaron