Surface Pro Kali Linux

[Billie Kjergaard]

Thanksfor 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

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

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.

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.

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.

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'

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

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.

3a8082e126