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.