Ethereal-dev: Re: [Ethereal-dev] [PATCH] fix for multiple dcerpc connections over single socke
Guy Harris <guy@xxxxxxxxxx> writes:
> > I'm glad to see someone getting this working, but wouldn't it be
> > cleaner to have the SMB layer add this to the conversation info for
> > the packet? I.e., add a port_type PT_SMB, and have the FID be either
> > src or dest port (both?), or something along those lines.
>
> Unfortunately, you can't replace the TCP port number with the FID; the
> same FID can be used in more than one connection from client X to SMB
> server Y.
>[...]
> A Fid returned by the server to one process may be used by any
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> other process using the same transport connection and Tid.
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> which suggests that file IDs are unique only within a given transport
> connection and Tid, not globally unique.)
>
Well, how about this, then. The TCP port(s) are only 16 bits, and
the SMB fid and tid are only 16 bits (yes?), so we can define a
PT_SMB (or PT_SMB_TCP?), which would combine the TCP src port with
the TID, and the TCP dest port with the FID. I.e.,
smb.srcport = (tcp.srcport << 16) | smb.tid
smb.destport = (tcp.destport << 16) | smb.fid
Rather hackish, admittedly, but cleaner than the current approach,
IMO.
> There is no provision in the conversation code for more than the source
> and destination port numbers being used...
I think this is the crux of the problem. It would seem better to base
conversations on aggregated properties from each protocol in the
stack. Each one would add in the 'multiplexing' parts it knows about.
IP would add addresses and proto_type, TCP and UDP would add ports,
SMB would add in TID, FID, or whatever. The same approach would work
with IPX, etc. Probably a lot of work to retrofit at this point,
though.
>
> (You could, I guess, replace the server port number, but that strikes me
> as being at least as greasy a hack as the current code - frankly, it
> strikes me as even uglier than what we're doing now; what we're
> currently doing really doesn't bother me all that much, as the
> underlying DCE RPC implementations, at some layer, *are* treating
> different transports differently, I suspect.)
>
For the most part, they don't,. For connection oriented dcerpc, all
the dcerpc layer cares about is having a reliable byte-stream. The
only difference between protseqs is having different functions to
send/receive PDUs.
Todd
