Ethereal-dev: Re: [Ethereal-dev] [PATCH] fix for multiple dcerpc connections over single socke
> 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?
> 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?
> > If DCE RPC treats *all* underlying transports as byte streams (if, for
> ^ connection-oriented
> > 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
>
> There are separate issues here.
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? As I understand it, OSI COTP, for example, provides packets,
not a byte stream.
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,
the equivalent of TCP desegmentation isn't needed - or whether it treats
packet-oriented transports as if they merely provided a sequenced byte
stream, in which case either
1) the DCE RPC dissector needs to do segment reassembly anyway,
and can probably do the reassembly itself for TCP
or
2) you'd need that "more generic way of doing this" even if the
caller provides packets rather than a byte stream.
