Cause of relatively large retransmission-rate in radsniff output
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
On Feb 12, 2019, at 5:17 AM, Fekete Tamás <fektom@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.
Ok, Thank you! Alan DeKok <aland@deployingradius.com> ezt írta (időpont: 2019. febr. 12., K, 13:11):
On Feb 12, 2019, at 5:17 AM, Fekete Tamás <fektom@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
participants (2)
-
Alan DeKok -
Fekete Tamás