Hi Evan Did this approach got implemented? If not, I would like to give it a try.
regards, Roland On Tue, Aug 5, 2014 at 12:14 AM, Roland Knall <[email protected]> wrote: > Yes, that it what I was saying. > > Cool, you can look forward to the openSAFETY patch, the minute the change > hit the official repo ;-) > > regards, > Roland > > > On Mon, Aug 4, 2014 at 11:51 PM, Evan Huus <[email protected]> wrote: > >> >> On Aug 4, 2014, at 17:21, Roland Knall <[email protected]> wrote: >> >> >> Am 04.08.2014 um 23:16 schrieb Evan Huus <[email protected]>: >> >> >> >> On Aug 4, 2014, at 17:11, Roland Knall <[email protected]> wrote: >> >> >> >> >> On Mon, Aug 4, 2014 at 10:40 PM, Evan Huus <[email protected]> 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 <[email protected]> >> Archives: http://www.wireshark.org/lists/wireshark-dev >> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev >> >> mailto:[email protected]?subject=unsubscribe >> <[email protected]?subject=unsubscribe> >> >> >> ___________________________________________________________________________ >> Sent via: Wireshark-dev mailing list <[email protected]> >> Archives: http://www.wireshark.org/lists/wireshark-dev >> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev >> >> mailto:[email protected]?subject=unsubscribe >> <[email protected]?subject=unsubscribe> >> >> >> ___________________________________________________________________________ >> Sent via: Wireshark-dev mailing list <[email protected]> >> Archives: http://www.wireshark.org/lists/wireshark-dev >> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev >> >> mailto:[email protected]?subject=unsubscribe >> <[email protected]?subject=unsubscribe> >> >> >> >> ___________________________________________________________________________ >> Sent via: Wireshark-dev mailing list <[email protected]> >> Archives: http://www.wireshark.org/lists/wireshark-dev >> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev >> mailto:[email protected] >> ?subject=unsubscribe >> > >
___________________________________________________________________________ Sent via: Wireshark-dev mailing list <[email protected]> Archives: https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:[email protected]?subject=unsubscribe
