Adam, THank you for responding. Further questions below...
--- Adam Nielsen <[EMAIL PROTECTED]> wrote: > User-level and share-level authentication are only > terms for > configuring the server, they both appear the same > way on the client. OK, then I need to rephrase my point here: any ideas why mounting when specifying smbfs works, but specifying cifs fails with STATUS_WRONG_PASSWORD (the same password is given in both situations)? I'm only changing the fs option to mount; all other input is the same. When mounting with smbfs, ethereal shows that the order of traffic is: * the client sends an smb packet with a negotiate protocol request * the server replies with a negotiate protocol response * the client sends a Session Setup AndX Request specifying the incorrect user and incorrect domain but only '00' as the ANSI password * the server responds with success and reports the correct domain * the client sends a Tree Connect AndX Request specifying the correct share path and what I presume is the encrypted version of the actual password * the server responds with success. With cifs specified as the filesystem, something slightly different occurs: * the client sends an smb packet with a negotiate protocol request * the server replies with a negotiate protocol response * the client sends a Session Setup AndX Request specifying the incorrect user and domain and what I imagine is the actual password in ANSI (I presume this is encrypted) and in unicode * the server responds with success and reports the correct domain * the client sends a Tree Connect AndX Request specifying the correct share path but only '00' as the password * the server responds with STATUS_WRONG_PASSWORD. The fact that, with cifs, the password is not being sent at the same time as the share specification would seem to suggest that something incorrect is taking place in the client software when sending the request. This is why I was asking whether I needed to specify some different options to mount when dealing with cifs. > > > At this stage, I'm stumped. I have no access to > the > > server logs (since the NetCenter is a black-box > > appliance). > > But you said you could download the source? You > could recompile that > and enable SSH or something, presumably? They may > even have some sort > of SSH or telnet access already built in. There are no instructions provided. I have no idea what the toolchain requirements are, so I don't even know if I can compile it. I'll certainly try, however, if I have the time (not looking forward to this). > > > Any ideas? Is there anything else I can do to > gather > > more debugging data? Any mount options I should > try? > > You could try using Ethereal and see what's actually > going over the > network when the share locks up, but beyond that it > could be tricky > without access to the server. I'll try this as well. > > Cheers, > Adam. > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/listinfo/samba
