Re: [Wireshark-dev] Why is conflict check on the buildbot green?

> On Jul 5, 2020, at 9:09 AM, Martin Mathieson via Wireshark-dev > wrote: > > I added https://code.wireshark.org/review/#/c/37711/ for the DVB-S2-BB one. > It is a range_string, where arguably a value_string would be clearer, but the > linked-to documentation is currently unavailable. If

Re: [Wireshark-dev] Why is conflict check on the buildbot green?

I added https://code.wireshark.org/review/#/c/37711/ for the DVB-S2-BB one. It is a range_string, where arguably a value_string would be clearer, but the linked-to documentation is currently unavailable. Martin On Sun, Jul 5, 2020 at 11:41 AM Jaap Keuter wrote: > Hi, > > Okay, we should at

[Wireshark-dev] Reassemble serial protocols payloads

Hello, I am trying to implement reassembly for FTDI MPSSE protocol. The desegment API sounds like an excellent choice, because there can be more serial protocols implemented in the future that share similar characteristics to MPSSE (i.e. are designed around asynchronous character transmission).

Re: [Wireshark-dev] WLAN bug?

On Sun, Jul 5, 2020 at 5:29 AM Richard Sharpe wrote: > > On Sun, Jul 5, 2020 at 5:30 AM Jaap Keuter wrote: > > > > Hi Richard, > > > > Have you seen these entries from conflict check: > > > > ** (process:12824): WARNING **: 08:16:29.502: Field 'Status code' > > (wlan.fixed.status_code) has a

Re: [Wireshark-dev] WLAN bug?

On Sun, Jul 5, 2020 at 5:30 AM Jaap Keuter wrote: > > Hi Richard, > > Have you seen these entries from conflict check: > > ** (process:12824): WARNING **: 08:16:29.502: Field 'Status code' > (wlan.fixed.status_code) has a conflicting entry in its value_string: 125 is > at indices 125 (Requested

[Wireshark-dev] WLAN bug?

Hi Richard, Have you seen these entries from conflict check: ** (process:12824): WARNING **: 08:16:29.502: Field 'Status code' (wlan.fixed.status_code) has a conflicting entry in its value_string: 125 is at indices 125 (Requested TCLAS processing has been terminated by the AP due to conflict

[Wireshark-dev] Nordic_ble bug?

Hi Stig, Have you seen this entry from conflict check: ** (process:12824): WARNING **: 08:16:29.526: Field 'MIC' (nordic_ble.mic_not_relevant) has identical true and false strings ("Only relevant when encrypted", "Only relevant when encrypted”) Do you know how to address this? Thanks, Jaap

Re: [Wireshark-dev] Why is conflict check on the buildbot green?

Hi, Okay, we should at least try to ‘pick the low hanging fruit’ of this. I’ve started with these already: 37694 , 37692 and 37697 It would be great if at least the

Re: [Wireshark-dev] Why is conflict check on the buildbot green?

Hi Alexis, "issues are not yet fixed” sounds a bit weird for a reason for marking this stage okay (green). That would be the same as... ignoring all the compilation warnings. I’m not expecting it to be marked as error (red), but as warning (orange), calling attention to it. Because I wonder

[Wireshark-dev] Anyone with access to ANSI C12.22

Hi, In light of this change https://code.wireshark.org/review/37697, can anyone with access to ANSI C12.22 confirm that the changes in the ASN.1 is correct? Thanks, Jaap ___ Sent via:Wireshark-dev mailing list

Re: [Wireshark-dev] Why is conflict check on the buildbot green?

Hi Jaap, It is beacuse all issue are not yet fixed (some coming from generated code... or missing spec info to known what the correct fix). Personally, when review code after Petri dish, I try to look different output log, because I know don’t fail it is juste warning. Le dim. 5 juil. 2020 à

[Wireshark-dev] Why is conflict check on the buildbot green?

Hi, Due to some recent issues with DHCPv6 the buildbot began flagging the 'conflict check' stage as failed. This drew my attention to the fact that there is a long list of warnings in there about wrong use of protocol fields, but once the DHCPv6 issues were fixed the build happily went back to