Ngo, Hoc | 1 May 01:50 2002

RE: Found one culprit of -50 errors

It's the TCP sequence number.
Thanks

Hoc

> -----Original Message-----
> From: didier [mailto:dgautheron <at> magic.fr]
> Sent: Tuesday, April 30, 2002 5:06 AM
> To: Ngo, Hoc
> Cc: netatalk-devel
> Subject: Re: [Netatalk-devel] Found one culprit of -50 errors
> 
> 
> "Ngo, Hoc" wrote:
> > 
> > I checked the sequence numbers in these frames and they 
> were correct.
> > Indeed, open occurred before read, read before write!
> Do you mean dsi sequence number?
> 

didier | 1 May 02:29 2002
Picon

Re: Found one culprit of -50 errors

"Ngo, Hoc" wrote:
> 
> It's the TCP sequence number.
> Thanks
So what are the DSI seq.
Do you have
x	Open
x+1	Read
x+2	Write
or
x	Open
x+2	Read
x+1	Write

Ngo, Hoc | 1 May 03:53 2002

RE: Found one culprit of -50 errors

The DSI sequence numbers are

136 open
137 read
138 write

Thanks
Hoc

> -----Original Message-----
> From: didier [mailto:dgautheron <at> magic.fr]
> Sent: Tuesday, April 30, 2002 5:30 PM
> To: Ngo, Hoc
> Cc: netatalk-devel
> Subject: Re: [Netatalk-devel] Found one culprit of -50 errors
> 
> 
> "Ngo, Hoc" wrote:
> > 
> > It's the TCP sequence number.
> > Thanks
> So what are the DSI seq.
> Do you have
> x	Open
> x+1	Read
> x+2	Write
> or
> x	Open
> x+2	Read
> x+1	Write
(Continue reading)

Dan Ramaley | 1 May 16:34 2002

Netatalk woes, take 3

As some of you may remember, i have been having trouble with netatalk on
OpenBSD for awhile.

On Sun, 31 Mar 2002 15:09:58 +0100 Simon Bazley <sibaz <at> sibaz.com> wrote:
> My guess is that in the process of starting up atalkd is calling a function to register in all zones and since
it fails in
> 6, the function returns a fail state rather than a success state due to the other 1.  I guess that then its
taking that
> error as an indication that whatever else is required in the process leading up to registering the server
on the network,

Based on the suggestions in that message, i think it is time to start
adding logging to netatalk. I have version 1.5.2. I'm presently not
familiar with the code at all, and without assistance it will probably
take me awhile to become familiar. So i'm asking for help from those who
are familiar with it. Where in the code should i look for the
function(s) that registers atalkd in a zone? Once i find the spot to add
logging statements, will there be any problem with just inserting a
bunch of printf's (i presume that if it worked and i ran the daemon from
the console that i'd get messages all over the screen... which once i
got that i could redirect them to a file for examination)?

Whatever is causing the problem i'm seeing it must be faily obscure... i
suppose if we can fix it that netatalk will be more robust overall, no?
Thanks for all the help in the past couple months, and thanks in advance
for any responses to this post.

------------------------------------------------------------------------
Dan Ramaley
Digital Media Library Specialist
(Continue reading)

Simon Bazley | 1 May 17:05 2002

Re: Netatalk woes, take 3

Is started working on a new logger to help out in situations like this, but its only avaliable in the CVS
release (1.6verypre).
If left as it comes out of the cvs checkout, I think it works ok.  It doesn't seem to do what I wanted with the separate
loglevels, but as and when I have time I'm working on it.

Whatever you do though, please please please use the LOG macro rather than the syslog command when adding
log messages to the
code base

Simon

Dan Ramaley wrote:

> As some of you may remember, i have been having trouble with netatalk on
> OpenBSD for awhile.
>
> On Sun, 31 Mar 2002 15:09:58 +0100 Simon Bazley <sibaz <at> sibaz.com> wrote:
> > My guess is that in the process of starting up atalkd is calling a function to register in all zones and
since it fails in
> > 6, the function returns a fail state rather than a success state due to the other 1.  I guess that then its
taking that
> > error as an indication that whatever else is required in the process leading up to registering the server
on the network,
>
> Based on the suggestions in that message, i think it is time to start
> adding logging to netatalk. I have version 1.5.2. I'm presently not
> familiar with the code at all, and without assistance it will probably
> take me awhile to become familiar. So i'm asking for help from those who
> are familiar with it. Where in the code should i look for the
> function(s) that registers atalkd in a zone? Once i find the spot to add
(Continue reading)

List Manager | 1 May 21:24 2002

Introducing Emotion Recognition SDK for programmers

Dear Developer,

