[Wireshark-dev] How do I expose ECDSA-Sig-Value as a dissect function in pkcs1?

2020-05-07 Thread Richard Sharpe
Hi folks, I need a dissector for an EDCSA-Sig-Value, and it is nicely defined in epan/dissectors/asn1/pkcs1/PKIXAlgs-2009.asn as: - ECDSA-Sig-Value ::= SEQUENCE { r INTEGER, s INTEGER } - I tried the obvious by adding it as

Re: [Wireshark-dev] How do I expose ECDSA-Sig-Value as a dissect function in pkcs1?

2020-05-07 Thread Pascal Quantin
Hi Richard, Le jeu. 7 mai 2020 à 17:01, Richard Sharpe a écrit : > Hi folks, > > I need a dissector for an EDCSA-Sig-Value, and it is nicely defined in > epan/dissectors/asn1/pkcs1/PKIXAlgs-2009.asn as: > > - >ECDSA-Sig-Value ::= SEQUENCE { > r INTEGER, >

Re: [Wireshark-dev] How do I expose ECDSA-Sig-Value as a dissect function in pkcs1?

2020-05-07 Thread Richard Sharpe
On Thu, May 7, 2020 at 8:04 AM Pascal Quantin wrote: > > Hi Richard, > > Le jeu. 7 mai 2020 à 17:01, Richard Sharpe a > écrit : >> >> Hi folks, >> >> I need a dissector for an EDCSA-Sig-Value, and it is nicely defined in >> epan/dissectors/asn1/pkcs1/PKIXAlgs-2009.asn as: >> >>

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

2020-05-07 Thread Peter Wu
On Tue, May 05, 2020 at 10:42:24AM +0200, Jasper Bongertz wrote: > > On a related note, to address one of the use cases that prompted for the > > new field, I added expert info to mark connections where the server > > accepted TCP Fast Open (TFO) data. Is that useful to have? > > Yes, that's

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

2020-05-07 Thread Peter Wu
Hi Ahmed, On Tue, May 05, 2020 at 09:05:53AM -0700, Ahmed Elsherbiny wrote: > Hi Peter, > > Unfortunately I am not privy to the reasons for choosing this particular > cipher suite. If you can share them in private, I would be interested to hear about the use cases and why alternative

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

2020-05-07 Thread Peter Wu
On Tue, May 05, 2020 at 08:59:45AM -0400, Lee wrote: > On 5/4/20, Peter Wu wrote: > > 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

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

2020-05-07 Thread Jason Cohen
I think for some workflows it would be ideal to know if you are getting the relative or raw sequence numbers independent of preference. If that means there are three iterations, tcp.seq_raw, tcp.seq_rel and tcp.seq that changes based on pref... Or just two iterations. Either (tcp.seq_raw or