• TCP resets on Internet speed testing

    From Harold Johanssen@21:1/5 to All on Fri Mar 26 20:46:20 2021
    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?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Tauno Voipio@21:1/5 to Harold Johanssen on Sat Mar 27 18:05:58 2021
    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.

    --

    -TV

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Carlos E.R.@21:1/5 to Harold Johanssen on Sat Mar 27 17:51:53 2021
    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.

    --
    Cheers, Carlos.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jorgen Grahn@21:1/5 to Carlos E.R. on Sat Mar 27 22:08:51 2021
    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.

    /Jorgen

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jorgen Grahn@21:1/5 to Tauno Voipio on Sat Mar 27 22:36:05 2021
    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

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Carlos E.R.@21:1/5 to Jorgen Grahn on Sun Mar 28 13:01:28 2021
    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

    --
    Cheers, Carlos.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Tauno Voipio@21:1/5 to Jorgen Grahn on Sun Mar 28 19:38:58 2021
    On 28.3.21 0.36, Jorgen Grahn wrote:
    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



    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jorgen Grahn@21:1/5 to Carlos E.R. on Wed Mar 31 20:27:34 2021
    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.

    /Jorgen

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Carlos E.R.@21:1/5 to Jorgen Grahn on Thu Apr 1 23:30:22 2021
    On 31/03/2021 22.27, Jorgen Grahn wrote:
    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.

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


    --
    Cheers, Carlos.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)