From owner-freebsd-hackers  Wed Mar 25 11:34:49 1998
Return-Path: <owner-freebsd-hackers@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id LAA15183
          for freebsd-hackers-outgoing; Wed, 25 Mar 1998 11:34:49 -0800 (PST)
          (envelope-from owner-freebsd-hackers@FreeBSD.ORG)
Received: from cache2.Telkomsel.co.id ([202.155.14.253])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA15174
          for <freebsd-hackers@FreeBSD.ORG>; Wed, 25 Mar 1998 11:34:40 -0800 (PST)
          (envelope-from arman@ai3.net)
Received: from mail.Telkomsel.co.id (mail.Telkomsel.co.id [10.1.83.4])
	by cache2.Telkomsel.co.id (8.8.5/8.8.5) with ESMTP id CAA26266;
	Thu, 26 Mar 1998 02:42:36 +0700 (JAVT)
Received: from ai3.net (dumb.HQ.Telkomsel.co.id [10.1.80.217])
	by mail.Telkomsel.co.id (8.8.7/8.8.5) with ESMTP id CAA20440;
	Thu, 26 Mar 1998 02:42:52 +0700 (JAVT)
Message-ID: <3519C0D0.A32B15D6@ai3.net>
Date: Thu, 26 Mar 1998 02:43:28 +0000
From: Arman Hazairin <arman@ai3.net>
X-Mailer: Mozilla 4.03 [en] (X11; I; SunOS 5.6 sun4u)
MIME-Version: 1.0
To: dg@root.com
CC: Peter Edwards <peter.edwards@isocor.ie>, freebsd-hackers@FreeBSD.ORG
Subject: Re: TCP connection hang
References: <199803251902.LAA12049@implode.root.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-hackers@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

David Greenman wrote:
> 
> >> 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.
> 
>    If this is the case, then an examination of the 'netstat -s' stats should
> show this...Arman?
> 
> -DG
> 
> David Greenman
> Core-team/Principal Architect, The FreeBSD Project

Well, I think we already on the righ track, as splitting the file into
pieces doesn't
do any good, because the first fily could not be transferred. I will
look into hexdump
output to see the byte sequence around 4K.

btw, using netstat and snmp tools, I could see the increment in checksum
received error
in tcp.

before transmission:
netstat -s output:
tcp:
                  405912 discarded for bad checksums
snmp query output:
tcp.tcpInErrs:	  405912

after connection hang:
netstat -s output:
tcp:
                  405919 discarded for bad checksums
snmp query output:
tcp.tcpInErrs:    405919


So, is it mean that SCO implementation has problem, or just wrong setup
in
that SCO box ?

regards,


-arman-
ps. sorry for late response, localtime: 02.30 AM :)

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message