From owner-freebsd-bugs Wed Nov 13 23:30:07 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id XAA20553 for bugs-outgoing; Wed, 13 Nov 1996 23:30:07 -0800 (PST) Received: (from gnats@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id XAA20547; Wed, 13 Nov 1996 23:30:04 -0800 (PST) Date: Wed, 13 Nov 1996 23:30:04 -0800 (PST) Message-Id: <199611140730.XAA20547@freefall.freebsd.org> To: freebsd-bugs Cc: From: Peter Wemm Subject: Re: bin/2003: Finger does not work with many systems Reply-To: Peter Wemm Sender: owner-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk The following reply was made to PR bin/2003; it has been noted by GNATS. From: Peter Wemm To: Bill Fenner Cc: Jason Thorpe , "Justin T. Gibbs" , 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 (DF) 14:50:11.732709 enyo.finger > spinner.24601: SF 1673102906:1673102906(0) ack 562910476 win 31744 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 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 (DF) 14:50:38.464482 enyo.finger > spinner.24602: S 2156775287:2156775287(0) ack 568138592 win 31744 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 (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 (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 (DF) 14:55:04.069891 haywire.finger > spinner.24617: SFP 92827802:92828046(244) ack 620943613 win 17280 (DF) 14:55:04.070375 spinner.24617 > haywire.finger: . ack 246 win 17036 (DF) IMHO, Linux should worry more about getting their code right first rather than trying to get the wrong results quicker.. Cheers, -Peter