Android 2.3.5 supplicants failing after upgrade to FreeRADIUS 2.2.5 from 2.2.0

[Robert Franklin]

Hello,

We've suddenly started having reports of problems authenticating to our eduroam 802.1X service from users with Android 2.3.5 phones since an upgrade of FreeRADIUS on Tuesday morning this last week.  As far as we're aware, no other body of users are affected, including newer Android devices: our Service Desk are just noticing this OS as a significant pattern.

We were running FreeRADIUS 2.2.0, running on SLES 11 SP2, but upgraded to 2.2.5 and SLES 11 SP3, as far as we're aware, no other changes were made to the configuration, nor certificates.

This is aside from a period of about 45 minutes following the upgrade where a mistake in the RPM caused the sites-available/default and inner-tunnel files to be overwritten with the default ones, before our local copies were reinstated.  This obviously trashed much of our local configuration, causing authentication to fail for a period.  We know at least one user affected tried to connect during this time but are unsure if all the affected users also did so, nor if other Android 2.3.5 users are successful (I'm trying to lay my hands on one which didn't).

This situation may have upset the phones but we've tried removing the configuration from them, restarting them and then re-entering everything, but still they cannot connect.

I have tried the same username/password on a Windows 7 laptop, also using EAP/PEAP and that connects fine.


Looking at the debug (with raddebug on the Calling-Station-Id of an affected device's MAC address; a '-X' is a little busy) it seems to engage in an EAP dialogue with FreeRADIUS but then stops partway through.

I've attached a gzipped copy of the raddebug -- I could send "radiusd -X" but I don't think there'll be anything pertinent in there as all the other supplicants are working, but I'm happy to, if necessary.  The big lumps of hex in the EAP stuff doesn't make sense to me (I'm hoping it does to someone else!) but I have compared it with a successful device (an iPhone with a different username) to see where they differ.

Everything seems OK up to request 21021170 (which finishes on line 646 of the file), where an Access-Challenge goes back to the supplicant.  The following Access-Request has a very short EAP-Message compared to the successful iPhone, which makes me think EAP is aborting/restarting or broken somehow.  On the iPhone, after two more packets, peap reports that TUNNEL ESTABLISHED, whereas the Android device never does.

Please let me know if you need anything else.


There may be something else that has broken on the server, or a bit of configuration that has been corrupted, but it's odd it's just (apparently) affecting this class of device, but we don't think we've changed certificates or anything else.

The weird thing here is why just Android 2.3.5 (or possibly everything < version 3?) is failing, following the upgrade.  I can't spot anything has changed in the FreeRADIUS release notes that I might need to change, nor any reports of similar problems.


Thanks in advance for any help,

  - Bob


-------------- next part --------------
A non-text attachment was scrubbed...
Name: android-2.3.5-dot1x-fail.txt.gz
Type: application/x-gzip
Size: 37692 bytes
Desc: not available
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20140530/44ac190e/attachment-0001.bin>
-------------- next part --------------



-- 
Bob Franklin   rcf34 at cam.ac.uk / +44 1223 748479
Networks, University Information Services, University of Cambridge