Wireshark · Smb2-protocol: [Smb2-protocol] Re: a first look at SMB2

[ronnie sahlberg <ronniesahlberg@xxxxxxxxx>]

Bytes 12-15 after the FID in the request is the maximum in size. 
Telling the server that the DataIn can not be bigger than this.

See attached capture where the client first probes what size to use by
specifying 0x16  and then in the truncated response it sees how big
the in buffer needs to be
and the client reissues it with a bigger max size.


These commands are for the "" file/share
and 64.40.14.00

The response payload looks like
(12 byte header)
4 byte unknown
4 byte number of returned strings
4 byte offset from after the header til the 4 byte status code

sequence of null terminated unicode strings

4 byte status code of some sort



On 11/24/05, Stefan (metze) Metzmacher <metze@xxxxxxxxx> wrote:
> ronnie sahlberg schrieb:
> > I added some quick code to dissect the payload of 0x0b as DCE/RPC
> >
> >
> > please check it with current svn of ethereal.
> >
> > the 0x0b request in 468 looks just as one might expect.
>
> after the FID this follows:
>
> 4byte data_offset
> 4byte data_length
> 4byte unknown1
> 4byte unknown2 (maybe the length of what the server should repeat from the
> request?)
>
> >
> >
> > look at   frame 469.
> > Lets just say this one was a surprise.
>
> here after the FID this follows:
> 4byte repeated_data_offset
> 4byte repeated_data_length (maybe controlled by unknown2 of the request?)
> 4byte reply_data_offset
> 4byte reply_data_length
>
>
>
> --
> metze
>
> Stefan Metzmacher <metze at samba.org> www.samba.org
>
> _______________________________________________
> Smb2-protocol mailing list
> Smb2-protocol@xxxxxxxxxxxx
> http://www.ethereal.com/mailman/listinfo/smb2-protocol
>

Attachment: foo.cap
Description: Binary data