I assume that 140.142.3.227 is the remote server correct?
>12:27:38.494757 140.142.3.227.ftp-data > 194.222.36.72.1525: S 1096000000:1096000000(0) win 16384
Ok, remote server sends us a SYN packet without an MSS option
(violation of RFC1122 if I recall). In any case we should be
assuming that this means the mss is 536.
>12:27:38.494757 194.222.36.72.1525 > 140.142.3.227.ftp-data: S 1818665878:1818665878(0) ack 1096000001 win 8192 <mss 0>
>
>*** (notice <mss 0>)
But, as you note this leads us to assume the mss is 0, rather than
the mandated 536. The patch to net/ipv4/tcp_ipv4.c attached to the
end of this message fixes the problem, and has been checked into the
CVS tree. Note that the patch line numbers might be a bit off,
since they were generated against the latest cvs checkin, not
a clean 2.1.36. It's a short patch, adjust by hand if necessary :-)
>12:27:39.014754 140.142.3.227.ftp-data > 194.222.36.72.1525: . ack 1 win 16384
>12:27:39.034754 140.142.3.227.ftp-data > 194.222.36.72.1525: . ack 1 win 16384
>12:27:39.054754 140.142.3.227.ftp-data > 194.222.36.72.1525: . ack 1 win 16384
>
>*** (and MUCH more of this. The other end doesn't stop for half an hour.)
And this is interesting, since it reveals a bugin the remote TCP,
and I suppose an attack method on that host.... No further comment.
-- Eric Schenk www: http://www.dna.lth.se/~erics Dept. of Comp. Sci., Lund University email: Eric.Schenk@dna.lth.se Box 118, S-221 00 LUND, Sweden fax: +46-46 13 10 21 ph: +46-46 222 96 38diff -u -r1.40 tcp_ipv4.c --- tcp_ipv4.c 1997/04/27 19:24:41 1.40 +++ tcp_ipv4.c 1997/04/29 16:04:58 @@ -939,6 +939,7 @@ req->rcv_isn = skb->seq; req->snt_isn = isn; tp.tstamp_ok = tp.sack_ok = tp.wscale_ok = tp.snd_wscale = 0; + tp.in_mss = 536; tcp_parse_options(th,&tp); if (tp.saw_tstamp) req->ts_recent = tp.rcv_tsval; @@ -1377,7 +1378,7 @@ tp->tstamp_ok = 0; tp->sack_ok = 0; tp->wscale_ok = 0; - tp->in_mss = 0; + tp->in_mss = 536; tp->snd_wscale = 0; tp->sacks = 0; tp->saw_tstamp = 0;