Wireshark · Wireshark-dev: Re: [Wireshark-dev] RFC: Internally Generated "Records"

[Evan Huus <eapache@xxxxxxxxx>]

On Aug 4, 2014, at 17:21, Roland Knall <rknall@xxxxxxxxx> wrote:

Am 04.08.2014 um 23:16 schrieb Evan Huus <eapache@xxxxxxxxx>:

On Aug 4, 2014, at 17:11, Roland Knall <rknall@xxxxxxxxx> wrote:

On Mon, Aug 4, 2014 at 10:40 PM, Evan Huus <eapache@xxxxxxxxx> wrote: 

Right now you can't filter on field combinations that must appear "together" in one of those application frames: if fieldA appears in frame 1, and fieldB appears in frame 2, then that packet will match "fieldA && fieldB" even if they never appear "together" in the way a normal human would intend. Being able to label each of those frames as a separate "record" would solve this problem.

 

One thing to look out for here is the fact, that this may change behavior of the display filters in a way, the end-user may never see coming. We would have to come up with a syntax in wireshark, where we allow either "(fieldA && fieldB)" meaning, record1.fieldA and record2.fieldB or fieldA and fieldB in the same record. The end-user does not necessarily make that distinction. If he simply selects frame fields, he may end up with display filters which do not filter the intended or any packages, but he has no clue why simply because the display filter interprets the syntax in a way the end-user could not foresee.

Yes, I was thinking some additional syntax like wrapping an _expression_ in {} or something to indicate it should only match within a single record.

It should be the other way around. The new syntax should emphasize the fact that it should match in different records, otherwise you are going to break compatibility with the current usability. 

?

Right now we match regardless of records - that should continue to be the default so that existing display filters don't break. We should introduce a new syntax for the new feature... Or is that what you are already saying?

On the rest, I see your point.

regards,

Roland

 

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
            mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
            mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
            mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe