Bug 538699

I'm the author of afpfs-ng.

Two things:

a)  Could you provide a network dump of the session so I can see what's going on?

b) What do you get when do:
afpgetstatus 10.0.0.1


This is unusual.

- Alex

For the latter:

Server name: (elided)
Machine type: AirPort5,105
AFP versions: 
     AFP3.2
     AFP3.1
UAMs:
     DHCAST128
     DHX2
Signature: (elided)

For the former, what sort of dump do you need?  Happy to run whatever commands you want me to.

Boris,

As root, you should run something like:
tcpdump -i eth0 -s0 -wmydump port 548

This will generate a file called mydump, which you can read using wireshark, but you should send me a copy so I can have a look at what's happening.

- A

Created attachment 376557 [details]
mount_afp dump

Alex,

Another datapoint:
# afpgetstatus 10.0.0.1
Server name: router
Machine type: AirPort5,114
AFP versions: 
     AFP3.2
     AFP3.1
UAMs:
     DHCAST128
     DHX2
Signature: 3646393434374e36414343007369672d

# mount_afp -o volpass=volpass afp://router/g-drive /g-drive/
Mounting router from g-drive on /g-drive/
Could not connect, never got a response to getstatus, Connection timed out

--dump file (afpdump-kevin) attached

-- Kevin

Created attachment 376585 [details]
My tcpdump

I am also having this issue:

afpgetstatus afp://servername
Server name: servername
Machine type: Netatalk
AFP versions: 
     AFPVersion 1.1
     AFPVersion 2.0
     AFPVersion 2.1
     AFP2.2
     AFPX03
     AFP3.1
UAMs:
     Client Krb v2
Signature: 0a54ffffffffffff0a54ffffffffffffffffff

However, the mount is failing:
mount_afp afp://server/share /mnt/point
Mounting server from share on /mnt/point
Could not connect, never got a response to getstatus, Connection timed out

Okay. You're all having the same problem, and I've only ever seen this on newish Airports.

Could I get one of you to do both of the following:

1. Rebuild with DSI debugging

in lib/dsi.c, at the start of the file, change:
#undef DEBUG_DSI
to:
#define DEBUG_DSI 1

Then recompile, reinstall, killall afpfsd if it is still running.

2. Time the mount so I can see if it is timing out

Run the command again, but this time as follows:

mount_afp -o volpass=volpass afp://router/g-drive /g-drive/


That'll help.

Mailing me at alexthepuffin helps, I only see these bugs when my google alerts picks it up.  There are too many distros with afpfs-ng problems for me to monitor them all.

- Alex

After recompile:
[root@druid afpfs-ng-0.8.1]# mount_afp -o volpass=volpass afp://router/g-drive /g-drive/
The afpfs daemon does not appear to be running for uid 0, let me start it for you
*** Sending 1, Zero
=== Waiting for response for 1 Zero
=== Waiting for 1 Zero, for 20s
<<< read() for dsi, 16 bytes
<<< read() of rest of AFP, 447 bytes
=== Timedout for 1
*** removing 1, Zero
Mounting router from g-drive on /g-drive/
Could not connect, never got a response to getstatus, Connection timed out

...and for a little more timing info:
[root@druid afpfs-ng-0.8.1]# time mount_afp -o volpass=volpass afp://router/g-drive /g-drive/
*** Sending 1, Zero
=== Waiting for response for 1 Zero
=== Waiting for 1 Zero, for 20s
<<< read() for dsi, 16 bytes
<<< read() of rest of AFP, 447 bytes
=== Timedout for 1
*** removing 1, Zero
Mounting router from g-drive on /g-drive/
Could not connect, never got a response to getstatus, Connection timed out

real	0m20.006s
user	0m0.000s
sys	0m0.001s

-- 
Kevin

I'm doubtful that this will make a difference, but you should not be doing your mounts as root.  You'll get permission problems later.

Yes, that's a bug.  At very least it should warn you.


- Alex

Note that I'm not doing my mounts as root.  My results are very similar to Kevin's; I sent them directly to your gmail address.

Created attachment 397154 [details]
Debug info from dsi.c

Created attachment 397155 [details]
A guess patch that removes offset calculation.

Okay, next up.  I'm including two patches.

The first one is a debug one, the results of it using both just afpgetstatus and mount_afp would help.

The second one is a guess to see if there's a problem with offsets; the AFP spec says that the signature field should be on an even boundary.  I note that it isn't for your dumps.

Some other questions:
- are you using 64-bit host distributions?  uname -a will show that
- have you tried any of this with different AFP servers (eg. netatalk)?
- when you do a 'time afpgetstatus ...', does it also take 20s?  20s is the default timeout.

Thanks for your quick responses, sorry you haven't gotten that from me.

- Alex

