Subject: TCP and RFC 1323 extension
To: None <netbsd-bugs@netbsd.org, bugs@openbsd.org>
From: Rostislav Krasny <rosti_bsd@yahoo.com>
List: netbsd-bugs
Date: 01/03/2003 12:34:03
Hello.

I have FreeBSD 4.7-RELEASE and Windows 98 Second Edition operating
systems installed in the same computer. Also I have Alcatel Speedtouch
Home ADSL modem connected to this computer by Ethernet. I use PPPoE
protocol in both operating systems for connecting with my ISP (Internet
Service Provider) through the ADSL. In FreeBSD I use ppp (a.k.a.
user-ppp) and in Win98SE I use RASPPPOE. Because of PPPoE protocol
usage the MTU cannot be greater than 1492, so I use MTU == 1492 in both
OS-es. Win98SE doesn't support RFC 1323 extension of the TCP protocol.
FreeBSD 4.7 supports RFC 1323 extensiontion of the TCP protocol and
this extension is enabled by default.

I don't use proxies and my ISP doesn't run transparent proxy.
When I use FreeBSD I have troubles with some hosts but when I use
Win98SE I have no troubles with those hosts. For example www.ssh.com
and www.netbsd.org. When I make a tcp connection to the tcp/80 port of
one of the hosts and send a HTTP/1.0 or a HTTP/1.1 request I get no
answer. But if I send a HTTP/0.9 (just "GET /") or any wrong request
(something like "dfghfdh") I get some short answer. No matter what
browser I use, the problem exist even if I use telnet.
I don't have this problem with www.openbsd.org but this host use
Solaris. According to
http://uptime.netcraft.com/up/graph?site=www.ssh.com the host
www.ssh.com uses NetBSD or OpenBSD operating system. So I'm not sure
about OpenBSD have any bug or not. Also I don't know exactly what OS
www.ssh.com use, maybe NetBSD but maybe OpenBSD.

I found two independent workarounds that I can use in my side:

1. reconfigure ppp in my FreeBSD according to the following expression:
MTU == MRU == 1484 (or smaller)

or

2. reconfigure the FreeBSD according to the following expression:
net.inet.tcp.rfc1323 == 0

It looks like a bug in NetBSD's and/or OpenBSD's implementation(s) of
the TCP protocol or/and its extensions. Something like MSS/MTU overflow
because of timestamps when my host declared some infrequently used MSS
like 1452 (in case of MTU == 1492).

P.S.
When I first confronted by the problem with www.ssh.com I found one
more strangeness. Look at the following diagrams of first two TCP/IP
packets in case of Win98SE, FreeBSD with net.inet.tcp.rfc1323 == 0 and
FreeBSD with net.inet.tcp.rfc1323 == 1

Windows 98 Second Edition with RASPPPOE

1. my host -----> SYN (DF) -----> www.ssh.com
   options = <mss 1452,nop,nop,0402>

2. my host <----- ACK,SYN <----- www.ssh.com
   options = <mss 1452>

0402 is a SACK-Permitted option that IMHO have no influence to the main
problem. More information about this option can be found in RFCs 1072
and 2018.


FreeBSD 4.7-RELEASE; net.inet.tcp.rfc1323 == 1 (default)

1. my host -----> SYN (DF) -----> www.ssh.com
   options = <mss 1452,nop,wscale 0,nop,nop,timestamp 1532715 0>

2. my host <----- ACK,SYN <----- www.ssh.com
   options = <mss 1460,nop,wscale 0,nop,nop,timestamp 12034970 1532715>


FreeBSD 4.7-RELEASE; net.inet.tcp.rfc1323 == 0

1. my host -----> SYN (DF) -----> www.ssh.com
   options = <mss 1452>

2. my host <----- ACK,SYN <----- www.ssh.com
   options = <mss 1460>

Why in case of Win98SE the second packet have MSS == 1452 and in the
both cases of FreeBSD the second packet have MSS == 1460? Maybe
RASPPPOE decreases the MSS of incoming ACK,SYN packet according to MTU
or maybe www.ssh.com sends such ACK,SYN because of SACK-Permitted
option? What do you think?

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com