Description of problem: mount_afp (and "afp_client mount") not working. Version-Release number of selected component (if applicable): afpfs-ng-0.8.1-6.fc12.x86_64 fuse-afp-0.8.1-6.fc12.x86_64 How reproducible: Every time Steps to Reproduce: 1. Try to mount an AFP share (shared by an Airport Extreme) which allows anonymous access like so: afp_client mount -a "No User Authent" 10.0.0.1:Data /home/bzbarsky/foo/ Actual results: Mounting 10.0.0.1 from Data on /home/bzbarsky/foo/ Could not connect, never got a response to getstatus, Connection timed out Expected results: As on my FC9 machine: Mounting 10.0.0.1 from Data on /home/bzbarsky/foo/ Mounting of volume Data of server kiddo succeeded. Additional info: Both machines in question are plugged into the airport extreme in question via ethernet; the only difference is FC9 (working) vs FC12 (not working). If I try to mount the AFP share authenticated (with a password), that once again works on FC9 and times out on FC12. afpgetstatus afp://10.0.0.1 seems to work fine and return the same information on both distro versions.
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.
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.