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@lists.freeradius.org] Im Auftrag von Stefan Winter Gesendet: Donnerstag, 23. März 2017 08:21 An: freeradius-users@lists.freeradius.org <mailto:freeradius-users@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@po-box.esu.edu <mailto:jtobin@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@lists.freeradius.org on
behalf of BJulin@clarku.edu <mailto:BJulin@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
-
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