Bug 8260 - Browse fails under SMB2...trace attached...
Summary: Browse fails under SMB2...trace attached...
Alias: None
Product: Samba 3.6
Classification: Unclassified
Component: SMB2 (show other bugs)
Version: 3.6.0rc2
Hardware: x86 Windows 7
: P5 critical
Target Milestone: ---
Assignee: Karolin Seeger
QA Contact: Samba QA Contact
Depends on:
Reported: 2011-06-23 21:56 UTC by Linda Walsh
Modified: 2011-07-19 13:09 UTC (History)
1 user (show)

See Also:

application/wireshark-pcap (21.08 KB, application/octet-stream)
2011-06-23 21:56 UTC, Linda Walsh
no flags Details
smb.conf (8.18 KB, application/octet-stream)
2011-06-23 22:16 UTC, Linda Walsh
no flags Details
Patch for v3-6-test (1.51 KB, patch)
2011-06-24 09:34 UTC, Stefan Metzmacher
jra: review+
trace showing 'fix' applied by patch... (6.73 KB, application/wireshark-pcap)
2011-06-24 11:43 UTC, Linda Walsh
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Linda Walsh 2011-06-23 21:56:16 UTC
Created attachment 6614 [details]

Running 3.6.0-rc2 -- most things work fine...but just tried to browse my smb shares on 
my server yesturday...

The Win7 error I get is :
\\BLISS is not accessible.  You might not have permission to use this network resouce.
Contact the administrator of this server to find out if you have access permissions.

A remote procedure call (RPC) protocol error occurred.   (ok)...


The trace shows a few odd things.

The major one I noticed seems to be the conversation starting with the DCERPC in
line/packet #86 ... then goes from there.

Another odd problem I notice -- I hve the latest wireshark (1.6.0)...  yet there are two 
places where it can't decode the conversation due to 'malformed packet --
both of the 'STUN' protocol....that may be unrelated.   Don't know.

Anyway, to workaround this problem, I have to turn off 'smb2' on my server, then, after a win7 reboot), I can browse the shares normally...
Comment 1 Jeremy Allison 2011-06-23 22:00:34 UTC
The capture has a truncated packet size. Can you recapture with the size set to the maximum packet size on the wire please ?

Comment 2 Jeremy Allison 2011-06-23 22:07:22 UTC
Please also attach your smb.conf file so I can try and reproduce here.

Comment 3 Linda Walsh 2011-06-23 22:15:05 UTC
Comment #2 -- was just about to do that...
Comment #1 -- RATS...have to reboot again!!!
Comment 4 Linda Walsh 2011-06-23 22:16:58 UTC
Created attachment 6615 [details]

full mess of my smb.conf...
Comment 5 Linda Walsh 2011-06-23 22:30:32 UTC
 Something important I noticed -- both in smb and smb2 mode, Windows logged me on with
'cached' credentials', saying it could not reach a logon server.

Though, probably, because my server's domain name is also it's 'workgroup' name, all my
file shares continue to work normally...

It DOES appear my roaming profiles were being sync'ed (though lately with all the reboots, been skipping that...takes too long on logoff otherwise...)
Comment 6 Linda Walsh 2011-06-23 22:48:42 UTC
How do I unlimit that which seems to already be unlimited?

I.e. in capture options I don't have the option checked to "limit" the captured packet size.

I tried checking it and putting in a larger value than the default 64k (tried 256k), but it kept truncating it back to 64k)...so checking the 'truncate' box in order to try to extend it doesn't seem like it would be of any benefit.

I didn't have that box checked when I ran the capture.

Is there some other place?   I looked under individual protocols SMB, TCP, IP, & DCE,
the only number I found was under 'RPC' PDU size which was set to 4M, (I'll try upping that to
8M, but I can't believe 4M would be a limiting factor on any of these packets...)...

Otherplaces to look?
DCERPC has both reassemble options checked...

Will try increasing capture buffer from default 1M to 3...but that usually causes dropped packets, and given the length of the capture, I don't think I'm running into that limit...
Comment 7 Linda Walsh 2011-06-24 04:27:13 UTC
There must be a bug in the capture routines.

I've tried command line options to increase captures sizes, but the packet in question is ONLY ~1700 bytes while it claims 2400+ was allocated.  But it looks like it is truncated because it doesn't find the rest of the list -- which is probably why win7 fails.

Maybe that's the bug?

I.e. the rest of the packet that would have been sent in a separate TCP packet -- it was
'fragmented'....  Every option I've tried results in the same two errors noted in the trace 
(the short server list packet, and the malformated STUN packet)....

Either it's a bug in wireshark, OR this could be the reason why Win7 is saying their's an RPC
error -- the answer packet is 'truncated'....(from it's persepective).

I don't know why it used a 'fragmented packet'...since max packet size I've seen
SMB2 use is ~9k (9014)... (my TCP MTU size)...
Comment 8 Linda Walsh 2011-06-24 05:26:02 UTC
I think I see prob...maybe?


(I have 20 share entries not counting global)...

(18 not counting 'netlogon' and 'public')....

Why is there a fixed limit of 15 and why would it work on SMB but not SMB2?

Perhaps the slightly larger packet size on SMB2 would allow for more than 15, but SMB2, not getting a 'full packet', thinks the answer is truncated?

I'm shooting the dark here ya know...
Comment 9 Volker Lendecke 2011-06-24 05:55:12 UTC
What is the exact tcpdump cmd line you gave. You might want to take a look at

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

Comment 10 Stefan Metzmacher 2011-06-24 07:10:06 UTC
There's no problem with the capture, the ethernet frame has 1194 bytes,
the netbios length starts at offset 54 (0x36) and consumes 4 bytes
and the netbios payload is 1136.

The client asks for 1024 bytes and it gets them. However the DCERPC fragment consumes 2452 bytes and is incomplete.

I think the bug is that we return NT_STATUS_SUCCESS instead of
STATUS_BUFFER_OVERFLOW. I'll push a fix for this to master shortly
and attach it here for testing.
Comment 11 Stefan Metzmacher 2011-06-24 09:34:42 UTC
Created attachment 6616 [details]
Patch for v3-6-test

Does this patch fixes the problem for you?
Comment 12 Linda Walsh 2011-06-24 11:43:15 UTC
Created attachment 6620 [details]
trace showing 'fix' applied by patch...

the patch appears to have fixed the problem -- can enum my server shares now.

attached is trace showing the new, fixed conversation...

Most excellent!
Comment 13 Jeremy Allison 2011-06-24 17:15:47 UTC
Comment on attachment 6616 [details]
Patch for v3-6-test

Looks good to me and the reported confirms.
Comment 14 Jeremy Allison 2011-06-24 17:16:39 UTC
Re-assigning to Karolon. Please pick metze's patch for the 3.6.0 release as being able to browse large numbers of shares over SMB2 is important.

Thanks !

Comment 15 Karolin Seeger 2011-06-24 19:06:29 UTC
Pushed to v3-6-test.
Closing out bug report.