[RADIATOR] UNS: Basic Question on 802.1X

Hugh Irvine hugh at irvine.com.au
Fri Aug 25 22:15:31 UTC 2023


Hello Roberto -

Yes, loadbalancers usually employ some method to determine the “aliveness” of the configured targets.

I’ve seen cases where RADIUS requests are used, and yes Access-Reject is an indication of “aliveness”.

regards

Hugh


> On 26 Aug 2023, at 01:53, Ullfig, Roberto Alfredo via radiator <radiator at lists.open.com.au> wrote:
> 
> 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 - ChicagoFrom: 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
>> Systems Administrator
>> Enterprise Applications & Services | Technology Solutions
>> University of Illinois - ChicagoFrom: Ullfig, Roberto Alfredo <rullfig at uic.edu>
>> Sent: Thursday, August 24, 2023 1:19 PM
>> To: Dubravko Penezic <dpenezic at srce.hr>; radiator at lists.open.com.au <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
>> Systems Administrator
>> Enterprise Applications & Services | Technology Solutions
>> University of Illinois - ChicagoFrom: Dubravko Penezic <dpenezic at srce.hr>
>> Sent: Thursday, August 24, 2023 8:34 AM
>> To: Ullfig, Roberto Alfredo <rullfig at uic.edu>; radiator at lists.open.com.au<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
>> > Systems Administrator
>> > Enterprise Applications & Services | Technology Solutions
>> > University of Illinois - Chicago
>> > 
>> > _______________________________________________
>> > radiator mailing list
>> > 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
>> 
>> _______________________________________________
>> radiator mailing list
>> radiator at lists.open.com.au
>> https://lists.open.com.au/mailman/listinfo/radiator
> _______________________________________________
> radiator mailing list
> radiator at lists.open.com.au
> https://lists.open.com.au/mailman/listinfo/radiator




More information about the radiator mailing list