Re: [cifs-protocol] Conflicting OIDs
Good morning Andrew - thanks for your question - I have created the below case for us to track our efforts regarding that. One of my colleagues will take ownership and contact you shortly. SRX091209600017 : [MS-ADA3] Conflicting OIDs 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: Andrew Bartlett [mailto:abart...@samba.org] Sent: Tuesday, December 08, 2009 8:44 PM To: Interoperability Documentation Help Cc: cifs-proto...@samba.org; p...@tridgell.net; Endi Sukma Dewata Subject: Conflicting OIDs MS-ADA3 2.305 Attribute thumbnailLogo has: cn: Logo ldapDisplayName: thumbnailLogo attributeId: 2.16.840.1.113730.3.1.36 However, this OID is allocated, according to http://www.alvestrand.no/objectid/2.16.840.1.113730.3.1.36.html to Netscape (now Red Hat), and is used for nsLicensedFor. It appears the official OID for thumbnailLogo is 1.3.6.1.4.1.1466.101.120.36 according to http://tools.ietf.org/html/draft-ietf-asid-schema-pilot-00 So far, we have found the following OIDs that are allocated to different names between Microsoft's AD implementation and the official allocations: #MiddleName has a conflicting OID 2.16.840.1.113730.3.1.34:1.3.6.1.4.1.7165.4.255.1 #defaultGroup has a conflicting OID 1.2.840.113556.1.4.480:1.3.6.1.4.1.7165.4.255.2 #thumbnailPhoto has a conflicting OID 2.16.840.1.113730.3.1.35:1.3.6.1.4.1.7165.4.255.10 #thumbnailLogo has a conflicting OID 2.16.840.1.113730.3.1.36:1.3.6.1.4.1.7165.4.255.11 What I want to know is: What is the full list of OIDs that Microsoft uses in Active Directory that have conflicting allocations between AD and either the OID allocation hierarchy or common practice? This will assist us as we aim for interoperability, as for each conflict, we must manually remap. In the long term, we would like to see the AD schema documents annotated with this conflict (both as as summary table and on each attribute), and a process put in place to avoid these kinds of problems in future. Thanks, Andrew Bartlett -- Andrew Bartletthttp://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Cisco Inc. ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] [Pfif] SMB1 Trans2SetPathInfo() FileEndOfFileInformation is not enforcing share modes
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'
[cifs-protocol] New case: SRX091209600095 Trans2SetPathInfo() returns truncated SMB header
Hello Tim - I have created case SRX091209600095 to track this issue. My current test setup is Ubuntu 9.10 against Windows 2008 R2. I will be testing against Windows 7, Windows Vista, and Windows XP (and Windows 2000 if necessary) before proceeding with any product bug filings. Samba4 from: http://samba.org/~tprouty/samba.2009.12.08.tar.gz >From trans2setpathinfo_against_win7_2.cap in the attached zip (using Network >Monitor 3.4): Frame: Number = 39, Captured Frame Length = 244, MediaType = ETHERNET + Ethernet: Etype = Internet IP (IPv4),DestinationAddress:[00-0C-29-84-0A-41],SourceAddress:[00-0C-29-3F-D2-D7] + Ipv4: Src = 10.54.159.14, Dest = 10.54.159.10, Next Protocol = TCP, Packet ID = 42077, Total IP Length = 230 + Tcp: Flags=...AP..., SrcPort=58261, DstPort=Microsoft-DS(445), PayloadLen=178, Seq=2212562830 - 2212563008, Ack=108947765, Win=566 + SMBOverTCP: Length = 174 - Smb: C; Transact2, Set Path Info, Set File EOF Info, Path = \testsfileinfo\test_sfileinfo_end_of_file.dat Protocol: SMB Command: Transact2 50(0x32) + NTStatus: 0x0, Facility = FACILITY_SYSTEM, Severity = STATUS_SEVERITY_SUCCESS, Code = (0) STATUS_SUCCESS + SMBHeader: Command, TID: 0x0800, PID: 0x5935, UID: 0x0800, MID: 0x0009 - CTransaction2: WordCount: 15 (0xF) TotalParameterCount: 98 (0x62) TotalDataCount: 8 (0x8) MaxParameterCount: 2 (0x2) MaxDataCount: 0 (0x0) MaxSetupCount: 0 (0x0) Reserved: 0 (0x0) + Flags: Do NOT disconnect TID Timeout: 0 sec(s) Reserved2: 0 (0x0) ParameterCount: 98 (0x62) ParameterOffset: 68 (0x44) DataCount: 8 (0x8) DataOffset: 166 (0xA6) SetupCount: 1 (0x1) Reserved3: 0 (0x0) SubCommand: Set Path Info, 6(0x0006) ByteCount: 109 (0x6D) Pad1: Binary Large Object (3 Bytes) - SetPathInfoParameterBlock: InformationLevel: Set File EOF Info padding: 0 (0x0) + PathName: \testsfileinfo\test_sfileinfo_end_of_file.dat + EndOfFile: 200 Frame: Number = 40, Captured Frame Length = 102, MediaType = ETHERNET + Ethernet: Etype = Internet IP (IPv4),DestinationAddress:[00-0C-29-3F-D2-D7],SourceAddress:[00-0C-29-84-0A-41] + Ipv4: Src = 10.54.159.10, Dest = 10.54.159.14, Next Protocol = TCP, Packet ID = 14043, Total IP Length = 88 + Tcp: Flags=...AP..., SrcPort=Microsoft-DS(445), DstPort=58261, PayloadLen=36, Seq=108947765 - 108947801, Ack=2212563008, Win=260 + 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: 0x5935, UID: 0x0800, MID: 0x0009 + Flags: 136 (0x88) + Flags2: 34819 (0x8803) PIDHigh: 0 (0x0) SecuritySignature: 0x0 Unused: 0 (0x0) TreeID: 2048 (0x800) ProcessID: 22837 (0x5935) UserID: 2048 (0x800) MultiplexID: 9 (0x9) 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 Captures.zip.bin Description: Captures.zip.bin ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] New case: SRX091209600095 Trans2SetPathInfo() returns truncated SMB header
Thank you Bill. I'm looking forward to hearing the results of your investigation. -Tim On Dec 9, 2009, at 9:13 AM, Bill Wesse wrote: Hello Tim - I have created case SRX091209600095 to track this issue. My current test setup is Ubuntu 9.10 against Windows 2008 R2. I will be testing against Windows 7, Windows Vista, and Windows XP (and Windows 2000 if necessary) before proceeding with any product bug filings. Samba4 from: http://samba.org/~tprouty/samba.2009.12.08.tar.gz From trans2setpathinfo_against_win7_2.cap in the attached zip (using Network Monitor 3.4): Frame: Number = 39, Captured Frame Length = 244, MediaType = ETHERNET + Ethernet: Etype = Internet IP (IPv4),DestinationAddress: [00-0C-29-84-0A-41],SourceAddress:[00-0C-29-3F-D2-D7] + Ipv4: Src = 10.54.159.14, Dest = 10.54.159.10, Next Protocol = TCP, Packet ID = 42077, Total IP Length = 230 + Tcp: Flags=...AP..., SrcPort=58261, DstPort=Microsoft-DS(445), PayloadLen=178, Seq=2212562830 - 2212563008, Ack=108947765, Win=566 + SMBOverTCP: Length = 174 - Smb: C; Transact2, Set Path Info, Set File EOF Info, Path = \testsfileinfo\test_sfileinfo_end_of_file.dat Protocol: SMB Command: Transact2 50(0x32) + NTStatus: 0x0, Facility = FACILITY_SYSTEM, Severity = STATUS_SEVERITY_SUCCESS, Code = (0) STATUS_SUCCESS + SMBHeader: Command, TID: 0x0800, PID: 0x5935, UID: 0x0800, MID: 0x0009 - CTransaction2: WordCount: 15 (0xF) TotalParameterCount: 98 (0x62) TotalDataCount: 8 (0x8) MaxParameterCount: 2 (0x2) MaxDataCount: 0 (0x0) MaxSetupCount: 0 (0x0) Reserved: 0 (0x0) + Flags: Do NOT disconnect TID Timeout: 0 sec(s) Reserved2: 0 (0x0) ParameterCount: 98 (0x62) ParameterOffset: 68 (0x44) DataCount: 8 (0x8) DataOffset: 166 (0xA6) SetupCount: 1 (0x1) Reserved3: 0 (0x0) SubCommand: Set Path Info, 6(0x0006) ByteCount: 109 (0x6D) Pad1: Binary Large Object (3 Bytes) - SetPathInfoParameterBlock: InformationLevel: Set File EOF Info padding: 0 (0x0) + PathName: \testsfileinfo\test_sfileinfo_end_of_file.dat + EndOfFile: 200 Frame: Number = 40, Captured Frame Length = 102, MediaType = ETHERNET + Ethernet: Etype = Internet IP (IPv4),DestinationAddress: [00-0C-29-3F-D2-D7],SourceAddress:[00-0C-29-84-0A-41] + Ipv4: Src = 10.54.159.10, Dest = 10.54.159.14, Next Protocol = TCP, Packet ID = 14043, Total IP Length = 88 + Tcp: Flags=...AP..., SrcPort=Microsoft-DS(445), DstPort=58261, PayloadLen=36, Seq=108947765 - 108947801, Ack=2212563008, Win=260 + 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: 0x5935, UID: 0x0800, MID: 0x0009 + Flags: 136 (0x88) + Flags2: 34819 (0x8803) PIDHigh: 0 (0x0) SecuritySignature: 0x0 Unused: 0 (0x0) TreeID: 2048 (0x800) ProcessID: 22837 (0x5935) UserID: 2048 (0x800) MultiplexID: 9 (0x9) 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 ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] Conflicting OIDs
Andrew, I am taking care of this and will be updating you as soon as I have news. Best regards, Edgar -Original Message- From: Bill Wesse Sent: Wednesday, December 09, 2009 7:51 AM To: Andrew Bartlett; Interoperability Documentation Help Cc: cifs-proto...@samba.org; p...@tridgell.net; Endi Sukma Dewata Subject: RE: Conflicting OIDs Good morning Andrew - thanks for your question - I have created the below case for us to track our efforts regarding that. One of my colleagues will take ownership and contact you shortly. SRX091209600017 : [MS-ADA3] Conflicting OIDs 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: Andrew Bartlett [mailto:abart...@samba.org] Sent: Tuesday, December 08, 2009 8:44 PM To: Interoperability Documentation Help Cc: cifs-proto...@samba.org; p...@tridgell.net; Endi Sukma Dewata Subject: Conflicting OIDs MS-ADA3 2.305 Attribute thumbnailLogo has: cn: Logo ldapDisplayName: thumbnailLogo attributeId: 2.16.840.1.113730.3.1.36 However, this OID is allocated, according to http://www.alvestrand.no/objectid/2.16.840.1.113730.3.1.36.html to Netscape (now Red Hat), and is used for nsLicensedFor. It appears the official OID for thumbnailLogo is 1.3.6.1.4.1.1466.101.120.36 according to http://tools.ietf.org/html/draft-ietf-asid-schema-pilot-00 So far, we have found the following OIDs that are allocated to different names between Microsoft's AD implementation and the official allocations: #MiddleName has a conflicting OID 2.16.840.1.113730.3.1.34:1.3.6.1.4.1.7165.4.255.1 #defaultGroup has a conflicting OID 1.2.840.113556.1.4.480:1.3.6.1.4.1.7165.4.255.2 #thumbnailPhoto has a conflicting OID 2.16.840.1.113730.3.1.35:1.3.6.1.4.1.7165.4.255.10 #thumbnailLogo has a conflicting OID 2.16.840.1.113730.3.1.36:1.3.6.1.4.1.7165.4.255.11 What I want to know is: What is the full list of OIDs that Microsoft uses in Active Directory that have conflicting allocations between AD and either the OID allocation hierarchy or common practice? This will assist us as we aim for interoperability, as for each conflict, we must manually remap. In the long term, we would like to see the AD schema documents annotated with this conflict (both as as summary table and on each attribute), and a process put in place to avoid these kinds of problems in future. Thanks, Andrew Bartlett -- Andrew Bartletthttp://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Cisco Inc. ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] New case: SRX091209600095 Trans2SetPathInfo() returns truncated SMB header
Tim - I have verified that Windows 2000 through Windows 2008 R2 & Windows 7 all behave the same way - and return the invalid level DOSError 124. This is definitely by design, as is the omission of WordCount and ByteCount. What [CIFS] and [MS-SMB] do not detail very well is how error codes are cooked before return. It is true that the request header.Flags2 field has SMB_FLAGS2_NT_STATUS set - which one would expect to force an NT Status return code. There are cases where this is not going to occur - Trans2SetPathInfo() with an invalid level being one of them. There are many #defined for constants and macros in cifs.h (from the Windows Driver Kit [WDK-7]) noted in the below description - and I have included the relevant ones below. Before I can go further with a more global description of SMB error code 'cooking', I will file a TDI to request that. For the moment, here is what's up with Trans2SetPathInfo(): In this case - an SMB_COM_TRANSACTION2 (and I think as a consequence of the history of SMB) requesting TRANS2_SET_PATH_INFORMATION (0x06) with an invalid level per [CIFS], such as SMB_SET_FILE_END_OF_FILE_INFO (0x104) - our implementation sets the internal SMB Status to STATUS_OS2_INVALID_LEVEL (cifs.h), which is '0xC098F07C'. This is processed as follows before appearing on the wire: If the SrvIsSrvStatus(Status) check passes (which it should, in this case, per the included #defines from cifs.h), the error code is truncated using the SrvErrorClass(Status) macro (also from cifs.h), and the error class is set to SMB_ERR_CLASS_DOS (0x1). The SMB_FLAGS2_NT_STATUS bit is cleared in the response header.Flags2 field, and the return context is marked to omit WordCount and ByteCount. The error equates to '01 00 7C 00' : DOSError.ErrorClass (0x0001, 1d) : SMB_ERR_CLASS_DOS DOSError.Error (0x007C, 124d) : SrvErrorCode(STATUS_OS2_INVALID_LEVEL) [CIFS] A Common Internet File System (CIFS/1.0) Protocol Preliminary Draft http://www.microsoft.com/about/legal/protocols/BSTD/CIFS/draft-leach-cifs-v1-spec-02.txt [WDK-7] Windows Driver Kit Version 7.0.0 http://www.microsoft.com/downloads/details.aspx?FamilyID=2105564e-1a9a-4bf4-8d74-ec5b52da3d00&displaylang=en [WDKI MSDN] Windows Driver Kit http://msdn.microsoft.com/en-us/library/aa972908.aspx == winerror.h #define ERROR_INVALID_LEVEL 124L == cifs.h #define SrvIsSrvStatus(Status) \ ( ((Status) & 0x1FFF) == SRV_STATUS_FACILITY_CODE ? TRUE : FALSE ) #define SrvErrorClass(Status) ((UCHAR)( ((Status) & 0xF000) >> 12 )) #define STATUS_OS2_INVALID_LEVEL (NTSTATUS)(SRV_OS2_STATUS | ERROR_INVALID_LEVEL) #define SrvErrorCode(Status) ((USHORT)( (Status) & 0xFFF) ) #define SMB_ERR_CLASS_DOS (UCHAR)0x01 #define SRV_STATUS_FACILITY_CODE 0x0098L #define SRV_SRV_STATUS(0xC000L | SRV_STATUS_FACILITY_CODE) #define SRV_DOS_STATUS(0xC0001000L | SRV_STATUS_FACILITY_CODE) #define SRV_SERVER_STATUS (0xC0002000L | SRV_STATUS_FACILITY_CODE) #define SRV_HARDWARE_STATUS (0xC0003000L | SRV_STATUS_FACILITY_CODE) #define SRV_WIN32_STATUS (0xC000E000L | SRV_STATUS_FACILITY_CODE) #define SRV_OS2_STATUS(0xC000F000L | SRV_STATUS_FACILITY_CODE) 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: Wednesday, December 09, 2009 12:24 PM To: Bill Wesse Cc: Jeremy Allison; cifs-proto...@samba.org; p...@tridgell.net Subject: Re: New case: SRX091209600095 Trans2SetPathInfo() returns truncated SMB header Thank you Bill. I'm looking forward to hearing the results of your investigation. -Tim On Dec 9, 2009, at 9:13 AM, Bill Wesse wrote: > Hello Tim - I have created case SRX091209600095 to track this issue. > My current test setup is Ubuntu 9.10 against Windows 2008 R2. I will > be testing against Windows 7, Windows Vista, and Windows XP (and > Windows 2000 if necessary) before proceeding with any product bug > filings. > > Samba4 from: http://samba.org/~tprouty/samba.2009.12.08.tar.gz > > From trans2setpathinfo_against_win7_2.cap in the attached zip (using > Network Monitor 3.4): > > Frame: Number = 39, Captured Frame Length = 244, MediaType = ETHERNET > + Ethernet: Etype = Internet IP (IPv4),DestinationAddress: > [00-0C-29-84-0A-41],SourceAddress:[00-0C-29-3F-D2-D7] > + Ipv4: Src = 10.54.159.14, Dest = 10.54.159.10, Next Protocol = > TCP, Packet ID = 42077, Total IP Length = 230 > + Tcp: Flags=...AP..., SrcPort=58261, DstPort=Microsoft-DS(445), > PayloadLen=178, Seq=2212562830 - 2212563008, Ack=108947765, Win=566 > + SMBOverTCP: Length = 174 > - Smb: C; T