> - are you using 64-bit host distributions?  uname -a will show that

I am, yes.

> - have you tried any of this with different AFP servers (eg. netatalk)?

I have not, no.

> - when you do a 'time afpgetstatus ...', does it also take 20s?

No, it's basically instantaneous:

time afpgetstatus afp://10.0.0.1
...
0.000u 0.000s 0:00.00 0.0%      0+0k 0+0io 0pf+0w

Trying those patches now.

With the debugging patch:

% mount_afp -o volpass="XXXXXXXXX" afp://10.0.0.1/Data /tmp/test/
*** Sending 1, Zero
=== Waiting for response for 1 Zero
=== Waiting for 1 Zero, for 20s
<<< read() for dsi, 16 bytes
<<< read() of rest of AFP, 426 bytes
<<< read(), couldn't read the buffer, trying to read 426 bytes
read(): Bad address
=== Timedout for 1
*** removing 1, Zero
Mounting 10.0.0.1 from Data on /tmp/test/
Could not connect, never got a response to getstatus, Connection timed out

% afpgetstatus afp://10.0.0.1                                                  *** Sending 1, Zero
=== Waiting for response for 1 Zero
=== Waiting for 1 Zero, for 20s
<<< read() for dsi, 16 bytes
<<< read() of rest of AFP, 426 bytes
<<< Handling 1
<<< Found request 1, Zero
<<< Signalling 1, returning 0 or 0
<<< read() for dsi, 16 bytes
=== Done waiting for 1 Zero, waiting for 0s, return 0, DSI return 0
*** removing 1, Zero
Server name: (elided)
Machine type: AirPort5,105
AFP versions: 
     AFP3.2
     AFP3.1
UAMs:
     DHCAST128
     DHX2
Signature: (elided)

It looks like the codepath changed in the guess patch is not reached at all when I run mount_afp.  It _is_ reached by afpgetstatus, but the condition tests false (so p is 2-byte aligned).

> - are you using 64-bit host distributions?  uname -a will show that
Yes. Linux druid.kpsimm.net 2.6.31.12-174.2.22.fc12.x86_64 #1 SMP Fri Feb 19 18:55:03 UTC 2010 x86_64 x86_64 x86_64 GNU/Linux

> - have you tried any of this with different AFP servers (eg. netatalk)?
No.

> - when you do a 'time afpgetstatus ...', does it also take 20s?
No. There is no delay.

After patches:
[kevin@druid vault]$ time mount_afp -o volpass=volpass afp://router/g-drive /g-drive/
*** Sending 1, Zero
=== Waiting for response for 1 Zero
=== Waiting for 1 Zero, for 20s
<<< read() for dsi, 16 bytes
<<< read() of rest of AFP, 447 bytes
<<< read(), couldn't read the buffer, trying to read 447 bytes
read(): Bad address
=== Timedout for 1
*** removing 1, Zero
Mounting router from g-drive on /g-drive/
Could not connect, never got a response to getstatus, Connection timed out

real	0m20.002s
user	0m0.001s
sys	0m0.001s
[kevin@druid vault]$ time afpgetstatus afp://router
*** Sending 1, Zero
=== Waiting for response for 1 Zero
=== Waiting for 1 Zero, for 20s
<<< read() for dsi, 16 bytes
<<< read() of rest of AFP, 447 bytes
<<< Handling 1
<<< Found request 1, Zero
<<< Signalling 1, returning 0 or 0
<<< read() for dsi, 16 bytes
=== Done waiting for 1 Zero, waiting for 0s, return 0, DSI return 0
*** removing 1, Zero
Server name: 
Machine type: AirPort5,114
AFP versions: 
     AFP3.2
     AFP3.1
UAMs:
     No User Authent
     DHCAST128
     DHX2
Signature: 001a0027003d00ffffff06726f757465

real	0m0.005s
user	0m0.001s
sys	0m0.001s

Well, that narrows it down anyway.  I'll look for the buffer allocation problem.

- A

> - are you using 64-bit host distributions?  uname -a will show that
Yes. Linux client 2.6.32.9-67.fc12.x86_64 #1 SMP Sat Feb 27 09:26:40 UTC 2010 x86_64 x86_64 x86_64 GNU/Linux

> - have you tried any of this with different AFP servers (eg. netatalk)?
Yes. I'm trying against netatalk-2.0.5-3.el5

> - when you do a 'time afpgetstatus ...', does it also take 20s?  20s is the
default timeout.
No:
$ time afpgetstatus afp://server
Server name: server
Machine type: Netatalk
AFP versions: 
     AFPVersion 1.1
     AFPVersion 2.0
     AFPVersion 2.1
     AFP2.2
     AFPX03
     AFP3.1
UAMs:
     Client Krb v2
     DHX2