MultiSensory Technology Corporation is developing a software engine that can
automatically extract and rank over 130 unique emotions from plain text! 

- Information Extraction
- Voice and E-Mail Analysis
- CRM, KM, Customer Service

Try it out for FREE! (for a limited time only...)
http://www.mstcorporation.com

Please tell us what you think too! We would love to hear from you.

MultiSensory Technology Corporation
31841 Via Coyote
Trabuco Canyon, CA 92679
(949) 713-2869
info <at> mstcorporation.com

=================
To be removed from our list please reply with "remove"
in the subject line. We will immediately update our list accordingly.
=================

Marc Taylor | 2 May 15:40 2002
Picon

Problems with Authenticated printing

Hello All,

I am using netatalk 1.5.3.1 on a Solaris box running 2.8 and I am testing authenticated printing.  The mac says that there has been some sort of postscript error and asks if I would like to try and print again.

I am not sure I understand what is not happening or what I did to not make it happen.

Here are pertinent papd.conf file entries and system log messages.

Thanks.

Marc Taylor

papd.conf file:

zhp1714a-test-au:\

        :pr=|/usr/local/bin/lpr -Php1714a:\

        :pd=/usr/local/etc/netatalk/ppd/HPLJ5M_4.PPD:\

        :ca=/tmp/print:\

        :am=uams_clrtxt.so:

Messages from system logs:

Apr 25 14:39:26 bi-printhost1 papd[6689]: [ID 242679 lpr.info] child 6754 for "zhp1714a-test-au" from 30716.5

Apr 25 14:39:29 bi-printhost1 papd[6754]: [ID 829185 lpr.info] CAP error: No such file or directory

Apr 25 14:39:29 bi-printhost1 papd[6754]: [ID 759020 lpr.error] lp_init: must authenticate

Apr 25 14:39:29 bi-printhost1 papd[6754]: [ID 831402 lpr.error] lp_open failed

Apr 25 14:39:29 bi-printhost1 papd[6689]: [ID 973532 lpr.info] child 6754 done


Andrew Morgan | 2 May 17:01 2002

Re: Problems with Authenticated printing


On Thu, 2 May 2002, Marc Taylor wrote:

> Hello All,
>
> I am using netatalk 1.5.3.1 on a Solaris box running 2.8 and I am testing
> authenticated printing.  The mac says that there has been some sort of
> postscript error and asks if I would like to try and print again.
>
> I am not sure I understand what is not happening or what I did to not make
> it happen.
>
> Here are pertinent papd.conf file entries and system log messages.
>
> Thanks.
>
> Marc Taylor
>
> papd.conf file:
>
> zhp1714a-test-au:\
>         :pr=|/usr/local/bin/lpr -Php1714a:\
>         :pd=/usr/local/etc/netatalk/ppd/HPLJ5M_4.PPD:\
>         :ca=/tmp/print:\
>         :am=uams_clrtxt.so:
>
> Messages from system logs:
>
> Apr 25 14:39:26 bi-printhost1 papd[6689]: [ID 242679 lpr.info] child 6754
> for "zhp1714a-test-au" from 30716.5
> Apr 25 14:39:29 bi-printhost1 papd[6754]: [ID 829185 lpr.info] CAP error: No
> such file or directory
> Apr 25 14:39:29 bi-printhost1 papd[6754]: [ID 759020 lpr.error] lp_init:
> must authenticate
> Apr 25 14:39:29 bi-printhost1 papd[6754]: [ID 831402 lpr.error] lp_open
> failed
> Apr 25 14:39:29 bi-printhost1 papd[6689]: [ID 973532 lpr.info] child 6754
> done

Does the /tmp/print/ directory exist?  Did the user first login to the
netatalk file server over appletalk (not tcp)?

	Andy

David Harder | 2 May 23:06 2002

Stability of 1.6verypre anyone?

Can anyone tell me how stable the cvs build of Netatalk is right now?

The reason I ask is that I have a production system running 1.5.1 that has some serious issues when saving multi-part files from Photoshop (described previously) and the current cvs version doesn't exhibit this problem.  However, I need to know if upgrading to 1.6verypre is likely to introduce any new bugs.

I do have a development server and I'm testing 1.6verypre there, but experience tells me that if there is a bug, my Mac users will probably find a way of triggering it and losing half a day's work in the process.

The other option I'm willing to consider is if someone can point me in the right direction, I would be willing to build a patch for 1.5.3.1 that only incorporates the fix for whatever it is that is causing my specific issue.

-Dave-

Ngo, Hoc | 2 May 23:26 2002

RE: Found one culprit of -50 errors

Hi all,

I'd like to update on this bug.

