How to deal with the Access-challenge response?

[security4java]

Dear people,

I use Jradius for couple of years but I see the following problem first time.

In the environment of one of our customers the server response with Access-challenge response.

Unfortunately Jradius client starts to repeat AccessRequest a lot of times and does not return an execution to its caller.
The capture of the protocol is presented below:

RADIUS  121 Access-Request(1) (id=240, l=79)
RADIUS  143 Access-challenge(11) (id=240, l=101)
RADIUS  135 Access-Request(1) (id=240, l=93), Duplicate Request ID:240
RADIUS  143 Access-challenge(11) (id=240, l=101)
RADIUS  135 Access-Request(1) (id=240, l=93), Duplicate Request ID:240

How to deal with the Access-challenge response?

How to configure Jradius it will return Access-challenge to its caller and will not repeat AccessRequest a lot of times?

[necouchman]

I encountered this error as well. It appears that the JRadius code, specifically in the authenticate method, assumes that any AccessChallenge that is received will be something like an EAP Challenge/Response. Obviously this is not always the case - I use FreeRadius with LinOTP to do 2-Factor authentication, and FreeRadius uses the AccessChallenge packet to send a request back to the client to get the one-time password.

I worked around this by not using the authenticate method, and, instead, using sendReceive and some logic of my own to check on the type of packet received (AccessChallenge, for example) and handle it myself. I look for the EAPMessage attribute in the reply, and, if that's found, call the processChallenge method and then sendReceive, again, to send it back. Then, elsewhere in my code, I look for the Reply Message attribute in the AccessChallenge response, and, if that's present, prompt the user for the one-time password.

I'm not sure it's great that the authenticate method assumes that an AccessChallenge will always be some sort of internal Challenge/Response, but it is relatively easy to work around.