Tim, - thanks for the updated smbtorture. I have reproduced the truncated SMB error response - see frames 132 & 133 in the attached capture. I will create a new case for this, and begin debugging today (after verifying whether or not this happens against older Windows versions).
Frame: Number = 133, Captured Frame Length = 102, MediaType = ETHERNET + Ethernet: Etype = Internet IP (IPv4),DestinationAddress:[00-15-5D-04-7B-03],SourceAddress:[00-15-5D-04-7B-09] + Ipv4: Src = 192.168.0.10, Dest = 192.168.0.21, Next Protocol = TCP, Packet ID = 1552, Total IP Length = 88 + Tcp: Flags=...AP..., SrcPort=Microsoft-DS(445), DstPort=47152, PayloadLen=36, Seq=3281756320 - 3281756356, Ack=267797329, Win=510 (scale factor 0x8) = 130560 + SMBOverTCP: Length = 32 - Smb: R - DOS OS Error, (124) INVALID_LEVEL Protocol: SMB Command: Transact2 50(0x32) + DOSError: DOS OS Error - (124) INVALID_LEVEL - SMBHeader: Response, TID: 0x0800, PID: 0x77C9, UID: 0x0800, MID: 0x0008 + Flags: 136 (0x88) + Flags2: 34819 (0x8803) PIDHigh: 0 (0x0) SecuritySignature: 0x0 Unused: 0 (0x0) TreeID: 2048 (0x800) ProcessID: 30665 (0x77C9) UserID: 2048 (0x800) MultiplexID: 8 (0x8) Regards, Bill Wesse MCSE, MCTS / Senior Escalation Engineer, US-CSS DSC PROTOCOL TEAM 8055 Microsoft Way Charlotte, NC 28273 TEL: +1(980) 776-8200 CELL: +1(704) 661-5438 FAX: +1(704) 665-9606 -----Original Message----- From: Tim Prouty [mailto:tim.pro...@isilon.com] Sent: Tuesday, December 08, 2009 12:55 PM To: Bill Wesse Cc: p...@tridgell.net; cifs-proto...@samba.org Subject: Re: [Pfif] SMB1 Trans2SetPathInfo() FileEndOfFileInformation is not enforcing share modes Thank you for your diligence on this Bill and the answers you have provided. I have some responses inline below. On Dec 8, 2009, at 6:07 AM, Bill Wesse wrote: > Is #3 actually correct behavior that other servers should implement? > If so, can the cases where share modes are not enforced be enumerated > in the documentation? > > Response: > > #3 is correct behavior. Sending an SMB_COM_TRANSACTION2 request for > SET_PATH_INFORMATION with SMB_INFO_PASSTHROUGH + > FileEndOfFileInformation is > functionally equivalent to a remote call to NtSetInformationFile. > > NtSetInformationFile sends an IRP_MJ_SET_INFORMATION request to the > file > system driver in question; this does not involve the usual I/O Manager > ShareMode checks. I share the same sentiment as Zach on this behavior, but it is definitely useful to know how windows handles this. Are there plans for this to be documented anywhere or does it receive documentation exemption since this is passthrough-speceific? > = > = > = > = > = > = > = > = > ====================================================================== > Question: > > If a client can send a particular info level and windows implements > it, then we have a compatibility problem if we choose not to support > it. What I would really like to know is if other SMB implementations > need to circumvent share-mode checks for this pass through level (and > maybe others?). > > Response: > > This should be the case for all supported SMB_INFO_PASSTHROUGH > levels, as they > run through the same essential logic. > > However, I have additional testing to perform before I can > completely confirm > this. I am interested to know the results of your testing. I believe there are some tests in RAW-OPLOCKS that use the rename passthrough level to test oplocks, but implicitly rely on share modes not being enforced for the rename passthrough. RAW-OPLOCK-BATCH19, 20 and 21 are good ones to look at. > = > = > = > = > = > = > = > = > ====================================================================== > Question: > > 1. Packet 40 appears to have the WordCount and ByteCount truncated, > making the packet smaller than normal minimum size of 35? Is this > intended behavior that other servers should implement? > > Additionally a DOS Error is returned instead of a standard NT_STATUS > error. MS-CIFS does say that a DOS error or an NT_STATUS error may be > returned, but I don't see any indication in the documentation of when > a DOS error should be returned instead of an NT_STATUS error. Is it > possible to make this explicit in the docs or is this a case where > it's purposefully left ambiguous? > > Response: > > The WordCount/ByteCount truncation against the Dos INVALID_LEVEL > error problem > (trans2setpathinfo_against_win7_2.pcap) you saw did not reproduce > with my > clients (who succeeded against the call). > > I have attached a zip file with your trace > (trans2setpathinfo_against_win7_2.pcap), and my equivalent trace > (test_trans2setpathinfo_Win7.pcap). Mine does not have that second > Set EOF call. Do I need a newer build of smbtorture (my current one > from you is samba.2009.12.01.tar.gz)? In comparing the pcaps, it does indeed appear that the version of smbtorture you're running doesn't include the most recent version of RAW-SFILEIFNO-END-OF-FILE. Packet 54 in your trace corresponds to packet 33 in my trace which is sending the SNIA CIFS EOF level rather than the passthrough. Packet 39 in my trace is the setpathinfo EOF passthrough level that is actually getting the strange error, and there is no corresponding packet in your trace. I'll get you the most recent code drop in a private channel. -Tim
my_trans2setpathinfo_R2.pcap
Description: my_trans2setpathinfo_R2.pcap
_______________________________________________ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol