How can I catch the bug?

work vlpl thework.vlpl at
Wed Jul 25 15:45:49 CEST 2018

Maybe this will help, or maybe you will give me a hint where I should
look again to find the cause.

In debug log file, that I show in first email, there are the lines

(34) Restoring &session-state
(34) # Executing section authorize from file
(34)   authorize {

>From the code of `state.c`

Judging by the code, this line `Restoring &session-state` may appear
in log only if `entry` exists, and therefore
`state` and `state_ctx` are copied back from cached `entry`.

The restoring of session-state is happens inside `rad_authenticate()`
And after that, the modules described in the virtual site
configuration are executed, with update session-state, that failed on
I may miss something, but it seems, that `state_ctx` is not changed
after it was set in `fr_state_get_vps()` function and before failed
assertion. So this means, the cached entry contains `state_ctx =

Also I  watch in logs lines like this

(31) session-state: Saving cached attributes
(31)   Supplicant-User-Name := "redacted-redacted-redacted-redacted-redacted"
State should be 16 octets!

And `State` attributes in received request (see logs in first email)
has values like these (values are from different requests):

State = 0x333753657373696f6e49443d4844514e4341435330332f3332303738393230342f3336303634383b
State = 0x333753657373696f6e49443d4844514e4341435330332f3332303738393230342f3336303634373b

If I understand correctly function that search state `fr_state_find()`
uses only first 16 octets

Because of using sizeof and structure `state` defined like this

And although, function `fr_state_create()` also using only first 16
octets, it does not matter because, first 16 octets, from two
different request are match. So function `fr_state_find()` select the
wrong state.


More information about the Freeradius-Users mailing list