Re: [Wireshark-dev] Proposed changes to make tcp.ack and tcp.seq relative

2020-05-04 Thread Peter Wu
Hi Jasper, On Tue, May 05, 2020 at 01:24:33AM +0200, Jasper Bongertz wrote: > Hello Peter, > > > A request was filed earlier to add a new "tcp.ack_rel" field to ensure > > that color filters can be created that always work on the relative > > sequence numbers independent of the "Relative

Re: [Wireshark-dev] Trying to decode a TLS 1.3 with null cipher

2020-05-04 Thread Peter Wu
Hi Ahmed, On Mon, May 04, 2020 at 03:12:50PM -0700, Ahmed Elsherbiny wrote: > First of all, thank you again for creating the patch. I did test it and was > able to successfully decode some messages. > My implementation uses WolfSSL v4.3.0. > > I hope the patch will be merged in, please let me

Re: [Wireshark-dev] Proposed changes to make tcp.ack and tcp.seq relative

2020-05-04 Thread Jasper Bongertz
Hello Peter, > A request was filed earlier to add a new "tcp.ack_rel" field to ensure > that color filters can be created that always work on the relative > sequence numbers independent of the "Relative sequence numbers" option. > Instead of adding a new field, I propose to change the existing

Re: [Wireshark-dev] Trying to decode a TLS 1.3 with null cipher

2020-05-04 Thread Ahmed Elsherbiny
Hello Peter, First of all, thank you again for creating the patch. I did test it and was able to successfully decode some messages. My implementation uses WolfSSL v4.3.0. I hope the patch will be merged in, please let me know if there's any more info you need from my end. Regards, Ahmed On

[Wireshark-dev] Proposed changes to make tcp.ack and tcp.seq relative

2020-05-04 Thread Peter Wu
Hi all, A request was filed earlier to add a new "tcp.ack_rel" field to ensure that color filters can be created that always work on the relative sequence numbers independent of the "Relative sequence numbers" option. Instead of adding a new field, I propose to change the existing ones. My

Re: [Wireshark-dev] Regenerating packet-parlay.c

2020-05-04 Thread Jaap Keuter
On 5/4/20 11:16 AM, Luke Mewburn wrote: > On 20-05-04 10:55, Jaap Keuter wrote: > | Hi Luke, > | > | > Yes, I regenerated the code using that patch to > | > tools/wireshark_gen.py, and it builds fine across a couple of > | > platforms. > | > | Yes, I could build it too, so the

Re: [Wireshark-dev] Regenerating packet-parlay.c

2020-05-04 Thread Jaap Keuter
On 5/4/20 11:24 AM, Alexis La Goutte wrote: > Hi, > > I have already on the past try to rebuild parlay and remember i don't get the > same output... > but like Luke say, it will be coming from dict don't sort correctly > > Luke, can you push your ./idl-regen on CMakeList.txt ? > we can (need) to

Re: [Wireshark-dev] Regenerating packet-parlay.c

2020-05-04 Thread Alexis La Goutte
Hi, I have already on the past try to rebuild parlay and remember i don't get the same output... but like Luke say, it will be coming from dict don't sort correctly Luke, can you push your ./idl-regen on CMakeList.txt ? we can (need) to add a step on buildbot for rebuild (all)dissector and check

Re: [Wireshark-dev] Regenerating packet-parlay.c

2020-05-04 Thread Luke Mewburn
On 20-05-04 10:55, Jaap Keuter wrote: | Hi Luke, | | > Yes, I regenerated the code using that patch to | > tools/wireshark_gen.py, and it builds fine across a couple of | > platforms. | | Yes, I could build it too, so the generated code itself was okay. My | quest is to

Re: [Wireshark-dev] Regenerating packet-parlay.c

2020-05-04 Thread Jaap Keuter
On 5/3/20 10:35 AM, Luke Mewburn wrote: > On 20-05-01 13:46, Jaap Keuter wrote: > | On 5/1/20 12:02 PM, Luke Mewburn wrote: > | > On 20-05-01 07:34, Jaap Keuter wrote: > | > | > | > | > On 1 May 2020, at 04:13, Luke Mewburn > | > | > wrote: However, looking at the code some more,