https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=252913
--- Comment #24 from [email protected] --- (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. _______________________________________________ [email protected] mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[email protected]"
