Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.os.linux.networking > #4851
| 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> |
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
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