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


Groups > comp.os.linux.networking > #4851

Re: TCP resets on Internet speed testing

From Tauno Voipio <tauno.voipio@notused.fi.invalid>
Newsgroups comp.os.linux.networking
Subject Re: TCP resets on Internet speed testing
Date 2021-03-28 19:38 +0300
Organization A noiseless patient Spider
Message-ID <s3qbf2$8cb$1@dont-email.me> (permalink)
References <s3lh6s$hv5$1@gioia.aioe.org> <s3nl57$2i9$1@dont-email.me> <slrns5vcql.2ptb.grahn+nntp@frailea.sa.invalid>

Show all headers | View raw


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

Back to comp.os.linux.networking | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

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

csiph-web