Ethereal-dev: Re: [Ethereal-dev] [PATCH] fix for multiple dcerpc connections oversingle socket
Well what matters is is that currently DCERPC uses the can_desegment service
without making sure it
only does this when running directly ontop of TCP and that nothing similar
exists for any other
connection oriented transport used by DCERPC.
Until can_desegment services can be offered by all connection oriented
transports used by DCERPC
DCERPC must make sure only to use it when it explicitely knows it is running
ontop of TCP.
Currently only TCP offers can_desegment as a service. I think it is
"difficult" to implement something
similar, unsing the same can_desegment API for saomething like SMB. Not
impossible, but difficult.
However that is a feature that does not exist today.
I think DCERPC SHOULD make sure it only uses can_desegment when it knows it
is running directly
ontop of TCP.
I also think it is reasonable that the routines calling subdissectors should
be modified so that they always
clears can_desegment unless being invoked via tcp_try_ports AND
TCP-desegmentation is ON.
I actually think that inside tcp_try_port() is where we should have
something like
...
if TCPv4_DESEGMENTATION_ENABLED
can_desegment = TRUE
else
can_desegment = FALSE
and not in the code before calling tcp_try_port()
All other subdissector dispatcher should always clear can_desegment.
This WILL be nessecary WHEN/IF soemone does some cut-n-paste to add this
feature to
TCPv6. (a matter of time? when TCPv6 becomes popular?)
Illustration,
Assume we have TCP desegmentation for BOTH IPv4 and IPv6.
Assume TCP-desegmentation is only enabled for IPv6
Assume fictional packet
IPv6 - TCPv6 - HTTP (HTTPtunnel) - IPv4 - TCPv4 - NBSS - whatever
TCPv6 offers the can_desegment service, HTTP in a future version might
actually use it, but that is irrelevant.
The NBSS dissector sees can_desegment and wants to use it, tough luck TCPv4
ignores it since
desegmentation is not on for v4.
However, TCPv6 dissector will see, hey HTTP wants desegmentation, oki mate.
Estimated end result : BAD.
2, I dont like the PORT_SMB idea. It feels weird.
Normal ports are normally statically bound to a service and can be used to
multiplex and identify which
service it refers with only the local information.
(local as in knowing which service say a UDP port refers to without knowing
what crap was sent on a different session
or in a different packet.)
----- Original Message -----
From: "Guy Harris"
To: "Todd Sabin"
Sent: Tuesday, November 20, 2001 3:24 PM
Subject: Re: [Ethereal-dev] [PATCH] fix for multiple dcerpc connections
oversingle socket
> > 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.
>
> _______________________________________________
> Ethereal-dev mailing list
> Ethereal-dev@xxxxxxxxxxxx
> http://www.ethereal.com/mailman/listinfo/ethereal-dev
