[RADIATOR] UNS: Basic Question on 802.1X

Fri Aug 25 15:53:27 UTC 2023

Understood about "dropped packets, incorrect load-balancing, or even just out of sequence requests will cause failure." - but with 1 out of 3 login failures shouldn't we be seeing lots of complaints about the inability to connect to WiFi. We did have a network load balancer issue this week that did cause an small uptick in 802.1X failures and this generated many complaints from users unable to login. It seems like these 1 out of 3 login failures aren't actually being generated by a user attempting to login (or they would be complaining) - can wireless controllers send spurious logins to the radius servers, something like a keepalive or are these just failed logins that the user doesn't notice for some odd reason.

---
Roberto Ullfig - rullfig at uic.edu
Systems Administrator
Enterprise Applications & Services | Technology Solutions
University of Illinois - Chicago
________________________________
From: Hugh Irvine <hugh at radiatorsoftware.com>
Sent: Thursday, August 24, 2023 10:46 PM
To: Ullfig, Roberto Alfredo <rullfig at uic.edu>; Dubravko Penezic <dpenezic at srce.hr>; radiator at lists.open.com.au <radiator at lists.open.com.au>
Subject: Re: [RADIATOR] UNS: Basic Question on 802.1X

Hello Roberto -

As EAP is a sequence of RADIUS requests, anything that interrupts the sequence will result in a failure.

Ie. dropped packets, incorrect load-balancing, or even just out of sequence requests will cause failure.

This being the case it is entirely possible that the same device can behave as you observe.

regards

Hugh

On 25/8/2023 04:44, Ullfig, Roberto Alfredo via radiator wrote:
That's not always the case though - for example (log chopped).

Aug 24 07:59:46 802.1X OK
Aug 24 08:01:30 802.1X FAILED
Aug 24 09:15:44 802.1X OK

139983 failed
357509 ok

19714 different mac addresses both had a failure and a success. If it's the same device that's misconfigured it should always fail

---
Roberto Ullfig - rullfig at uic.edu<mailto:rullfig at uic.edu>
Systems Administrator
Enterprise Applications & Services | Technology Solutions
University of Illinois - Chicago
________________________________
From: Ullfig, Roberto Alfredo <rullfig at uic.edu><mailto:rullfig at uic.edu>
Sent: Thursday, August 24, 2023 1:19 PM
To: Dubravko Penezic <dpenezic at srce.hr><mailto:dpenezic at srce.hr>; radiator at lists.open.com.au<mailto:radiator at lists.open.com.au> <radiator at lists.open.com.au><mailto:radiator at lists.open.com.au>
Subject: Re: UNS: [RADIATOR] Basic Question on 802.1X

Yes, I think you're right, I spot checked several of them and they never succeed.

---
Roberto Ullfig - rullfig at uic.edu<mailto:rullfig at uic.edu>
Systems Administrator
Enterprise Applications & Services | Technology Solutions
University of Illinois - Chicago
________________________________
From: Dubravko Penezic <dpenezic at srce.hr><mailto:dpenezic at srce.hr>
Sent: Thursday, August 24, 2023 8:34 AM
To: Ullfig, Roberto Alfredo <rullfig at uic.edu><mailto:rullfig at uic.edu>; radiator at lists.open.com.au<mailto:radiator at lists.open.com.au> <radiator at lists.open.com.au><mailto:radiator at lists.open.com.au>
Subject: Re: UNS: [RADIATOR] Basic Question on 802.1X

Hi Roberto,

if you "only" see FAILD no error or something elese, in you log,  it is
normal and just reflact fact that is more and more devices which try to
connect to eduroam, but doesnt have proper configuration.

Some time on national level logs FAIL to OK may be 70:30%.

Regards,
Dubravko

