Hello,
I tried to do that, but failed on Qt packet list logic...
Idea: add children to packets on packet list.
https://code.wireshark.org/review/#/c/10107/1
Please feel free to use it. (let treat is as Public Domain)
On 18 August 2015 at 17:04, Roland Knall <rkn...@gmail.com> wrote:
> 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
>
--
Pozdrawiam / Best regards
-------------------------------------------------------------------------------------------------------------
Michał Łabędzki, Software Engineer
Tieto Corporation
Product Development Services
http://www.tieto.com / http://www.tieto.pl
---
ASCII: Michal Labedzki
location: Swobodna 1 Street, 50-088 Wrocław, Poland
room: 5.01 (desk next to 5.08)
---
Please note: The information contained in this message may be legally
privileged and confidential and protected from disclosure. If the reader of
this message is not the intended recipient, you are hereby notified that
any unauthorised use, distribution or copying of this communication is
strictly prohibited. If you have received this communication in error,
please notify us immediately by replying to the message and deleting it
from your computer. Thank You.
---
Please consider the environment before printing this e-mail.
---
Tieto Poland spółka z ograniczoną odpowiedzialnością z siedzibą w
Szczecinie, ul. Malczewskiego 26. Zarejestrowana w Sądzie Rejonowym
Szczecin-Centrum w Szczecinie, XIII Wydział Gospodarczy Krajowego Rejestru
Sądowego pod numerem 0000124858. NIP: 8542085557. REGON: 812023656. Kapitał
zakładowy: 4 271500 PLN
___________________________________________________________________________
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
