I have a cheap NAS box that does not understand the unix extensions of samba. Other than that, it was more or less working fine in Jaunty. After recent updates, accessing the box from Karmic is hit-and-miss at best. smblient returns undecipherable errors that change from one second to the next $ smbclient -L mynas Enter rolf' password: protocol negotiation failed: NT_STATUS_END_OF_FILE $ smbclient -L mynas Enter rolf's password: Receiving SMB: Server stopped responding session request to MYNAS failed (Call returned zero bytes (EOF)) Receiving SMB: Server stopped responding session request to *SMBSERVER failed (Call returned zero bytes (EOF)) An autofs/smbfs mount with nounix option turned on does see the shares, but the shares themselves are empty. $ ll /mnt/smb/mynas/ total 0 drwx------ 1 rolf rolf 0 2008-07-07 18:40 backup drwx------ 1 rolf rolf 0 2008-07-07 18:39 Musik drwx------ 1 rolf rolf 0 2008-07-07 18:39 PUBLIC drwx------ 1 rolf rolf 0 2008-07-07 18:40 Video $ ll /mnt/smb/mynas/backup/ total 0 GUI clients such as thunar or nautilus can sometimes access the shares themselves, but it's hit-and-miss. You never know if it will work today. Accessing from a hardy box usually works fine. Some logs accessing the box from a hardy client (OK) and a karmic client (fails) http://launchpadlibrarian.net/29961520/smb_hardy.log http://launchpadlibrarian.net/29961383/smb_karmic.log
smbclient is 3.0.28a in hardy and 3.4.0 in karmic. karmic:> dpkg -l smbclient Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Cfg-files/Unpacked/Failed-cfg/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name Version Description +++-=========================-=========================-================================================================== ii smbclient 2:3.4.0-3ubuntu1 command-line SMB/CIFS clients for Unix hardy:> dpkg -l smbclient Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Installed/Config-f/Unpacked/Failed-cfg/Half-inst/t-aWait/T-pend |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name Version Description +++-=========================-=========================-================================================================== ii smbclient 3.0.28a-1ubuntu4.8 a LanManager-like simple client for Unix I tried recompiling 3.0.28a for karmic, but that failed so far.
Can you get me a wireshark/tcpdump trace of the jaunty and karmic version?
I'll gladly do that. But I'm not very familiar with either of the programs. I've used them once or twice but never really knew what I was doing. Would you be so kind to point me to a howto of what you want to see?
Info on how to create useful network traces can be found under http://wiki.samba.org/index.php/Capture_Packets Volker
Created attachment 4628 [details] tcpdump on karmic I hope this has some information for those who understand what's in this file. These are the captured packets for the following session from a karmic client. $ smbclient -L mynas Enter rolf's password: protocol negotiation failed: NT_STATUS_END_OF_FILE
Created attachment 4629 [details] tcpdump on hardy same thing for the hardy client. $ smbclient -L mynas Password: Domain=[ȇ] OS=[] Server=[�] Sharename Type Comment --------- ---- ------- PUBLIC Disk Musik Disk backup Disk Video Disk IPC$ IPC Domain=[ȇ] OS=[] Server=[�] Server Comment --------- ------- Workgroup Master --------- -------
Created attachment 4633 [details] Patch Can you try the attached patch? Thanks, Volker
Created attachment 4637 [details] source3/libsmb/cliconnect.c from karmic Volker, thank you very much for your patch. Unfortunately, that did not work. Here is what I did. First, I tried to add the patch to the patch system of the karmic package (version 3.4.0-3ubuntu1). The source3/libsmb/cliconnect.c has changed since publication, the patch you provided does not apply cleanly. Second thing I tried is just grabbing source3/libsmb/cliconnect.c from git (including your patch) and attempt compilation with that new source file. Alas, compilation ultimately failed. I wonder if I can bother you to provide a patch against the source3/libsmb/cliconnect.c file in the karmic package? I attach the file here for your convenience.
Created attachment 4638 [details] Patch for 3.4 Sorry! The attached patch should do it for 3.4. Thanks for attempting the test so quickly! Volker
unfortunately, the patch does not seem to change the situation.
Can you send a new tcpdump with the patched smbclient? Thanks, Volker
Created attachment 4656 [details] tcpdump on karmic (patched) (In reply to comment #11) > Can you send a new tcpdump with the patched smbclient? gladly. Here it is. Something I just found out. smbclient *will* give me the list of shares initially. But when I access the box with autofs/smbfs, I get an error. I can reproduce this 100% of the time. The log you find attached is the result of the following command: "$ smbclient -L mynas;ll /mnt/smb/mynas/Video/;smbclient -L mynas" I have added ;;; to make clear where the output of one command ends and the next begins. $ smbclient -L mynas;ll /mnt/smb/mynas/Video/;smbclient -L mynas Enter rolf's password: Sharename Type Comment --------- ---- ------- PUBLIC Disk Musik Disk backup Disk Video Disk IPC$ IPC Server Comment --------- ------- Workgroup Master --------- ------- ;;; total 0 ;;; Enter rolf's password: protocol negotiation failed: NT_STATUS_END_OF_FILE
Is this really the patched smbclient binary? Frame 241, the tree ID in the SMB header is still 65535 or 0xffff. This is the field that my patch was indented to set to 0. Can you verify that my patch was applied correctly and that you are using the recompiled binary? Thanks, Volker
Created attachment 4695 [details] capture of port 445 Yes, the effect is still the same even with the patch applied. I made absolutely sure by recompiling the binary once more and inspecting the build log. $ grep lp407 /tmp/pbuilder.log Applying patch lp407583.patch Now at patch lp407583.patch Then I reran above command sequence and captured the output.
Created attachment 4696 [details] capture of port 139 (as before)
Volker, any comment or idea?
Not really, no. Maybe I could get it done when I get direct access to such a box. But I really don't see any difference anymore. Volker
Comment on attachment 4638 [details] Patch for 3.4 I am not an expert here but it looks all right to me.
I'm happy to report that this is close to being back in working order with the latest samba package in karmic-updates (changelog: http://changelogs.ubuntu.com/changelogs/pool/main/s/samba/samba_3.4.0-3ubuntu5.1/changelog). On accessing a share for the first time, I get a bunch of bogus entries. But on the second attempt everything works fine. $ ll /mnt/smb/mynas/backup/ total 0 drwx------ 1 rolf rolf 0 2008-06-26 10:17 drwx------ 1 rolf rolf 0 2008-06-26 10:17 drwx------ 1 rolf rolf 0 2008-06-26 10:17 drwx------ 1 rolf rolf 0 2008-06-26 10:17 drwx------ 1 rolf rolf 0 2008-06-26 10:17 drwx------ 1 rolf rolf 0 2008-06-26 10:17 drwx------ 1 rolf rolf 0 2008-06-26 10:17 drwx------ 1 rolf rolf 0 2008-06-26 10:17 drwx------ 1 rolf rolf 0 2008-06-26 10:17 drwx------ 1 rolf rolf 0 2008-06-26 10:17 drwx------ 1 rolf rolf 0 2008-06-26 10:17 $ ll /mnt/smb/mynas/backup/ total 0M drwx------ 1 rolf rolf 0 2008-12-30 19:13 Archiv drwx------ 1 rolf rolf 0 2008-12-19 02:27 aussortieren drwx------ 1 rolf rolf 0 2008-06-26 10:22 Backups to delete drwx------ 1 rolf rolf 0 2008-06-26 06:30 pfaffe drwx------ 1 rolf rolf 0 2009-01-26 11:12 remote drwx------ 1 rolf rolf 0 2008-07-08 11:37 tmp drwx------ 1 rolf rolf 0 2008-08-25 12:06 X24
In the text you posted it doesn't look like you're using smbclient. "ll" is a Linux command, meaning you're using the kernel CIFSFS client, not smbclient. Can you clarify what you're doing here please ? Jeremy.
BTW I can reproduce this leak using rpcclient "sourcedata 9000" command, so it's not exactly hard to trigger. Jeremy.
Arg. Ignore the last comment. It was meant for a different bug report. Jeremy.
Volker, the patch is obsolete now, right? If you still see things to do here, please reopen the bug.