unknown1-4 are the 16 bytes just prior to the fid in the request?
For class:0x03 level:0x00 it is unknown3
that controls what parts of the security descriptor to return.
that means that at least unknown3 and unknown4 are part of
a fixed size parameter block that is specific to the infolevel called.
should i implement code in ethereal to assume that all 16 bytes of unknown1-4 are level specific ?
On 11/16/05, tridge@xxxxxxxxx <tridge@xxxxxxxxx> wrote:
Ronnie,
Some strange stuff with the EA_LIST level (0xf). It appears to be
stateful! The server seems to remember how many EAs you have fetched
on the handle and returns the next bunch when you call again.
This also seems to be controlled by the field which I have called
'unknown4' in the following getinfo request structure:
struct {
uint16_t buffer_code;
uint16_t level;
uint32_t max_response_size;
uint32_t unknown1;
uint32_t flags;
uint32_t unknown3;
uint32_t unknown4;
struct smb2_handle handle;
} in;
the weird part is exactly how it is controlled. For example, with 10
EAs on a file I get:
unknown4==0 -> fetch next set of EAs, or return STATUS_NO_MORE_EAS
unknown4==1 -> always fetch from the beginning of the EA list
unknown4==2 -> fetch the next single EA from the list
unknown4==3 -> fetch one value from the start of the list
any other value of unknown4 up to 7 gives STATUS_NON_EXISTENT_EA_ENTRY
it appears only the bottom 4 bits matter.
Cheers, Tridge
_______________________________________________
Smb2-protocol mailing list
Smb2-protocol@xxxxxxxxxxxx
http://www.ethereal.com/mailman/listinfo/smb2-protocol
