How to bypass some logic during EAP-TLS auth?

dominic.stalder at unibe.ch dominic.stalder at unibe.ch
Sun Nov 3 12:45:57 UTC 2024


Hi guys

Can I shortly catch up on this topic, because I have a similar use case as well: I add some missing RADIUS attributes on the first RADIUS request to the request packet and afterwards, this if block will not be hit anymore. Great hint with this session variable, thanks Matthew.

A general question concerning this question: evaluating those if statements 8 times in the first place does not have any performance impact on FreeRADIUS, correct? I think it does not really matter, if FreeRADIUS has to do it. I know it would be more optimal to not have FreeRADIUS evaluate multiple attributes each time, but does it harm the overall performance noticeable?

Thanks and regards
Dominic

Am 02.11.24, 22:11 schrieb "Freeradius-Users im Auftrag von Matthew Newton via Freeradius-Users" <freeradius-users-bounces+dominic.stalder=unibe.ch at lists.freeradius.org <mailto:unibe.ch at lists.freeradius.org> im Auftrag von freeradius-users at lists.freeradius.org <mailto:freeradius-users at lists.freeradius.org>>:

On 02/11/2024 21:05, Alexey D. Filimonov wrote:
>
> Currently I have several if()s in authorize{} before eap and I think I
> can not move it past EAP call
>
> But during EAP authentication I see this logic gets executed 8(!) times
> in -X debug session.
>
> Can I wrap those if()s into some rule like "If session is new, then
> execute wrapped logic, else - just bypass wrapped block"?


Use an attribute in the session-state list, which exists over all
packets in the same session. It will be empty in the first request.


authorize {


if (!&session-state:Tmp-Integer-1) {


update session-state {
&Tmp-Integer-1 := 1
}


... stuff only the first time here ...
}


... everything else here ...
}


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





More information about the Freeradius-Users mailing list