Created attachment 6614 [details] application/wireshark-pcap 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...
The capture has a truncated packet size. Can you recapture with the size set to the maximum packet size on the wire please ? Jeremy.
Please also attach your smb.conf file so I can try and reproduce here. Jeremy.
Comment #2 -- was just about to do that... Comment #1 -- RATS...have to reboot again!!!
Created attachment 6615 [details] smb.conf full mess of my smb.conf...
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...)
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...
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)...
I think I see prob...maybe? why is MAX_SERVER_DISK_ENTRIES = 15? (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...
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 http://wiki.samba.org/index.php/Client_specific_Log Volker
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.
Created attachment 6616 [details] Patch for v3-6-test Does this patch fixes the problem for you?
Created attachment 6620 [details] trace showing 'fix' applied by patch... 'bingo'.... 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 on attachment 6616 [details] Patch for v3-6-test Looks good to me and the reported confirms.
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 ! Jeremy.
Pushed to v3-6-test. Closing out bug report. Thanks!