Cause of relatively large retransmission-rate in radsniff output

[Alan DeKok]

On Feb 12, 2019, at 5:17 AM, Fekete Tamás <fektom at gmail.com> wrote:
> As it can be seen above, I got 56 retransmission.
> 
> It is a huge number compared to the 66 Total Access Request / sec.

  Yes.

> I checked if the RT (retransmission) value contains the loss packets and
> the Access-Requests which has been resent due to Access-Challenges.

  No... Access-Requests are *not* re-sent due to Access-Challenges.

> It means that the Access-Requests followed by Access-Challenges are not
> evaluated like Retransmitted requests. They are counted like new
> Access-Requests.

  Because they are new requests.  The RADIUS ID is different, the authentication vector is different.

  See RFC 5080 Section 2.2.2 for requirements on duplicate detection.

> So my question is, do you think this retransmission rate is normal?
> 
> And if not or not sure, do you have a hint or suggestion where to start the
> investigation?

  Retransmissions are sent by the client when the server doesn't respond to packets.

> If I should use debug output of Freeradius, what is the thing I have to
> look in it?

  The debug log in this case may not help.  The debug output is best at showing what's received and what the server is doing with it.

  In this case, if the server is slow / blocked, the debug log won't show it.  You need to read the normal logs, and look for things like "unresponsive", or "blocked".

  Since the default configuration *doesn't* do this, the problem is local changes.  And it's almost always a slow database, or slow external script.

  Alan DeKok.