gentoo linux, kernel independent (have tested 2.2x - 2.31) mount-cifs versions up to and including 3.0.30 on x86, the following works: mount -t cifs //<ip addr>/wipelog /mnt/test -o \ username=<un>,domain=<d>,sec=ntlmv2 Password: <pwd> # works while the exact same command, on the exact same network from a sparc64 gentoo linux machine, same versions of kernel and mount-cifs package produces: mount -t cifs //<ip addr>/wipelog /mnt/test -o \ username=<un>,domain=<d>,sec=ntlmv2 Password: <pwd> mount error 13 = Permission denied Refer to the mount.cifs(8) manual page (e.g.man mount.cifs) Backing the server down to ntlm (v1) works from both x86 clients, but v2 does not.
typo on kernel versions tested--meant kernel versions 2.6.2x - 2.6.31
Jeff, I think this is yours :-) Volker
Steve, any thoughts on this? Sounds like an endianness problem, but I'm not that familiar with the ntlmv2 code. I see this in CalcNTLMv2_response(): memcpy(v2_session_response + 8, ses->server->cryptKey, 8); ...which looks like it probably needs to be endian converted, no? I'm guessing there may be other places as well.
One thing that might not hurt is a capture of the traffic between client and server while reproducing this. That should tell us on what call this is occurring. It's probably during session setup, but it wouldn't hurt to be sure. Info on how to do that is here: http://wiki.samba.org/index.php/LinuxCIFS_troubleshooting
Reassigning to Steve since he understands NTLMv2 much better than I...
Is this one really a blocker for 3.5.0?
Almost certainly not. mount.cifs just hands the plaintext password off to the kernel. The kernel does all of the hashing and assembly of packets for NTLMv2. If there's a problem in this area, it's almost certainly in the kernel and not in samba or any of the userspace code. Reducing severity from "blocker" to "normal".
Does this work better with a more recent kernel? The NTLMv2 auth code was overhauled within the last year or so, and I suspect that this bug was fixed in the process.
Assuming that this is fixed with the NTLM auth overhaul. Looked like an old endianness issue long fixed.