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 <eapa...@gmail.com> wrote: > > On Aug 4, 2014, at 17:21, Roland Knall <rkn...@gmail.com> wrote: > > > Am 04.08.2014 um 23:16 schrieb Evan Huus <eapa...@gmail.com>: > > > > On Aug 4, 2014, at 17:11, Roland Knall <rkn...@gmail.com> wrote: > > > > > On Mon, Aug 4, 2014 at 10:40 PM, Evan Huus <eapa...@gmail.com> 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@wireshark.org> > Archives: http://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev > mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe > <wireshark-dev-requ...@wireshark.org?subject=unsubscribe> > > ___________________________________________________________________________ > Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> > Archives: http://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev > mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe > <wireshark-dev-requ...@wireshark.org?subject=unsubscribe> > > ___________________________________________________________________________ > Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> > Archives: http://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev > mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe > <wireshark-dev-requ...@wireshark.org?subject=unsubscribe> > > > ___________________________________________________________________________ > Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> > Archives: http://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev > mailto:wireshark-dev-requ...@wireshark.org > ?subject=unsubscribe >
___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe