Subject: Re: help interpret netatalk log message
From: Dejan Muhamedagic (dejanm@aon.at)
Date: Thu Jun 08 2000 - 20:42:37 EDT
Hello,
On Thu, Jun 08, 2000 at 11:09:10AM -0400, Leo Wierzbowski wrote:
>
> 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
> ...
>
> 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
> ...
> 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?
It seems so. At some point Mac gives up and closes the
connection.
> 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?
Probably not and not.
This is way too hard to track without knowledge about the higher
level protocol. The TCP is reliable, so there must be some
misunderstanding on the higher protocol level. That is if there
isn't a bug in netatalk's dsi code. Reading the code
(dsi_stream_read) and the include/atalk/dsi.h reveals that
netatalk expects a certain amount of data depending on the DSI
header received. Perhaps dumping packets from the dsi_write
function would give a protocol expert a chance to resolve it. Or,
if the DSI header was something expected, then there's a bug
somewhere, and probably triggered by unusual conditions.
The odd thing is that netatalk is _not_ reading the data at all
(the recvq just keeps growing). It seems like it has stocked
somewhere else.
The fiddling in the DSI code with those "tickles" and interrupts
to handle them doesn't look good to me. Perhaps it is safe.
Still, I don't see a need for "tickles" on TCP connections, though
those are, I suppose, a property of AFP.
> Any ideas?
Well, not much of a help here. I hope that there's somebody
knowledgeable about netatalk's DSI code who could be able to
figure out what is going on.
Cheers.
Dejan
This archive was generated by hypermail 2b28 : Wed Jan 17 2001 - 14:31:01 EST