Date: Wed, 13 Nov 1996 23:30:04 -0800 (PST) From: Peter Wemm <peter@spinner.DIALix.COM> To: freebsd-bugs Subject: Re: bin/2003: Finger does not work with many systems Message-ID: <199611140730.XAA20547@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR bin/2003; it has been noted by GNATS.
From: Peter Wemm <peter@spinner.DIALix.COM>
To: Bill Fenner <fenner@parc.xerox.com>
Cc: Jason Thorpe <thorpej@nas.nasa.gov>,
"Justin T. Gibbs" <gibbs@freefall.freebsd.org>,
freebsd-gnats-submit@freefall.freebsd.org
Subject: Re: bin/2003: Finger does not work with many systems
Date: Thu, 14 Nov 1996 15:21:12 +0800
Bill Fenner wrote:
> In message <199611132316.PAA10135@lestat.nas.nasa.gov> you write:
> >Eww. Rather backwards, isn't it? Shouldn't the FreeBSD finger be
> >compatible by default?
>
> It is. T/TCP clients can talk just fine to properly working TCP servers.
>
> Bill
Here's a sample of "finger" and "finger -T" of various systems, including
a working T/TCP 3-packet exchange.
[finger @enyo - linux 2.0.23]
14:50:11.517816 spinner.24601 > enyo.finger: SFP 562910475:562910477(2)
win 16728 <mss 1460,nop,wscale 0,nop,nop,timestamp 449441 0,nop,nop,ccnew
9512> (DF)
14:50:11.732709 enyo.finger > spinner.24601: SF 1673102906:1673102906(0)
ack 562910476 win 31744 <mss 1460>
14:50:11.733021 spinner.24601 > enyo.finger: F 3:3(0) ack 2 win 17520 (DF)
14:50:11.969032 enyo.finger > spinner.24601: R 1673102908:1673102908(0)
win 0
14:50:15.348381 enyo.finger > spinner.24601: SF 1673102906:1673102906(0)
ack 562910476 win 31744 <mss 1460>
14:50:15.348624 spinner.24601 > enyo.finger: R 562910476:562910476(0) win 0
Ouch!! Note that it sends data *after* it has sent a TCP reset? (it does
this consistantly). Linux is screwing up by sending a SYN/FIN response
when it should most definately not be.
Doing the same again with -T:
[finger -T @enyo]i - linux 2.0.23
14:50:37.973008 spinner.24602 > enyo.finger: S 568138591:568138591(0) win
16384 <mss 1460,nop,wscale 0,nop,nop,timestamp 449494 0,nop,nop,ccnew 9513>
(DF)
14:50:38.464482 enyo.finger > spinner.24602: S 2156775287:2156775287(0)
ack 568138592 win 31744 <mss 1460>
14:50:38.464784 spinner.24602 > enyo.finger: . ack 1 win 17520 (DF)
14:50:38.465144 spinner.24602 > enyo.finger: FP 1:3(2) ack 1 win 17520 (DF)
14:50:38.662354 enyo.finger > spinner.24602: . ack 4 win 31744
14:50:39.212310 enyo.finger > spinner.24602: P 1:58(57) ack 4 win 31744
(DF)
14:50:39.212620 spinner.24602 > enyo.finger: . ack 58 win 17463 (DF)
14:50:39.440097 enyo.finger > spinner.24602: P 58:120(62) ack 4 win 31744
(DF)
14:50:39.440358 spinner.24602 > enyo.finger: . ack 120 win 17458 (DF)
14:50:39.586468 enyo.finger > spinner.24602: P 120:122(2) ack 4 win 31744
(DF)
14:50:39.586735 spinner.24602 > enyo.finger: . ack 122 win 17518 (DF)
14:50:39.997177 enyo.finger > spinner.24602: F 1056:1056(0) ack 4 win 31744
14:50:39.997470 spinner.24602 > enyo.finger: . ack 122 win 17520 (DF)
14:50:40.434268 enyo.finger > spinner.24602: P 122:1056(934) ack 4 win
31744 (DF)
14:50:40.434622 spinner.24602 > enyo.finger: . ack 1057 win 16586 (DF)
I am not sure why it's such a protracted packet exchange, the finger
service on this machine (not ours) may be doing unbuffered writes to the
socket, causing excess pushes.
For comparison, here's a two systems that respond correctly to T/TCP:
[finger @uniwa - ultrix 4.2A]
14:51:34.644754 spinner.24603 > uniwa.finger: SFP 578896636:578896638(2)
win 16728 <mss 1460,nop,wscale 0,nop,nop,timestamp 449608 0,nop,nop,ccnew
9514> (DF)
14:51:34.998571 uniwa.finger > spinner.24603: S 1678848000:1678848000(0)
ack 578896637 win 16384
14:51:34.998836 spinner.24603 > uniwa.finger: F 3:3(0) ack 1 win 16728 (DF)
14:51:35.456412 uniwa.finger > spinner.24603: . ack 4 win 16382
14:51:48.637461 uniwa.finger > spinner.24603: . 1:513(512) ack 4 win 16384
14:51:48.637800 spinner.24603 > uniwa.finger: . ack 513 win 16216 (DF)
14:51:48.725069 uniwa.finger > spinner.24603: . 513:1025(512) ack 4 win
16384
14:51:48.725384 spinner.24603 > uniwa.finger: . ack 1025 win 15872 (DF)
14:51:49.177499 uniwa.finger > spinner.24603: FP 1025:1095(70) ack 4 win
16384
14:51:49.177789 spinner.24603 > uniwa.finger: . ack 1096 win 16314 (DF)
[finger @gecko - svr4/386]
14:54:08.919029 spinner.24614 > gecko.finger: SFP 609915659:609915661(2)
win 16728 <mss 1460,nop,wscale 0,nop,nop,timestamp 449916 0,nop,nop,ccnew
9532> (DF)
14:54:09.043901 gecko.finger > spinner.24614: S 680601089:680601089(0) ack
609915660 win 4096
14:54:09.044220 spinner.24614 > gecko.finger: F 3:3(0) ack 1 win 16728 (DF)
14:54:09.161715 gecko.finger > spinner.24614: . ack 4 win 4094
14:54:09.980147 gecko.finger > spinner.24614: P 1:230(229) ack 4 win 4096
14:54:09.980514 spinner.24614 > gecko.finger: . ack 230 win 16499 (DF)
14:54:09.984948 gecko.finger > spinner.24614: F 230:230(0) ack 4 win 4096
14:54:09.985216 spinner.24614 > gecko.finger: . ack 231 win 16498 (DF)
I'm sure the Linux people would just love to know that even SVR4.0 (1992
vintage) gets it right.
And here's what the hassle is all about and why it's worth it.. This is
what a T/TCP connection that succeeds with the TAO (Tcp Accellerated Open).
These three packets contain the open, handshake, the initial request to the
finger server (" /W" I think), the response, and the connection close, all
acknowledged and safe, in three packets. (Think of what this would do for
HTTP etc.)
[finger @haywire - freebsd w/ ttcp enabled]
14:55:03.880129 spinner.24617 > haywire.finger: SFP 620943609:620943611(2)
win 17280 <mss 1460,nop,wscale 0,nop,nop,timestamp 450026 0,nop,nop,cc
9538> (DF)
14:55:04.069891 haywire.finger > spinner.24617: SFP 92827802:92828046(244)
ack 620943613 win 17280 <mss 1460,nop,wscale 0,nop,nop,timestamp 891860
450026,nop,nop,cc 15128,nop,nop,ccecho 9538> (DF)
14:55:04.070375 spinner.24617 > haywire.finger: . ack 246 win 17036
<nop,nop,timestamp 450027 891860,nop,nop,cc 9538> (DF)
IMHO, Linux should worry more about getting their code right first rather
than trying to get the wrong results quicker..
Cheers,
-Peter
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199611140730.XAA20547>