On Jul 25, 2018, at 9:45 AM, work vlpl <thework.vlpl@gmail.com> wrote:
Maybe this will help, or maybe you will give me a hint where I should look again to find the cause. ... 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`.
Sure.
The restoring of session-state is happens inside `rad_authenticate()` function https://github.com/FreeRADIUS/freeradius-server/blob/v3.0.x/src/main/auth.c#... And after that, the modules described in the virtual site configuration are executed, with update session-state, that failed on assertion. 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 = NULL`.
state_ctx isn't supposed to change. And state_ctx=NULL might be OK. I'll take a look.
And `State` attributes in received request (see logs in first email) has values like these (values are from different requests):
State = 0x333753657373696f6e49443d4844514e4341435330332f3332303738393230342f3336303634383b State = 0x333753657373696f6e49443d4844514e4341435330332f3332303738393230342f3336303634373b
These are from another system, not from FreeRADIUS.
If I understand correctly function that search state `fr_state_find()` uses only first 16 octets https://github.com/FreeRADIUS/freeradius-server/blob/v3.0.x/src/main/state.c...
Yes,
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.
Yeah. It's best to fix the state code so that if State is larger than 16 octets, then the state code uses MD5(State), which should be better. I've pushed a fix. Alan DeKok.