When performing this command : smbclient -L server -U foo on a CIFS share (netApp server), the server receives the login "oo". If passing an extra letter at the beginning of the login, everything works perfectly. Same bug with the long option --username=foo or by omitting the option and implicitly using the active login on the workstation. This bugs seems to appears on GNU/Linux (x86) and FreeBSD (amd64) with Samba 3.0.22.
UPDATE : after having played with ethereal, it seems that smbclient sends the full username. Is it a compatibility problem with netapp or a netapp bug [...] ?
Can you get an ethereal trace of a Windows client connecting successfully to a NetApp filer - and then add both the smbclient trace and the windows trace as attachments to this bug. That will help greatly in tracking this down. What version of the NetApp filer software is this ? Jeremy
Created attachment 1965 [details] smbclient ethereal dump
We are using Netapp version 7.1. Find attached an ethereal dump of this command : smbclient -U test -L <server>
Created attachment 1966 [details] smbclient ethereal dump (connection OK by tricking the login)
Unfortunately, I won't be able to send a windows trace, but here is a trace with a connection established (by doubling the first letter) : smbclient -U ttest -L <server>
That doesn't really help. I really need to see the Windows trace to compare. Jeremy.
Created attachment 1968 [details] Windows XP SP2 ethereal dump Dump of a Win XP SP2 client successfully connecting to Netapp 7.1
Hi Jeremy, I finally got a Windows dump (previously attached). I also submitted a bug to Netapp, without success : https://now.netapp.com/eservice/caseStatusSystemSearch.do?searchType=NA_WQS_CASE&value=1552876
Wait a second -- NetApp is using PLAIN TEXT passwords???? Volker
Can you try smbclient -L server -U test -W EMMENTAL ? Volker
Hi Volker, Yes, Netapp does not support encryption when using an /etc/passwd and/or NIS/LDAP authentication backend, so I disabled encryption on Samba side (encrypt passwd = no). Unfortunately, I've got the same problem with "smbclient -L emmental -U test -W EMMENTAL".
We might have an alignment problem here. Could you try to set the password 1 character longer? Volker
I changed the password to "teste", but it didn't work. I've got the same connection error and have to add one more letter to the login to authenticate.
Same bug with smbclient shipped with MasOSX 10.4.3
I have a fix for this bug. The problem is that the packet sent from smbclient to the server has an incorrect password length specified. This can be corrected by modifying the code in cliconnect.c that determines the length of the password string and modifying its value to give a correct answer (the computed answer seems to always be too large by 1). This is probably not the correct way of solving the issue, but it does work. I don't know if the problem is simply a math error because of how the string length is computed or if this is actually part of a larger bug that might be affecting other Samba components as well.
Created attachment 3241 [details] Proof of concept patch for cliconnect.c for 3.0.28a Here's a patch that demonstrates a workaround for bug 3840. My testing has shown that this works, and as it doesn't modify the macros used in this portion of the code it shouldn't have any unintended effects on other sections of the code. It needs input from others more familiar with the code base in order to make sure there's nothing particularly nasty about what's suggested here. This was solely derived from packet trace comparisons between smbclient and Windows authenticating against a NetApp FAS270 running DOT 7.2.4.
(In reply to comment #17) > Created an attachment (id=3241) [edit] > Proof of concept patch for cliconnect.c for 3.0.28a Hi Bryan, Thanks a lot for your work. I have tested your patch against NetApp Release 7.2.3P7 : it solves the problem :)
It's the ucs2_align that's causing the problem with unicode passwords. I'll fix this for 3.0.28a and 3.2 - thanks a lot ! Jeremy.
Fixed in 3.0.x and 3.2 git-trees. Jeremy.