I found a bug while trying out a smbclient ls command:

# smbclient //server/data -U% 
Domain=[SERNET] OS=[Unix] Server=[Samba 3.5.8]
smb: \> ls
NT_STATUS_NO_SUCH_FILE listing \*


Interestingly a second "ls" works just the first one always fails like this. In the capture and logs you see that the first FIND_FIRST2 call is not UTF-16 encoded, the second one is:

First (broken) "*" on the net is "2A 00"

Second (correct) "*" on the net is "00 2A 00 00 00"

Valgrind output reveals that the problem seems to be in the generic libsmb code:

==18895== Conditional jump or move depends on uninitialised value(s)
==18895==    at 0x2F8EED: push_string_base (charcnv.c:1650)
==18895==    by 0x23A221: clistr_push_fn (clistr.c:48)
==18895==    by 0x234863: cli_list_new (clilist.c:285)
==18895==    by 0x235228: cli_list (clilist.c:684)
==18895==    by 0x1E4F71: do_list (client.c:839)
==18895==    by 0x1E56FA: cmd_dir (client.c:890)
==18895==    by 0x1E2345: process_command_string (client.c:4123)
==18895==    by 0x1E3B75: main (client.c:4577)

(the line numbers match on 3.5.8 code)

and finally I was able to see this bug on several x86_64 machines (with 3.4 and 3.5) but not on a i586 32bit machine.