Wireless Access

I'm working through this issue right now with TAC, but would like to reach out to the community to see if anyone else is seeing this.

 

We're seeing several disconnects a day for (Win7) Dell laptops w/ Intel 7260s when VHT is enabled on AP-225s.  The user notices being dropped from the WLAN and attempts to reconnect by clicking the wireless icon in Windows.  However, the SSID they were connected to disappears from the network list.  The user has to reboot their laptop in order to reconnect.  In a 2 day long test, VHT was disabled, and the disconnects stopped.  I'm working with TAC now figuring out if there is some combination of VHT and disabling another function to get clients working properly.

 

I captured the issue in Omnipeek and noticed the disconnect occurs when the client receives a probe request and attempts a roam.  I see the Auth from the client, and several retransmits, but no ACK from the AP.  The client tries again and finally gets an ACK, then Auth success from the AP, but the client starts Auth over.  The client just seems to get stuck attempting to Auth, but never gets passed this phase.  I don't understand how this can be tied to VHT being disabled since Auth is obviously not just part of the 11ac spec.  The other possibility is that disabling VHT never solved the issue, and it was just a fluke that clients didn't disconnect during my test.

 

If you google Intel 7260 there's actually a ton of complaints regarding disconnects and flat out being unable to connect to an 11ac network.  I've tried many different Intel drivers, including the ones straight from Intel (not Dell) and not seeing any improvement. Currently on version 17.0.5.8, but have not tried the latest driver (17.13.11) straight from Intel.  I'm going to disable WMM U-APSD tonight to see if this improves anything based on a TAC suggestion, but I worry about the sides effects of clients reverting to PS Poll mode.  Hoping to see some positive improvements as we are in the process of migrating many users to laptops with the Intel 7260 chipset.

 

Anyone going through the same issue now?

#AP225

I saw this issue with pre-17.x drivers on the 7260.

thecompnerd,

 

Please message me the TAC case# so that we can take a second look.

 

Messaged.  Thanks!

I also saw this with pre 17.x drivers as well, however I've seen it stabilize even more as the drivers have been updated. I'm currently running 17.13.x on my laptop with the AC7260 and it's been rock solid, so you might give it a shot.

Thans tsd25108.

 

I intended to run the 17.13 drivers, then forgot that I advised my test clients not to upgrade until we had fully tested WLAN infrastructure changes.  Trying to limit 1 change at a time for testing/verification purposes.  When I posted this, I forgot that we are still on 17.0 drivers from the middle of 2014.  So I've asked one test client to upgrade to 17.13 drivers to see if they have any improvement.

 

I have a good contact at Dell, so I'm reaching out to them as well to see if they have any reports of this and if they plan to release a more up to date driver.  For whatever reason, they're far behind in releases in comparison to the OEM drivers Intel puts out.  We'll the OEM driver a shot for now.

Well, turns out one of my test candidates did upgrade their drivers to the 17.13 drivers from December 2014, and they're still experiencing disconnects.  They had UAPSD disabled for some reason, so I enabled it and verified the chipset won't turn off under power management settings.  We'll see if that makes a bit of difference...

This thread has come just at the right time.

Customer escalation complaining of frequent disconnections and guess what Intel Dual-band 7260AC chipset running 16.1.3.1 as the driver.

We are in the process of seeing if the issue can be replicated then will try with 17.13 as suggested above

 

EDIT: the network is running IAP-225s, VHT is not enabled.

From all the reading I've done, it seems like the 16.X drivers were especially bad.  Hope the latest drivers are helpful to you!

 

Please post back if it doesn't help.  Would be good to compare setups if you still have issues.

Everyone on this thread, I am assuming that 802.11k is disabled, right? It is not enabled by default.

Disabled.

yup it is disabled.

thecompnerd, any idea where I can get those 17.13 drivers?

 

I was lazy

https://downloadcenter.intel.com/SearchResult.aspx?lang=&ProductID=3714&ProdId=3714

 

Here you go:
https://downloadcenter.intel.com/Detail_Desc.aspx?DwnldID=24578

great thanks

More testing tomorrow, field services couldn't secure a laptop for today.

Tomorrow user who complained will test with her 16.1.3.1 laptop and field service guy will test with 16.1.3.1 and 17.13.

hi all,

Chipping in on this, yes I have seen this issue at three large enterprise customers, Lenovo eventually asked the customer to disable the VHT in the driver (they were on the 17.x latest) and that stabilised, but not after we had to clean up a few things on the Aruba side.

 

For 7260 and AP225, the following needs to be true as of now to minimise problems like lost WLANS, ! icons, stalls, disconnections etc.

 

>> client must be on latest 17.x driver

>> ArubaOS must be 6.4.2.3  or higher (i.e. prefer 6.4.2.4 right now) - absolutely cannot be less than 6.4.2.3 unless its the HDMS load but that's a longer story.

>> ensure features like 11k are not enabled

>> disable wmm-uapsd in the SSID profiles

>> Disable VHT in the client supplicant if you are seeing "!" icon, missing WLAN ssids etc. * see note 1

 

* Caveat - I have yet to personally test if the 17.13 driver deals with the need to disable VHT at the client to stop the "wlan disappears" lockup, if anyone proves to the contrary please update the thread

 

* note1 - this has been reported to us as a solution to the supplicant lockup issue, YMMV

 

thecompnerd wrote:

 I'm going to disable WMM U-APSD tonight to see if this improves anything based on a TAC suggestion, but I worry about the sides effects of clients reverting to PS Poll mode. 

 

>> We have done this in multiple Aruba 11ac customers, there should be no issue from it.

 

regards

-jeff

#AP225

Hi Jeff,

Would you leave HT mode on HT instead of VHT or have it disabled completely?

No testing today, i did manage to get the individuals laptop upgraded to 17.13.11 with HT mode set to HT, not VHT.

Wondering if it should be disabled completely. Testing scheduled for tomorrow

Pasquale,

 

In my testing I was able to stop the disconnects for 2 days after disabling VHT on the infrastructure side.  You may have the same result.

 

I've got one user upgraded to 17.13.11, VHT and UAPSD disabled.  No disconnects yet.

The other user is on 17.0.X drivers,VHT, and UAPSD disabled.  Disconnected twice.

Thanks, I will get them to go back in where it says HT mode and select disable.

I am on an instant network so no UAPSD for me.

VHT is not enabled on the network, using 20mhz on the 5ghz.

What kind of testing did you perform, anything specific I should give a shot tomorrow?

