Bug 6665 - karmic smbclient fails to access NAS box
karmic smbclient fails to access NAS box
Status: NEW
Product: Samba 3.4
Classification: Unclassified
Component: Client Tools
3.4.0
x86 Linux
: P3 major
: ---
Assigned To: Samba Bugzilla Account
Samba QA Contact
https://bugs.launchpad.net/ubuntu/+so...
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-08-27 12:08 UTC by Rolf Leggewie
Modified: 2010-01-05 16:28 UTC (History)
1 user (show)

See Also:


Attachments
tcpdump on karmic (1.89 KB, application/octet-stream )
2009-09-03 00:08 UTC, Rolf Leggewie
no flags Details
tcpdump on hardy (7.86 KB, application/octet-stream)
2009-09-03 00:13 UTC, Rolf Leggewie
no flags Details
Patch (1.22 KB, patch)
2009-09-03 02:25 UTC, Volker Lendecke
no flags Details
source3/libsmb/cliconnect.c from karmic (65.43 KB, text/plain)
2009-09-03 06:54 UTC, Rolf Leggewie
no flags Details
Patch for 3.4 (1.15 KB, patch)
2009-09-03 07:05 UTC, Volker Lendecke
gd: review+
Details
tcpdump on karmic (patched) (39.35 KB, application/octet-stream)
2009-09-07 00:36 UTC, Rolf Leggewie
no flags Details
capture of port 445 (688 bytes, application/octet-stream)
2009-09-15 06:43 UTC, Rolf Leggewie
no flags Details
capture of port 139 (as before) (35.11 KB, application/octet-stream)
2009-09-15 06:45 UTC, Rolf Leggewie
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Rolf Leggewie 2009-08-27 12:08:34 UTC
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
Comment 1 Rolf Leggewie 2009-08-27 12:14:55 UTC
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.
Comment 2 Kai Blin 2009-09-02 11:25:39 UTC
Can you get me a wireshark/tcpdump trace of the jaunty and karmic version?
Comment 3 Rolf Leggewie 2009-09-02 16:52:08 UTC
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?
Comment 4 Volker Lendecke 2009-09-02 22:52:25 UTC
Info on how to create useful network traces can be found under

http://wiki.samba.org/index.php/Capture_Packets

Volker
Comment 5 Rolf Leggewie 2009-09-03 00:08:55 UTC
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
Comment 6 Rolf Leggewie 2009-09-03 00:13:23 UTC
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
        ---------            -------
Comment 7 Volker Lendecke 2009-09-03 02:25:48 UTC
Created attachment 4633 [details]
Patch

Can you try the attached patch?

Thanks,

Volker
Comment 8 Rolf Leggewie 2009-09-03 06:54:49 UTC
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.
Comment 9 Volker Lendecke 2009-09-03 07:05:00 UTC
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
Comment 10 Rolf Leggewie 2009-09-06 12:27:58 UTC
unfortunately, the patch does not seem to change the situation.
Comment 11 Volker Lendecke 2009-09-06 15:01:58 UTC
Can you send a new tcpdump with the patched smbclient?

Thanks,

Volker
Comment 12 Rolf Leggewie 2009-09-07 00:36:20 UTC
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
Comment 13 Volker Lendecke 2009-09-07 06:13:17 UTC
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
Comment 14 Rolf Leggewie 2009-09-15 06:43:20 UTC
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.
Comment 15 Rolf Leggewie 2009-09-15 06:45:35 UTC
Created attachment 4696 [details]
capture of port 139 (as before)
Comment 16 Rolf Leggewie 2009-10-06 16:06:54 UTC
Volker, any comment or idea?
Comment 17 Volker Lendecke 2009-10-07 00:43:10 UTC
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 18 Guenther Deschner 2009-11-27 04:29:13 UTC
Comment on attachment 4638 [details]
Patch for 3.4

I am not an expert here but it looks all right to me.
Comment 19 Rolf Leggewie 2010-01-05 09:58:31 UTC
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
Comment 20 Jeremy Allison 2010-01-05 14:03:31 UTC
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.
Comment 21 Jeremy Allison 2010-01-05 16:27:07 UTC
BTW I can reproduce this leak using rpcclient "sourcedata 9000" command, so it's not exactly hard to trigger.

Jeremy.
Comment 22 Jeremy Allison 2010-01-05 16:28:04 UTC
Arg. Ignore the last comment. It was meant for a different bug report.
Jeremy.