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

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

Date Index Thread Index Other Months All Mailing Lists
Date Next Thread Next
From: ronnie sahlberg <ronniesahlberg@xxxxxxxxx>
Date: Mon, 6 Feb 2006 11:47:54 +1100
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?"