I captured network trace of copying my Illustrator 10 folder from
Mac OS X to a Mac OS 9 server.  I got the same EOF error as in
the case with Netatalk 1.5.2 server, but the copy process
was successful.

Other than the EOF error and a number of -5018 errors (object not found),
which were expected, I did not see anything unusual in the
Netatalk network trace.  All the client requests had consecutive DSI
sequence numbers; i.e., no frames were missing.

So this bug is elusive.  I'm still working on it.

Hoc

> -----Original Message-----
> From: Daniel E. Lautenschleger [mailto:dan <at> bocklabs.wisc.edu]
> Sent: Tuesday, April 30, 2002 5:31 AM
> To: Ngo, Hoc
> Cc: netatalk-devel
> Subject: Re: [Netatalk-devel] Found one culprit of -50 errors
> 
> 
> I think it's great that we've finally got some solid 
> information regarding
> the -50/OS X issue. This has been driving me (and others) nuts.
> 
> I'm all for a temporary fix, but is this a fault of OS X or 
> not? If it is,
> should we not submit a bug report to Apple?
> 
> I'd like to here from the major code commiters what they think.
> 
> Good job, Hoc!
> -Dan
> 
> On Tue, 30 Apr 2002, Ngo, Hoc wrote:
> 
> > Hi all,
> >
> > To reproduce -50 errors, I tried copying a number of
> > folders inside the Applications folder from my OS X to
> > Netatalk 1.5.2 server.  To my dismay most folders
> > failed for -50 errors.
> >
> > I captured network traffic and found out these -50
> > errors were EOF when my Mac client tried to read the
> > resource fork without writing resource data to it first.
> > Following is the summary of my network trace:
> >
> > Frame Description
> >
> > ...   ............
> > 72    AFPD Request: Get FileDirParams for "Adobe 
> Illustrator 10" on vol id 0
> > 73    AFPD Reply:   Attrib=0x0, dir id 20, fileno 
> 973078657, datalen 0,
> > resrc len 0, ...
> > 74    AFPD Request: Open resource fork "Adobe Illustrator 
> 10", access mode
> > 0x03, ...
> > 75    AFPD Reply:   Open fork success, orefnum = 0x0300
> > 76    AFPD Request: Read resource fork, orefnum = 0x0300, 
> offset 0, len 761
> > 77    AFPD Reply:   Read error: result = -5009 (EOF error)
> > 78    AFPD Request: Write resource fork, orefnum = 0x0300, 
> offset 0, len 761
> > 79    DSI Write Request continued
> > ...   ....
> > 81    AFPD Reply:   Write success, bytesWritten: 761
> > ...   .....
> >
> > In summary, the server informed the Mac OS client that
> > both data and resource forks were empty at frame 73.
> > However, the client still proceeded to open the resource fork
> > anyway and then tried to read 761 bytes from it.
> > Because the resrc fork was empty, the client got error -5009,
> > which it translated to -50, I believe.  Although the read failed,
> > the client still proceeded to write 751 bytes. This time it 
> succeeded.
> >
> > I checked the sequence numbers in these frames and they 
> were correct.
> > Indeed, open occurred before read, read before write!
> >
> > I think the order was wrong.  The client should have written first
> > before reading back.
> >
> > In fact, in cases where the copy process was successful, my network
> > trace showed the correct ordering:  open, write, then read.
> >
> > As for the error, you can go to fork.c, search for "AFPERR_EOF".
> > For every EOF error, insert a debug syslog() statement.
> > Then you will see this EOF occurs when offset = 0 and filesize = 0.
> >
> > I think there may be a racing condition somewhere that caused
> > the read request to arrive before the write.
> >
> > Now that I know this type of error, I think it is impossible
> > to fix on the server side.  Netatalk does exactly what the
> > protocol says.
> >
> > However, for temporary relief to Mac users, can we, somehow,
> > detect this bad read/write ordering by checking the following
> > condition on each read:
> > 	 offset = 0, filesize = 0, bytesToRead > 0
> > or more generally:
> > 	offset + bytesToRead > filesize
> > and infer that the client does not intend on reading ahead
> > of writing (hopefully).  If this is the case, we will fork
> > another process to handle a delayed read. If the next request
> > the parent process receives is
> >
> >    1) a write request:
> >     the child process will wait for the write to complete,
> >     then proceeds to read the data and reply to client,
> >     then dies.
> >    2) not a write request:
> >     Then the child process will go ahead to reply EOF error to
> >     the client, then go away.
> >    3) If the parent process does not receive the next request
> >     in a reasonable of time, we will do as step 2.
> >
> > Anyone has a better idea?
> >
> > Thanks
> >
> > Hoc
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > Netatalk-devel mailing list
> > Netatalk-devel <at> lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/netatalk-devel
> >
> 


Gmane