It is also interesting in your captyure that buffercode is 0x18
indicating the pdu ends immediately after the end of the fid.
what are those trailing 24 bytes then? padding, a bug in vista
or data from a chained command(unlikely)?
that would leave the 6 bytes between buffer code and fid to hold the
possible field/flags to specify:
Client holds no oplock (real break)
Client holds level 2 oplock (downgrade)
Can a client issue a Break request to deliberately release an oplock?
On 4/5/06, ronnie sahlberg <ronniesahlberg@xxxxxxxxx> wrote:
> Checked in with minor changes
>
> there are 6 unknown bytes between the buffercode and the fid not 4.
> (dissection till worked with 4 since it will auto align the fid to be
> on a 32bit boundary)
>
> i also marked commandsequencenumber == -1 in the header as
> "(unsolicited response)"
>
>
> --
>
> shouldnt there be a flag or something in there as well that indicated
> whether the oplock is broken or merely just being downgraded to a
> level 2 oplock ?
>
>
> I will update the wiki for the break command.
> Can i have your permission to upload the capture file to the wiki?
>
>
> On 4/5/06, Stefan (metze) Metzmacher <metze@xxxxxxxxx> wrote:
> > Hi Ronnie,
> >
> > can you apply this patch please,
> > it adds dissecting of Oplock Breaks.
> >
> > thanks!
> >
> >
>
