Higher Education

Hello,

We have been steadily upgrading our old AP-61/65/70 abg access points to 105/93H 'n' access points.
As this has happened the number of complaints from linux users has increased.

We cannot control devices that students bring on campus or the operating systems they choose to run.

In my own testing (using a single ap-group so all settings across AP's are the same), my test device was a thinkpad with an intel 1000bgn adapter running Ubuntu 12.04 LTS.

On our captive portal SSID on the 802.11n AP's linux performs fine.
On our dot1x wpa2-aes SSID on the 802.11n AP's linux connects, and the performance is terrible
On our dot1x wpa2-aes SSID on the 802.11n AP's, if I disable the 'n' rates on the linux host, the performance is good.
On our dot1x wpa2-aes SSID on the AP-61, linux performs fine.
On our dot1x wpa2-aes SSID on the 802.11n AP's with a specific USB 802.11n adapter (Ralink & tplink) I am told linux is fine (someone else tested that, I did not observer)

I would like to know if anyone else is having the same issues, or if there are any suggestions for me.

Thanks,

Matt

For the affected cards.  I have asked now to get the card/driver but I don't have enough replies yet, thanks.

intel 1000bgn card is affected

intel wireless 5100agn card is affected

We saw an issue that seem similar.  I found that the user could connect and stay connected to eduraom but not our campus SSID.  The only difference on the two was Bandsteering.  

The user disabled 11n (using the commands from the 3rd link below )and then worked fine.

Previous Thread on Community

http://community.arubanetworks.com/t5/ArubaOS-and-Controllers/Connection-Problem-in-Linux/td-p/4340

The user disabled 11n and then worked fine.

Here are the posts-

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/420678

http://ubuntuforums.org/showthread.php?t=2030227

Chris Hart

Northwestern University

Matt,

The first place that I would start is to see if there are any updated drivers available in a repository for these cards.

Thanks for the suggestions.

On our two SSID profiles, both have band steering.  the dot1x profile is eduroam, and the other is our captive portal.
I will try a dev SSID without band steering and see if there is a difference.

For the drivers, a colleague more familiar with Linux than I has I think tried that, but I will double check.

Regards,

Matt

Disabling band steering on the VAP did not help. 
The performance remains poor.

If i do pings to my gateway or to a website 

the pings happen fine for a few seconds, and then everything appears to stop for a few seconds.  (over and over)

We had a problem with Linux users getting connected to our .1x or WPA2 PSK SSIDs but they could only send traffic for a minute or two at best.  Upgrading to 6.3.1.0 did not fix the problem (although we did get to start playing with AirGroup).  Here is what fixed it for us, right from the Aruba TAC:

"Upon further research found that there was a problem with client linux driver's MPDU aggregation mechanism and it's possible that somehow Linux MPDU aggregation (both in ath9k - atheros and Intel drivers in Linux) suffers this problem.

As a workaround, could you please try to disabled MPDU Aggregation in our controller configuration and please check the status of the client communication.

Under High-Throughput SSID Profile, we have the feature called "MPDU Aggregation". So could you plesae try to disable this " MPDU Aggregation" in the ht-ssid-profile, which will be inside of the SSID profile."

Good luck!

Aaron

Thanks Aaron, 

I will try that.

Regards,

Matt

I found a solution for Linux with Intel cards that works for some of my coworkers. Basically, you disable 802.11n speeds and the driver behaves reliably.

Here is a temporary solution that does not survive a reboot. 

sudo modprobe -r iwlwifi

sudo modprobe iwlwifi 11n_disable=1

Does any one know the affects of turning off MPDU aggragation? 

I'm going to test it, but I want to make sure that I'm not hindering other clients for the sake of a small population.

Hi Aaron,

On my test SSID I made the change as suggested and it worked.  

I am also interested in knowing what we are losing with this disabled,  how often are packets aggregated together with AMPDU, as charlesr asked.

I will however been making this change for my campus tomorrow.

Thanks,

Matt

It was explained to me that MPDU Aggregation is used to improve performance in mesh networks.  Since making the change I have not had any problems get traced back to that feature, at least not yet.  It has been running for about a month now.  I hope that helps.  If folk are looking for more detials, maybe someone from Aruba could chime in with more technical details.

Making this setting change has helped my linux users, however my Microsoft surface pro users cannot connect on eduroam now.

The adapter is: Marvell AVASTAR 350N Wireless

The users associate, radius authentication passes, I see the DHCPDISCOVER, we send from the server DHCPOFFER and the client never gets an IP.

I haven't installed wireshark yet, but I have tested that re-enabling MPDU Aggregation fixes things for surface pro.

~Matt

An update, the surface pro sometimes succesffully DHCP's but will fail to work after that.
Looking at wireshark, filtered on ICMP, if do a continuous ping of my gateway from the surface pro, no traffic is generated as coming from the surface pro.

For the Surface issue, go under your HT ssid-profile and disable LDPC. Let me know if that works for you.

So...I had a chromebook client in my test area that started to have problems once I turned off MPDU. I just turned off LDPC for the area, and he can now connect.

I'm going to push this change out to a couple more test areas, and see what happens.

I had opened a case months ago and Aruba finally discovered the issue. If an LDPC enabled client connects to an AP, and the AP is configured with 20MHz channels, and a Surface tablet (client in my case) is far enough to require RTS/CTS frame usage, the Surface would have these failures. Workaround was to disable LDPC or use 40MHz channels. Bug is with Aruba+20MHz+LDPC. Fix pending in an upcoming release.

That's all I know.

I tried disabling LDPC, but that unfortunately did not help.

The AP's I am using are AP-93H and AP105.

DHCP from the surface is usually successful, on occasion when i disconnect and reconnect to the SSID while a continuous ping is running i have observed a few ping replies. followed by a stream of 'Destination host unreachable' or 'Request timed out'

MattV, I'm not sure if you saw Peter Lane's (plane) post about the surface in another thread, and how he fixed a similar issue with a registry / driver update, it's in this thread: http://community.arubanetworks.com/t5/Education/Chromebooks-on-802-1x-SSIDs-issues/gpm-p/112769/page/3

That might be what you're looking for with the Surface. 

-awl

I tried the below, but it did not help.
""

netsh int tcp set heuristics disabled

    Press ‘Enter’. You would see ‘Ok’ as answer. Now, type the following:

netsh int tcp set global autotuninglevel=disabled

    Press ‘Enter’. You would see ‘Ok’ again. Type the following now:

netsh int tcp set global rss=enabled

    Press ‘Eneter’ and you would see ‘Ok’.

"

One thing i see now,  on the surface pro, if I do an " arp - av"   It shows my gateway as Type Invalid.

In case anyone else is having this issue with Surface Pro,

We have found that for the adapter Marvel AVASTAR 350N Wireless Network Controller, using the newest Marvel signed driver does not work when MPDU Aggregation is disabled.  However, using the Microsoft signed driver version 14.69.17064.93 does work.

We had to unistall the marvel driver and remove it from the comptuer (and repeat to get back to the Microsoft driver). 
Followed by a reboot.

~Matt

We're still having problems with surface pro; the work around still works; I have a few more details.

With MPDU Aggregation disabled on our wireless subnet  ( /16 ) ; the surface pro completes the 802.11 auth and assoc, completes the 802.1X auth, starts the DHCP process and usually gets an IP and then stops working.

With MPDU Aggregation ENABLED on our wireless subnet  ( /16 ) ; the surface pro  works fine.

With MPDU Aggregation disabled on a test wireless subnet  ( /27 ) ; the surface pro works fine.

I called microsoft customer support for my surface, I was told to just try updating every 2 weeks to see if it works, if it doesn't roll back to the work around driver. (14.69.17064.93)

This doesn't help the surface RT 2 which suffers the same issue.

ArubaOS 6.3.1.2 release notes:

Unfortunately I am on 6.3.1.2 and am still having surface pro issues.

MattV,

The thread title is "Students and Staff Linux on Wifi".  It is probably best that you open a separate thread for Surface issues, that way only people who have information to give on the surface participate.