Subject: Re: help interpret netatalk log message
From: Leo Wierzbowski (leow@ufl.edu)
Date: Fri Jun 09 2000 - 14:29:58 EDT
An interesting new tidbit was discovered today, relating to this
problem. It turns out that certain files "cause" or are related to the
cause of the tcp/ip connection being dropped. We are downloading approx
40,000 files totaling approx 2GB (system folder and applications for
computing labs) from netatalk 2.1.3/2.1.4 on rh linux 6.0 (kernel 2.2.5)
to mac os 8.6 and 9.0.4 on g4, g3, and imac. Somebody finally noticed
that our download attempts always stop on the same file. This person
did some more tests and discovered (and I verified):
The "bad" file can be downloaded and uploaded via appletalk OK. It can
be uploaded via
tcp/ip OK. It cannot be downloaded via tcp/ip.
We moved the "bad" file out, and then discovered another "bad" file with
identical symptoms. These "bad" files work OK once on the mac's hard
drive (applications can open them).
Any ideas?
Leo Wierzbowski wrote:
>
> andrew morgan wrote:
> >
> > dsi_stream_read calls the standard POSIX read function. It returns -1 on
> > an error and sets errno. In the log above, we see "dsi_stream_read(-1):
> > Connection reset by peer", which indicates that the other end of the
> > tcp/ip connection either timed out or closed the connection with a
> > standard tcp/ip FIN/ACK packet.
> >
> > Small correction to the above. I should have said "timed out or closed
> > the connection *without* a standard tcp/ip FIN/ACK packet."
> >
>
> I have some new info to add to the puzzle. Here is what shows in
> netstat --ip (sleep 1 between netstat's) during finder copying files
> from server to local hard disk:
>
> before the connection hangs, things look OK:
>
> prot recv q send q
>
> tcp 0 84 dilbert.circ:afpovertcp 10.227.158.146:49153
> ESTABLISHED
> tcp 0 54724 dilbert.circ:afpovertcp 10.227.158.146:49153
> ESTABLISHED
> tcp 0 3619 dilbert.circ:afpovertcp 10.227.158.146:49153
> ESTABLISHED
> tcp 0 84 dilbert.circ:afpovertcp 10.227.158.146:49153
> ESTABLISHED
> tcp 0 53264 dilbert.circ:afpovertcp 10.227.158.146:49153
> ESTABLISHED
> tcp 180 53851 dilbert.circ:afpovertcp 10.227.158.146:49153
> ESTABLISHED
> tcp 0 54708 dilbert.circ:afpovertcp 10.227.158.146:49153
> ESTABLISHED
> tcp 0 272 dilbert.circ:afpovertcp 10.227.158.146:49153
> ESTABLISHED
>
> during the connection hang (immediately following the above):
>
> tcp 60 54424 dilbert.circ:afpovertcp 10.227.158.146:49153
> ESTABLISHED
>
> the above is repeated 28 times (secs), then
>
> tcp 76 54424 dilbert.circ:afpovertcp 10.227.158.146:49153
> ESTABLISHED
>
> the above is repeated 28 times (secs), then
>
> tcp 92 54424 dilbert.circ:afpovertcp 10.227.158.146:49153
> ESTABLISHED
>
> ditto, then
>
> tcp 108 54424 dilbert.circ:afpovertcp 10.227.158.146:49153
> ESTABLISHED
>
> ditto, then
>
> tcp 124 54424 dilbert.circ:afpovertcp 10.227.158.146:49153
> ESTABLISHED
>
> ditto, then
>
> tcp 140 54424 dilbert.circ:afpovertcp 10.227.158.146:49153
> ESTABLISHED
>
> ditto, then
>
> tcp 156 54424 dilbert.circ:afpovertcp 10.227.158.146:49153
> ESTABLISHED
>
> ditto, then finally
>
> tcp 126 54424 dilbert.circ:afpovertcp 10.227.158.146:49153
> CLOSE
--Sincerely, Leo Wierzbowski
"The University of Florida does not endorse or disendorse the content of this document. It is the author's private opinion."
This archive was generated by hypermail 2b28 : Wed Jan 17 2001 - 14:31:02 EST