> I've been sucessfully using a combination of perl and tethereal to
> decode a data packet. I recently discovered that 1/12 of the data is
> missing and appears in a subsequent packet. I'd post the packets from a
> generic ethereal monitor via an X copy-paste into emacs, but some
> bright spark coded ethereal such that X copy doesn't work
Or, rather, the GTK+ widgets in question don't automatically do that
sort of clipboard/selection stuff (for one thing, it's not clear what a
row in a GtkClist would put into the primary selection or clipboard, and
that wouldn't get you the detailed decode in any case, as the CList that
shows the list of packets knows nothing about the printed form of
Ethereal protocol tree displays), and nobody has yet written code in
Ethereal to do clipboard stuff itself - it's on the wishlist, but there
are a *lot* of things on the wishlist, and not all of them get done
immediately.
You can, for now, "print" the contents of a packet to a file, and put
that into a mail message.
> (grumble;
> perhaps if the shift or control key is depressed, it could indicate
> that X-copy is desired, not packet selection).
The issue has nothing to do with mouse key bindings, the issue has to do
with the fact that Ethereal contains no code to put stuff into the GTK+
primary selection or clipboard (which, on X, puts it into the PRIMARY
and CLIPBOARD selection. It could put, say, the text for the protocol
tree of the currently selected packet into the primary selection, in
which case the middle button would paste that text, and Cut and Copy
could also be made to copy that text to the clipboard; it's a Simple
Matter Of Programming, but nobody's programmed it yet....
> The first packet is easy to find, it's an unusual size, the source IP
> is known and the dest port is known. A simple filter :
>
> tethereal -n -i eth1 -x -c 1 -f "ip src $server and greater 490"
>
> reliably picks it out of a noisy LAN to pipe into the perl decoder.
> The remaining data appears in a smaller 45 byte packet that has the
> same Ack code, but the arrival timing appears to be far faster than a
> second invocation of tethereal with appropriate parameters could
> capture.
>
> So I need a different answer. The nature of this problem (picking
> data out of multiple packets) has surely been seen before and solved
> within ethereal.
No, it hasn't, in fact; no dissectors currently assemble higher-level
packets from multiple frames. That's *another* item on the wish list,
and it involves
1) building code to do reassembly of fragmented IP datagrams;
2) building code to reassemble TCP streams
3) building code in at least some dissectors called from TCP to
reassemble higher level packets from the raw TCP stream
3) building code to reassemble stuff in other protocols, over
time, as needed.
> How do I do that? Can I reuse the perl decoder (or is it just a
> roadmap)?
Well, I've never seen the Perl decoder in question, so I don't know
whether it could be reused; one problem is that you might need the raw
packet data in order to put two packets together.