Good, have some vacation days coming up and will give it a try.
regards,
Roland
On Tue, Aug 18, 2015 at 4:53 PM, Evan Huus <eapa...@gmail.com> wrote:
> On Tue, Aug 18, 2015 at 10:49 AM, Roland Knall <rkn...@gmail.com> wrote:
> > Hi Evan
> >
> > Did this approach got implemented? If not, I would like to give it a try.
>
> As far as I know nobody is working on it. Feel free to give it a try.
>
> Evan
>
> > regards,
> > Roland
> >
> > On Tue, Aug 5, 2014 at 12:14 AM, Roland Knall <rkn...@gmail.com> 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 <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
> >>>
> >>>
> >>>
> ___________________________________________________________________________
> >>> 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
> >>>
> >>>
> >>>
> >>>
> ___________________________________________________________________________
> >>> 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: https://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: https://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: https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
