EAP abort in the middle of conversation

[Alan DeKok]

Stefan Winter wrote:
...
> I.e. there is no networking issue, packet exchange works, but as soon as the second Access-Request
> comes in, the request is rejected.
> 
> The -X log of the packet exchange in question gives a hint:
...
> Sending Access-Challenge of id 14 to 158.64... port 1814
>         EAP-Message = 0x010100061920
>         State = 0xb6a7e30b6348a332f14e7da16cc90197
...
> rad_recv: Access-Request packet from host 158.64...:1814, id=15, length=160

  Where's the State attribute?  It's *required* to be there for EAP to
work.  Either the client is dropping State, or one of the proxies is
dropping it.

>         EAP-Message = 0x020100060315

  And in any case, that's an EAP NAK, asking for TTLS.  This could
arguably be considered valid behavior by the client.  i.e. it doesn't
need the State attribute, because it's not continuing the previous EAP type.

> I would guess that eapol_test might be broken, but strangely enough it works perfectly
> when initiating an EAP exchange to another server that ends up at the same home server.

  My guess, then, is that one of the other servers is deleting the State
 attribute.  *Please* follow the packets in *both* paths from client
through all of the servers, to see what's happening.  In order to fix
this issue, it's important to know where the State attribute is
disappearing, and why.

> So, the only thing that's different is the first-in-line FR 1.1.3 server.
> I'm perfectly clueless here :-( Why would the EAP conversation be unknown?
> 
> All FR servers in the chain are 1.1.3, there is one Radiator server in the proxy chain.

  My guess is that Radiator is throwing away the State attribute.  I
know FreeRADIUS doesn't.

  The "unknown EAP conversation" checks could be relaxed a little for
EAP type NAK, but that would mean starting over at EAP Identity, because
the server has no way of looking up the original identity... because
there's no State attribute.

  All in all, I think one of the proxies is broken.  If it's Radiator,
discuss it with them, and we can hash it out.

  Alan DeKok.
--
  http://deployingradius.com       - The web site of the book
  http://deployingradius.com/blog/ - The blog