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@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 - rull...@uic.edu
> Systems Administrator
> Enterprise Applications & Services | Technology Solutions
> University of Illinois - ChicagoFrom: Hugh Irvine <h...@radiatorsoftware.com>
> Sent: Thursday, August 24, 2023 10:46 PM
> To: Ullfig, Roberto Alfredo <rull...@uic.edu>; Dubravko Penezic
> <dpene...@srce.hr>; radiator@lists.open.com.au <radiator@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 - rull...@uic.edu
>> Systems Administrator
>> Enterprise Applications & Services | Technology Solutions
>> University of Illinois - ChicagoFrom: Ullfig, Roberto Alfredo
>> <rull...@uic.edu>
>> Sent: Thursday, August 24, 2023 1:19 PM
>> To: Dubravko Penezic <dpene...@srce.hr>; radiator@lists.open.com.au
>> <radiator@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 - rull...@uic.edu
>> Systems Administrator
>> Enterprise Applications & Services | Technology Solutions
>> University of Illinois - ChicagoFrom: Dubravko Penezic <dpene...@srce.hr>
>> Sent: Thursday, August 24, 2023 8:34 AM
>> To: Ullfig, Roberto Alfredo <rull...@uic.edu>;
>> radiator@lists.open.com.au<radiator@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@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 - rull...@uic.edu
>> > Systems Administrator
>> > Enterprise Applications & Services | Technology Solutions
>> > University of Illinois - Chicago
>> >
>> > _______________________________________________
>> > radiator mailing list
>> > radiator@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@lists.open.com.au
>> https://lists.open.com.au/mailman/listinfo/radiator
> _______________________________________________
> radiator mailing list
> radiator@lists.open.com.au
> https://lists.open.com.au/mailman/listinfo/radiator
_______________________________________________
radiator mailing list
radiator@lists.open.com.au
https://lists.open.com.au/mailman/listinfo/radiator
