Wireshark · Smb2-protocol: [Smb2-protocol] SMB2 named pipes and TID

[ronnie sahlberg <ronniesahlberg@xxxxxxxxx>]

I have one trace that contains an instance of DCERPC over a named
pipe  and where the pipe is slightly busy  so it returns a 
STATUS_PENDING   followed slightly later by the real reply.
The weird thing here  and which breaks ethereal is that in both
replies   the TID is suddenly 0   instead of the
real value used in the request.

Apart from this   the client still seems happy   so
it seems it does not check the TID   or require it being the
same in a reply as in the request



The sequence is   (client has opened a named pipe and is doing i/o using read/write calls, not ioctl)

Client->Server    SMB2 Write request : DCERPC Bind
Server->Client    SMB2 Write reply        

 (now the client will use Read to get the BindACK back from the client,   here is the weird TID)

Client->Server    SMB2 Read request : TID=1   
Server->Client    SMB2 Read reply :  TID=0   STATUS_PENDING   no bytes returned
(somewhat later)
Server->Client      SMB2 Read reply : 
TID=0    92 bytes of data returned  (bindack)

the client is still perfectly happy with TID=0   since
immediately afterwards it proceeds to send normal commands on the pipe
it just bound to.


Ethereal gets confused though and refuses to dissect the bind ack
reply   since ethereal relies on the TID value in the
response.   I will change this to
"remember" the TID from the request and use that one instead.
(ethereal uses the TIDs to determine what is IPC$ and what is
not     so it can distinguish normal file
i/o   with ipc$ named pipe file i/o)



I have only one single capture with one single sequence when this happens.



i.e.   it appears that the TID is "undefined" in SMB2 replies
(except for TConnect)  and a server need not reply with the same
TID as in the request   and thus a client (such as ethereal)
can
not rely on the TID being bounced back.

Maybe ethereal should not dissect the TID field from replies at all ?   Except for the TreeConnect response ?


Could this be related to the "a FID can be used across any TID, not just the one it was created through?"