> I have finally found an area of the SMB decode that needs state info.
>
> In order to match TRANSACT2 responses with requests (that is, get the names
> correct), I need to keep state for each TCP connection.
>
> This is because the TRANSACT2 response does not contain any indication of
> the request that it relates to.
Just like ONC RPC requests and replies...
> So, I must keep info about the current outstanding TRANSACT2 command
> ...
...except that ONC RPC can't do it by keeping state for connections, as
it may be running over a connectionless protocol.
The way "tcpdump" handles ONC RPC (or, at least, the two ONC RPC
protocols that have fixed port numbers; it punts on doing heuristics to
identify ONC RPC operations on ports *other* than 111 and 2049) is that,
when it sees a request, it records the IP address and port number of the
sender and recipient, along with the information about the operation
being done and the transaction ID of the request, and, when it sees a
reply, it looks for a request with the same source address and port as
the reply's destination address and port, the same destination address
and port as the reply's source address and port, and the same
transaction ID.
The addresses and ports amount to a connection ID for TCP; the
transaction ID in RPC corresponds, if I remember correctly, to the
"multiplex ID" in SMB.
