How can I catch the bug?

[Alan DeKok]

On Jul 25, 2018, at 9:45 AM, work vlpl <thework.vlpl at 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#L503
> 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#L354

  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.