From owner-freebsd-hackers Wed Mar 25 05:18:11 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA03956 for freebsd-hackers-outgoing; Wed, 25 Mar 1998 05:18:11 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from penrose.isocor.ie (penrose.isocor.ie [194.106.155.117]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id FAA03945 for ; Wed, 25 Mar 1998 05:18:07 -0800 (PST) (envelope-from peter.edwards@isocor.ie) Received: from isocor.ie (194.106.155.26) by penrose.isocor.ie; 25 Mar 1998 13:17:56 +0000 Message-ID: <351903E6.FB041AEC@isocor.ie> Date: Wed, 25 Mar 1998 13:17:26 +0000 From: Peter Edwards Organization: ISOCOR X-Mailer: Mozilla 4.04 [en] (WinNT; I) MIME-Version: 1.0 To: Arman Hazairin , freebsd-hackers@FreeBSD.ORG Subject: Re: TCP connection hang References: <199803242235.OAA27379@implode.root.com> <35190E33.7E908938@ai3.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Btw, I convert the binary file that i want to transmit into text using > uuencode, and finaly i can transfer the file. > But still no answer for this 'strange' behaviour. I hear a bell ringing in the distance. This indicates that the problem is not related to the size of the data, but its content. If the data-link path wasn't 8-bit clean (say, the SCO terminal device was doing cr->cr-lf translations on the TCP packets for example), is it possible that tcpdump shows the incoming (corrupted) packets coming up through bpf but the TCP code discards them because the checksum is invalid? This would explain why the FreeBSD box apparently "sees" the incoming packet, but the TCP stack doesn't respond to it. Cheers, Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message