On Dec 12, 2014, at 12:23 PM, Chris Arg <grkcharge@gmail.com> wrote:
Quick overview of what I think/see is happening. I'm sure it's wrong so please correct me.
Packet 8 comes in. Post-Proxy is run and the update to outer.session-state happens. Access-Challenge is sent and the state is cached. Packet 9 comes in. It's an Access-Request packet which triggers the previously cached information to be retrieved. This packet only gets to the authenticate section before a new Access-Challenge is sent causing the current state to be cached. Packet 10 comes in. It's an Access-Request which retrieves the previous state information. Post-Auth in sites-enabled/default is ran which executes update for &reply: += &session-state:. This results in a No attributes updated because the previous state didn't have any.
No. The “session-state” attributes are tracked across multiple packets. They are NOT tied to a particular “State” attribute. Please read the comments about “session-state” in the configuration files. If there are no attributes cached in the “session-state” list, then there may be a bug in the code. The debug output looks suspicious. It runs the inner-tunnel EAP method, and then *nothing* else before it sends the Access-Challenge. I’ll take a look. I don’t have time to reproduce this test now. But the session-state code was tested to work... Alan DeKok.