No specific tests since I can't seem to recreate the issue on demand.  Enable user debug and gather Windows WLAN Autoconfig event log so you can track the times they're having issues and verify it's the same issue each time.

---

@pmonardo wrote:
Hi Jeff,

Would you leave HT mode on HT instead of VHT or have it disabled completely?

---

hi Pasquale

sorry for the late response, in the customer in question, yes just VHT disabled, HT was left enabled.

regards

-jeff

No worries.

I'll see tomorrow how the instant cluster with this chipset behaves

Does Aruba report these issues to Intel? I don't feel like if I complain to
Intel my voice will be heard. Seems for effective coming from a large
company such as Aruba. Very frustrating because this is the only 11ac
chipset we have in laptops and can't even take advantage of it as long as
VHT is disabled.

Good question.
I wonder whether the financial institution I am dealing with will escalate to Intel as well, not only Aruba.

Found it odd that when I mentioned driver issue, I got crickets in response.

Aruba does have a channel to report issues to all the chipset vendors, for these 11ac issues I am not sure what has been the dialogue. Having said that, not every issue is the chipset vendor (ap or client) there are Aruba's issues too. Issues are also not necessarily caused by an actual bug - some are misinterpretations of the standard and some are unforseen interop issues due to features like scanning, powersave etc.

 

By all means have your end users raise up their issues - likely they will go to the laptop vendor that they are using.

 

In the case of disabling VHT, just to clarify, this was mentioned to me by a customer as stopping the supplicant lockup/loss of WLAN ssids - whose bug it is to fix may require longer to determine and I shouldn't speculate too much since we have not reproduced it internally as far as I know (I know we tried as a result of the customer who mentioned the VHT disable to us). But, if it works for you too, then in the interim use it while waiting for it to be fixed because the symptom is quite annoying.

 

Sorry if that all sounds a tad disclaimer-ish ;)

 

regards

-jeff

Little update for everyone.

Running 3 different laptops with 3 different cards

Samsung Laptop with
Wifi card -> Intel centrino Ultimate-N 6300 AGN
Driver -> 15.0.0.75

HP laptop with
Wifi Card -> Broadcom 43224AG 802.11a/bg/n
Driver -> 5.60.350.23

The problematic laptop (Dell) with
Wifi card Intel dual-band wireless-AC 7260
Driver -> 17.13.11.5
HT mode -> HT
U-APSD -> disabled

Both Dells disconnected but after looking at the WLAN Auto config logs, both showed key exchange issues for the disconnection reason.

The Samsung is going strong for close to 2 hours now.

The SSID is a WPA2-PSK AES encrypted one.

More to follow

Update

Testing went fine with the new driver.
We lost internet access to the site (grrr DSL)

Overall looking at the wlan control logs i see this one time.


WLAN AutoConfig service failed to connect to a wireless network.

Network Adapter: Intel(R) Dual Band Wireless-AC 7260
Interface GUID: {9326c4fc-62d4-4aff-ab74-7ab97d004b69}
Connection Mode: Automatic connection with a profile
Profile Name: BMobile
SSID: BMobile
BSS Type: Infrastructure
Failure Reason:Security failed.

Overall, I think more testing is required but I am curious about the security failed error. need to look more into it.

---

@jgoff wrote:

 

For 7260 and AP225, the following needs to be true as of now to minimise problems like lost WLANS, ! icons, stalls, disconnections etc.

 

>> client must be on latest 17.x driver

>> ArubaOS must be 6.4.2.3  or higher (i.e. prefer 6.4.2.4 right now) - absolutely cannot be less than 6.4.2.3 unless its the HDMS load but that's a longer story.

>> ensure features like 11k are not enabled

>> disable wmm-uapsd in the SSID profiles

>> Disable VHT in the client supplicant if you are seeing "!" icon, missing WLAN ssids etc, until Intel has a fix

 

regards

-jeff

---

Thanks for the input, Jeff!

 

Currently testing 17.13 drivers w/ UAPSD disabled on the client side.  Will report back after several days of testing.

#AP225

"Well, turns out one of my test candidates did upgrade their drivers to the 17.13 drivers from December 2014, and they're still experiencing disconnects.  They had UAPSD disabled for some reason, so I enabled it and verified the chipset won't turn off under power management settings.  We'll see if that makes a bit of difference..."

 

Can you tell me where to enable uapsd?   And can you tell me what you mean the chipset won't turn off under power management settings - are you talking about windows power saving settings?

boe,

 

To disable/enable U-APSD:

 

Device Manager > Network Adapters.

Right-click on your adapter.  Click on Properties.

In the window that popped up, click on the Advanced tab.

You'll see the option U-APSD in the scrollable list of options.  Click on it and select disable/enable from the drop-down.

 

Regarding your second question, there is a power option for the the NIC to "Allow the computer to turn off this device to save power".  I disabled it as a troubleshooting step.  You can find the option here:

 

Device Manager > Network Adapters.

Right-click on your adapter.  Click on Properties.

In the window that popped up, click on the Power Management tab.

 

Thanks,   I know these are all macbooks and mac airs - I'll have to find out if they have intel nics tomorrow.

boe,

 

To be clear, there are no specific issues with the adapters in the macbook pros and 802.11ac.  Most current macbook pros have broadcom chipsets for their WLAN adapters.

Thanks - I guess that isn't the issue, I'll have to try to figure out why their clients keep having issues.

I am late to the show, and I didn't have the exact same symptoms, but here goes:

 

I purchased a Dell with an Intel 7260 AC late last year, and I have was having issue with experiencing almost 100% packet loss with the device. There were known Quiet IE problems with the chip and many driver updates failed to fix it, but I didn't think the problem would affect me because I always had 802.11k disabled.

 

I found that the only way to fix the issue was uncheck "Advertise Quiet IE" in the RRM IE settings. I had always ignored these settings because I thought that having "Advertise 802.11K capability" unchecked meant these settings were disabled.

 

Doesn't sound like exactly your issue, but I use this laptop daily now and have not had a problem at all since that. (6.4.2.3 code, unknown recent 17.x Intel driver).

 

Aaron

Thanks Alamey.

It is odd because users can sustain a connection for 3+ hours then suddenly drop off, have to reboot their laptop in order to see and connect to the SSID again.

The financial company I am dealing with does not want to upgrade the drivers just yet without more testing.

I will give the setting you mention a shot and see if it makes a difference.

Again I am on an instant network, 80211k disabled.

What was discovered yesterday that blows my mind is that this network is over 3 floors with ~30 IAP-225s, the 3rd floor when the user pings yahoo.com suffers massive packet loss and high ping times but going down to the 1st and 2nd floors this is issue is not apparent.