On 8/24/23 15:28, Ullfig, Roberto Alfredo via radiator wrote:
> My knowledge of our 802.1X configuration is barebones and we inherited
> this configuration from ~20 years ago. We are seeing lots of failures in
> this part for a long time most likely (omitted some more sensitive details):
>
> <Handler Client-Identifier=n8021x>
> #
> # The rock8021x block and 8021x blocks are identical. The rock8021x
> block is needed as it acts
> # differently than the WISMs in that it does a login-user rather than a
> access-request. This
> # interferes with the 8021x clause that we have for uic-guest support
> #
>          <AuthBy FILE>
>                  # Users must be in this file to get anywhere. In this
> example,
>                  # it reques an entry for 'anonymous' which is the
> standard username
>                  # in the outer requests, and it also requires an entry
> for the
>                  # actual user name who is trying to connect (ie the
> 'Login name' entered
>                  # in the Funk Odyssey 'Edit Profile Properties' page
>                  Filename %D/users
>
>                  EAPAnonymous %0 at uic.wireless
>                  EAPType PEAP, TTLS
>                  EAPTLS_PEAPVersion 0
>                  EAPTLS_CAFile /etc/radiator/certificatechain.crt
>                  EAPTLS_CertificateFile /etc/radiator/wireless.crt
>                  EAPTLS_CertificateType PEM
>                  EAPTLS_PrivateKeyFile /etc/radiator/wireless.key
>                  EAPTLS_MaxFragmentSize 1000
>                  AutoMPPEKeys
>                  EAPTLS_SessionResumption 0
>          </AuthBy>
>
>          RewriteUsername s/^([^@]+).*/$1/
>          RewriteUsername s/\s+//g
>          RewriteUsername s/^.*\\(.*)/$1/
>          RewriteUsername tr/[A-Z]/[a-z]/
>
>          <AuthBy SUSPEND>
>                  Dir /mnt/...
>          </AuthBy>
>
>          <AuthBy SUSPEND>
>                  Dir /mnt/...
>          </AuthBy>
>
>          <AuthBy WIRELESS>
>                  Dir /mnt/...
>          </AuthBy>
>
>          AcctLogFileName %L/wireless-detail
>
>          <AuthLog SYSLOG>
>                  LogSuccess 1
>                  LogFailure 1
>                  Facility local0
>                  SuccessFormat %T : '%U' from %C
> mac=%{Calling-Station-Id} NAS-Id=%{Called-Station-Id}
> PEAP-SSID=%{NAS-Identifier} -- 802.1X OK
>                  FailureFormat %T : '%u' from %C
> mac=%{Calling-Station-Id} NAS-Id=%{Called-Station-Id}
> PEAP-SSID=%{NAS-Identifier} -- 802.1X FAILED
>          </AuthLog>
>
> The failure rate is about 1 out of 3! But this does not to appear to be
> impacting anyone. The file "users" does not exist so I assume that
> entire Authby is ignored.
>
> What could be causing these failures? Filesystem access?
>
> ---
> Roberto Ullfig - rullfig at uic.edu<mailto:rullfig at uic.edu>
> Systems Administrator
> Enterprise Applications & Services | Technology Solutions
> University of Illinois - Chicago
>
> _______________________________________________
> radiator mailing list
> radiator at lists.open.com.au<mailto:radiator at lists.open.com.au>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.open.com.au%2Fmailman%2Flistinfo%2Fradiator&data=05%7C01%7Crullfig%40uic.edu%7Ccd24dab7e4a1484609e308dba4a6e17f%7Ce202cd477a564baa99e3e3b71a7c77dd%7C0%7C0%7C638284808887330321%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=QrJdmONwpJpUafGHsjuf4BsGRurB4rcd56JOd4D3%2Fvo%3D&reserved=0<https://lists.open.com.au/mailman/listinfo/radiator>

_______________________________________________
radiator mailing list
radiator at lists.open.com.au<mailto:radiator at lists.open.com.au>
https://lists.open.com.au/mailman/listinfo/radiator
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.open.com.au/pipermail/radiator/attachments/20230825/c83bc758/attachment-0001.html>