Ethereal-dev: Re: [Ethereal-dev] [PATCH] fix for multiple dcerpc connections over single socke
Guy Harris <guy@xxxxxxxxxx> writes:
> > I'm fairly surprised by that. The obvious corollary would be that the
> > TCP layer should use the same approach to allow the dcerpc dissector
> > to distinguish between port pairs.
>
> What approach?
>
Tim's patch to the SMB layer added special case code
(dcerpc_private_info, etc.) which lets the SMB layer tell dcerpc about
the multiplexing info (FIDs) that it has figured out. The dcerpc
dissector then checks for this special case, and, if it finds it, uses
it in its conversation code. I'm saying this is bad, and that the
generic conversation code should be enhanced to account for
multiplexing over SMB. That way, the SMB layer wouldn't have to do
special things solely for dcerpc, and dcerpc wouldn't have to check
for the special case of running atop SMB.
My understanding was that you didn't mind the current way, but perhaps
I misunderstood and you were referring to something else. IMO, if the
current way makes sense, then it would make equal sense for the TCP
layer to put src and dest port information into a dcerpc_private_info,
with DCERPC_TRANSPORT_TCP, e.g., and let dcerpc check for that, as
well.
> > Surely you wouldn't want to do
> > that? Also, dcerpc isn't the only thing that's done with SMB named
> > pipe transactions. There're very likely to be other dissectors which
> > will want to be able to distinguish between SMB
> > fids/ports/conversations/whatever.
>
> But how many of them are dissectors that don't know that they're running
> atop SMB?
>
I think that's the wrong question to ask. I think a better question
is how many of them NEED to know that they're running over SMB. (And
to be clear, I'm talking about SMB Named Pipes, not all of SMB.) IMO,
the answer is 0, provided, of course, that the SMB layer provides the
infrastructure to allow them to be ignorant.
A perfect example of this just came up in another thread. The
netlib/TDS stuff used by SQL Server runs identically over TCP port
1433, and SMB on \pipe\sql\query. Should the dissector for that be
forced to figure out which it's running on? Shouldn't it just be able
to use find_conversation in either case, if it wants to? It's exactly
the same for dcerpc.
(In my mind, the below is unrelated to the above.)
> I only mentioned the DCE fragmentation in passing; the only issue I'm
> asking about is splitting a DCE fragment across multiple transport-layer
> packets and putting more than one DCE fragment in a single transport
> layer packet.
>
> > As I understand it, the TCP
> > desegmenting code is for the use of dissectors which can tell "Oh, I
> > don't have a complete blob to work on. Let me get more data, first."
> > If so, then it's a natural fit for dcerpc over TCP, and indeed, it
> > works well on my captures, here. Now, I agree that it'd be better if
> > there were a more generic way of doing this, so that a dissector could
> > ask its caller (assuming the caller provides a byte stream), "I need N
> > more bytes, please.", and not just the TCP layer.
>
> What transport protocols are there other than TCP that provide a byte
> stream?
The Netbios session service and SMB Named Pipes do, and there are
others. Basically, anything that connection oriented dcerpc runs over
does, as well. If it didn't, dcerpc would use the connectionless
approach, like ncadg_ip_udp.
> As I understand it, OSI COTP, for example, provides packets,
> not a byte stream.
>
I'm not familiar with COTP, but calling them packets gets confusing
for me. Perhaps saying NBT and SMB Named Pipes (and others) provide
reliable byte streams with message boundaries would be more clear?
> So the question is whether DCE RPC, when running atop *packet-oriented*
> connection-oriented transports, arranges that each transport PDU
> contains one and only one DCE PDU - in which case, for those transports,
I think that's true for some transports, but not others. E.g., the
case of ncacn_nb_tcp (dcerpc/nbt/tcp) seems to always put one dcerpc
PDU in one NBSS message, but ncacn_np (dcerpc over smb named pipes)
doesn't necessarily do that. One PDU may require several SMB Writes
and/or Reads.
> the equivalent of TCP desegmentation isn't needed - or whether it treats
> packet-oriented transports as if they merely provided a sequenced byte
> stream,
Yes.
> in which case either
>
> 1) the DCE RPC dissector needs to do segment reassembly anyway,
> and can probably do the reassembly itself for TCP
>
I think this is the wrong way to go. What is the purpose of the TCP
desegmenting code, if not for this?
> or
>
> 2) you'd need that "more generic way of doing this" even if the
> caller provides packets rather than a byte stream.
>
Yes, I think this is the way to go. It sounds like the netlib/TDS
could use it, too. I don't have a particular implementation in mind,
though.
Todd
