TCP resets on Internet speed testing

Harold Johanssen

unread,

Mar 26, 2021, 4:46:26 PM3/26/21

to

I have a Linux system connected to a gigabit Internet provider.
In this system I have the netdata application - in essence, a monitoring
application to assess the resources usage and general health of the
system.

When I use any of the speed testing utilities available online,
netdata informs me about the following:

ipv4.tcphandshake
10s ipv4 tcp resets sent = 228.4 tcp resets/s

Why is this happening? Can I tune my system to prevent this from
happening?

Tauno Voipio

unread,

Mar 27, 2021, 12:06:02 PM3/27/21

to

A TCP reset is sent by a TCP peer when it is not happy with the
incoming segment. If the sender is your end of the test, the reset
may be from your firewall not happy with the tester attempting to
open a TCP connection.

A tcpdump / Wireshark trace could provide some light inti the details.

--

-TV

Carlos E.R.

unread,

Mar 27, 2021, 12:52:09 PM3/27/21

to

Have a look at ethernet resent/retries.

--
Cheers, Carlos.

Jorgen Grahn

unread,

Mar 27, 2021, 6:08:55 PM3/27/21

to

Where in the system is this setting or counter? AFAIK, Ethernet
doesn't have a retransmit mechanism. Not a user-visible one, anyway.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

Jorgen Grahn

unread,

Mar 27, 2021, 6:36:09 PM3/27/21

to

On Sat, 2021-03-27, Tauno Voipio wrote:
> On 26.3.2021 22:46 PM, Harold Johanssen wrote:
>> I have a Linux system connected to a gigabit Internet provider.
>> In this system I have the netdata application - in essence, a monitoring
>> application to assess the resources usage and general health of the
>> system.
>>
>> When I use any of the speed testing utilities available online,
>> netdata informs me about the following:
>>
>> ipv4.tcphandshake
>> 10s ipv4 tcp resets sent = 228.4 tcp resets/s
>>
>> Why is this happening? Can I tune my system to prevent this from
>> happening?
>
>
> A TCP reset is sent by a TCP peer when it is not happy with the
> incoming segment.

That doesn't ring quite true: if a TCP endpoint -- I mean the TCP
implementation in the networking stack -- doesn't like a segment it
doesn't have to do anything. It can just sit there, passive-
agressively, and wait for a good segment, or for either application to
give up. Maybe ACKing what it already has in the meantime.

I associate RST more with quick and dirty termination of a TCP
connection or connect attempt. An application can emit one by
calling shutdown(2), or simply by exiting.

> If the sender is your end of the test, the reset
> may be from your firewall not happy with the tester attempting to
> open a TCP connection.

Perhaps that's the most likely cause, yes (although I don't fully
understand the OP's description). Perhaps the firewall runs out of
some resource? Personally I don't know firewalls and NAT devices very
well. They seem to frequently break old TCP/IP conventions.

> A tcpdump / Wireshark trace could provide some light inti the details.

Carlos E.R.

unread,

Mar 28, 2021, 7:04:09 AM3/28/21

to

It certainly does.

Telcontar:~ # ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.1.2 netmask 255.255.255.0 broadcast 192.168.1.255
inet6 fe80::2d8:61ff:fea1:5abd prefixlen 64 scopeid 0x20<link>
ether 00:d8:61:a1:5a:bd txqueuelen 1000 (Ethernet)
RX packets 205610 bytes 174787921 (166.6 MiB)
RX errors 0 dropped 7 overruns 0 frame 0
TX packets 162558 bytes 37233468 (35.5 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

--
Cheers, Carlos.

Tauno Voipio

unread,

Mar 28, 2021, 12:39:02 PM3/28/21

to

Please have a look at RFC793 section 3.4 and its subsection on
reset generation.

If the receiving TCP is confised about the segment coming in,
it has to generate a reset, without user's shutdown().

--

-TV

Jorgen Grahn

unread,

Mar 31, 2021, 4:27:39 PM3/31/21

to

Maybe I'm stupid, but I cannot see a resent/retries counter in the
above output.

Carlos E.R.

unread,

Apr 1, 2021, 5:32:10 PM4/1/21

to

Not directly. You can see the errors. The errors have to be retransmited.

--
Cheers, Carlos.