Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.linux.networking > #4845 > unrolled thread

TCP resets on Internet speed testing

Back to article view | Back to comp.os.linux.networking

Contents

  TCP resets on Internet speed testing Harold Johanssen <noemail@please.net> - 2021-03-26 20:46 +0000
    Re: TCP resets on Internet speed testing Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2021-03-27 18:05 +0200
      Re: TCP resets on Internet speed testing Jorgen Grahn <grahn+nntp@snipabacken.se> - 2021-03-27 22:36 +0000
        Re: TCP resets on Internet speed testing Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2021-03-28 19:38 +0300
    Re: TCP resets on Internet speed testing "Carlos E.R." <robin_listas@es.invalid> - 2021-03-27 17:51 +0100
      Re: TCP resets on Internet speed testing Jorgen Grahn <grahn+nntp@snipabacken.se> - 2021-03-27 22:08 +0000
        Re: TCP resets on Internet speed testing "Carlos E.R." <robin_listas@es.invalid> - 2021-03-28 13:01 +0200
          Re: TCP resets on Internet speed testing Jorgen Grahn <grahn+nntp@snipabacken.se> - 2021-03-31 20:27 +0000
            Re: TCP resets on Internet speed testing "Carlos E.R." <robin_listas@es.invalid> - 2021-04-01 23:30 +0200

#4845 — TCP resets on Internet speed testing

	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? 

[toc] | [next] | [standalone]

#4846

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

[toc] | [prev] | [next] | [standalone]

#4849

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   .

[toc] | [prev] | [next] | [standalone]

#4851

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

[toc] | [prev] | [next] | [standalone]

#4847

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.

[toc] | [prev] | [next] | [standalone]

#4848

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   .

[toc] | [prev] | [next] | [standalone]

#4850

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.

[toc] | [prev] | [next] | [standalone]

#4865

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   .

[toc] | [prev] | [next] | [standalone]

#4868

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.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.os.linux.networking

csiph-web