 | 1 | initial version |
1) Filter expressions aren't not regular expressions in the Kleene sense, they're tests of the values of protocol fields, although Kleene-style regular-expression matching is one type of test that can be performed, using the "matches" operator.
2) That wouldn't be a question of "flexibility", it would be a question of a massive revamp of the way filtering is done, as the notion that a filter applies only to the contents of the packet being filtered, not to subsequent or previous packets, is fundamentally built into the filtering code.
It might even end up best being done as a mechanism separate from the filter-evaluation mechanism - a mechanism such as MATE.
3) If "the tool" means Wireshark, "the tool" won't be able to do anything for you if it doesn't "know the protocol", in the sense of knowing how to dissect fields in the protocol. MATE doesn't have wired into it knowledge of particular protocols; it has a language that allows you to specify named fields for any protocol that Wireshark can dissect. However, the goal of MATE is to allow patterns that involve relationships between the values of named fields, where those relationships aren't tested by the dissector logic, to be specified. You inherently have to have patterns that are "bound by the protocol" in the sense of testing fields in the protocol; what MATE does is let you have patterns that aren't bound by the logic of the dissector.
