Cause of relatively large retransmission-rate in radsniff output

[Fekete Tamás]

Ok, Thank you!

Alan DeKok <aland at deployingradius.com> ezt írta (időpont: 2019. febr. 12.,
K, 13:11):

> 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.
>
>
> -
> List info/subscribe/unsubscribe? See
> http://www.freeradius.org/list/users.html