Cause of relatively large retransmission-rate in radsniff output

classic Classic list List threaded Threaded
3 messages Options
| Threaded
Open this post in threaded view
|

Cause of relatively large retransmission-rate in radsniff output

Fekete Tamás
Hello!

I would like to ask help with understanding my radsniff output as usually I
get a huge number of Access-Request retransmission rate.

When I have run radsniff -W 1, I got the following output:

...

Access-Request counters:
        Total     : 66.000/s
        Linked    : 64.000/s
        Unlinked  : 0.000/s
Access-Request latency:
        High      : 1000.607ms
        Low       : 0.260ms
        Average   : 17.473ms
        MA        : 23.723ms
Access-Request retransmits & loss:
        RT (0)    : 56.000/s


...

As it can be seen above, I got 56 retransmission.

It is a huge number compared to the 66 Total Access Request / sec.

I checked if the RT (retransmission) value contains the loss packets and
the Access-Requests which has been resent due to Access-Challenges.
My result is that loss packets are separately show up in this statistics
like:

Access-Request retransmits & loss:
        Lost      : 1.000/s
        RT (0)    : 55.000/s

And Access-Requests followed by Access-Challenges are not count into the
Retrasmission. Here is an output from a virtual machine which was tested
with eapol_test (with peap-mschapv2 method):
Interface capture rate:
        ens3      : 0.000/s
        lo        : 40.000/s
Access-Request counters:
        Total     : 10.000/s
        Linked    : 10.000/s
        Unlinked  : 0.000/s
Access-Request latency:
        High      : 6.417ms
        Low       : 0.119ms
        Average   : 0.949ms
        MA        : 0.949ms
Access-Accept counters:
        Total     : 1.000/s
        Linked    : 1.000/s
        Unlinked  : 0.000/s
Access-Accept latency:
        High      : 0.190ms
        Low       : 0.190ms
        Average   : 0.190ms
        MA        : 0.190ms
Access-Challenge counters:
        Total     : 9.000/s
        Linked    : 9.000/s
        Unlinked  : 0.000/s
Access-Challenge latency:
        High      : 6.417ms
        Low       : 0.119ms
        Average   : 1.033ms
        MA        : 1.033ms

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

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?
If I should use debug output of Freeradius, what is the thing I have to
look in it?

- Tamas Fekete
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
| Threaded
Open this post in threaded view
|

Re: Cause of relatively large retransmission-rate in radsniff output

Alan DeKok-2
On Feb 12, 2019, at 5:17 AM, Fekete Tamás <[hidden email]> 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
| Threaded
Open this post in threaded view
|

Re: Cause of relatively large retransmission-rate in radsniff output

Fekete Tamás
Ok, Thank you!

Alan DeKok <[hidden email]> ezt írta (időpont: 2019. febr. 12.,
K, 13:11):

> On Feb 12, 2019, at 5:17 AM, Fekete Tamás <[hidden email]> 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
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html