Alejandro Perez Mendez <[log in to unmask]> wrote
Mon, 11 Nov 2013 17:11:54 +0100:
| I just summarized. But for me they are the same case.
|
| 00.04 cli -> srv Access-Request (LOST)
| 02.07 cli -> srv Access-Request (Retransmission that arrives)
| 00.02 srv -> cli Access-Challenge (Response to retransmission)
| 06.25 cli -> srv Access-Request (Second retransmission since it didn't
| notice there were a response already)
| 01.16 srv -> cli Access-Reject (Reject as this second retransmission
| related to an expired EAP session)
| 14.60 cli -> srv Access-Request (Third retransmission, since it didn't
| even notice the Access-Reject)
| 01.16 srv -> cli Access-Reject (Reject as this third retransmission is
| related to an expired EAP session)
I see. Thank you.
| > Have you verified that you indeed have packet losses, f.ex. by looking
| > at traffic at the server?
|
| Yes, I did. The packet does not arrive to the AAA server, just the
| first and subsequent retransmission do.
OK, good info.
| > libradsec doesn't handle Access-Challenge at all -- it simply verifies
| > the response authenticator and sends it upwards in the stack.
|
| My impression is that it is related to the lower network operation
| (socket related), not with the packet processing. Indeed, note that it
| fails equally processing Challenges and Rejects. It just omit the
| received packet and keeps retransmitting previous Request.
|
| > Do we know
| > that authenticating with a server that is sending Access-Challenge works
| > when we don't think that we have packet loss?
| >
|
| Sorry, I did not get this question.
I don't blame you. The question was very stupid. I have very little
experience with Moonshot.
I would not be surprised if the retransmission code in libradsec is
buggy. Let me reproduce packet losses and have a look over the next
couple days.
|