Signature: 09ff0a200000000009ff0a2000000000

real	0m0.011s
user	0m0.001s
sys	0m0.007s

For grins I just tried afpfs-ng-0.8.1-6.fc12.i686 and fuse-afp-0.8.1-6.fc12.i686 with the same results.

Do we have any activity with the issue?
I have exactly the same one, I would like to fix.(In reply to comment #20)

I'm sorry, but the problem lies in threading problems in afpfs-ng 0.8.1.  You'll have to wait until 0.9.

- alex

This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '12'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 12's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 12 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Given that Fedora 14 is shipping the same exact package version, I would fully expect the bug to be present there.

Hello,

I'm running Fedora 14 and getting the same issue. mount_afp doesn't work.


mount_afp -o volpass=xxxx "afp://;AUTH=No User Authent/Time Capsule" /media/capsule
Mounting zoe.local from Time Capsule on /media/capsule
Could not connect, never got a response to getstatus, Connection timed out

I cannot find anything in the log ...
rpm -qf /usr/bin/mount_afp
fuse-afp-0.8.1-6.fc12.x86_64

 uname -a
Linux grincheux 2.6.35.10-74.fc14.x86_64 #1 SMP Thu Dec 23 16:04:50 UTC 2010 x86_64 x86_64 x86_64 GNU/Linux

Please let me know if you need any more information.

Hello,

I'm running Fedora 14 and getting the same issue. mount_afp doesn't work.


mount_afp -o volpass=xxxx "afp://;AUTH=No User Authent/Time Capsule" /media/capsule
Mounting zoe.local from Time Capsule on /media/capsule
Could not connect, never got a response to getstatus, Connection timed out

I cannot find anything in the log ...
rpm -qf /usr/bin/mount_afp
fuse-afp-0.8.1-6.fc12.x86_64

 uname -a
Linux grincheux 2.6.35.10-74.fc14.x86_64 #1 SMP Thu Dec 23 16:04:50 UTC 2010 x86_64 x86_64 x86_64 GNU/Linux

Please let me know if you need any more information.

Has a fix been found for this problem?

I have two Fedora 14 systems that need to make the same mount.  One works and one fails with this exact same error.  The working systems is not 64-bit:

mount_afp -o user=apache "afp://risotto:****@academic.baaccess.net/Curriculum Repository" Curriculum_Repository/
Mounting academic.baaccess.net from Curriculum Repository on Curriculum_Repository/
Mounting of volume Curriculum Repository of server academic succeeded.

rpm -qf /usr/bin/mount_afp
fuse-afp-0.8.1-6.fc12.i686

Linux sandbox 2.6.33.3-85.fc13.i686.PAE #1 SMP Thu May 6 18:27:11 UTC 2010 i686 i686 i386 GNU/Linux

but the failing system **IS** 64-bit:

mount_afp -o user=apache "afp://risotto:****@academic.baaccess.net/Curriculum Repository" Curriculum_Repository/
Mounting academic.baaccess.net from Curriculum Repository on Curriculum_Repository/
Could not connect, never got a response to getstatus, Connection timed out

rpm -qf /usr/bin/mount_afp
fuse-afp-0.8.1-6.fc12.x86_64

Linux dunsel.baaccess.net 2.6.35.6-45.fc14.x86_64 #1 SMP Mon Oct 18 23:57:44 UTC 2010 x86_64 x86_64 x86_64 GNU/Linux

The problem is caused very ugly pointer arithmetic 
example:
p=(void *)((unsigned int) server->incoming_buffer + sizeof(*reply1));
from dsi.c

I recommend to solve all pointer arithmetic warnings from the build to repair this bug.

Created attachment 505576 [details]
Patch soving some pointer and other issues

Posted a patch which solves some pointer arithmetic and similar bugs. Please include it.

ping

Confirming that this bug is still present in Fedora 15, I can recreate this issues on 2.6.38.8-32.fc15.x86_64

With the patch Jan F has provided is there an ETA for inclusion at this point?

as this bug should not be in a CLOSED state

note: I have checked Koji, and this is in the f16 build: http://koji.fedoraproject.org/koji/buildinfo?buildID=251506

Can you test in in f16 please? or use the package from f16 in f15.

Hi Jan,

Will do first thing in the morning, I ran a scratch rebuild through koji of your f16 src rpm http://koji.fedoraproject.org/koji/taskinfo?taskID=3220916 and intend to install the results on the f15 client in the office in the morning.

I will update this ticket with the result pending testing.

thanks David

Hi Jan,

I can confirm that the RPM from the scratch build linked above resolved the afp issues on the F15 client, we were using the mount_afp FUSE package, and all is working well.

wanna it in f15?

Hi Jan,

Ideally yes it would be good to have this in f15, please let me know if I can run it through koji for a normal build.