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

[Evan Huus <eapache@xxxxxxxxx>]

On Tue, Aug 18, 2015 at 10:49 AM, Roland Knall <rknall@xxxxxxxxx> 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 <rknall@xxxxxxxxx> 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 <eapache@xxxxxxxxx> wrote:
>>>
>>>
>>> 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
>>>
>>>
>>>
>>> ___________________________________________________________________________
>>> 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:    https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>              mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe