Subject: Re: help interpret netatalk log message
From: andrew morgan (morgan@orst.edu)
Date: Fri Jun 16 2000 - 11:25:06 EDT
Maybe this is crazy, but could these "bad" files contain data that is
interpreted as a DSI header? Something that the server thinks is the end
of the packet? Another user complained that trying to create an EPS file
on the server would consistently drop the connection.
Do you have the "bad" files still that we could inspect?
Andy
On Fri, 9 Jun 2000, Leo Wierzbowski wrote:
> 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:04 EST