Even on the new drivers and the limited testing they still get disconnected but I may have to change the "Advertise Quiet IE" like you mentioned.

HT mode is already set to HT and not VHT.

Pasquale,

 

Our symptoms are very similar to yours.  Only after rebooting will their computer reconnect.

 

We're still seeing disconnects on 17.13.11 drivers with UAPSD disabled in the client drivers. As suggested by TAC, I will disable it from the SSID profile to see if that has any effect.  If not, it seems like we'll be turning off VHT on our APs.

I don't even have VHT enabled on the IAPs and I am using 20 mhz on the 5ghz.

I'll let you know how it goes

Just realized that after re-reading your post.  Very odd, as I was fairly confident that resolved our issue in initial testing.

Nope not in ours it seems.

There are a multitude of issues at this location. It would seem the problematic ones come from a Dell Latitude 7240 using the bad chipset whereas the Dell Latitude 7440 doesn't have this problem but it's like pulling teeth to find out which driver and chipset that laptop is using.

There is also roughly anywhere between 90 and 120 users on the Wi-Fi at any point all using a pipe of 12Mbps/1Mbps but that's a separate issue. I am monitoring the WAN throughput to see if it is getting maxed out.
2 SSIDs, where 80% of the users are on the SSID not using external captive portal and mostly using VPN

Removed DFS channels, reduced power to 12-18, no VHT, no 40Mhz channels.

On the 7240 laptop using the 7260 AC chipset, driver version is at 17.13.11 with HT mode set to HT.
I need that person who has that laptop to constantly test but that laptop is not an "employee's" laptop it is a test laptop.

I will try disabling VHT on one of the employee's laptops today to see if it helps.

here is an update.

User's connection drops
Instant still shows user connected, laptop still says connected.

User cannot surf anywhere.

Something that may help in troubleshooting this is Microsoft Message Analyzer.

 

It can both capture network drive and capture driver state messages from the OS at the same time. Very handy for this type of stuff.

 

http://www.microsoft.com/en-us/download/details.aspx?id=44226

Pasquale,

 

I saw this issue on my 7260AC in a niche situation last December. At the time, I was running 6.4.2.2 and the AP I was connecting to was the AP-205 with a 7210 controller. The Intel driver was the one that came out before 17.13.11.5

 

It has not reappeared after updating my 7210 controllers to 6.4.2.3 and upgrading to Intel 17.13.11.5. Sorry for changing two things before checking if it fixed the problem. :)

 

Hope that is in anyway helpful,

 

Aaron

 

Edit: Added the fact I changed the Intel Driver versions.

#AP205
#7210

Thanks Alamey.

My network uses Aruba Instant with 225s.

Seems as though the SSID did not disappear after setting the HT mode to HT (from VHT).

user got disconnect and wireless stopped working.

even on the new drivers with HT mode set to HT.
Going to try and disable UAPSD then uncheck "Advertise Quiet IE" in the RRM IE settings

Well, I've decided against disabling U-APSD on the WLAN side with VHT mode enabled.  We're a Lync deployment and I'm not sold on the idea of reverting to power save polling where WMM is not applied to queued voice packets.  I don't have the best test-bed for determining if there is a noticeable difference in voice quality with/without U-APSD enabled, so I think I will error on the side of caution and run HT mode with U-APSD enabled as I didn't seem to have disconnects then.  Will be testing all next week in this config to be sure we don't have any more disconnects.

 

Pasquale, I don't believe you'll see any benefit from disabling advertise quite IE if 802.11K is disabled.

---

@thecompnerd wrote:

 

Pasquale, I don't believe you'll see any benefit from disabling advertise quite IE if 802.11K is disabled.

---

That is what I thought as well, but the TAC engineer told me to do it, and it worked. :)

Actually I can't disable that setting, doesn't exist in IAPs, only controllers.

---

@alamey wrote:

---

@thecompnerd wrote:

 

Pasquale, I don't believe you'll see any benefit from disabling advertise quite IE if 802.11K is disabled.

---

That is what I thought as well, but the TAC engineer told me to do it, and it worked. :)

---

Aaron,

 

Very odd.  I wonder if that means the user guide is incorrect?  I setup an OTA capture and I'm not seeing this advertised in the beacon or in probe responses.  Really bugging me...

 

Although your issue is a bit different, it shouldn't hurt to disable quiet IE.  It's purpose is for radar detection, but we aren't running DFS channels yet.

I haven't heard of any issues today.

I have asked them to try the Open SSID with the test laptop to see if it makes any difference.
I am wondering whether the re-keying of WPA2 is causing issues with this chipset as I see "security failed" messages in the WLAN windows logs.

Aruba is also looking into it with me so I will keep everyone posted.

Thanks,
Pasquale

Wanted to mention that this customer also has carbon copy setups in other buildings using the same model laptops and wifi chipsets and i have not heard of issues at those buildings.

that's a head scratcher

Hey guys,

 

have you seen this before?

 

on the VC, I have client match enabled, VHT and wide-channel bands disabled but on the cli running the following command

show ap debug driver-config

 I see the following on my APs for example. see attached.

client match -> no value set

Very high throughput enable (radio)                                     Enabled

40 MHz channel usage                                                    Enabled

 High throughput enable (SSID)                                           Enabled
40 MHz channel usage                                                    Enabled
Very High throughput enable (SSID)                                      Enabled
80 MHz channel usage (VHT)                                              Enabled

hi Pasquale

 

I wouldn't necessarily trust that output...The way I understand it is that the basic config is pushed down to the radio that would be considered "all features enabled" then after that specific tweaks get used to shut down things like VHT and other goodies that apply per BSSID . The same thing is seen in the controller where the radio may appear to be HT enabled but the SSID profile may not be (i.e. ht ssid profile vs. the radio profile).

 

Admitedly this is a pretty bad explanation :) but certainly I would look for another means to verify, perhaps from the beacons themselves, probe responses or even from some of the other ap debug commands (not sure you can do that on instant so easily, but controller yes).

 

regards

-jeff

Thanks Jeff.

Good information it's is just a bit misleading when you're troubleshooting and the results you get differ from what is actually configured.

Back to the issue at hand, this has caused a massive escalation with the customer (not fun). More to come from me later.

I've got a tac engineer booked tomorrow to get some pcaps from the wireless side but we are also going to be testing with a freshly imaged windows 7 laptop (non company windows image) to rule out the image.

More updates, you love it admit it.

