Cool.
Will this be included in CVS after the release?
(if so Great, I _HATE_ fragmented packets when analyzing upper layers, as
RPC)
Some questions, (I have not tested this yet, will do tomorrow)
1, When reading captures or rescan_packets() (when changing something or
applying a display filter)
will the dissector for the higher-layer protocol (==UDP) be called for
the alternative named source
instead of the original content of the datagram?
I, mean, does stuff like (rpc.program==100021) still work even if the
rpc-header is not in the first ip-fragment?
2, Will this affect the possibilities to get this feature in Tethereal? (I
dont use tethereal)
3, When analyzing higher-layer protocols, I would like to be able to do
something like
(ip.fragment==FALSE) so that no fragments are seen. But I would still
want to se the defragmented packet.
Would this be theoretically possible?
If you are happy with this version (which if question #1 is answered YES is
IMHO superior to the original design)
I would love to see it in CVS.
Some additional features that should be included (I can look at this
tomorrow) would be:
* fragments should not be considered for defragmentation if the checksum is
not correct (really a bug)
* if there are overlapping fragments when putting together the defragmented
packet one should
have a searchable field ip.fragment.overlap==TRUE or similar.
* if overplapping fragments have different/conflicting data one should set a
searchable
field ip.fragment.conflict or similar.
* the defragmented packet should indicate which original packets were used
to defragment the packet.
All or some of this might already be implemented, I have not looked properly
yet.
Again, many many thanks for improving the patch.
----- Original Message -----
Sent: Tuesday, April 10, 2001 6:20 PM
Subject: Re: [Ethereal-dev] ip defragment, virtual packets
> On Mon, Apr 09, 2001 at 11:50:56AM -0700, Guy Harris wrote:
> > > I think that the named data sources would be a cleaner method to
> > > handle the ip defrag.
> >
> > Precisely what I was thinking this morning.
> >
> > > You can use the current code to build the
> > > ip data list. Then when all the data is received create a named
> > > view with the defrag'ed data. This way you don't have to create
> > > the virtual packet. And the data storage doesn't have to include
> > > an IP header, just save the actual packet data after the IP
> > > header.
> >
> > ...and, in addition, you'd get to see the link-layer header on the last
> > fragment even if you've enabled IP reassembly.
>
> Here's a patch, which applies to the current CVS version of Ethereal.
>
> Unfortunately, the named data sources stuff works right only if all the
> dissectors handed the named data are tvbuffified.
>
> This may be a failure in the way we handle calling old-style dissectors
> from tvbuffified dissectors...
>
> ...but the right way to fix it is, I think, to get rid of the remaining
> old-style dissectors or, at least, get rid of the ones for protocols
> that run atop UDP (you're unlikely to get TCP segments inside fragmented
> IP datagrams, although it's not impossible to get that).
>
