Inner Tunnel User-Name - PEAP/MSCHAPV2

[Chris Arg]

Thanks Alan. Should I turn this into a ticket on github?

On Fri, Dec 12, 2014 at 12:59 PM, Alan DeKok <aland at deployingradius.com>
wrote:
>
> On Dec 12, 2014, at 12:23 PM, Chris Arg <grkcharge at 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.
>
> -
> List info/subscribe/unsubscribe? See
> http://www.freeradius.org/list/users.html
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20141212/49afc7cd/attachment.html>