NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
Readynas beta for Lion (AFP fix) hoses Mac
Hi, First, thanks for your quick work addressing the Readynas Lion problems. For some reason, it's not working for me. I've got an NV+. I installed the Readynas beta for Lion to get afp workin...
I took packet captures when doing a successful mount using an alternate account and when failing using my own account, and compared.
There were only two differences up to the point where netatalk segfaulted, and they were both extra requests from the client on the failed side.
The Lion client did a 'FPMapID' request after getting user info, to map my numeric UID to my username. That returned a result so I don't think it's directly related to the problem.
Later, the lion client did an 'FPAccess' request on the share name. Shortly later, the connection is reset. I see this pattern recurring. Sometimes the client makes a second request before getting the RST (without waiting for a reply from fpaccess,) but that second request matches the behavior of the working username. The working username never makes a FPAccess request at all. FPAccess never returns a result at all.
It looks to me like there's a bug in netatalk's implementation of the FPAccess command. I see on the forum that other people who aren't seeing crashes are having problems with incorrect permissions on a share, only when using their own user ID. Since FPAccess is used to determine whether the user has access to a file, I bet that bug is directly related to this one. It's just a matter of what bad data the FPAccess function reads - garbage it can deal with, or garbage that causes a segfault.
There were only two differences up to the point where netatalk segfaulted, and they were both extra requests from the client on the failed side.
The Lion client did a 'FPMapID' request after getting user info, to map my numeric UID to my username. That returned a result so I don't think it's directly related to the problem.
Later, the lion client did an 'FPAccess' request on the share name. Shortly later, the connection is reset. I see this pattern recurring. Sometimes the client makes a second request before getting the RST (without waiting for a reply from fpaccess,) but that second request matches the behavior of the working username. The working username never makes a FPAccess request at all. FPAccess never returns a result at all.
It looks to me like there's a bug in netatalk's implementation of the FPAccess command. I see on the forum that other people who aren't seeing crashes are having problems with incorrect permissions on a share, only when using their own user ID. Since FPAccess is used to determine whether the user has access to a file, I bet that bug is directly related to this one. It's just a matter of what bad data the FPAccess function reads - garbage it can deal with, or garbage that causes a segfault.
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!
