Date: Fri, 29 Jan 2021 10:58:56 +0000 From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 252913] [tcp] Using RACK leaks mbufs Message-ID: <bug-252913-7501-HccHYAWbp7@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-252913-7501@https.bugs.freebsd.org/bugzilla/> References: <bug-252913-7501@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D252913 --- Comment #23 from Michael Tuexen <tuexen@freebsd.org> --- OK. In the tracefile you provided, shows that: * the TCP connection does not use time stamps * the peer is not available anymore, since there are every 3 seconds 3 ICMP messages indicating that the host is not reachable. * the RACK stack sends out the same TCP segments once per ms. The question is why the stack gets into this condition. Two questions: 1. When the stack has been in such a condition, can you provide the output = of sysctl net.inet.tcp.rack Maybe the stats counters there provide some hints. 2. Looking at the graphic you provided seems to indicate that the traffic volume increases when you enable RACK. I don't see a reason for a substanti= al increase. So I guess that some connections get into the state we are intere= sted soon after you enable RACK. So could you start without enabling RACK, start capturing traffic with tcpdump, enable RACK, ensure that some connection hit the bug, and stop the capturing. It would be great, if I could get the .pcap file for one of the connections getting in the buggy state. Based on the .p= cap file I can write a packetdrill script to try to reproduce what is happening. --=20 You are receiving this mail because: You are on the CC list for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-252913-7501-HccHYAWbp7>