On Thu, Mar 1, 2018 at 11:24 AM, Alexis La Goutte
wrote:
>
>>
>> Hi folks,
>>
>> Seeing this. Maybe need some _U_ on those parameters? Looks like the
>> ifdef is causing it because I don't have the latest libraries.
>>
>> packet-quic.c: In function 'dissect_quic_initial':
>> packet-quic.c:801:131:
On Thu, Mar 1, 2018 at 5:27 PM, Richard Sharpe
wrote:
> Hi folks,
>
> Seeing this. Maybe need some _U_ on those parameters? Looks like the
> ifdef is causing it because I don't have the latest libraries.
>
> packet-quic.c: In function 'dissect_quic_initial':
> packet-quic.c:801:131: error: unused
Hi folks,
Seeing this. Maybe need some _U_ on those parameters? Looks like the
ifdef is causing it because I don't have the latest libraries.
packet-quic.c: In function 'dissect_quic_initial':
packet-quic.c:801:131: error: unused parameter 'pkn' [-Werror=unused-parameter]
dissect_quic_initial(tv
On 1 March 2018 at 14:36, Anders Broman wrote:
> Ho,
>
> I don’t have asciidoctor installed, NSIS build fails with:
>
>
>
> Processing config: C:\Program Files (x86)\NSIS\nsisconf.nsh
>
> Processing script file: "wireshark.nsi" (ACP)
>
> File: "C:\Development\wsbuild64\doc
Ho,
I don't have asciidoctor installed, NSIS build fails with:
Processing config: C:\Program Files (x86)\NSIS\nsisconf.nsh
Processing script file: "wireshark.nsi" (ACP)
File: "C:\Development\wsbuild64\docbook\user-guide.chm" -> no files fo
und.
Usage: File [
I didn’t realise that the support effort is greater. I was thinking, coding
all dissectors, including new and existing block types, as plugins seems like a
good strategic direction. Surely beefing up the plugin framework would make
Wireshark more extensible.
Anyway, I’ll re-code as built-in
OK – I’ll take a look.
Best regards…Paul
From: Wireshark-dev [mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of
Pascal Quantin
Sent: 01 March 2018 10:24
To: Developer support list for Wireshark
Subject: Re: [Wireshark-dev] Dissector - plugin or built-in
Hi Paul,
Le 1 mars 2018 10:47, "
On 1 March 2018 at 10:27, Roland Knall wrote:
>
>
> On Thu, Mar 1, 2018 at 11:22 AM, Graham Bloice <
> graham.blo...@trihedral.com> wrote:
>
>>
>>
>> On 1 March 2018 at 10:18, Roland Knall wrote:
>>
>>> We do not have any other dissector within the code, which dissects
>>> blocktypes. Therefore
On Thu, Mar 1, 2018 at 11:22 AM, Graham Bloice
wrote:
>
>
> On 1 March 2018 at 10:18, Roland Knall wrote:
>
>> We do not have any other dissector within the code, which dissects
>> blocktypes. Therefore I would not be so sure, that it will get rejected (in
>> my book it definitely should not).
>
Hi Paul,
Le 1 mars 2018 10:47, "Paul Offord" a écrit :
Hi Pascal,
Thanks for your note regarding my change 26203 - https://code.wireshark.org/
review/#/c/26203/ . You suggested that I submit it as a built-in
dissector, not a plugin. I’m not keen for two reasons:
- If it is rejected (a
On 1 March 2018 at 10:18, Roland Knall wrote:
> We do not have any other dissector within the code, which dissects
> blocktypes. Therefore I would not be so sure, that it will get rejected (in
> my book it definitely should not).
>
> But it most likely will get rejected as a plugin.
>
> Main reas
We do not have any other dissector within the code, which dissects
blocktypes. Therefore I would not be so sure, that it will get rejected (in
my book it definitely should not).
But it most likely will get rejected as a plugin.
Main reasons for built-in:
- Easier to maintain
- Best-practice appr
Hi Pascal,
Thanks for your note regarding my change 26203 -
https://code.wireshark.org/review/#/c/26203/ . You suggested that I submit it
as a built-in dissector, not a plugin. I'm not keen for two reasons:
* If it is rejected (and I have a feeling it will be), I'll then have to
rewrite
13 matches
Mail list logo
