From owner-freebsd-current Sun Jun 30 09:37:12 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA26626 for current-outgoing; Sun, 30 Jun 1996 09:37:12 -0700 (PDT) Received: from haywire.DIALix.COM (root@haywire.DIALix.COM [192.203.228.65]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id JAA26615 for ; Sun, 30 Jun 1996 09:37:07 -0700 (PDT) Received: (from news@localhost) by haywire.DIALix.COM (8.7.5/8.7.3) id AAA00567 for freebsd-current@freebsd.org; Mon, 1 Jul 1996 00:37:03 +0800 (WST) Received: from GATEWAY by haywire.DIALix.COM with netnews for freebsd-current@freebsd.org (problems to: usenet@haywire.dialix.com) To: freebsd-current@freebsd.org Date: 30 Jun 1996 16:37:01 GMT From: peter@spinner.DIALix.COM (Peter Wemm) Message-ID: <4r6afe$g0p$1@haywire.DIALix.COM> Organization: DIALix Services, Perth, Australia. References: <199606250412.VAA07543@multivac.orthanc.com> Subject: Re: Has anyone noticed a problem with rshd in -current? Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In article , taob@io.org (Brian Tao) writes: > On Mon, 24 Jun 1996, Lyndon Nerenberg VE7TCP wrote: >> >> If so, this is a symptom of a long-standing bug (since 2.1-RELEASE at >> the very least) related to reuse of addr/port pairs that I haven't >> been able to track down. (And lots of other people have seen.) > > I've been seeing it since my first FreeBSD installation, just > after 2.0 was released. I've personally only seen it happen with > rlogin only, and Jordan reports a similar or identical problem with > rsh. I've *never* seen it happen with any other inetd service. On > top of that, rlogins from our Livingston PM-2e termservers to our > FreeBSD servers have never failed either. I tried to get a tcpdump of this happening to me one time, but what I saw didn't make sense (to me :-). For me though, it was with ssh, and I dont remember the exact sequence of events, but I think one end was in "ESTABLISHED", and the other end sitting in SYN_SENT, and it looked like each SYN that was being sent was being ACK'ed by the remote end, keeping it alive. The Stevens' books, tcp/ip Illustrated (vol 2 I think) say something about an ``unfortunate'' feature of the 4.4BSD code, and give examples of how the code fails under some situations. I'll try and find it, and now that I have the books, I'll look at the tcpdump outhput again... > -- > Brian Tao (BT300, taob@io.org, taob@ican.net) > Systems and Network Administrator, Internet Canada Corp. > "Though this be madness, yet there is method in't" >