Any ideas Folks Dev
On Fri, Feb 20, 2009 at 4:41 AM, big dev <bigdev...@gmail.com> wrote: > Hi Folks > > I am trying to understand the notion of parsing a SMB packet under > wireshark, espcially the flags2 field in the smb header. This is a 16bit > value where we have 14 flags with 2 reserved bits but wireshark interprets > only 10. not sure if we aggregate the fields. For example if I look at SMB > signing in the Protocol C and R Negotiate (SMB_COM_NEGOTIATE), the wireshark > parses it as SMB signing is enabled or disabled or required where as these > are two seperate fields. > > whereas if I compare the same with network monitor the flags are parsed to > the entirety with all 16 fields shown as shown below. > > Flags2: 51205 (0xC805) > KnowsLongFiles: (...............1) Understands Long File Names > (SMB_FLAGS2_KNOWS_LONG_NAMES) > ExtendedAttribs: (..............0.) Does NOT understand extended > attributes (SMB_FLAGS2_KNOWS_EAS) > SignEnabled: (.............1..) Security signatures enabled > (SMB_FLAGS2_SMB_SECURITY_SIGNATURE) > Compressed: (............0...) Compression Disabled for > REQ_NT_WRITE_ANDX and RESP_READ_ANDX (SMB_FLAGS2_COMPRESSED) > SignRequired: (...........0....) Security Signatures are NOT > required (SMB_FLAGS2_SMB_SECURITY_SIGNATURE_REQUIRED) > Reserved_bit5: (..........0.....) Reserved (Must Be Zero) > LongFileNames: (.........0......) DO NOT use Long File Names > (SMB_FLAGS2_IS_LONG_NAME) > Reserved_bits7_9: (......000.......) Reserved (Must Be Zero) > ReparsePath: (.....0..........) NOT a Reparse path > (SMB_FLAGS2_REPARSE_PATH) > ExtSecurity: (....1...........) Aware of extended security > (SMB_FLAGS2_EXTENDED_SECURITY) > Dfs: (...0............) NO DFS namespace > (SMB_FLAGS2_DFS) > Paging: (..0.............) Read operation will NOT be > permitted unless user has permission (NO Paging IO) (SMB_FLAGS2_PAGING_IO) > StatusCodes: (.1..............) Using 32-bit NT status error > codes (SMB_FLAGS2_NT_STATUS) > Unicode: (1...............) Using UNICODE strings > (SMB_FLAGS2_UNICODE) > > So while reading the trace how do I interpret these and are there any plans > of modifying t he same. > > Thanks and Regards > Dev >
___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe