Mmh... we already have this functionality with the "filter out this
stream" function, but we then generate a display filter expression for
TCP sream exclusion. I'm not 100% familiar with filtering, but I know
there's a thing called a "primed tree". Maybe it's just this primed
tree that we need in this situation, and then the effort to implement
it would be minimal.
Regards,
Olivier
----- Original Message -----
From: "Ulf Lamping"
| Chris Wilson wrote:
|
| >Hi all,
| >
| >
| >Thought I'd get some views on this before digging around in the
sourcecode.
| >
| >When using Ethereal I've often wanted a "crop" feature - that would
discard all the packets not matched by a particular filter, so that
subsequent filtering is much quicker.
| >
| This would be a valuable feature, I've often wanted something like
that
| myself :-)
|
| >A little button next to "Clear" and "Apply" on the GUI mainscreen
would be perfect.
| >
| >
| Yes, it would fit best to the "filter toolbar" as I've started
calling
| it yesterday. Additionally, we might want to have a menuitem e.g.
under
| "File", but if we have the main functionality, that's easy to add.
|
| >I realise that this saving/reloading is probably going to be
neccessary since all the packets will need to be refiltered once the
unmatched packets are discarded.
| >
| >So... do people think this sounds sensible:
| >
| >A "Crop" button next to "Clear" and "Apply" on the mainscreen.
| >
| >
| I'm not sure about the word crop itself. I currently searching for a
| better one, maybe "trim". As I'm not a "native english speaker",
there
| might be better words for this I just don't see.
|
| >The button would save the displayed packets to a temporary file,
| >
| There are two possible reactions to the button press:
|
| a.) always saving the currently displayed packets (hardwired,
without
| any dialog box), making things work with less clicks
| b.) showing up a dialog box with the range frame (just like the
"Save
| As" dialog), let the user choose the packets to be saved, making
things
| more flexible
|
| I currently don't have an opinion, if a.) or b.) would be better.
|
| >load the temporary file but still leave ethereal thinking it's
editing the original file (so that "Save" overwrites the original
file).
| >
| >
| IMHO it would be better to display the new file as a temporary file
(not
| as a "faked saved file"), as thats what it is. In such cases I tend
to
| keep the original file, when saving a trimmed file, just in case I
| missed something out and need other packets of this file later.
|
|
| One thing left to think about: what should be done, if the current
file
| *is* a temporary file (recently captured)? As Ethereal can only
handle
| one file at a time, the original file would be gone, when the
trimmed
| file is made.
|
| >Hopefully I should be able to implement this without changing too
much of the file loading internals.
| >
| >Let me know your thoughts...