2 Laptops.
1 stock windows 7 running version 16.1.3.1
1 customer image windows 7 running 17.13.11 with VHT and U-APSD disabled.

all day connected streaming youtube and doing other various things( roaming , etc ).

the one with the 17.13.11 driver has not locked up and/or lost connection.

The stock laptop dropped off, a reset of the wireless card fixes it.

Pointing more and more to the driver which helps me and my partner isolate and technically have some leverage on changes the customer needs to make

Even with the 17.13.11 driver we suffered a disconnection issue.

Seems as though that did not fix it.
Will go back to TAC with this

hi Pasquale

When you say disconnect, do you mean some sort of limited connectivity that suddenly appears ? I can confirm we just recently found and fixed an issue that can cause a periodic "!" limited connectivity stall to occur (it can also eventually recover itself, but takes many minutes, perhaps up to 10mins). It is fixed in 6.4.2.5 which is currently scheduled for end of day 26th Feb.

 

To determine if you are hitting this bug is a bit tricky, but shoot me an email at my forum nume @ aruba and I can step you through it.

 

FWIW there is also some sort of issue we see from time to time where certain laptops are getting stuck when they come out of sleep/hibernate, they try to connect to the wifi but fail to answer the eap-id-req from the AP, I have a feeling this is not a wireless issue (if you're seeing that, let me know too)

 

regards

-jeff

 

Sharing my update as well...

 

The only thing so far that has stopped the disconnects for us is disabling VHT.  For clarification, our disconnects result in the client disassociating from the AP.  The clients are unable to associate unless they reboot.

 

Support is monitoring the case and trying to identify if anything can be tweaked so VHT can be enabled.

Jeff, emailed you.

I wish just disabling VHT would solve this but it doesn't. I have heard there is a new driver out 17.14 but I have yet to verify it myself.

After troubleshooting with TAC we re-enabled VHT and attempted to catch a disconnect in the act so engineering can get a look at the AP console. Logs were sent and they are investigating.

ALso, a new driver is out 17.14.x and TAC has asked me to install on some devices to try it out. I will be doing that and will let you know.

Hi

i have had this in one of my customers they are not running Aruba, they are running HP wireless.

Nut we have tried both Lenovo and Dell computers, the affected machines are machines with Intel 7260AC. It seems that the problem occurs on SSID where you have a lot of machines conected and the machine is in some power save mode.

The solution is to skip using dell or lenovo driver and using the latest Intel driver with WIFI proset and also use the latest BIOS on the machine.

The latest driver that works and is confirmed for numerous of test is this 17.13.11.5 it need to be 5 i the end.

And you also need to run the latest BIOS on the PC.

 

Regards

Peter Andersén

 

Hi Peter,


Thanks for your update.


There is a new version 17.14.x out as well.

Have you had a chance to test this as well?


What would the BIOS have to do with the issue? Not that I am questioning the reason to upgrade it but more wondering what changes an upgrade to the BIOS can improve?


Thanks,

Pasquale

I am experiencing similar issues to Pasquale. Give or take 200 users all using Intel 7260ac wireless cards and connected to wifi and they are experiencing frequent "!" limited connectivity issues. When it occurs, a reboot is required to allow new connection that actually passes traffic. It doesn't always happen, and seems to happen at random. We are always testing with the latest driver released for every user that this occurs to, at least once or twice a day to different users. I have tested a multitude of CLIENT-SIDE settings including: HT/VHT, disabling U-APSD, preferring certain bands, testing every intel driver known to man for the 7260, etc. Our users only experience these wifi connectivity issues while they are at our HQ and connected to the Aruba equipment. If they are in a remote office with non-aruba wireless, they report no issues, and the users also report no issues while at home.

 

I too use a mix of AP-125, IAP-225 and AP-225, yet all are currently running in campus controlled mode. Currently running version: 6.3.1.9. Quiet-IE is currently enabled and have not tested disabling yet. 

 

Would like to try to upgrade to 6.4.2.5 and test. If no success, will then disable Quiet-IE and test more. Will return once I have gathered some data.

 

Try upgrading to 6.4.2.5, It has some intel bug fixes.

 

Bug ID Description
108839 Symptom: Intel clients disconnected randomly. The fix ensures that deauthorization of UAPSD clients
follows the correct path instead of randomly disconnecting from the legacy power save queue.
Scenario: This issue was observed in controllers running ArubaOS 6.4.0.3 in a master local topology.

Yes I read through all of the bug fixes and noted this as well and this was the most interesting one in the entire post. 

 

Another that also interests me is: 

 

105613 Symptom: An intermittent connectivity problem occurred between clients and AP-225. This issue is resolved by implementing internal code changes. Scenario: This issue was observed in AP-225 access points using 2.4 GHz radio

 

Were you ever able to resolve the issue you were experiencing?

We are currently testing a customer build for my IAP-225s and it seems to be working well. No documented disconnections using this build and driver version 17.14.

I also have VHT enabled on the client side, u-apsd disabled.
On the IAP side of things, I have VHT enabled but not using any VHT channels, engineering recommended that for now. I have also had to deal with co-channel interference, etc.




Pasquale Monardo
Conseiller Principal Solution R?seaux, Op?ration | Senior Network Solutions Consultant, Operation
[cid:image001.png@01D05AE1.26D6FEF0]

T 514 385-4448 #204 DATAVALET.COM

5275, chemin Queen-Mary, Montr?al (Qu?bec) H3W 1Y3 Canada

CE COURRIEL AINSI QUE CES DOCUMENTS JOINTS peuvent contenir des renseignements confidentiels et privil?gi?s. Si vous n'?tes pas le destinataire d?sign?, veuillez nous en informer imm?diatement et effacer toute copie. Merci. THIS EMAIL AND THE DOCUMENTS ATTACHED may contain privileged or confidential information. If the reader of this message is not the intended recipient, please notify the sender immediately and delete the original message. Thank you.

just to put some extra info out there....

 

108839 was fixed in 6.4.2.3, in particular it was related to a CLI command being run which caused an inconsistency. If you werent running the CLI command (aaa user delete all) you probably weren't seeing it.

 

105613 was found against 2.4ghz voice devices, it wasn't an issue specific to the 7260ac.

 

112960 is an important one to take for 6.4.2.5, causes certain TIDs to lockup due to the AP erronesously sending a BAR frame with seqnumber=0. This would also show up as "!" icon/limited connectivity

 

There is another issue that has recently been nailed down, it can manifest as inability to connect to the wlan or as very high latency if testing with ping. The issue is a client side driver issue and it only happens when the AP is operating in unii2/unii2e channels that require DFS. So far in our testing, driver intel package 17.14 appears to have resolved the issue; if you use DFS channels, you should upgrade to 17.14.

 

hth

regards

-jeff

 

 

 

 

 

 

 

 

Wanted to provide a quick update to everyone.
Using newly released IAP code 6.4.2.3-4.1.1.3_48994 on our IAP-225 network and with the latest Intel driver package of 17.14 (actual driver is 17.13.11.5) has shown 0 disconnects in over 2 weeks (we had an earlier build for 1 site but the other was using the code above for a day or two). This is just amazing news for us and our customer. So amazing.

Next is to upgrade the controllers to 6.4.2.5 (proactive before the customer starts complaining).

Thats great news. Thanks for the update.

I upgraded our controller last night from 6.3.1.9 to 6.4.2.5 and so far today there hasn't been a single user come to the IT office complaining of wifi issues. This is unusual (as we usually received 3-4 people a day stopping by). Hoping this keeps up, i'll update after a week or so of test.

That is the version to use.

I had one complaint yesterday where the user locked her computer and walked away for 15 min, came back and was disconnected and couldn't reconnect.
She did it again and stayed away for 30 min but didn't have a problem.

Power-save is not enabled on the driver, she was on AC power. So I am scratching my head.
There is no timer within Instant that disconnects users if no activity unless an idle-timeout is configured but that just ages out the user from the database.

Overall, no user disconnects using the 17.13.11.5 version of the driver and this new IAP firmware. We still see disconnects with the 16.x version but we have told the customer to upgrade.

Well, I'm still struggling.  Performed the following:

 

1. Upgraded to 6.4.2.5 (re-enabled VHT mode)
2. Disabled QuietIE

I have more clients on the 7260 chipset now than I did weeks ago when I posted this.  I'm confirming that everyone is on the latest driver.  Very disappointed to still have problems.  I'm not convinced that anything can be done on the Aruba side to fix this issue.  I'm ready to give up and just disable VHT mode.

Interesting definitely.

I have VHT enabled on the VC and on the clients but I don't actually use an VHT channels and we don't have issues, so I guess we're not using VHT either.

To confirm, driver is 17.13.11.5?

You don't need to use wide channels for 11ac (VHT) to be enabled.  You'll still get the (small) benefit of 256 QAM and explicit beam forming.

 

Yes, I believe those are the latest drivers from December.  Haven't found anything newer.

Just to confirm, I have all clients on 17.13.11.5 and not seeing any improvement.  In fact, within the last hour I've had 3 users contact me about getting disconnected.  Bad deal as these users are on Lync phone calls and obviously lose their call.  Turning off VHT mode tonight as I can no longer deal with this issue.

That's too bad.
Not sure if this was answered previously but is the RF environment free of interference?
I ask because not only was I having issues with the driver and APs, my environments was suffering from lots of CCI where had to move APs to static channels in order for them to stop changing, played with RF power levels and basic rates in order, etc in order to stabilize it prior to upgrading the cluster.
I suggest you keep chugging away with TAC on this and get it escalated even higher if you can.

I'm back to confirm that after updating to 6.4.2.5 that our wireless disconnect issue has disappeared. That is as long as their drivers are up to date. If they are on an older driver, namely the 16.* versions, disconnecting continues as if nothing has changed.

 

I'm quite happy about 6.4.2.5 fixing this issue for me however now Sonos doesn't work for any mac clients, that's another story...

Over the last month or so the wireless disconnects have slowly been finding their way back into the network. Maybe Intel ruined their driver again? Either way, I've had to disable RRM Advertise Quiet IE packets. This has completely eliminated wireless disconnects for the last 8 days.

Brianjacobson,

 

Thanks for your feedback

 

Disabling QuietIE has always been mandatory with Intel if you have 802.11k enabled.  We will post if anything changes with that.

 

New Intel driver version out 17.16.0.4 for the 7260.
Anyone give it a go yet?

last month one of my client upgraded their laptops to this new adapter and since then everything looking nice.

hi Pasquale

I was still able to crash 17.16.0.x in my own testing with heavy download of small packets (actually, I used Aruba wireless packet capture and sent it down the wifi), I was able to internally get 17.16.1.2 and that has been much better.  I could crash 17.16.0.x in about 10 mins, 17.16.1.2 takes me about a day to kill - reported as fixed in 18.11....

 

I don't know what is Intel's plan for releasing 17.16.1.2, but it is floating around in the internet.

 

slowly getting better..

regards

-jeff

Hi Jeff,

Thanks for the input. Ever since we upgraded the client to the 4.1.1.3 version of IAP code and had them move to the 17.13.11 driver along with tweaks to the WiFi, we haven't heard a thing from them.
We plan on moving them to 4.1.1.5 soon to match other locations. I know 4.1.1.7 is out but that's the way it goes.

I am curious how you test this yourself as I have a Lenovo with that Intel card and would love to test it out.

Thanks,
Pasquale

hi Pasquale

There is a copy of it that appears to be on the Internet dated 12/04/2015, Lenovo has it up on their website apparently (http://support.lenovo.com/us/en/products/laptops-and-netbooks/thinkpad-x-series-laptops/thinkpad-x240/downloads/DS102886)

regards

-jeff

Thanks Jeff.

What about your testing, how are you conducting them?

Hi Pasquale

the best way of locking up my laptop wifi (requiring a reboot, no wlans visible, no response from driver), win8.1 + 7260 has been so far the combination of youtube together with Aruba wifi capture being sent to my laptop; please tell my boss it was after hours :)

 

                                         [ internet ]

                                                |

  [ laptop ]       ap215  ---- [ controller ]  --------- [ other AP ]

 

where other ap has 'ap packet-catpure' enabled with a destination IP of laptop, and just let it sniff whatever is going on. The two APs above are not on the same channel (feedback loop), but 'other ap' has various other APs on the same channel just beaconing and sending various traffic.

 

so far 17.16.1.2 is far harder to kill that 17.16.0.x was, but I have still managed to lock up 17.16.1.2 a couple of times, and have reported it to Intel internally.

 

hth

-jeff

Amazing, thanks for this. Happy you reported this to Intel.

hello all,

intel has released 18.11.0.8, if you are using 7260, I would recommend that you install it - especially if you are on 17.16.1.2 and still seeing the occaisional lockup requiring a toggle of the wifi card h/w switch.

 

http://www.intel.com/support/wireless/wlan/sb/CS-034315.htm?wapkw=intel+wifi+driver+versions

 

Just to recap, these are the two builds I would be recommending (but prefer 18.11.0.8)

 

17.16.1.2    12/04/2015

==================

much harder to hit issues than 17.16.0.1, but can still lockup sometimes

 

18.11.0.8     22/06/2015

==================

has a couple of fixes for lockups

 

I have been running 18.11.0.8 internally for a couple of weeks and have yet to see any reproduction of the issue I mentioned in my last post - which is a good sign.

 

regards

-jeff

Thanks for the update, Jeff.

We've been using them for a week on a few workstations w/AP-225s in 11n
mode.. Have yet to enable 11ac on the APs to see if the disconnect issues
can be reproduced. Shooting for next week.

Does Intel not publish the details of their driver releases?

hi Jay

We get a very vague and short list of things that are fixed and told that we cannot publish it - but apparently there are 2 fixes related to bad driver behaviour in this release over and above 17.16.1.2.

regards

-jeff

 

Understood. Thanks again for the info!

This is great news Jeff, which AOS and Instant version should we move to with these new drivers. I suppose anything above 6.4.2.5 (including 6.4.3.x) and Instant 4.1.1.3+

 

 

Hi Jeff,

 

We have a lot of the ac-7260 in our environment. Do you know how frequently Aruba update their 'Interoperability Page' http://www.arubanetworks.com/support-services/interoperability/ as we generally refer to this for driver updates, of course, we also do our own internal testing. I ask this as this page is currently recommending 17.13.1.13.

 

Thanks,

 

Darren

---

@dazc wrote:

Hi Jeff,

 

We have a lot of the ac-7260 in our environment. Do you know how frequently Aruba update their 'Interoperability Page' http://www.arubanetworks.com/support-services/interoperability/ as we generally refer to this for driver updates, of course, we also do our own internal testing. I ask this as this page is currently recommending 17.13.1.13.

 

Thanks,

 

Darren

---

vey infrequently; as evidenced by that driver recommendation. This thread is the authority at the moment on 7260AC interop with Aruba 200 series APs

 

regards

-jeff

That didn't take long.  Already a version 18.12.0.3.

 

Jeff, can you offer any insight into changes with this driver version?

The compnerd,

 

Did you get that from Intel's website?  What OS?

I can't find that version anywhere myself

Looks like Windows 18.12.0.3 is for Windows 10.

Ya just noticed that as well.
side note, any way we can make this thread a sticky at the top?

http://www.intel.com/support/wireless/wtech/proset-ws/sb/CS-034038.htm

 

Good for Win10, 8.1, & 7.

The Compnerd,

 

Thanks so much for the link.  Let's hope we can possibly mark this as a solution in the near future.

 

You're welcome.

 

I'm asking a couple of users to upgrade so I can turn on VHT mode and test.  I'll respond back with the results in a few days.

Thought I'd chime in, since this is the most accurate thread I've found on the subject. Some 30 (I)AP-215 and a 7205 controller. Testing with linux and an AC7260 adapter. First when connecting I connect at the nominal rate of 867 Mbps. After a minute or so the adapter drops down to sub 300 Mbps and whatever I do the connection won't go back up to ac-speeds.

 

Well OK, if I unload the driver I get ac-speeds for a minute or two again. The funny thing is that I have bandsteering on, with force-5GHz and still 'iwconfig' reports 2.442 GHz as the frequence. This is after the speed has dropped. When still at ac-speeds it reports 5 GHz.

 

Have disabled U-APSD on the controller.

hi HaraldH,

 

Thanks for the info - force5ghz and bandsteering are ultimately going to be overriden by client match, but even then there is no guarantee that the client wont do something odd. What driver version do you have for the linux side ?

 

I have noticed that my 7260 really seems to keep jumping back to 2.4ghz despite being in the same room as a AP205 that has 5ghz and 2.4ghz enabled.

 

when you first associate, can you run the following commands

show ap association | include <mac address of client>
show ap debug client-table ap-name <the ap where client is>
show ap debug client-stats <mac addr of client>
show ap remote debug mgmt-frames ap-name <ap where client is>

then after you notice the problem please collect the same commands again above.

 

regards

-jeff

 

That's exactly what mine does, jumps to 2.4 GHz after a while. Running linux kernel 3.19, firmware reported as 25.17.12.0 (12.ucode). I tried -10.ucode to no avail, same problem.

 

I tried with the 4.2-rc backport and ucode.14 but that stumbled on the kernel version and generated som regulatory error. I would have to pursue that test with a 4.2rc kernel.

 

I don't recall seeing this behaviour when using IAP-215. This seem to have come with the controller.

 

Hope the attachment is readable.

 

edit: my phone (Note3) seems to stay rock solid on ac.

 

edit²: This might be related: "wlan0: capabilities/regulatory prevented using AP HT/VHT configuration, downgraded". Regardless of me setting FI as the alpha-2 code or not.

HaraldH

yes that error seems possibly involved - you could try some of the things mentioned here

https://forums.gentoo.org/viewtopic-t-968312-view-previous.html?sid=74c949af883e65bb4dea9040900e8869

 

which involve telling the driver itself to use the right regdomain (i presume US?)

 

try adding to /etc/modprobe.d/cfg80211.conf

   options cfg80211 ieee80211_regdom=US

 

or using iw, i.e. "iw reg set US"

 

other things to try include changing the AP channel (esp if it's on a DFS channel, try setting it to 161 or 36 instead). You could also try as a test putting up a HT (not VHT) ssid profile for a test to see if it stabilises.

 

That error doesnt seem limited to Intel on linux, someone might also be able to offer something if you can post the entire dmesg log from the time the card comes up to the time it connects ?

 

regards

-jeff

 

 

 

The error came when testing other firmwares. A cold boot fixed it.

Hopefully some good news here.

 

We have been fighting this issue for sometime as well. 

We have two Aruba 7210 Controllers in Active/Standby with v. 6.3.1.16

We use Lenovo T440s with the 7260AC chipset. 

 

We were seeing two different issues:

1.  "No Internet Access" Yellow exclamation point while not totally dropping connection to the network.

2.  Total Disconnections. 

Putting the machine to sleep seemed to make the issue occur more often.

 

I have had the newly released 18.12.0.3 version fo the driver installed for about 2 weeks now and have not had the issues since. 

 

#7210

moved to new topic.

Pushed the latest drivers out to 50 colleagues and testing with 11ac enabled in their area. Hoping for some good mojo today!

Sending good vibes your way along shots of Jameson if all goes well.

Out of curiosity.. how do you push out drivers? Can that 'easily' be automated?

We use Microsoft SCCM to push the drivers and set them to install when the
user shuts down the laptop.

I didn't have any complaints Friday about disconnects, but I also didn't
see any 11ac clients connected when I did a spot check. I have a reliable
person that tells me when she disconnects but she was out of the office.
Hopefully she is in today.

I had a little problem with VHT not actually being advertised in the beacons, which explains why I didn't have an VHT associations the last couple of days.  Got that fixed up last night, and today was the first day of VHT actually running.  Went a whole day with no complaints.  I double-checked with at least one user that consistently had problems and her connectivity was fine.  I believe I've been in this position before, so I'll give it several more days before giving it a thumbs up.

 

Interesting side note here.  As I mentioned, we deployed the latest drivers last week to many users.  It appears that Intel is disabling U-APSD support by default in the driver settings.  Interesting, because Intel mentioned in a post last year that U-APSD may need to be disabled as it caused performance issues with certain APs.  This is something that Aruba TAC was aware of at the time as well and had me test connectivity by turning off U-APSD.  I never found that it helped.

Thank you for the updates thecompnerd. Please, keep them coming.

We are deploying a good number of HP laptops with Intel 7260 and are trying to decide on which driver version to include in the OS image.

We have a problem with the initial connection to the wireless, but so far it looks like it is related to the Single Sign On software installed on the laptops. Without that software installed they connect with no problems. The interesting part is that other NICs work just fine with the same software.

A firmware for linux called ucode.15 came out. I tried it, and it did roughly the same. After a minute or two I was dropped from AC to N-speeds. Ordered a BCM94352HMB, hopefully I'll be able to rule out bad configuration on my part.

 

wireless.kernel.org/en/users/Drivers/iwlwifi

I've been withholding updates as I did not want to speak too soon.  My test subject has reported no wifi disconnects since updating to 18.12.0.3 driver with 11ac on the AP enabled.  I'm going to check in with her again at the end of the week to be absolutely sure, but it's looking very good now.

Hi,

 

which Windows Version (7, 8, 8.1, 10) do you use for the 18.12.x driver?

 

thanks

martin

 

Win7

Ok thanks,

 

did anyone has problems in WIN8 with this NIC and on which you have installed on the Controller and the NIC driver?

Final update: disconnect issue has been resolved.  We are not getting any reports of wifi disconnects using driver version 18.12.0.3.

and VHT is enabled?

Yep!  Our disconnect symptoms existed only when VHT mode was enabled on the AP, with associated VHT clients.  We just disabled VHT to stop the disconnects.

Great news indeed!

hi all

 

Good to hear that people are starting to report much better stability on 18.12.

 

Having said that, 18.20 is out - it has a couple of fixes that may be useful for some scenarios.

 

In our own internal testing we also see that most of the lockup up issues seem to have gone away since 18.12, but there have been some cases where we saw occaisional roaming issues and band selection issues. 18.20 has at least one fix for each of these two topics, and so far seems to be holding up well in our internal testing.

 

If you have devices which roam a lot or seem to be frequently dwelling on the wrong band then perhaps give 18.20 a whirl.

 

regards

-jeff

Hi Jeff,
can you link me?
This link which the 'thecompnerd' provided does not have it
http://www.intel.com/support/wireless/wtech/proset-ws/sb/CS-034038.htm

Here you go:
https://downloadcenter.intel.com/product/75440/Intel-Dual-Band-Wireless-N-7260

I've read through every suggestion in this thread (all 13 pages) and I'm still seeing issues with "Intel(R) Dual Band Wireless-AC 3160" cards (the low end of the VHT cards). 

 

What I see:  Two dell laptops (different models but with the same card and OS) will initally associate with 5 ghz radios but then end up on 2.4.  Sometimes they will disconnect all together, but 99% of the time its just the roaming to 2.4.  I tried forcing 5 ghz on the adapter, and it would work for a few min and then just stop working.  I suspect it is something with the Intel drivers.  I say this because the SAME hardware worked fine under windows 7, but upgrading to windows 10 (fresh installs) seemed to start the issues.  I don't see any of these issues with any other systems on the network.  I'm kinda bummed since I bought these cards to benefit from the 802.11ac speeds but they never stay on it. 

 

Driver: 18.21.0.2 (dated 9/24/2015)

OS: Windows 10 64 bit TH2

U-APSD on or off made no difference

802.11k on/off made no difference

Quiet IE on/off made no difference

Turning off VHT on the adapter made no difference

client match and band steering made no difference

AP: AP 225 and AOS 6.4.3.6

Quiet RF environment and about 20 feet from the AP.

Usually prior to roaming to 2.4 I will see the retired frames go to 100% on the controller to client. 

 

Anyway, it seemed like everyone on here was having almost the exact same symptoms but they were able to resolve them in one way or another, so I'm just wondering if I'm missing something and if anyone has a suggestion.  Thanks in advance. 

Are you broadcasting your SSID on both 2.4 and 5ghz? If so, what are your
min/max eirp set to and what power levels are your APs actually setting to?

Yes same SSID on both bands

5ghz min 9 max 18

2.4 min 9 max 15

AP ERIP is running at 5ghz: 18 and 2.4: 15

I have tried lowing the ERIP on the 2.4 band, I didn't have any noticable difference doing that.

netsh wlan show int shows a signal of 98-99% same when on 2.4.  

If I do a netsh wlan connect name=<SSID> it will ALWAYS reconnect to the 5 ghz.  Then after anywhere from 1 min to 15 it will end up on 2.4.  I don't think I've ever seen it go back to 5 on its own after that.  Does that make any sense?  While writing this post I just saw it happen again!  

The issue sounds very different from mine. I had a 5ghz only SSID and
disconnects occurred. Despite the changes you've made and the fact that
things worked properly on win7, it still sounds like the chipset just
prefers the 2.4 band. Does the device drop from the network after it
switched bands? I would lower the 2.4 power to 12dbm if it still provided
enough coverage. Is it possible to disable 2.4 for the SSID?

arubasecrets

 

as Jay mentioned in his post, try setting the power difference between 2.4 and 5ghz to be a little wider. For a test, do this by moving both the arm min and arm max power, set it to be something like

g-tx-min=9,  g-tx-max=12,  a-tx-min=18,  a-tx-min=21

 

you can also try also changing the power saving settings of the card (properties) and de-select "Allow the computer to turn off this device to save power" in the Power Management section of the driver. Try also changing the roaming aggressiveness in the driver to 'lower'.

 

the other possiblity is that something the AP is doing is triggering the client to roam - try setting the AP on different 5ghz channels to see if that helps (to do this, you need to create an arm profile with assigment set to "disable", then create a new 11a radio profile that uses this ARM profile, and set the channel and power as preferred. You can then apply this to a single AP using "ap-name" config. Example CLI commands below.

 

 

conf t
  rf arm-profile test
    assignment disable
  ! 
  rf dot11a-radio-profile test
    arm-profile test
    channel X
    power Y
  !
  ap-name someApToChange
     dot11a-radio-profile test
  !
!

 

 

Try setting the AP to channel 36E (for example), then try 161E which is the opposite end of the band- does it behave any differently.

 

You mentioned that VHT disable had been tried, how did you disable it exactly ? (there is more than one way to do it)

 regards

-jeff

 

 

Thanks for the advise, I did play with making the 2.4 weaker to see if that would help, but not to that extreme, so I just set them per your recommendation and I'll let it run like that.

Yeah, I might just do away with the dual band SSIDs but I've read a lot on the intel forums that it seems to be a huge problem with these cards and windows 10 in general.  I may buy a non-intel one and pop it in and see what happens.  I'll let you know what I find.  

Well I tried everything with the intel card, different settings, different drivers - even tried the just released Wireless_18.32.0_PROSet64_Win10 drivers from 1/19/16.  I put in a Broadcomm BCM94352HMB 802.11ac card and it has stayed on the 5ghz band since I installed it.  So I supsect something is defective with the intel drivers, or at least with windows 10 and this laptop.

Thanks,

Mike

Thanks for the info, Mike .

We had the same issue and all we did is disable "Advertise Quite IE" 

 

I saw the yellow ! while running 7260 with 18.32.0.5 drivers.  I have since disabled VHT and quiet IE.  We are monitoring......

follow up : these changes appear to have solved the issue.  On a side note,  I am hearing from others that 18.40 drivers are fixing a bunch of other issues in cisco and aruba.

Seeing disconnect and roaming issues here with 7260-N and 7265-N cards and AP-215s with VHT enabled on the SSID.

Clients frequently roaming and moving back to 2.4ghz even with driver set to prefer 5ghz and client connected at -60 or better.

Did anyone get to the bottom of the issues with these cards ?

Thanks

Lee

Please start a new thread.  Your problem could be a general issue and not specifically with Intel.

---

@lee_d_m wrote:
Seeing disconnect and roaming issues here with 7260-N and 7265-N cards and AP-215s with VHT enabled on the SSID.

Clients frequently roaming and moving back to 2.4ghz even with driver set to prefer 5ghz and client connected at -60 or better.

Did anyone get to the bottom of the issues with these cards ?

Thanks

Lee

---

To be honest, you have a fair question for this thread "Did anyone get to the bottom of issue with these cards?"

 

Your other description, like clients roaming to the 2.4ghz could mean that there is not enough power separation between the 2.4ghz and 5ghz  band.  The 5ghz should be 3 to 6 dbm stronger than the 2.4ghz band to ensure that clients do not favor the 2.4ghz band, in general.  It might not be an Intel Issue.

Hello,

Over a year later and this still looks to be an issue.  I have several computers (~12) using the Intel AC 7260.  This specific vendor is still selling PCs with the AC 7260 as an option.  Over the past couple months, some of these computers have started to experience intermittent connectivity issues like what has been posted in this thread.

 Here’s what I’m experiencing:

• After a reboot, the PC connects to the wireless SSID fine.  I start a constant ping from the PC to one of the Google DNS servers (8.8.8.8).  But from anywhere from 5-60mins (varies) the connection will stop passing traffic (ping times out with Destination unreachable.)
• After the disconnect, the wireless icon in the taskbar will continue to say connected, even though nothing is pingable, not even it’s gateway.  Soon after, the infamous yellow "!" shows up.
•  If I then try and switch from that SSID to another (like my cell phone's hotspot), the connection icon turns to a red “X” and says that there are no networks available.
• If I reboot the PC, the connection connects as expected, but again quits passing traffic within 5-60mins.
•  I’ve checked Event Viewer and there are no errors listed, other than not being able to connect to a DNS or NTP server, which is expected if the network connection drops.  Otherwise, there are no errors prior to or after the connection quits passing traffic, or when it switches to the red “X”.

 

Here’s what I’ve done to test this issue:

• Completely wiped the hard drive and installed 64bit Windows 7 from scratch, installing all the manufacturer's drivers listed here:  https://www.logicsupply.com/ml210g-10/#specs
• Did not apply any Windows patches or 3rd party applications at this point because I wanted a vanilla baseline to test on. I also wanted to ensure there wasn’t a Microsoft patch that was interfering with the adapter. I currently have some of these PCs running just fine on my wireless network, but some have started to experience this issue. So I was thinking something must have changed on these PCs to suddenly stop working.
• I created a new WPA2 wireless connection with default settings (Using Aruba IAP access points.)
• After experiencing the issue with the above setup, I eliminated my wireless network from the equation by connecting to my cell phone’s hot spot (Samsung Galaxy S6 using the stock hotspot settings.) Same issue with this setup.
• I’ve turned off the setting “Allow the computer to turn off this device to save power”.
• I’ve made sure that the Power Saving Mode for the “Wireless Adapter Settings” is set to “Maximum Performance”. 
• Tried to change the various settings on the client's adapter.
  • Forcing to either 2.4 or 5
  • Disabling VHT (This does seem to make the connection more stable, but eventually disconnects.)
  • Disabling WMM
  • Rolling back to older drivers...(as old as 17.13.1.13)
• Rolled back my Aruba firmware to 6.4.4.8-4.2.4.5
• Installed a newer, Standard (instead of Conservative) version of Aruba firmware (6.5.2.0)

Nothing seems to resolve this issue.  Because I eliminated Aruba from the equation and still experienced issues, this really points the finger at Intel.  Because I have several of these PCs and only a couple have started to act like this, could it be faulty hardware?  (Chipset's failing?)

Please check for the latest driver here:  https://www.intel.com/content/www/us/en/support/network-and-i-o/wireless-networking/000005559.html?wapkw=intel+driver+versions

 

Which version were you testing with?

Most of my testing has been with that version (18.33.7.2).  Only until I read the 15 pages here did I start rolling back to 17.13.1.13, as well as 18.12.0 and 18.20.0.

 

All had the same results.

We have the same on going issue for multiple years, the only sollution we have been able to establish is to shut off HT and VHT. This solves the disconnect issues though it does limit the clients to a maximum of 54Mb