[Bug 252913] [tcp] Using RACK leaks mbufs

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=252913

--- Comment #24 from iron.udjin at gmail.com ---
(In reply to Michael Tuexen from comment #23)
1. For such looping TCP connections at Nov 16 2020 I wrote script which checks
if SENDQ greater 1700000 and drop them use tcpdrop:

netstat -p tcp -n | awk '{print $3" "$5" "$6}' | egrep "^[0-9]" | grep -v '^0\
' | while read line;
do
        SENDQ=`echo $line | awk '{print $1}'`
        if [ "$SENDQ" -gt "1700000" ];
        then
                echo $line | awk '{print $2}' | awk -F\. '{print
$1"."$2"."$3"."$4" "$5}' | xargs tcpdrop XXX.XXX.XXX.XXX 443 > /dev/null
                echo -n "`date`: " >> /root/check_drop.log
                echo "$line - DROPPED" >> /root/check_drop.log
        fi
done

# cat /root/check_drop.log | wc -l
     460

Sometimes the script kills 5-10 connections/hour. Sometimes nothing in a day.
I'll disable this script and when I catch such connection, I'll post sysctl
net.inet.tcp.rack output.

>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.

2. It's impossible because very low percent of connections hit such looping
state. And that's happening not right after enabling RACK. On the picture I
wanted to show how looping connections increases traffic volume. I assume the
connection should hit a few conditions to start looping.

I can write script which with a certain frequency will collect network vaiables
and write output to the log file. Tell me please frequency and variables which
you need to see and I'll share logs via private link by webserver (will email
you credentials).

-- 
You are receiving this mail because:
You are on the CC list for the bug.