Trying to debug a network issue - we have problems with scp transfers to a remote host intermittently stalling. I believe it may have something to do with incorrect handling of sack / dsack TCP options. Looking at netstat -s, during a (successful) scp transfer the TCPSACKDiscard and TCPDSACKIgnoredNoUndo counters increase rapidly. This is on the client initiating the transfer to the remote server. This doesn't seem normal, but I'm having difficulty finding an explanation of what exactly these counters signify. The tcp_sack / tcp_dsack / tcp_fack options are enabled in the kernel on both hosts.

How do I debug this further? Are the counters a symptom of a known problem? It's kind of hard to google this, all I get is unrelated netstat output which happens to include 1 or 2 discarded SACKs, not tens of thousands like I am seeing. I can make tcpdumps on the client (unfortunately not the server), but what should I look for?

Distro ? .. version ?

Debian Lenny. I am firewalling invalid packets (-m state --state invalid), allowing related / established traffic in, and allowing ICMP types 3, 4, 8, 11 & 12. The stalls seem to be less frequent when I explicitly allow invalid packets coming from the remote host. Could it be that some device along the route is handling SACK incorrectly?

Example of a packet I explicitly allowed even though iptables marked it invalid:

This is from my syslog using iptables --log-tcp-options - they appear to be timestamp and sack. Is there a way to log more, or make it show what specifically causes iptables to mark this an invalid packet?

It might be an idea to disable the firewall temporarily and see if the problem is still present