From: "Ulf Lamping"
| Olivier Biot wrote:
|
| >Hi list,
| >
| >Now that we don't put carriage returns in the display filter
anymore,
| >the dialog for "Filter out this stream" doesn't show up anymore
after
| >2 or 3 filtered-out streams (probably because the dialog becomes
too
| >wide, however I see no error or warning message). Should we keep
two
| >versions of the filter string for this peculiar situation (one for
the
| >dialog, another for the display filter)?
| >
| >
| I fear I might understand you incorrect.
|
| Do you refer to the "Follow TCP stream" function?
Yes, but in cooperation with "Filter out this stream". The bug I was
referring to is related to the progress dialog that shows up when an
end-user clicks on the "Filter out this stream" button. The current
implementation does not show the dialog anymode from the instance that
the rendered display filter string pixel width exceeds the dialog's
maximum width. This occurs rather quickly (follow some 2-3 streams and
you're already at this limit on cygwin with GTK2).
| Filtering out a TCP stream will only show *one* TCP stream (by TCP
| design), or how do you filter out two streams or more in parallel?
No. Filtering out a TCP stream filters it out and leaves all remaining
packets that are *not* part of this TCP stream.
| Do mean filtering out *the same* TCP stream again and again? As this
| might not be wise, it should work of course (and it seems to be a
bug in
| it).
This is not possible using the "Filter out this stream" function, as
you cannot follow a TCP stream if it doesn't match the current display
filter.
| The generated filter string (doing "follow TCP stream" on the same
| packet twice) will look something like:
|
| (ip.addr eq 10.0.0.10 and ip.addr eq 10.0.0.11) and (tcp.port eq
4517
| and tcp.port eq 135) and !((ip.addr eq 10.0.0.10 and ip.addr eq
| 10.0.0.11) and (tcp.port eq 4517 and tcp.port eq 135))
|
| As the second stream filter is appended using an exclamation mark,
this
| is logically a: "(stream a) and !(stream a)", which of course is
wrong
That's not the way this logic applies.
| and won't show any packets.
That is *not* the way the "Filter out this stream" functionality
works. It takes the existing display filter, and refines this
*existing* display filter by iltering out the packets belonging to the
TCP stream that has been followed, hence the logic reads: "(existing
display filter) and !(followed tcp stream)", which works.
| Could someone look at the "follow TCP stream" code and fix this?
Nothing to be fixed for display filter generation, however the current
implementation will not show the progress dialog because (I guess but
with enough confidence) of an unwrapped display filter string which
yields too wide a dialog.
Regards,
Olivier
