[prev in list] [next in list] [prev in thread] [next in thread] 

List:       netatalk
Subject:    Re: [Netatalk-admins] bad function 7a
From:       Frank Lahm <franklahm () googlemail ! com>
Date:       2010-05-26 18:07:05
Message-ID: AANLkTilSp-HzpGQV-topQsRoWsCHIy7k5a-YdDBAmOhu () mail ! gmail ! com
[Download RAW message or body]

2010/5/26 Mark Edwards <mark@antsclimbtree.com>:
> On May 25, 2010, at 6:29 AM, Frank Lahm wrote:
> 
> > 2010/5/23 Mark Edwards <mark@antsclimbtree.com>:
> > > Using netatalk 2.0.5 on Ubuntu 10.04, receiving the following in logs \
> > > regularly: 
> > > May 23 12:17:43 mini afpd[23216]: bad function 7A
> > 
> > Which client OS version? 7a is FPZzzz which the client uses when going
> > to sleep. It's definetely supported by Netatalk, but only for AFP
> > versions >= 2.2. Since 2.2 means any client starting (afair) with OS
> > 8.6 I have no idea how you can screw up like that.
> > 
> > > May 23 12:17:53 mini afpd[23216]: dsi_stream_read(0): unexpected EOF
> > 
> > The connection got interuppted so the server reported this error.
> > 
> > Cheers, F.!
> 
> As I said the client is running OS X 10.6.3.  Its a Macbook, nothing unusual, and \
> the server as far as I know is pretty much a stock configuration.  The only \
> possibly unusual thing here is I'm using it for Time Machine, with a hand-rolled \
> .sparsebundle 
> The unexpected EOF error seems benign, is that correct?  Particularly since this is \
> a laptop that gets closed regularly, and the errors seem to coincide with it \
> getting closed.

Now things are starting making sense. I guess there is a relation
between the server running in a mode where it's not supporting FPZzzzz
(AFP function 0x7a) and thus the client not being able to put the AFP
connection to sleep. Which later will cause the unexpected EOF when
the client instead just closes the connection fd.

> I'm tempted to just ignore the bad function 7A as well, as its surely also related \
> to the laptop closing.  I'm just bringing it up here before I add it to my logcheck \
> ignore file, since it seems like netatalk 2.0.5 shouldn't be capable of producing \
> that error.

Exactly. It's very odd. Would you be able to install Netatalk 2.1.x ?
There have been changes in quite a few areas compared to 2.0.x. This
one isn't really one of them, but anyway...
In either case, if the problem is reproducable, I'd like to see a
network trace of it. Please try to produce a trace as small as
possible by limitting any action strictly to the minimum required to
reproduce the issue. Run tcpdump on the server like this:
# tcpdump -w afp.pcap -s 0 port 548

Depending on the capture size, pm it to me or post it somewhere where
I can download it.

Thanks!

------------------------------------------------------------------------------

_______________________________________________
Netatalk-admins mailing list
Netatalk-admins@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/netatalk-admins


[prev in list] [next in list] [prev in thread] [next in thread]