> 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.
I'm not sure I agree; the current approach doesn't bother me all that
much, for reasons discussed below.
> For the most part, they don't,. For connection oriented dcerpc, all
> the dcerpc layer cares about is having a reliable byte-stream.
Well, it also cares about knowing which connection it's dealing with,
presumably. That stuff is probably buried in:
> The
> only difference between protseqs is having different functions to
> send/receive PDUs.
...the functions in question, as I assume those connections deal with
establishing and tearing down connections, as well as sending and
receiving PDUs.
As such, it doesn't bother me to have multiple pieces of code in the DCE
RPC dissector that know about different transports, as there's multiple
pieces of code in the DCE RPC *implementation* that know about different
transports.
If DCE RPC treats *all* underlying transports as byte streams (if, for
example, it treats record-oriented transports such as NetBIOS as byte
streams, with no guarantees that DCE RPC PDUs start or end on
lower-level protocol PDU boundaries), then, arguably, DCE RPC shouldn't
rely on TCP's desegmentation code either - it should do its own
desegmentation to desegment the pieces of a fragment (over and above
reassembly of fragments), and shouldn't treat the stuff handed to it by
the dissector that calls it as necessarily containing one and only one
DCE RPC PDU, regardless of whether that dissector is the TCP dissector
or not.