On Sat, Jul 07, 2001 at 10:08:18AM -0600, John McDermott wrote:
> Richard,
> This could be quite useful, but I have two thoughts:
> 1) It would be nearly impossible to find matches as proxy-based
> firewalls by their nature entail two connections: one from inside host
> to firewall and one from firewall to outside host. Thus, matching ident
> fields would not be possible. Sure, one could find datagrams from host
> a to host b in both traces, but I'm not sure how to find the heuristic
> to match the packets. Size won't work as MTUs and windows may differ
> along the (up to) 5 firewall path.
>
> 2) It seems as though the goal here is not to dissect packets (a task at
> which ethereal excels), but to compare packets. How about having
> ethereal save "short-form" traces (similar to the top pane on the
> display) and use, e.g., perl to compare them?
Well, I deal with problems like this a lot. Debugging faulty links and
connections often result in situation where I have multiple dumps of one
data transfer (in one or more TCP connections), one acquired near the
source and one near the destination (and possibly other(s) acquired
somewhere in between). Then I need to compare them to see where exactly
a TCP segment got lost or messed up. I wrote a TCP connection
visualisation module (something like tcptrace) for this purpose. When I
display graphs of all of the dumps I can usually see quite quickly where
they begin to differ. This visual method might not look "exact" or
"automated" enough but it has suprisingly good results. I've been able
to spot a subtle problem in dumps with tens of thousands of segments
almost immediatelly. After I noticed something weird at the graph I can
click on the interesting segment in the graph and it gets selected in
ethereal's main window (packet list) so I can dissect it, check seq/ack
numbers and generally do anything I need. You might want to give it a
try, the patch against 0.8.18 is available at http://kostra.uh.cz/ethereal/ .
pvl