Wireshark mailing list archives
Re: RFC: Internally Generated "Records"
From: Roland Knall <rknall () gmail com>
Date: Tue, 18 Aug 2015 17:04:16 +0200
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 <eapache () gmail com> wrote:
On Tue, Aug 18, 2015 at 10:49 AM, Roland Knall <rknall () 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. Evanregards, Roland On Tue, Aug 5, 2014 at 12:14 AM, Roland Knall <rknall () gmail com> wrote:Yes, that it what I was saying. Cool, you can look forward to the openSAFETY patch, the minute thechangehit the official repo ;-) regards, Roland On Mon, Aug 4, 2014 at 11:51 PM, Evan Huus <eapache () gmail com> wrote:On Aug 4, 2014, at 17:21, Roland Knall <rknall () gmail com> wrote: Am 04.08.2014 um 23:16 schrieb Evan Huus <eapache () gmail com>: On Aug 4, 2014, at 17:11, Roland Knall <rknall () gmail com> wrote: On Mon, Aug 4, 2014 at 10:40 PM, Evan Huus <eapache () 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 inframe 1,and fieldB appears in frame 2, then that packet will match "fieldA && fieldB" even if they never appear "together" in the way a normalhuman wouldintend. 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 changebehaviorof the display filters in a way, the end-user may never see coming. Wewouldhave to come up with a syntax in wireshark, where we allow either"(fieldA&& fieldB)" meaning, record1.fieldA and record2.fieldB or fieldA andfieldBin the same record. The end-user does not necessarily make thatdistinction.If he simply selects frame fields, he may end up with display filterswhichdo not filter the intended or any packages, but he has no clue whysimplybecause the display filter interprets the syntax in a way the end-usercouldnot foresee. Yes, I was thinking some additional syntax like wrapping an expressionin{} or something to indicate it should only match within a singlerecord.It should be the other way around. The new syntax should emphasize the fact that it should match in different records, otherwise you aregoing tobreak compatibility with the current usability. ? Right now we match regardless of records - that should continue to bethedefault so that existing display filters don't break. We shouldintroduce anew syntax for the new feature... Or is that what you are alreadysaying?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-request () 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-request () 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-request () 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-request () 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-request () 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-request () 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-request () wireshark org?subject=unsubscribe
Current thread:
- Re: RFC: Internally Generated "Records" Roland Knall (Aug 18)
- Re: RFC: Internally Generated "Records" Evan Huus (Aug 18)
- Re: RFC: Internally Generated "Records" Roland Knall (Aug 18)
- Re: RFC: Internally Generated "Records" Michal Labedzki (Aug 18)
- Re: RFC: Internally Generated "Records" Roland Knall (Aug 18)
- Re: RFC: Internally Generated "Records" Evan Huus (Aug 18)