Bug 3840 - Smbclient tool removing the first letter of the username
Smbclient tool removing the first letter of the username
Status: RESOLVED FIXED
Product: Samba 3.0
Classification: Unclassified
Component: Client Tools
3.0.22
x64 FreeBSD
: P3 normal
: none
Assigned To: Samba Bugzilla Account
Samba QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-06-16 08:56 UTC by Ganael LAPLANCHE
Modified: 2008-04-04 17:29 UTC (History)
1 user (show)

See Also:


Attachments
smbclient ethereal dump (1.99 KB, application/octet-stream)
2006-06-16 10:43 UTC, Ganael LAPLANCHE
no flags Details
smbclient ethereal dump (connection OK by tricking the login) (8.42 KB, application/octet-stream)
2006-06-16 10:51 UTC, Ganael LAPLANCHE
no flags Details
Windows XP SP2 ethereal dump (21.32 KB, application/octet-stream)
2006-06-19 04:38 UTC, Ganael LAPLANCHE
no flags Details
Proof of concept patch for cliconnect.c for 3.0.28a (1.03 KB, patch)
2008-04-04 04:11 UTC, Bryan Kolodziej
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ganael LAPLANCHE 2006-06-16 08:56:57 UTC
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.
Comment 1 Ganael LAPLANCHE 2006-06-16 10:28:53 UTC
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 [...] ?
Comment 2 Jeremy Allison 2006-06-16 10:32:41 UTC
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
Comment 3 Ganael LAPLANCHE 2006-06-16 10:43:42 UTC
Created attachment 1965 [details]
smbclient ethereal dump
Comment 4 Ganael LAPLANCHE 2006-06-16 10:44:09 UTC
We are using Netapp version 7.1.

Find attached an ethereal dump of this command :

smbclient -U test -L <server>
Comment 5 Ganael LAPLANCHE 2006-06-16 10:51:01 UTC
Created attachment 1966 [details]
smbclient ethereal dump (connection OK by tricking the login)
Comment 6 Ganael LAPLANCHE 2006-06-16 10:51:25 UTC
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>
Comment 7 Jeremy Allison 2006-06-16 11:06:46 UTC
That doesn't really help. I really need to see the Windows trace to compare.
Jeremy.
Comment 8 Ganael LAPLANCHE 2006-06-19 04:38:50 UTC
Created attachment 1968 [details]
Windows XP SP2 ethereal dump

Dump of a Win XP SP2 client successfully connecting to Netapp 7.1
Comment 9 Ganael LAPLANCHE 2006-06-19 04:53:34 UTC
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

Comment 10 Volker Lendecke 2006-06-19 05:43:41 UTC
Wait a second -- NetApp is using PLAIN TEXT passwords????

Volker
Comment 11 Volker Lendecke 2006-06-19 05:46:56 UTC
Can you try

smbclient -L server -U test -W EMMENTAL

?

Volker
Comment 12 Ganael LAPLANCHE 2006-06-19 06:35:45 UTC
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".

Comment 13 Volker Lendecke 2006-06-19 08:59:56 UTC
We might have an alignment problem here. Could you try to set the password 1 character longer?

Volker
Comment 14 Ganael LAPLANCHE 2006-06-19 09:50:58 UTC
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.
Comment 15 Ganael LAPLANCHE 2006-06-30 01:15:42 UTC
Same bug with smbclient shipped with MasOSX 10.4.3
Comment 16 Bryan Kolodziej 2008-04-04 01:18:23 UTC
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.
Comment 17 Bryan Kolodziej 2008-04-04 04:11:19 UTC
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.
Comment 18 Ganael LAPLANCHE 2008-04-04 07:18:27 UTC
(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 :)
Comment 19 Jeremy Allison 2008-04-04 17:19:56 UTC
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.
Comment 20 Jeremy Allison 2008-04-04 17:29:11 UTC
Fixed in 3.0.x and 3.2 git-trees.
Jeremy.