Wireless Access

I have several users with Nexus devices unable to log on to the WLAN.  Was wondering if anyone else has seen this issue?

Android 6.0 has been out for a year and it has worked for a year.  What are the specifics of your problem?

What encryption is being used?  If so, what kind?

Is authentication being used?  If so, what kind?

Who is the handset manufacturer?

Unfortunately I have been unable to contact any of my customers who are having issues yet to find out specifics.  I run wireless on a large college campus and the helpdesk has reached out to me saying that they have had multiple students complaining of Google Nexus handsets unable to connect.  I believe that Huawei manufactures Nexus handsets for Google.  That about sums up the details I have at this time.  I was just curious if anyone else in the Airheads community has been getting/seen similar complaints.

The newest version of Android is Android 7 and Huawei makes the Nexus 6p.  Both have worked since the Nexus 6p came out and since android 7 came out.  Many times users who upgrade to the latest have also rooted their phones or are running custom roms, which could lead to further confusion or issues.  We need specific information about authentication, encryption on the network and the devices otherwise we cannot be of help.

Thanks for all your worldly advice.  Was really just interested to see if any one else has had similar issues, which I thought was plainly stated.

.

Just to follow up on this in case anyone else had similar issues.  This does not appear to be anything related to the Aruba controller.  It seems that Nexus Androids 5x and above running Nougat are not able to verify the certificate from our RADIUS server when logging on to the WLAN.  Other Androids have no problem with this.  The work around is to set the device to "Do not verify" in the certificate drop down.  There are quite a few reports of this issue on Google's Nexus Help Forum as well.

---

@smartin wrote:

Just to follow up on this in case anyone else had similar issues.  This does not appear to be anything related to the Aruba controller.  It seems that Nexus Androids 5x and above running Nougat are not able to verify the certificate from our RADIUS server when logging on to the WLAN.  Other Androids have no problem with this.  The work around is to set the device to "Do not verify" in the certificate drop down.  There are quite a few reports of this issue on Google's Nexus Help Forum as well.

I resolved one version of this issue (Android 7) back in January and had the Help Desk update our documentation at that time - and there's documentation on some eduroam universities - but wanted to post for reference for anyone that finds this. Note this was Android 7 - Nougatt.

Background:

Back in August, a student had switched to a new Nexus 5X and was unable to connect to our wireless network "PEAP-MSCHAPv2" without specifying "Do Not Verify" under the CA certificate settings. The default "Use System Certificates" requires a Domain (Must Specify Domain) otherwise the "Save" button remains greyed out.


January:
Shift forward a few months to January when a new password change system was implemented and our IT department was encouraged to go through an account refresh before campus deployment. My co-worker was running an Android 7 phone by HTC, forgot the network to change his password, and upon configuring the new profile, found that he ran into this issue. I looked into it more and found that the Domain field needs to come from the CN/SAN of the radius certificate - not the "Active Directory - Domain/User-Name" like in previous versions of Android. I tested this on several co-workers Android 7 devices - and each of them now connect by verifying the certificate. I had our Help Desk update our KB Article to specify the CN domain for Android 7.X devices.

My co-worker's issue was the 2nd report of this issue in the 5 months of first finding this. If students had a working saved WLAN profile and then updated to Android 7 - like my 3 coworkers had initially done, the WLAN Profile would have converted without user knowledge to "Do not verify" and continue functioning up until the point forgot the network - which usually occurs during password changes.

cbjohns,

I agree with your solution entireley.  We also found the same with the domain and no longer use the "do not verify" option.  FYI - I also saw this with the Pixel XL a couple of days ago.

Looks like this might hapen on a pixel 2 running Android 8 as well .

Alexsuoy,

I ran the Pixel for one year and have been running the pixel 2 since it came out on 802.1x with a range of access points on ArubaOS 6.5 and I don't have a problem.

If you have a recurring problem, please open a case with TAC.  It could be configuration or your environment.

It would appear that setting the Domain name to be ( in our case) york.ac.uk fixed the problem. Note:- this is a Pixel 2 running Android 8. Haven't seen this issue before with lower versions of Android

Sigh! Unfortunately not as simple as that. Still having issues with A8. However, wht we;ve noticed is although the client device doesnt  look as if its connected, clearpass and and the mobiliy controller do think it is .... and if I send a CoA Aruba bounce-port  command from clearpass for the last authenticated session, the client device springs into life. currently no idea why ...

A

How long has this been happening, and what changes have been made recently?  The bounce port should not really be needed as a part of basic 802.1x authentication for connectivity.

The only change was the introduction of a Pixel 2 running A8 :-)

We were running 802.11r in our building and have done for a long long time ... just switched it off and  one of the problemmatic ones started working. Our productino wifi doesn. t have 11r enabled and both phones work there

802.11r is treated different by so many different clients, that I would not bother running it in a mixed client environment.  Some clients like it, others do not and act unpredictably.  The benefits do not justify leaving it enabled.  Robust 802.11r support is not pervasive and it is not necessary for good roaming performance.

UPDATE 6/2018 -  The updated RF and Roaming Optimization Validated Reference Design Guide (VRD) has been published and has updated recommendations about enabling 802.11v, k and r in user networks.  The VRD can be found here: http://community.arubanetworks.com/t5/Validated-Reference-Design/RF-and-Roaming-Optimization-for-Aruba-802-11ac-Networks/ta-p/432994

Agree, that's what we found. That's why it isn't enabled on our production WiFi. Our building has its own controller and I apply software updates and play with things on it. Been running with 11r for months and months and months and the only issue we had was 1 windows machine with an out of date driver, which was fixed. 

Other phones running A8 work fine, just seems to be the pixel 2

A