Wireshark-bugs: [Wireshark-bugs] [Bug 8178] Multiple requests or responses in a single frame ca
Comment # 13
on bug 8178
from Evan Huus
(In reply to comment #12)
> (In reply to comment #10)
> > It seems to me that there are two separate issues here:
> >
> > 1. How to usefully filter multiple protocol occurrences in a single frame.
> >
> > What about a function limit_distance(n, filter) where an n of 0 requires the
> > filter be satisfied in a single subtree, n of 1 allows the engine to travel
> > one level to satisfy the filter, etc.
>
> I take it that's similar to same_subtree(protocol, filter)? If so, what
> defines a subtree? If there are multiple levels at which there are multiple
> higher-level packets per frame, with an n of 0, which of those subtrees
> would be used?
Similar to but more flexible than same_subtree. A subtree in this context is
whatever is registered with proto_register_subtree_array (basically ett_
variables). This has the advantage that it works automatically with existing
dissectors as long as they group tree items under a subtree when they belong
together. For example:
PROTO
|-item1
|-item2
|-subtree
||-item3
||-item4
|-subtree
||-item4
||-item5
||-subtree
|||-item6
|||-item7
These filters would match:
limit_distance(0, item1 && item2)
limit_distance(0, item3 && item4)
limit_distance(0, item4 && item5)
limit_distance(0, item6 && item7)
These would not:
limit_distance(0, item1 && item3)
limit_distance(0, item3 && item5)
limit_distance(0, item4 && item6)
These would match:
limit_distance(1, item1 && item3)
limit_distance(1, item3 && item5)
limit_distance(1, item4 && item6)
limit_distance(2, item1 && item7)
This would not:
limit_distance(1, item1 && item7)
Something about this still doesn't feel quite ideal, but it's a step in the
right direction.
You are receiving this mail because:
- You are watching all bug changes.
