AW: iOS mysterious issues on Freeradius 3.0.14

Thu Mar 23 08:48:26 CET 2017

Hello,

we are expieriencing the same issues in our network.

We were able to reproduce the problems and it's totally the fault of iOS.

If a user is walking through the building and iOS is roaming through the 
various access points, than

in some point the wifi client software on iOS is running into a memory 
overflow or something, after 6-7 incomplete

logins because of poor signal strength. After reaching this point, 
either the wifi must be disabled for few seconds and

then it works or the device must be restarted.

Our other clients doesn't have these issues.

Kind regards.

D. Stabla

-----Ursprüngliche Nachricht-----

Von: Freeradius-Users 
[mailto:freeradius-users-bounces+dstabla=materna.de at lists.freeradius.org] 
Im Auftrag von Stefan Winter

Gesendet: Donnerstag, 23. März 2017 08:21

An: freeradius-users at lists.freeradius.org 
<mailto:freeradius-users at lists.freeradius.org>

Betreff: Re: iOS mysterious issues on Freeradius 3.0.14

Hi,

I was seeing something /very/ similar to the below TLS error recently

and that was because the expected *server name* I configured in the

client didn't match what my server was actually sending.

Despite the usual suspects like typos in client config, you may also

want to check for wildcard names in certs, or things that are not

hostnames (spaces...) - clients sometimes choke on harmlessly looking

things.

Greetings,

Stefan Winter

Am 22.03.2017 um 21:54 schrieb John Tobin:

 > The log snip below, shows test on os x Sierra, Windows 7 works, I 
have not

 > had the time to test win 10.

 > So free Radiusd works, this is just an apple os x problem, server cert is

 > self signed, dot1xprofiler is my profile app, and has both the signed 
cert

 > [server.pem] and client cert [client.p12] generated by the make in

 > /etc/raddb/certs.

 >

 > On 3/22/17, 16:37, "John Tobin" <jtobin at po-box.esu.edu 
