Ethereal-dev: Re: [Ethereal-dev] tcp, desegmentation, multiple pdus per segment thoughts

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: "Ronnie Sahlberg" <rsahlber@xxxxxxxxxxxxxx>
Date: Tue, 6 Nov 2001 20:52:21 +1100
Good points,

Sometime later, after smb and nfs (and a few other nfs and smb ideas i have)
are finished I
might look into this. Unless someone else beats me to it.

Perhaps starting with TCP only and something like
    while(tvb_length_remaining()) {
        consumed = decode_tcp_ports();
        if (consumed==0 ){
            display_as_unknown_data()
            break;
        }
        offset += consumed;
    }

Ill add it to my list of fun ideas/todo-stuff

Would this only be relevant to TCP?
Do you know of any udp based protocols which pads multiple pdu's in a udp
datagram?
(I suspect there can be some RTP protocols like voip where this might occur)


----- Original Message -----
From: "Guy Harris"
Subject: Re: [Ethereal-dev] tcp, desegmentation, multiple pdus per segment
thoughts


> On Tue, Nov 06, 2001 at 08:00:57PM +1100, Ronnie Sahlberg wrote:
> > This assumes a few things:
> > 1, there is some way that decode_tcp_ports (reliably) can detect how
much
> > data was dissected by
> > the call to the subdissector.
>
> If all subdissectors were to return either
>
> 1) the offset of the first byte after the stuff they dissected
>
> or
>
> 2) zero, if they're acting as heuristic dissectors and didn't
>    recognize the frame as one of theirs
>
> that might let "decode_tcp_ports()" figure that out.
>
> > 2, every subdissector consumes at least one byte, or we will have to
prevent
> > this from becoming an infinite loop.
>
> If it doesn't consume a byte, that will be considered evidence that it
> didn't like what it saw.
>
> > 3, there are no protocols which pad the remains of a segment with
> > crap/random data after the pdu.
>
> Any TCP protocol that did that wouldn't work very well - dissectors
> that run over TCP have no notion of segment boundaries, so they couldn't
> distinguish
>
> +-------+
> | PDU 1 |
> +-------+
> | PDU 2 |
> +-------+
> | crap  |
> +-------+
>
> in one segment from
>
> +-------+
> | PDU 1 |
> +-------+
> | PDU 2 |
> +-------+
>
> in one segment and
>
> +-------+
> | crap  |
> +-------+
>
> in the next segment.  The latter isn't going to work, so the former
> isn't going to work either.
>

Yes. I was confused.