This is a reproducible problem (would take me between 30 mins and a day to reproduce it). Please feel free to provide me with tcpdump options to be sure I include to get the information you need. I've been informed there is no firewall at all, the only firewalling that takes place is the local Linux netfilter, I've never audited the kit at the SERVER end to know for sure. I have run a tcpdump from the server side before now (not for the tcpdump I enclosed) when try to diagnose the problem in the first place and the triplet of packets: 09:28:11.331256 IP SERVER.ssh > CLIENT.50727: . 12408:13856(1448) ack 2991 win 2728 09:28:11.331354 IP CLIENT.50727 > SERVER.ssh: . ack 18464 win 378 09:28:44.286495 IP CLIENT.50727 > SERVER.ssh: P 2991:3039(48) ack 18464 win 378 That keeps repeating from that point in was observable at both sides. No checksum errors have ever been shown on any tcpdump I saw. The dump I posted was the first dump I was able to reliably reproduce (observing from the CLIENT end), I'm pretty sure given some time tomorrow I could create you 2 dumps of the same session (the view from each end). Looking a little more at the dump today I see that at time index 09:21:39.860245 to server sends data from seq 12408:13856 again. Here is a snippet that backs up a little more around the time the trouble starts, as SERVER send sequence 12408 seems to be the problem maybe I need to illustrate what happened when that sequence was first sent. Excuse my understanding if it seems a bit limited. SACK is only used when segments are dropped and from inspecting the dump I can't spot where a lost segment occurs. My main question is why does the CLIENT ack data 12408:13856 and beyond all the way up to 18464 (@ 09:21:39.490775) and then start to SACK {12408:13856} (@ 09:21:39.860302) ? Does this mean the client is the buggy end for going back on data it has already acked cleanly, that would be my interpretation of events. Enclosed should be a tcpdump with -vvS of the same session as before observing from the client side. I hope I've answered all the points raised in this thread. Darryl