<mailto:jtobin at po-box.esu.edu>> wrote:

 >

 >> Ah, you mean like this: [ERROR: TLS is down a bit, I took the entire

 >> transaction out of the logŠ]

 >>

 >> (86) Received Access-Request Id 196 from 10.99.7.190:1645

 >> <http://10.99.7.190:1645/> to 10.99.7.21:1812 <http://10.99.7.21:1812/>

 >> length 153

 >> (86)User-Name = "tobi1"

 >> (86)Framed-MTU = 1400

 >> (86)Called-Station-Id = "0022.90bd.9500"

 >> (86)Calling-Station-Id = "0025.4b8e.15b9"

 >> (86)Service-Type = Login-User

 >> (86)Message-Authenticator = 0x5f033b48ec2f2a210b5e0ce5379cdf49

 >> (86)EAP-Message = 0x0205001119800000000715030100020100

 >> (86)NAS-Port-Type = Wireless-802.11

 >> (86)NAS-Port = 394

 >> (86)NAS-Port-Id = "394"

 >> (86)State = 0xe046c6d9e243dfdaa11e15be1d36d7b4

 >> (86)NAS-IP-Address = 10.99.7.190

 >> (86)NAS-Identifier = "ap"

 >> (86) session-state: No cached attributes

 >> (86) # Executing section authorize from file

 >> /etc/raddb/sites-enabled/default

 >> (86)authorize {

 >> (86)policy filter_username {

 >> (86)if (&User-Name) {

 >> (86)if (&User-Name)-> TRUE

 >> (86)if (&User-Name){

 >> (86)if (&User-Name =~ / /) {

 >> (86)if (&User-Name =~ / /)-> FALSE

 >> (86)if (&User-Name =~ /@[^@]*@/ ) {

 >> (86)if (&User-Name =~ /@[^@]*@/ )-> FALSE

 >> (86)if (&User-Name =~ /\.\./ ) {

 >> (86)if (&User-Name =~ /\.\./ )-> FALSE

 >> (86)if ((&User-Name =~ /@/) && (&User-Name !~ /@(.+)\.(.+)$/)) 
<mailto:/@%28.+%29%5C.%28.+%29$/%29%29>{

 >> (86)if ((&User-Name =~ /@/) && (&User-Name !~ /@(.+)\.(.+)$/)) 
<mailto:/@%28.+%29%5C.%28.+%29$/%29%29>

 >> -> FALSE

 >> (86)if (&User-Name =~ /\.$/){

 >> (86)if ((&User-Name =~ /@/) && (&User-Name !~ /@(.+)\.(.+)$/)) 
<mailto:/@%28.+%29%5C.%28.+%29$/%29%29>

 >> -> FALSE

 >> (86)if (&User-Name =~ /\.$/){

 >> (86)if (&User-Name =~ /\.$/)-> FALSE

 >> (86)if (&User-Name =~ /@\./ <mailto:/@%5C./>){

 >> (86)if (&User-Name =~ /@\./ <mailto:/@%5C./>)-> FALSE

 >> (86)} # if (&User-Name)= notfound

 >> (86)} # policy filter_username = notfound

 >> (86)[preprocess] = ok

 >> (86)[chap] = noop

 >> (86)[mschap] = noop

 >> (86)[digest] = noop

 >> (86) suffix: Checking for suffix after "@"

 >> (86) suffix: No '@' in User-Name = "tobi1", looking up realm NULL

 >> (86) suffix: No such realm "NULL"

 >> (86)[suffix] = noop

 >> (86) eap: Peer sent EAP Response (code 2) ID 5 length 17

 >> (86) eap: Continuing tunnel setup

 >> (86)[eap] = ok

 >> (86)} # authorize = ok

 >> (86) Found Auth-Type = eap

 >> (86) # Executing group from file /etc/raddb/sites-enabled/default

 >> (86)authenticate {

 >> (86) eap: Expiring EAP session with state 0xe046c6d9e243dfda

 >> (86) eap: Finished EAP session with state 0xe046c6d9e243dfda

 >> (86) eap: Previous EAP request found for state 0xe046c6d9e243dfda,

 >> released from the list

 >> (86) eap: Peer sent packet with method EAP PEAP (25)

 >> (86) eap: Calling submodule eap_peap to process data

 >> (86) eap_peap: Continuing EAP-TLS

 >> (86) eap_peap: Peer indicated complete TLS record size will be 7 bytes

 >> (86) eap_peap: Got complete TLS record (7 bytes)

 >> (86) eap_peap: [eaptls verify] = length included

 >> (86) eap_peap: <<< recv TLS 1.0 Alert [length 0002], warning 
close_notify

 >> (86) eap_peap: ERROR: TLS_accept: Failed in unknown state

 >> (86) eap_peap: ERROR: SSL says: error:140940E5:SSL

 >> routines:ssl3_read_bytes:ssl handshake failure

 >> (86) eap_peap: ERROR: SSL_read failed in a system call (-1), TLS session

 >> failed

 >> (86) eap_peap: ERROR: TLS receive handshake failed during operation

 >> (86) eap_peap: ERROR: [eaptls process] = fail

 >> (86) eap: ERROR: Failed continuing EAP PEAP (25) session.EAP sub-module

 >> failed

 >> (86) eap: Sending EAP Failure (code 4) ID 5 length 4

 >> (86) eap: Failed in EAP select

 >> (86)[eap] = invalid

 >> (86)} # authenticate = invalid

 >> (86) Failed to authenticate the user

 >> (86) Using Post-Auth-Type Reject

 >> (86) # Executing group from file /etc/raddb/sites-enabled/default

 >> (86)Post-Auth-Type REJECT {

 >> (86) attr_filter.access_reject: EXPAND %{User-Name}

 >> (86) attr_filter.access_reject:--> tobi1

 >> (86) attr_filter.access_reject: Matched entry DEFAULT at line 11

 >> (86)[attr_filter.access_reject] = updated

 >> (86)[eap] = noop

 >> (86)policy remove_reply_message_if_eap {

 >> (86)if (&reply:EAP-Message && &reply:Reply-Message) {

 >> (86)if (&reply:EAP-Message && &reply:Reply-Message)-> FALSE

 >> (86)else {

 >> (86)[noop] = noop

 >> (86)} # else = noop

 >> (86)} # policy remove_reply_message_if_eap = noop

 >> (86)} # Post-Auth-Type REJECT = updated

 >> (86)} # policy remove_reply_message_if_eap = noop

 >> (86)} # Post-Auth-Type REJECT = updated

 >> (86) Delaying response for 1.000000 seconds

 >> Waking up in 0.3 seconds.

 >> Waking up in 0.6 seconds.

 >> (86) Sending delayed response

 >> (86) Sent Access-Reject Id 196 from 10.99.7.21:1812

 >> <http://10.99.7.21:1812/> to 10.99.7.190:1645 <http://10.99.7.190:1645/>

 >> length 44

 >> (86)EAP-Message = 0x04050004

 >> (86)Message-Authenticator = 0x00000000000000000000000000000000

 >> Waking up in 3.7 seconds.

 >> Š..

 >> Waking up in 0.1 seconds.

 >> (86) Cleaning up request packet ID 196 with timestamp +1294629

 >> Ready to process requests

 >> Ready to process requests

 >> Signalled to terminate

 >> Exiting normally

 >> rlm_ldap (ldap): Removing connection pool

 >> rlm_ldap (ldap): Closing connection (12)

 >> rlm_ldap (ldap): Closing connection (11)

 >> rlm_ldap (ldap): Closing connection (10)

 >> tls: Freeing cached session VPs

 >>

 >>

 >>

 >> On 3/22/17, 13:20, "Freeradius-Users on behalf of Brian Julin"

 >> <freeradius-users-bounces+jtobin=po-box.esu.edu at lists.freeradius.org on

 >> behalf of BJulin at clarku.edu <mailto:BJulin at clarku.edu>> wrote:

 >>

 >>>

 >>>

 >>>

 >>>

 >>>> This is not easy research, since the error messages you receive no one

 >>> else seems to see.

 >>>> My problem may be that apple devices are no longer accepting self

 >>>> signed

 >>> certs, but I have also looked at os x upgrades [home brew/openssl

 >>> problems] for openssl.

 >>>

 >>> If the OS is rejecting the cert (or visa versa), you'll see something

 >>> like:

 >>>

 >>> Error: TLS Alert fatal: blah blah blah

 >>>

 >>> The original poster was getting all the way through MS-CHAP inner

 >>> authentication,

 >>> so it was could not have been a certificate issue since the TLS tunnel

 >>> had successfully

 >>> established.

 >>>

 >>> -

 >>> List info/subscribe/unsubscribe? See

 >>> http://www.freeradius.org/list/users.html

 >>

 >

 >

 > -

 > List info/subscribe/unsubscribe? See 
http://www.freeradius.org/list/users.html

 >

-- 

Stefan WINTER

Ingenieur de Recherche

Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et

de la Recherche

2, avenue de l'Université

L-4365 Esch-sur-Alzette

Tel: +352 424409 1

Fax: +352 422473

PGP key updated to 4096 Bit RSA - I will encrypt all mails if the

recipient's key is known to me

http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66