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?
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?
On 26/03/2021 21.46, 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?
Have a look at ethernet resent/retries.
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.
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.
On Sat, 2021-03-27, Carlos E.R. wrote:
On 26/03/2021 21.46, 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?
Have a look at ethernet resent/retries.
Where in the system is this setting or counter? AFAIK, Ethernet
doesn't have a retransmit mechanism. Not a user-visible one, anyway.
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.
/Jorgen
On 27/03/2021 23.08, Jorgen Grahn wrote:
On Sat, 2021-03-27, Carlos E.R. wrote:
On 26/03/2021 21.46, 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?
Have a look at ethernet resent/retries.
Where in the system is this setting or counter? AFAIK, Ethernet
doesn't have a retransmit mechanism. Not a user-visible one, anyway.
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
On Sun, 2021-03-28, Carlos E.R. wrote:
On 27/03/2021 23.08, Jorgen Grahn wrote:
On Sat, 2021-03-27, Carlos E.R. wrote:
On 26/03/2021 21.46, 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?
Have a look at ethernet resent/retries.
Where in the system is this setting or counter? AFAIK, Ethernet
doesn't have a retransmit mechanism. Not a user-visible one, anyway.
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
Maybe I'm stupid, but I cannot see a resent/retries counter in the
above output.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 285 |
Nodes: | 16 (2 / 14) |
Uptime: | 74:15:24 |
Calls: | 6,489 |
Calls today: | 2 |
Files: | 12,096 |
Messages: | 5,275,935 |