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
Does this tell me that the mac is trying to communicate with netatalk,
because the receive queue is increasing in size? Did netatalk bump into
a buffer size limit on its send queue and not recover? Or was netatalk
not going to read from the receive queue until it's send queue had
emptied a bit? Any ideas?
--
Sincerely,
Leo Wierzbowski
"The University of Florida does not endorse or disendorse the
content of this document. It is the author's private opinion."
