When send_ackvec sysctl is on DCCP locks the machine. Unfortunately it doesn't send any output to the kernel. Test cases: On receive end (10.0.2.2): ./ttcp_acme -c -l500 -r On send end (10.0.7.7): ./ttcp_acme -c -l500 -n1000 -t 10.0.2.2 And the setup on 10.0.5.5 (which provides a route between 10.0.2.2 and 10.0.7.7) is: tc qdisc add dev eth0 root netem delay 50ms loss 10% tc qdisc add dev eth1 root netem delay 50ms loss 10% Passes: echo 0 > /proc/sys/net/dccp/default/send_ackvec echo 3 > /proc/sys/net/dccp/default/rx_ccid echo 3 > /proc/sys/net/dccp/default/tx_ccid Locks the machine: echo 1 > /proc/sys/net/dccp/default/send_ackvec echo 3 > /proc/sys/net/dccp/default/rx_ccid echo 3 > /proc/sys/net/dccp/default/tx_ccid Locks the machine: echo 1 > /proc/sys/net/dccp/default/send_ackvec echo 2 > /proc/sys/net/dccp/default/rx_ccid echo 2 > /proc/sys/net/dccp/default/tx_ccid Doesn't lock the machine but doesn't complete the test: echo 0 > /proc/sys/net/dccp/default/send_ackvec echo 2 > /proc/sys/net/dccp/default/rx_ccid echo 2 > /proc/sys/net/dccp/default/tx_ccid The only reason I say that there is a race is that the problems are similar to when I had races without proper locking when implementing tx buffering. When you inject delay/loss with netem it triggers a lot more code coverage because timers get fired, data is missing etc. I've had a quick look around but can't find it yet - I find these races quite nasty to find but will keep looking at it over as time permits... Ian -- Ian McDonald Web: http://wand.net.nz/~iam4 Blog: http://imcdnzl.blogspot.com WAND Network Research Group Department of Computer Science University of Waikato New Zealand - : send the line "unsubscribe dccp" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
