Re: [Wireshark-dev] please close issue 12805

[Evan Huus]

Done, thanks for pointing it out!

On Wed, Oct 13, 2021 at 3:53 PM Eugène Adell  wrote:

> Hello,
>
> anyone with sufficient rights please close :
>
> https://gitlab.com/wireshark/wireshark/-/issues/12805
>
> I didn't pay attention but it's in fact the very same than 16919 that
> was solved some time ago (cause : SRC < DST leading to a wrong
> identification of the conversation initiator).
>
> best regards
> E.A.
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org
> ?subject=unsubscribe
>
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] 3.6.0 release schedule

[Evan Huus]

On Wed., Oct. 6, 2021, 14:43 Jaap Keuter,  wrote:

> Hi,
>
> Are those wmem / pinfo->pool changes completed? Would be nice if that was
> consistent before branching.


I have three things left on my list:
- a few last changes in to_str macros - small and easy
- figure out what to do with valuestrings - hard and undefined
- convert remaining dissectors - trivial but large

The last two aren't worth waiting for as they will both require some
investment. The first one I'll try to get to soon, but should be
self-explanatory based on my recent merges if somebody else wants to grab
it today.

Evan

Is dfilter stabilised already? These are the things that come to mind.
>
> Thanks,
> Jaap
>
> > On 30 Sep 2021, at 23:29, Gerald Combs  wrote:
> >
> > Hi all,
> >
> > I have the 3.5.1 release scheduled for next Thursday, October 7, but I'm
> wondering if we shouldn't create the 3.6 branch and release 3.6.0rc1
> instead. Unless anyone needs to delay the 3.6 branch I plan on doing the
> following:
> >
> > Oct  6 : Release 3.4.9 & 3.2.17
> > Oct  7 : Create the release-3.6 branch
> > Oct  8 : Release 3.6.0rc1
> > Oct 20 : Release 3.6.0 and wind down the 3.2 branch
> > Nov 17 : Release 3.6.1 & 3.4.10
>
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org
> ?subject=unsubscribe
>
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

[Wireshark-dev] SCTP Reassembly Question

[Evan Huus]

I've been poking at the bug in
https://gitlab.com/wireshark/wireshark/-/issues/15584 but I've hit the
limit of what I can glean from the SCTP RFC on reassembly. If anybody
is familiar with the protocol and could provide some guidance as to
the correct behaviour when given nested begin/end data fragments, that
would be helpful.

Thanks,
Evan
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Replacing wmem_packet_scope() with pinfo->pool?

[Evan Huus]

FYI this migration has now begun. Going forward, please use pinfo->pool
instead of wmem_packet_scope() in new code when possible. And if anybody
has some time, there are lots of existing dissectors left to convert. I
expect most of them to be pretty straightforward, just adding pinfo to a
few more method signatures as needed.

Thanks,
Evan

On Mon, Jul 12, 2021 at 11:52 Evan Huus  wrote:

> I've been thinking recently about starting the process of getting rid
> of the "global" wmem scope methods (wmem_packet_scope,
> wmem_file_scope, etc) in favour of passing them around in arguments
> (or in pinfo, or something). This would let us drop a bunch of
> in-scope/out-of-scope tracking and assertion, as well as make the code
> more amenable to future refactors like (potentially) concurrency.
>
> At a first glance, we already have pinfo->pool which maintains the
> lifetime of the packet_info object. As far as I can reason, this is
> almost/effectively the same as the existing wmem_packet_scope - it
> gets cleaned up later in the dissection flow, but there's still only
> ever one which gets reused for each packet.
>
> Is this correct? If so, does it make sense to start replacing
> `wmem_packet_scope()` calls with `pinfo->pool` when pinfo is already
> in scope?
>
> Thanks,
> Evan
>
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Replacing wmem_packet_scope() with pinfo->pool?

[Evan Huus]

On Mon, Jul 12, 2021 at 14:42 João Valverde via Wireshark-dev <
wireshark-dev@wireshark.org> wrote:

>
>
> On 12/07/21 19:13, Evan Huus wrote:
> > On Mon, Jul 12, 2021 at 2:05 PM João Valverde via Wireshark-dev
> >  wrote:
> >>
> >>
> >>
> >> On 12/07/21 16:52, Evan Huus wrote:
> >>> I've been thinking recently about starting the process of getting rid
> >>> of the "global" wmem scope methods (wmem_packet_scope,
> >>> wmem_file_scope, etc) in favour of passing them around in arguments
> >>> (or in pinfo, or something). This would let us drop a bunch of
> >>> in-scope/out-of-scope tracking and assertion, as well as make the code
> >>> more amenable to future refactors like (potentially) concurrency.
> >>>
> >>> At a first glance, we already have pinfo->pool which maintains the
> >>> lifetime of the packet_info object. As far as I can reason, this is
> >>> almost/effectively the same as the existing wmem_packet_scope - it
> >>> gets cleaned up later in the dissection flow, but there's still only
> >>> ever one which gets reused for each packet.
> >>>
> >>> Is this correct? If so, does it make sense to start replacing
> >>> `wmem_packet_scope()` calls with `pinfo->pool` when pinfo is already
> >>> in scope?
> >>
> >> I think wmem_packet_scope() should return pinfo->pool.
> >
> > It would have to be converted to a macro (or do a mass-replace anyway
> > to take pinfo as an argument), so I figure using `pinfo->pool`
> > directly in most cases ends up being simplest.
>
> I really don't see it being simplest.


Why?

The motivation for this change is primarily to get rid of the global
methods so that scope management becomes easier, and so that we could e.g.
have two packet scopes active at once in a future where we do parallel
dissection.

Having wmem_packet_scope return pinfo->pool doesn’t really accomplish
either of those goals.

Please reconsider.
>
> Either wmem_packet_scope() is created earlier and pinfo->pool =
> wmem_packet_scope() or wmem_enter_packet_scope() is passed pinfo->pool
> and packet_scope = pinfo->pool.
>
> Either way works fine AFAICT.
>
> >> Other than that, I don't see a compelling reason to remove the global
> >> wmem scope methods.
> >>
> >>> Thanks,
> >>> Evan
> >>>
> ___
> >>> Sent via:Wireshark-dev mailing list 
> >>> Archives:https://www.wireshark.org/lists/wireshark-dev
> >>> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
> >>>mailto:wireshark-dev-requ...@wireshark.org
> ?subject=unsubscribe
> >>>
> >>
> ___
> >> Sent via:Wireshark-dev mailing list 
> >> Archives:https://www.wireshark.org/lists/wireshark-dev
> >> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
> >>   mailto:wireshark-dev-requ...@wireshark.org
> ?subject=unsubscribe
> >
> ___
> > Sent via:Wireshark-dev mailing list 
> > Archives:https://www.wireshark.org/lists/wireshark-dev
> > Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
> >   mailto:wireshark-dev-requ...@wireshark.org
> ?subject=unsubscribe
> >
>
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org
> ?subject=unsubscribe
>
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Replacing wmem_packet_scope() with pinfo->pool?

[Evan Huus]

On Mon, Jul 12, 2021 at 2:05 PM João Valverde via Wireshark-dev
 wrote:
>
>
>
> On 12/07/21 16:52, Evan Huus wrote:
> > I've been thinking recently about starting the process of getting rid
> > of the "global" wmem scope methods (wmem_packet_scope,
> > wmem_file_scope, etc) in favour of passing them around in arguments
> > (or in pinfo, or something). This would let us drop a bunch of
> > in-scope/out-of-scope tracking and assertion, as well as make the code
> > more amenable to future refactors like (potentially) concurrency.
> >
> > At a first glance, we already have pinfo->pool which maintains the
> > lifetime of the packet_info object. As far as I can reason, this is
> > almost/effectively the same as the existing wmem_packet_scope - it
> > gets cleaned up later in the dissection flow, but there's still only
> > ever one which gets reused for each packet.
> >
> > Is this correct? If so, does it make sense to start replacing
> > `wmem_packet_scope()` calls with `pinfo->pool` when pinfo is already
> > in scope?
>
> I think wmem_packet_scope() should return pinfo->pool.

It would have to be converted to a macro (or do a mass-replace anyway
to take pinfo as an argument), so I figure using `pinfo->pool`
directly in most cases ends up being simplest.

> Other than that, I don't see a compelling reason to remove the global
> wmem scope methods.
>
> > Thanks,
> > Evan
> > ___
> > Sent via:Wireshark-dev mailing list 
> > Archives:https://www.wireshark.org/lists/wireshark-dev
> > Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
> >   mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
> >
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

[Wireshark-dev] Replacing wmem_packet_scope() with pinfo->pool?

[Evan Huus]

I've been thinking recently about starting the process of getting rid
of the "global" wmem scope methods (wmem_packet_scope,
wmem_file_scope, etc) in favour of passing them around in arguments
(or in pinfo, or something). This would let us drop a bunch of
in-scope/out-of-scope tracking and assertion, as well as make the code
more amenable to future refactors like (potentially) concurrency.

At a first glance, we already have pinfo->pool which maintains the
lifetime of the packet_info object. As far as I can reason, this is
almost/effectively the same as the existing wmem_packet_scope - it
gets cleaned up later in the dissection flow, but there's still only
ever one which gets reused for each packet.

Is this correct? If so, does it make sense to start replacing
`wmem_packet_scope()` calls with `pinfo->pool` when pinfo is already
in scope?

Thanks,
Evan
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] RTP-MIDI strange field masks?

[Evan Huus]

I haven’t actually looked at the code, so it’s possible we’re doing the
masking but not actually combining the bits into a single 14-bit value
properly still. I wouldn’t expect a simple mask value to accomplish that.

Evan

On Thu, Jul 8, 2021 at 14:32 Evan Huus  wrote:

> Based on the 0xxx of your example and references like [1], I believe
> the masks are correct. MIDI seems to mostly use seven bit bytes schmucked
> together for some reason, so ignoring the high bit of each byte seems
> correct to me.
>
> Evan
>
> [1] http://midi.teragonaudio.com/tech/midispec/wheel.htm
>
> On Thu, Jul 8, 2021 at 13:58 Martin Mathieson via Wireshark-dev <
> wireshark-dev@wireshark.org> wrote:
>
>> These mask fields (0x7f7f, 0x7f7f7f7f, etc) look wrong to me, but I am
>> worried I might be missing something?
>> Looking at an example in RFC 4695 (Song Position Pointer) I think this
>> (on page 157) is saying that is it just a 2-byte field (and should
>> therefore have a non-mask of 0x0)?
>>
>> | Song Position Pointer  | 0010 0xxx 0yyy |
>>
>>
>> These warnings are from ./tools/check_typed_item_calls.py --mask
>>
>>
>> Warning:  epan/dissectors/packet-rtp-midi.c filter= rtpmidi.deltatime_2
>>  - mask with non-contiguous bits 0x7f7f
>> Warning:  epan/dissectors/packet-rtp-midi.c filter= rtpmidi.deltatime_3
>>  - mask with non-contiguous bits 0x7f7f7f
>> Warning:  epan/dissectors/packet-rtp-midi.c filter= rtpmidi.deltatime_4
>>  - mask with non-contiguous bits 0x7f7f7f7f
>> Warning:  epan/dissectors/packet-rtp-midi.c filter= rtpmidi.pitch_bend  -
>> mask with non-contiguous bits 0x7f7f
>> Warning:  epan/dissectors/packet-rtp-midi.c filter=
>> rtpmidi.sj_chapter_x_first_2  - mask with non-contiguous bits 0x7f7f
>> Warning:  epan/dissectors/packet-rtp-midi.c filter=
>> rtpmidi.sj_chapter_x_first_3  - mask with non-contiguous bits 0x7f7f7f
>> Warning:  epan/dissectors/packet-rtp-midi.c filter=
>> rtpmidi.sj_chapter_x_first_4  - mask with non-contiguous bits 0x7f7f7f7f
>> Warning:  epan/dissectors/packet-rtp-midi.c filter=
>> rtpmidi.song_position_pointer  - mask with non-contiguous bits 0x7f7f
>> Warning:  epan/dissectors/packet-rtp-midi.c filter=
>> rtpmidi.sysex_common_non_realtime_general_information_device_family  - mask
>> with non-contiguous bits 0x7f7f
>> Warning:  epan/dissectors/packet-rtp-midi.c filter=
>> rtpmidi.sysex_common_non_realtime_general_information_device_family_member
>>  - mask with non-contiguous bits 0x7f7f
>> Warning:  epan/dissectors/packet-rtp-midi.c filter=
>> rtpmidi.sysex_common_non_realtime_general_information_software_revision  -
>> mask with non-contiguous bits 0x7f7f7f7f
>> Warning:  epan/dissectors/packet-rtp-midi.c filter=
>> rtpmidi.sysex_common_non_realtime_sample_dump_sample_number  - mask with
>> non-contiguous bits 0x7f7f
>> Warning:  epan/dissectors/packet-rtp-midi.c filter=
>> rtpmidi.sysex_common_non_realtime_sample_dump_sample_period  - mask with
>> non-contiguous bits 0x7f7f7f
>> Warning:  epan/dissectors/packet-rtp-midi.c filter=
>> rtpmidi.sysex_common_non_realtime_sample_dump_sample_length  - mask with
>> non-contiguous bits 0x7f7f7f
>> Warning:  epan/dissectors/packet-rtp-midi.c filter=
>> rtpmidi.sysex_common_non_realtime_sample_dump_loop_start  - mask with
>> non-contiguous bits 0x7f7f7f
>> Warning:  epan/dissectors/packet-rtp-midi.c filter=
>> rtpmidi.sysex_common_non_realtime_sample_dump_loop_end  - mask with
>> non-contiguous bits 0x7f7f7f
>> Warning:  epan/dissectors/packet-rtp-midi.c filter=
>> rtpmidi.sysex_common_non_realtime_sample_dump_lp_trans_ln  - mask with
>> non-contiguous bits 0x7f7f
>> Warning:  epan/dissectors/packet-rtp-midi.c filter=
>> rtpmidi.sysex_common_non_realtime_fd_length  - mask with non-contiguous
>> bits 0x7f7f7f7f
>> Warning:  epan/dissectors/packet-rtp-midi.c filter=
>> rtpmidi.sysex_common_tune_freq  - mask with non-contiguous bits 0x7f7f7f
>> Warning:  epan/dissectors/packet-rtp-midi.c filter=
>> rtpmidi.sysex_common_rt_ni_barnum  - mask with non-contiguous bits 0x7f7f
>> Warning:  epan/dissectors/packet-rtp-midi.c filter=
>> rtpmidi.sysex_common_rt_dc_volume  - mask with non-contiguous bits 0x7f7f
>> Warning:  epan/dissectors/packet-rtp-midi.c filter=
>> rtpmidi.sysex_common_rt_dc_balance  - mask with non-contiguous bits 0x7f7f
>>
>> ___
>> Sent via:Wireshark-dev mailing list 
>> Archives:https://www.wireshark.org/lists/wireshark-dev
>> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>>  mailto:wireshark-dev-requ...@wireshark.org
>> ?subject=unsubscribe
>>
>
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] RTP-MIDI strange field masks?

[Evan Huus]

Based on the 0xxx of your example and references like [1], I believe
the masks are correct. MIDI seems to mostly use seven bit bytes schmucked
together for some reason, so ignoring the high bit of each byte seems
correct to me.

Evan

[1] http://midi.teragonaudio.com/tech/midispec/wheel.htm

On Thu, Jul 8, 2021 at 13:58 Martin Mathieson via Wireshark-dev <
wireshark-dev@wireshark.org> wrote:

> These mask fields (0x7f7f, 0x7f7f7f7f, etc) look wrong to me, but I am
> worried I might be missing something?
> Looking at an example in RFC 4695 (Song Position Pointer) I think this (on
> page 157) is saying that is it just a 2-byte field (and should therefore
> have a non-mask of 0x0)?
>
> | Song Position Pointer  | 0010 0xxx 0yyy |
>
>
> These warnings are from ./tools/check_typed_item_calls.py --mask
>
>
> Warning:  epan/dissectors/packet-rtp-midi.c filter= rtpmidi.deltatime_2  -
> mask with non-contiguous bits 0x7f7f
> Warning:  epan/dissectors/packet-rtp-midi.c filter= rtpmidi.deltatime_3  -
> mask with non-contiguous bits 0x7f7f7f
> Warning:  epan/dissectors/packet-rtp-midi.c filter= rtpmidi.deltatime_4  -
> mask with non-contiguous bits 0x7f7f7f7f
> Warning:  epan/dissectors/packet-rtp-midi.c filter= rtpmidi.pitch_bend  -
> mask with non-contiguous bits 0x7f7f
> Warning:  epan/dissectors/packet-rtp-midi.c filter=
> rtpmidi.sj_chapter_x_first_2  - mask with non-contiguous bits 0x7f7f
> Warning:  epan/dissectors/packet-rtp-midi.c filter=
> rtpmidi.sj_chapter_x_first_3  - mask with non-contiguous bits 0x7f7f7f
> Warning:  epan/dissectors/packet-rtp-midi.c filter=
> rtpmidi.sj_chapter_x_first_4  - mask with non-contiguous bits 0x7f7f7f7f
> Warning:  epan/dissectors/packet-rtp-midi.c filter=
> rtpmidi.song_position_pointer  - mask with non-contiguous bits 0x7f7f
> Warning:  epan/dissectors/packet-rtp-midi.c filter=
> rtpmidi.sysex_common_non_realtime_general_information_device_family  - mask
> with non-contiguous bits 0x7f7f
> Warning:  epan/dissectors/packet-rtp-midi.c filter=
> rtpmidi.sysex_common_non_realtime_general_information_device_family_member
>  - mask with non-contiguous bits 0x7f7f
> Warning:  epan/dissectors/packet-rtp-midi.c filter=
> rtpmidi.sysex_common_non_realtime_general_information_software_revision  -
> mask with non-contiguous bits 0x7f7f7f7f
> Warning:  epan/dissectors/packet-rtp-midi.c filter=
> rtpmidi.sysex_common_non_realtime_sample_dump_sample_number  - mask with
> non-contiguous bits 0x7f7f
> Warning:  epan/dissectors/packet-rtp-midi.c filter=
> rtpmidi.sysex_common_non_realtime_sample_dump_sample_period  - mask with
> non-contiguous bits 0x7f7f7f
> Warning:  epan/dissectors/packet-rtp-midi.c filter=
> rtpmidi.sysex_common_non_realtime_sample_dump_sample_length  - mask with
> non-contiguous bits 0x7f7f7f
> Warning:  epan/dissectors/packet-rtp-midi.c filter=
> rtpmidi.sysex_common_non_realtime_sample_dump_loop_start  - mask with
> non-contiguous bits 0x7f7f7f
> Warning:  epan/dissectors/packet-rtp-midi.c filter=
> rtpmidi.sysex_common_non_realtime_sample_dump_loop_end  - mask with
> non-contiguous bits 0x7f7f7f
> Warning:  epan/dissectors/packet-rtp-midi.c filter=
> rtpmidi.sysex_common_non_realtime_sample_dump_lp_trans_ln  - mask with
> non-contiguous bits 0x7f7f
> Warning:  epan/dissectors/packet-rtp-midi.c filter=
> rtpmidi.sysex_common_non_realtime_fd_length  - mask with non-contiguous
> bits 0x7f7f7f7f
> Warning:  epan/dissectors/packet-rtp-midi.c filter=
> rtpmidi.sysex_common_tune_freq  - mask with non-contiguous bits 0x7f7f7f
> Warning:  epan/dissectors/packet-rtp-midi.c filter=
> rtpmidi.sysex_common_rt_ni_barnum  - mask with non-contiguous bits 0x7f7f
> Warning:  epan/dissectors/packet-rtp-midi.c filter=
> rtpmidi.sysex_common_rt_dc_volume  - mask with non-contiguous bits 0x7f7f
> Warning:  epan/dissectors/packet-rtp-midi.c filter=
> rtpmidi.sysex_common_rt_dc_balance  - mask with non-contiguous bits 0x7f7f
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org
> ?subject=unsubscribe
>
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] allocator->in_scope

[Evan Huus]

Hi Paul, that’s an interesting case you’ve found. The file scope was
definitely intended for file-scoped dissection memory (which is why it is
enabled in init_dissection() and not earlier in the file lifecycle) but I
can definitely see the use for it in writing a block reader too.

I think it is probably worth figuring out where it ends up being called in
the case that crashes (since it must get called at some point just too
late), find the common ancestor, and move the enter_file_scope call there.
As long as each enter call always still has a single matching exit it
should be fine to enter file scope a bit sooner.

Alternatively you could create a new scope object explicitly attached to
the file struct and make that the eventual long-term file scope, since I
still have a pipe dream of getting rid of the scope globals entirely in
order to let Wireshark handle multiple files at once.

Evan

On Sun, Mar 25, 2018 at 12:20 Paul Offord  wrote:

> Aha – whilst what I’ve written below is true, it doesn’t accurately
> reflect the issue.
>
>
>
> If I start Wireshark and double click on a file in the recently opened
> list, part of the processing is this:
>
>
>
>   cf_open() calls
>
> ws_epan_new() calls
>
>   epan_new() calls
>
> init_dissection() calls
>
>   wmem_enter_file_scope() which sets
>
> file_scope->in_scope = TRUE;
>
>
>
> All of the above takes place before my new block reader is called.
>
>
>
> If I start Wireshark, use Ctl-O and then double click on a file in the
> file explorer dialogue, there is no call to wmem_enter_file_scope() before
> my block reader is called.
>
>
>
> I believe this is a bug.  The two file opens should be consistent in the
> setting of file_scope->in_scope = TRUE, and hence the scope of
> wmem_file_scope().
>
>
>
>- Am I wrong?
>- Have I missed something?
>- Should I create a bug report?
>
>
>
> Thanks and regards…Paul
>
>
>
> *From:* Paul Offord
> *Sent:* 25 March 2018 10:31
> *To:* Developer support list for Wireshark 
> *Subject:* allocator->in_scope
>
>
>
> Hi,
>
>
>
> Still working on my new block reader.  To recap, I’ve defined a new pcapng
> block type and written a dissector.  The first thing I have to do is read
> the new block type, and Wireshark provides a framework to do this.  In the
> new block reader I define some space like this:
>
>
>
> tdb_namespace = wmem_strdup_printf(wmem_file_scope(), "%s",
> option_block->option_data);
>
>
>
> Eventually the wmem_strdup_printf(…) execution calls this function:
>
>
>
> void *
>
> wmem_alloc(wmem_allocator_t *allocator, const size_t size)
>
> {
>
> if (allocator == NULL) {
>
> return g_malloc(size);
>
> }
>
>
>
> if (!allocator->in_scope) // debug code
>
> while (FALSE); // debug code
>
>
>
> g_assert(allocator->in_scope);
>
>
>
> if (size == 0) {
>
> return NULL;
>
> }
>
>
>
> return allocator->walloc(allocator->private_data, size);
>
> }
>
>
>
> The g_assert intermittently fails.  If I open one file containing the new
> block, allocator->in_scope is true.  If I call another it’s false.
>
>
>
> The block read is called before we start dissecting the contents with the
> dissector code.
>
>
>
>- At what point is wmem_file_scope in scope?
>- Should it be when my block reader is called or is it only guaranteed
>when the dissector code is called?
>
>
>
> Thanks and regards…Paul
>
>
>
> __
>
> This message contains confidential information and is intended only for
> the individual named. If you are not the named addressee you should not
> disseminate, distribute or copy this e-mail. Please notify the sender
> immediately by e-mail if you have received this e-mail by mistake and
> delete this e-mail from your system.
>
> Any views or opinions expressed are solely those of the author and do not
> necessarily represent those of Advance Seven Ltd. E-mail transmission
> cannot be guaranteed to be secure or error-free as information could be
> intercepted, corrupted, lost, destroyed, arrive late or incomplete, or
> contain viruses. The sender therefore does not accept liability for any
> errors or omissions in the contents of this message, which arise as a
> result of e-mail transmission.
>
> Advance Seven Ltd. Registered in England & Wales numbered 2373877 at
> Endeavour House, Coopers End Lane, Stansted, Essex CM24 1SJ
>
> __
> This email has been scanned by the Symantec Email Security.cloud service.
> For more information please visit http://www.symanteccloud.com
> __
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wiresha

Re: [Wireshark-dev] XXXX: avoid appending xxxx multiple times to frame.protocols field

[Evan Huus]

It sounds to me like it shouldn’t be a set or a list, but a tree?

Evan

On Fri, Oct 6, 2017 at 08:17 Michael Mann via Wireshark-dev <
wireshark-dev@wireshark.org> wrote:

> There's also this explanation:
> https://www.wireshark.org/lists/wireshark-dev/201701/msg5.html
>
>
> -Original Message-
> From: Pascal Quantin 
> To: Developer support list for Wireshark 
> Sent: Fri, Oct 6, 2017 3:06 am
> Subject: Re: [Wireshark-dev] : avoid appending  multiple times to
> frame.protocols field
>
> Hi Roland,
>
> 2017-10-06 8:23 GMT+02:00 Roland Knall :
>
> Personally I think moving to a set would reduce functionality for some
> applications. Industrial ethernet applications for instance heavily rely on
> multiple protocols being transported in single frames multiple times (one
> UDP packet contains a lot of openSAFETY frames, which themselve could
> contain data dissectors).
>
> So -1 for me for moving to a set.
>
>  @Pascal - could you point me in the direction of Michael's change you
> mentioned (pino stuff)?
>
>
> Here it is: https://code.wireshark.org/review/19464
>
>
> On Fri, Oct 6, 2017 at 7:01 AM, Pascal Quantin 
> wrote:
>
> Hi Guy,
>
> Le 5 oct. 2017 23:20, "Guy Harris"  a écrit :
>
> A given frame's dissection can have multiple packets for a given protocol,
> if, at any protocol layer, a PDU can contain multiple PDUs for the next
> layer above it (or parts of multiple PDUs, as with byte-stream protocols
> such as TCP).
>
> Some recent changes have been submitted to fix that for particular
> protocols.
>
> However, the underlying problem is that frame.protocols is intended to be
> a set (in which a given item can occur only once) rather than a bag (in
> which a given item can occur multiple times).  Perhaps it should be
> implemented as a set, with uniqueness enforced, so that individual
> dissectors don't need to keep from putting another  in the bag if
> there's already one there?
>
>
> What I like also with frame.protocols field is that it shows the protocol
> encapsulation order within the packet. So in case of an IP packet
> encapsulated inside a protocol running in top of IP, I think it makes sense
> to display up twice. Changing it to a set would lose this property.
>
> The problem with S1AP and Co is that it uses some dissector tables
> internally to decode the fields, leading to fake multiple occurrences
> within frame.protocols field. By the way, I realize that the pino
> functionality introduced by Michael might have been used here also instead
> of the simple patch I did. It might be an opportunity for me to see how
> this pino stuff behaves exactly ;)
>
> Cheers,
> Pascal.
>
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org
> ?subject=unsubscribe
>
>
>
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org
> ?subject=unsubscribe
>
>
> ___
> Sent via: Wireshark-dev mailing list 
> Archives: https://www.wireshark.org/lists/wireshark-dev Unsubscribe:
> https://www.wireshark.org/mailman/options/wireshark-dev
> mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
> 
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org
> ?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Crash in epan/geoip_db.c

[Evan Huus]

On Wed, Feb 22, 2017 at 09:50 Dario Lombardo 
wrote:

> On Tue, Feb 21, 2017 at 11:38 PM, João Valverde <
> joao.valve...@tecnico.ulisboa.pt> wrote:
>
>
> Fixes 850393b57bdd7011780f4cf897d4a2467f58a673. Please push to Gerrit.
> Bonus points for fixing the cast too.
>
>
> I pushed a patch that replaces g_free with free. Now the problem is that
> checkAPI doesn't allow free! No way to make petri-dish pass. We can:
>

checkAPI doesn't allow free because it also doesn't allow malloc; if the
malloced memory is coming from library internals somewhere, does the
library itself have a cleanup method we could call instead?


> - merge without PD
> - patch checkAPI to allow some forbidden calls in some files
>
> Is it worth the latter or we should be fine with the former?
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org
> ?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Checking address in WMEM

[Evan Huus]

On Thu, Jan 26, 2017 at 8:48 AM, Dario Lombardo
 wrote:
> On Thu, Jan 26, 2017 at 2:11 PM, Evan Huus  wrote:
>> - your code will fail any time wmem chooses a different allocator
>> (this happens in CI, and occasionally elsewhere as well)
>>
>
> I don't get this. Can you explain it a little bit?

wmem ships with four different allocator algorithms (see
wmem_allocator_type in wmem_core.h) of which the block allocator you
are looking at is only one. When a wmem scope is initialized the
backing algorithm can be overridden by an environment variable (see
wmem_init() and wmem_allocator_new() in wmem_core.c). This is mostly
useful on the build machines to turn on additional safety checks (the
strict allocator) or to be friendly to memory analyzers like valgrind
(the simple allocator). However, anyone can use it.

If the allocator is overridden then your cast
`(wmem_block_allocator_t*)allocator->private_data` will be invalid and
the remainder of the function will probably blow up somewhere.

> Yes. Basically I'd like the idea to give the user a very useful error 
> message. The wmem is pretty hard to debug, since a wrong scope basically 
> means a segment violation, a double free, or so. But that can happen very far 
> from where the error is.

You should actually be able to use the wmem scope override for this.
Force the allocator to be strict (run with
WIRESHARK_DEBUG_WMEM_OVERRIDE=strict) and it should fail immediately
at the point of the bug.
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Checking address in WMEM

[Evan Huus]

On Thu, Jan 26, 2017 at 4:06 AM, Dario Lombardo
 wrote:
>
>
> On Wed, Jan 25, 2017 at 6:50 PM, Evan Huus  wrote:
>>
>> On my phone, but the short version is that there's no way to check this,
>> and no efficient way to build it.
>>
>> Evan
>>
>
> Looking into the code it seems to me that the routine of free_all should
> traverse all the allocated memory. I've written a code that mimics it, but
> I'm still failing to have all the addresses for some type conversions.
> That's the code I'm working on
>
> // Check if 'address' belongs to the given scope.
> gboolean
> wmem_check_allocator_block(wmem_allocator_t* allocator, void* address)
> {
> wmem_block_allocator_t *private_allocator =
> (wmem_block_allocator_t*)allocator->private_data;
> wmem_block_hdr_t   *cur;
> wmem_block_chunk_t *chunk;
> void* a = WMEM_DATA_TO_CHUNK(address);
>
> cur = private_allocator->block_list;
>
> while (cur) {
> chunk = WMEM_BLOCK_TO_CHUNK(cur);
> if (a == chunk)
> return TRUE;
> cur = cur->next;
> }
> return FALSE;
> }
>
> If I allocate a block and the allocator gives me 7c40 as address, the
> function checks only 7c30. It looks like I'm casting/converting the
> addresses the wrong way.
> Any idea? Does this approach sound good, or am I completely following the
> wrong path?

Each block can consist of multiple chunks, so you need a second, inner
loop. You can do this with WMEM_CHUNK_NEXT.

Do note, however, that:
- you'll be iterating over every piece of memory allocated in this
scope, which will probably be quite expensive
- your code will fail any time wmem chooses a different allocator
(this happens in CI, and occasionally elsewhere as well)

What problem specifically are you trying to solve? There may be an easier way.

Evan
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Checking address in WMEM

[Evan Huus]

On my phone, but the short version is that there's no way to check this,
and no efficient way to build it.

Evan

On Jan 25, 2017 8:17 AM, "Dario Lombardo" 
wrote:

I want to check if an address belongs to a wmem scope. Basically I want to
do

func(allocator, address)
{
  ...
  wmem_realloc(allocator, address)
  ...
}

that fails if address doesn't belong to allocator scope. Any idea on how
can I check if address belongs to it?
Thanks.
Dario.

___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Linking on OSX Sierra

[Evan Huus]

On Wed, Oct 12, 2016 at 3:04 PM, Guy Harris  wrote:
> On Oct 12, 2016, at 11:41 AM, Jeff Morriss  wrote:
>
>> Just for fun I did a quick search for that Usage output (minus the 
>> "Wireshark" prefix which is clearly $0) and found this program which has 
>> that exact output:
>>
>> https://github.com/the-tcpdump-group/libpcap/blob/master/tests/capturetest.c
>
> Yeah, that's one of a pile of test programs I wrote to test various libpcap 
> features.
>
> The binary is *not* part of a libpcap installation, so there shouldn't be an 
> executable for it unless the test programs were built.
>
> Evan, what happens if you remove the build directory entirely, re-create it, 
> do a cmake in it, and then redo the build?

Completely blowing away the build directory and starting again seems
to have fixed it. That was really weird, especially since (to my
knowledge) I don't even have a source build of libpcap on this
machine.

Anywho, thanks everyone for the help!
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Linking on OSX Sierra

[Evan Huus]

On Fri, Oct 7, 2016 at 7:14 PM, Guy Harris  wrote:
> On Oct 7, 2016, at 4:03 PM, Gerald Combs  wrote:
>
>> On 10/7/16 7:45 AM, Evan Huus wrote:
>>> Hey all, recently upgrade my mac to Sierra and tried to revive my
>>> wireshark build environment. I got it compiling (out-of-tree cmake)
>>> and most of the tools (tshark) etc seem to work, but:
>>>
>>> $ ./run/wireshark
>>> Listening on en0
>>> 155 packets seen, 155 packets counted after pcap_dispatch returns
>>> ...
>>>
>>> No UI ever opens. I have Qt5 installed, and I checked my
>>> CmakeCache.txt and it is detected and building the UI module
>>> (BUILD_wireshark:BOOL=ON). The other weird part is:
>>>
>>> $ ./run/wireshark -h
>>> Usage: Wireshark [ -mn ] [ -i interface ] [ -t timeout] [expression]
>>>
>>> That's *all* it outputs. I have to assume that some other binary is
>>> being linked on top of the wireshark binary (tshark et al seem
>>> unaffected) but I don't recognize that option set.
>>>
>>> Any ideas? Has anybody seen this before?
>>
>> Weird. ./run/wireshark should be a shell script generated by CMakeLists.txt
>> that execs run/Wireshark.app/Contents/MacOS/Wireshark.
>
> ...and that's not Wireshark's "invalid command-line argument" error message.
>
> So what does "file run/wireshark" print?
>
> And if it's a shell script, what does it contain?

`run/wireshark` is a shell script pointing to
`./run/Wireshark.app/Contents/MacOS/Wireshark` the way it should. That
file is a Mach-O 64-bit executable x86_64. Running that file directly
has the same issues, so I suppose something is overwriting it or
mis-linking it or something.
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

[Wireshark-dev] Linking on OSX Sierra

[Evan Huus]

Hey all, recently upgrade my mac to Sierra and tried to revive my
wireshark build environment. I got it compiling (out-of-tree cmake)
and most of the tools (tshark) etc seem to work, but:

$ ./run/wireshark
Listening on en0
155 packets seen, 155 packets counted after pcap_dispatch returns
...

No UI ever opens. I have Qt5 installed, and I checked my
CmakeCache.txt and it is detected and building the UI module
(BUILD_wireshark:BOOL=ON). The other weird part is:

$ ./run/wireshark -h
Usage: Wireshark [ -mn ] [ -i interface ] [ -t timeout] [expression]

That's *all* it outputs. I have to assume that some other binary is
being linked on top of the wireshark binary (tshark et al seem
unaffected) but I don't recognize that option set.

Any ideas? Has anybody seen this before?

Thanks,
Evan
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Correct procedure for pushing a new dissector to Gerrit

[Evan Huus]

The relevant error is:

> ERROR: missing Change-Id in commit message footer

and the solution is also included in the message:

> Hint: To automatically insert Change-Id, install the hook:
> gitdir=$(git rev-parse --git-dir); scp -p -P 29418 
> pauloff...@code.wireshark.org:hooks/commit-msg ${gitdir}/hooks/
> And then amend the commit:
>   git commit --amend

The number of objects is not usually a human-useful value, git has an
interesting storage format so you're not going to see e.g. one object
per file. Although the fact that you're pushing 5 MiB seems a bit odd,
that's a *lot* of C code?

Cheers,
Evan

On Thu, Sep 15, 2016 at 4:56 PM, Paul Offord  wrote:
> Hi,
>
>
>
> I’m trying to upload a new dissector to Gerrit.  I don’t seem to be able to
> push it and I seem to be uploading too many objects.  This is what I get:
>
>
>
> C:\Development\Wireshark>set HOMEPATH=
>
>
>
> C:\Development\Wireshark>git status
>
> On branch bug12892
>
> Untracked files:
>
>   (use "git add ..." to include in what will be committed)
>
>
>
> CMakeListsCustom.txt
>
> plugins/bds/
>
> plugins/transum/
>
> wireshark-win64-libs/
>
>
>
> nothing added to commit but untracked files present (use "git add" to track)
>
>
>
> C:\Development\Wireshark>git add plugins/transum/
>
>
>
> C:\Development\Wireshark>git status
>
> On branch bug12892
>
> Changes to be committed:
>
>   (use "git reset HEAD ..." to unstage)
>
>
>
> new file:   plugins/transum/AUTHORS
>
> new file:   plugins/transum/CMakeLists.txt
>
> new file:   plugins/transum/COPYING
>
> new file:   plugins/transum/Makefile.am
>
> new file:   plugins/transum/NEWS
>
> new file:   plugins/transum/README
>
> new file:   plugins/transum/decoders.c
>
> new file:   plugins/transum/decoders.h
>
> new file:   plugins/transum/extractors.c
>
> new file:   plugins/transum/extractors.h
>
> new file:   plugins/transum/moduleinfo.h
>
> new file:   plugins/transum/packet-transum.c
>
> new file:   plugins/transum/packet-transum.h
>
> new file:   plugins/transum/plugin.rc.in
>
> new file:   plugins/transum/preferences.h
>
>
>
> Untracked files:
>
>   (use "git add ..." to include in what will be committed)
>
>
>
> CMakeListsCustom.txt
>
> plugins/bds/
>
> wireshark-win64-libs/
>
>
>
>
>
> C:\Development\Wireshark>git branch
>
> * bug12892
>
>   master
>
>
>
> C:\Development\Wireshark>git commit
>
> [bug12892 ec12fab] Initial upload of TRANSUM code Bug: 12892
>
> 15 files changed, 2715 insertions(+)
>
> create mode 100644 plugins/transum/AUTHORS
>
> create mode 100644 plugins/transum/CMakeLists.txt
>
> create mode 100644 plugins/transum/COPYING
>
> create mode 100644 plugins/transum/Makefile.am
>
> create mode 100644 plugins/transum/NEWS
>
> create mode 100644 plugins/transum/README
>
> create mode 100644 plugins/transum/decoders.c
>
> create mode 100644 plugins/transum/decoders.h
>
> create mode 100644 plugins/transum/extractors.c
>
> create mode 100644 plugins/transum/extractors.h
>
> create mode 100644 plugins/transum/moduleinfo.h
>
> create mode 100644 plugins/transum/packet-transum.c
>
> create mode 100644 plugins/transum/packet-transum.h
>
> create mode 100644 plugins/transum/plugin.rc.in
>
> create mode 100644 plugins/transum/preferences.h
>
>
>
> C:\Development\Wireshark>git push
> https://pauloff...@code.wireshark.org/review/w
>
> ireshark HEAD:refs/for/master/bug12892
>
> Password for 'https://pauloff...@code.wireshark.org':
>
> Counting objects: 3708, done.
>
> Delta compression using up to 4 threads.
>
> Compressing objects: 100% (1375/1375), done.
>
> Writing objects: 100% (3708/3708), 5.15 MiB | 117.00 KiB/s, done.
>
> Total 3708 (delta 2980), reused 3033 (delta 2331)
>
> remote: Resolving deltas: 100% (2980/2980)
>
> remote: Processing changes: refs: 1, done
>
> remote: ERROR: missing Change-Id in commit message footer
>
> remote:
>
> remote: Hint: To automatically insert Change-Id, install the hook:
>
> remote:   gitdir=$(git rev-parse --git-dir); scp -p -P 29418
> pauloff...@code.wir
>
> eshark.org:hooks/commit-msg ${gitdir}/hooks/
>
> remote: And then amend the commit:
>
> remote:   git commit --amend
>
> remote:
>
> To https://pauloff...@code.wireshark.org/review/wireshark
>
> ! [remote rejected] HEAD -> refs/for/master/bug12892 (missing Change-Id in
> comm
>
> it message footer)
>
> error: failed to push some refs to
> 'https://pauloff...@code.wireshark.org/review
>
> /wireshark'
>
>
>
> C:\Development\Wireshark>
>
>
>
> What am I doing wrong?
>
>
>
> Thanks and regards…Paul
>
>
> __
>
> This message contains confidential information and is intended only for the
> individual named. If you are not the named addressee you should not
> disseminate, distribute or copy this e-mail. Please notify the sender
> immediately by e-mail if you have

Re: [Wireshark-dev] I need wmem_alloc advice please

[Evan Huus]

Based on the name, this looks like memory that is only ever needed in the
scope of dissection for a single packet. If that is the case, it should
allocated in packet-scope when needed and not be global at all.

Evan

On Thu, Sep 15, 2016 at 12:48 PM, Pascal Quantin 
wrote:

> Hi Paul,
>
> 2016-09-15 18:44 GMT+02:00 Paul Offord :
>
>> My porting of TRANSUM from LUA to C continues.  I now have a working
>> dissector but I then read README.developer and noted the guidance regarding
>> use of static buffers.  I assume this applies to arrays too and so I’m now
>> trying to convert the statically defined arrays to versions based on
>> dynamic memory allocation.  I’ve converted some string buffers and a simple
>> gboolean array without problems.  I then tried to convert an array of
>> structures and this caused crashes all over the place.
>>
>>
>>
>> Before the conversion I had this as a global variable:
>>
>>
>>
>> PKT_INFO sub_packet[MAX_SUBPKTS_PER_PACKET];
>>
>>
>>
>> I replaced this with a global variable:
>>
>>
>>
>> PKT_INFO *sub_packet;
>>
>>
>>
>> And this in my init function:
>>
>>
>>
>> sub_packet = (PKT_INFO *)wmem_alloc(wmem_file_scope(),
>> (MAX_SUBPKTS_PER_PACKET * sizeof(PKT_INFO)));
>>
>>
>>
>> I subsequently use it like this:
>>
>>
>>
>> sub_packet[i].frame_number = 0;
>>
>>
>>
>> I seem to be getting memory corruption as a result of this change.  Weird
>> things happen, like I lose preference variables.
>>
>>
>>
>> What am I doing wrong here?
>>
>
> File scope memory is automatically freed each time a preference is
> changed, or a file is reloaded. If you need to keep some things persistent
> during all Wireshark instance, consider using epan scope memory for those
> variables instead.
>
> Regards,
> Pascal.
>
> 
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org?subject=
> unsubscribe
>
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] checkapi

[Evan Huus]

On Fri, Apr 22, 2016 at 10:24 AM, Jeff Morriss
 wrote:
>
>
> On Fri, Apr 22, 2016 at 3:28 AM, Graham Bloice 
> wrote:
>>
>> Just thinking for this for about 30 secs, is there another way?  checkAPIs
>> seems to be a very rudimentary (not meant in any derogatory way just because
>> it's written in Perl :_)) static code analyser.  Is there any way an actual
>> code analyser could be used with a configuration file listing the banned
>> API's etc.?  I guess one issue with that approach is that all the static
>> analysers I've used are quite slow, although that's maybe because I have
>> them turned up to 11.
>
>
> There are; someone (Evan?) suggested a couple of options a few years ago but
> I guess no one had enough interest to do anything about it.  But either my
> memory is wrong or my Google-fu isn't working well today because all I'm
> finding is a suggestion from Sebastien way back in 2008 (I really thought it
> was discussed more recently than that--and with more suggestions):
>
> https://www.wireshark.org/lists/wireshark-dev/200805/msg00128.html

I think I remember talking about http://cppcheck.sourceforge.net/ -
IIRC it lets you define custom rules either as regexes or as more
complex scripts on the C/C++ AST, though I haven't looked at it in a
while.

> Of course I doubt such tools could fully replace checkAPIs: it has a lot of
> custom stuff in there like ensuring various arrays are NULL terminated and
> that hf fields are appropriate (writing the regex to match all the hf array
> entries was all sorts of challenging fun :-)).

This may be somewhere a little bit of AST might go a long way, but it
would certainly be a lot of work to migrate everything over.

> (You really should just come on over to the world of Perl; eventually you'll
> wonder how you ever got along without it! ;-))
>
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Limiting amount of memory used to analyze TCP (HTTP) traffic. Questions about tcp dissector.

[Evan Huus]

Another article worth reading is
https://blog.wireshark.org/2014/07/to-infinity-and-beyond-capturing-forever-with-tshark/

It doesn't solve your problem, but it contains some good information
on surrounding issues.

Evan

On Thu, Feb 25, 2016 at 5:58 PM, Jeff Morriss  wrote:
>
>
> On Thu, Feb 25, 2016 at 4:53 PM, Vitaly Repin 
> wrote:
>>
>> Hello,
>>
>> I am trying to understand how the Wireshark TCP dissector utilizes memory.
>
>
> That's a good place to start but there's a lot of other stuff in Wireshark
> that will use a lot of memory as time goes by.
>
> On the off chance you haven't read it (at least a dozen times :-)) already:
> Wireshark's generally not the best tool for doing long-term analysis for
> exactly this reason (memory usage).
>
> At one point I was quite interested in adding some kind of memory profiling
> into Wireshark so we could see exactly where the memory was used at any
> given point in time (e.g., frame_data's are using 20 Mbytes, TCP
> reassembly's using 100 Mbytes, etc.) but I never came up with something
> good.
>
>> Then I have taken a look into  tcpd->acked_table.  According to the
>> comment it "contains a tree containing all the various ta's keyed by
>> frame number".
>> I see that this list monothonically grows during the analysis. It is
>> expected behavior?
>
>
> Assuming that 1) your TCP segments are being ACK'd and 2) you have TCP
> sequence analysis enabled (it is by default) then yes, it is expected.
>
>>
>> Any ideas how I can decrease memory consumption (even for the price of
>> not being able to analyze the whole TCP session if it contains huge
>> amount of data)?
>
>
> Have you gone through the suggestions in the Wiki's OutOfMemory article?  It
> has some pointers to things that will limit the memory usage.
>
> https://wiki.wireshark.org/KnownBugs/OutOfMemory
>
>
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Wireshark Performance

[Evan Huus]

https://code.wireshark.org/review/12389

A mistake in the macro->method conversion caused the addresses to not
actually be added to the hash, leading to hash collision for most
addresses and the extreme slowdown.

On Wed, Dec 2, 2015 at 4:42 PM, Evan Huus  wrote:
> Figured it out, the macro and the method are not identical. Patch incoming.
>
> On Wed, Dec 2, 2015 at 4:37 PM, Jim Young  wrote:
>> My tests point to v2.1.0rc0-228-g4f39c60 on master as the big one in terms 
>> of capture file load performance hit, but there is an earlier commit that 
>> appears to consistently added one second to  the load of my test file versus 
>> head on master-2.0.  I'll start bisect for this smaller one shortly.
>>
>>> C:\Development\wireshark>git bisect log
>>> # bad: [e628c02a78d1af3aa9ae8d707e6e10fe26591598] Update URLs for DDS 
>>> specifications.
>>> # good: [dae1286270af8cc9f6839e82102fa7433ac7acb4] Qt: Add "Bluetooth" 
>>> prefix for Bluetooth item in Wireless menu
>>> git bisect start 'e628c02' 'dae1286'
>>> # good: [0f2eb385f0b920cb4117189b9d13e88ae22787eb] x11 generator: Fix 
>>> struct size with array
>>> git bisect good 0f2eb385f0b920cb4117189b9d13e88ae22787eb
>>> # good: [b7de996684891c4d0584f78241d814de26509f44] RtpAudioStream: Add a 
>>> cast.
>>> git bisect good b7de996684891c4d0584f78241d814de26509f44
>>> # good: [ae130f114cd61443c8c93e1c9280e027726a0235] 802.1ah: call 
>>> subdissectors even when we have no tree.
>>> git bisect good ae130f114cd61443c8c93e1c9280e027726a0235
>>> # bad: [d77c1e18ebb9569dcfbe386156d0342944cd3325] NTP timestamps can't be 
>>> relative.
>>> git bisect bad d77c1e18ebb9569dcfbe386156d0342944cd3325
>>> # bad: [02d56ffa9c540dde3c3a9d1a77bd90f5a3b98962] TDS: Replace use of 
>>> val_to_str() with VALS()
>>> git bisect bad 02d56ffa9c540dde3c3a9d1a77bd90f5a3b98962
>>> # bad: [3385c2951c7dfecaaf0aad871a0842319d386321] NULL terminate some hf_ 
>>> arrays used in proto_tree_add_bitmask_xxx calls.
>>> git bisect bad 3385c2951c7dfecaaf0aad871a0842319d386321
>>> # bad: [4f39c603c2f0a2e429afedd18cd5c796bbbf8916] More ADDRESS macro to 
>>> address function conversions.
>>> git bisect bad 4f39c603c2f0a2e429afedd18cd5c796bbbf8916
>>> # first bad commit: [4f39c603c2f0a2e429afedd18cd5c796bbbf8916] More ADDRESS 
>>> macro to address function conversions.
>>>
>>> C:\Development\wireshark>git describe
>>> v2.1.0rc0-228-g4f39c60
>>>
>>> C:\Development\wireshark>
>> ___
>> Sent via:Wireshark-dev mailing list 
>> Archives:https://www.wireshark.org/lists/wireshark-dev
>> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>>  mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Wireshark Performance

[Evan Huus]

Figured it out, the macro and the method are not identical. Patch incoming.

On Wed, Dec 2, 2015 at 4:37 PM, Jim Young  wrote:
> My tests point to v2.1.0rc0-228-g4f39c60 on master as the big one in terms of 
> capture file load performance hit, but there is an earlier commit that 
> appears to consistently added one second to  the load of my test file versus 
> head on master-2.0.  I'll start bisect for this smaller one shortly.
>
>> C:\Development\wireshark>git bisect log
>> # bad: [e628c02a78d1af3aa9ae8d707e6e10fe26591598] Update URLs for DDS 
>> specifications.
>> # good: [dae1286270af8cc9f6839e82102fa7433ac7acb4] Qt: Add "Bluetooth" 
>> prefix for Bluetooth item in Wireless menu
>> git bisect start 'e628c02' 'dae1286'
>> # good: [0f2eb385f0b920cb4117189b9d13e88ae22787eb] x11 generator: Fix struct 
>> size with array
>> git bisect good 0f2eb385f0b920cb4117189b9d13e88ae22787eb
>> # good: [b7de996684891c4d0584f78241d814de26509f44] RtpAudioStream: Add a 
>> cast.
>> git bisect good b7de996684891c4d0584f78241d814de26509f44
>> # good: [ae130f114cd61443c8c93e1c9280e027726a0235] 802.1ah: call 
>> subdissectors even when we have no tree.
>> git bisect good ae130f114cd61443c8c93e1c9280e027726a0235
>> # bad: [d77c1e18ebb9569dcfbe386156d0342944cd3325] NTP timestamps can't be 
>> relative.
>> git bisect bad d77c1e18ebb9569dcfbe386156d0342944cd3325
>> # bad: [02d56ffa9c540dde3c3a9d1a77bd90f5a3b98962] TDS: Replace use of 
>> val_to_str() with VALS()
>> git bisect bad 02d56ffa9c540dde3c3a9d1a77bd90f5a3b98962
>> # bad: [3385c2951c7dfecaaf0aad871a0842319d386321] NULL terminate some hf_ 
>> arrays used in proto_tree_add_bitmask_xxx calls.
>> git bisect bad 3385c2951c7dfecaaf0aad871a0842319d386321
>> # bad: [4f39c603c2f0a2e429afedd18cd5c796bbbf8916] More ADDRESS macro to 
>> address function conversions.
>> git bisect bad 4f39c603c2f0a2e429afedd18cd5c796bbbf8916
>> # first bad commit: [4f39c603c2f0a2e429afedd18cd5c796bbbf8916] More ADDRESS 
>> macro to address function conversions.
>>
>> C:\Development\wireshark>git describe
>> v2.1.0rc0-228-g4f39c60
>>
>> C:\Development\wireshark>
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Wireshark Performance

[Evan Huus]

My current hypothesis is commit 74541a9596eead6647c592de9aa46797c2dffa84
but I don't have any files to test with locally.

On Wed, Dec 2, 2015 at 10:36 AM, Pascal Quantin 
wrote:

>
>
> 2015-12-02 16:31 GMT+01:00 Anders Broman :
>
>> Hi,
>>
>> I’m betting on this change J
>>
>>
>> https://code.wireshark.org/review/gitweb?p=wireshark.git;a=commitdiff;h=9e54fcee5224aef800155514cac5e40d9e38a23e
>>
>
> This change is also in master-2.0, so it cannot be the culprit.
>
> Pascal.
>
>
>>
>> *From:* wireshark-dev-boun...@wireshark.org [mailto:
>> wireshark-dev-boun...@wireshark.org] *On Behalf Of *Pascal Quantin
>> *Sent:* den 2 december 2015 16:26
>>
>> *To:* Developer support list for Wireshark
>> *Subject:* Re: [Wireshark-dev] Wireshark Performance
>>
>>
>>
>>
>>
>>
>>
>> 2015-12-02 16:12 GMT+01:00 POZUELO Gloria (BCS/PSD) <
>> gloria.pozu...@bics.com>:
>>
>> Where can I find that option?
>>
>>
>>
>> On Windows, Ctrl + Shift + E, or in the menu Analyze -> Enabled
>> protocols. Unselect stun_udp.
>>
>>
>>
>> *From:* wireshark-dev-boun...@wireshark.org [mailto:
>> wireshark-dev-boun...@wireshark.org] *On Behalf Of *Anders Broman
>> *Sent:* Wednesday 2 December 2015 16:08
>>
>>
>> *To:* Developer support list for Wireshark
>> *Subject:* Re: [Wireshark-dev] Wireshark Performance
>>
>>
>>
>> Hi,
>>
>> It’s probably deeper down, dissect_stun_heur has gone from 3.51 to 14.06.
>>
>> @ Gloria can you try to turn the stun heuristic off to see if it makes a
>> difference?
>>
>> Regards
>>
>> Anders
>>
>>
>>
>> *From:* wireshark-dev-boun...@wireshark.org [
>> mailto:wireshark-dev-boun...@wireshark.org
>> ] *On Behalf Of *Evan Huus
>> *Sent:* den 2 december 2015 16:02
>> *To:* Developer support list for Wireshark
>> *Subject:* Re: [Wireshark-dev] Wireshark Performance
>>
>>
>>
>> The only recent change to conversation_match_exact was the conversion
>> from address macros to functions, but in all cases the macros were just
>> pointing to the functions anyways so I can't imagine that would have a huge
>> effect on performance?
>>
>>
>>
>> On Wed, Dec 2, 2015 at 9:45 AM, Anders Broman 
>> wrote:
>>
>>
>>
>>
>>
>> *From:* wireshark-dev-boun...@wireshark.org [mailto:
>> wireshark-dev-boun...@wireshark.org] *On Behalf Of *Anders Broman
>> *Sent:* den 2 december 2015 15:41
>> *To:* Developer support list for Wireshark; alexis.lagou...@gmail.com
>> *Subject:* Re: [Wireshark-dev] Wireshark Performance
>>
>>
>>
>> Hi,
>>
>> Running valgrind on my standard pcap we have gone from
>>
>> ==36946== Callgrind, a call-graph generating cache profiler
>>
>> ==36946== Copyright (C) 2002-2013, and GNU GPL'd, by Josef Weidendorfer
>> et al.
>>
>> ==36946== Using Valgrind-3.10.0.SVN and LibVEX; rerun with -h for
>> copyright info
>>
>> ==36946== Command: /home/ericsson/wireshark/.libs/lt-tshark -Y frame -nr
>> /home/ericsson/etxrab/TCT_SIP_traffic.pcapng
>>
>> ==36946==
>>
>> ==36946== For interactive control, run 'callgrind_control -h'.
>>
>> ==36946==
>>
>> ==36946== Events: Ir
>>
>> ==36946== Collected : 18211043816
>>
>> ==36946==
>>
>> ==36946== I   refs:  18,211,043,816
>>
>>
>>
>> to
>>
>>
>>
>> ==4865==
>>
>> ==4865== Events: Ir
>>
>> ==4865== Collected : 1595333469530
>>
>> ==4865==
>>
>> ==4865== I   refs:  1,595,333,469,530
>>
>>
>>
>> The big difference seems to be
>>
>>
>>
>> Latest  June
>>
>> 87.95  37.92 6 076 548  g_hastable_lookup  5.56 2.98 6 515 523
>>
>>
>>
>> Looking deeper
>>
>> 49.43 25 142 686 213 conversation_match_exact 0.32 576 548
>>
>>
>>
>> decode_udp_ports seems much more expensive
>>
>>
>>
>> Regards
>>
>> Anders
>>
>>
>>
>>
>>
>> *From:* wireshark-dev-boun...@wireshark.org [
>> mailto:wireshark-dev-boun...@wireshark.org
>> ] *On Behalf Of *POZUELO Gloria
>> (BCS/PSD)
>> *Sent:* den 2 december 2015 14:01
>> *To:* Developer support list for Wireshark; alexis.lagou...@gmail.com

Re: [Wireshark-dev] Wireshark Performance

[Evan Huus]

The only recent change to conversation_match_exact was the conversion from
address macros to functions, but in all cases the macros were just pointing
to the functions anyways so I can't imagine that would have a huge effect
on performance?

On Wed, Dec 2, 2015 at 9:45 AM, Anders Broman 
wrote:

>
>
>
>
> *From:* wireshark-dev-boun...@wireshark.org [mailto:
> wireshark-dev-boun...@wireshark.org] *On Behalf Of *Anders Broman
> *Sent:* den 2 december 2015 15:41
> *To:* Developer support list for Wireshark; alexis.lagou...@gmail.com
> *Subject:* Re: [Wireshark-dev] Wireshark Performance
>
>
>
> Hi,
>
> Running valgrind on my standard pcap we have gone from
>
> ==36946== Callgrind, a call-graph generating cache profiler
>
> ==36946== Copyright (C) 2002-2013, and GNU GPL'd, by Josef Weidendorfer et
> al.
>
> ==36946== Using Valgrind-3.10.0.SVN and LibVEX; rerun with -h for
> copyright info
>
> ==36946== Command: /home/ericsson/wireshark/.libs/lt-tshark -Y frame -nr
> /home/ericsson/etxrab/TCT_SIP_traffic.pcapng
>
> ==36946==
>
> ==36946== For interactive control, run 'callgrind_control -h'.
>
> ==36946==
>
> ==36946== Events: Ir
>
> ==36946== Collected : 18211043816
>
> ==36946==
>
> ==36946== I   refs:  18,211,043,816
>
>
>
> to
>
>
>
> ==4865==
>
> ==4865== Events: Ir
>
> ==4865== Collected : 1595333469530
>
> ==4865==
>
> ==4865== I   refs:  1,595,333,469,530
>
>
>
> The big difference seems to be
>
>
>
> Latest  June
>
> 87.95  37.92 6 076 548  g_hastable_lookup  5.56 2.98 6 515 523
>
>
>
> Looking deeper
>
> 49.43 25 142 686 213 conversation_match_exact 0.32 576 548
>
>
>
> decode_udp_ports seems much more expensive
>
>
>
> Regards
>
> Anders
>
>
>
>
>
> *From:* wireshark-dev-boun...@wireshark.org [
> mailto:wireshark-dev-boun...@wireshark.org
> ] *On Behalf Of *POZUELO Gloria
> (BCS/PSD)
> *Sent:* den 2 december 2015 14:01
> *To:* Developer support list for Wireshark; alexis.lagou...@gmail.com
> *Subject:* Re: [Wireshark-dev] Wireshark Performance
>
>
>
> I’ve been testing the performance a little more and it seems that the
> loading time has increased not only for GTP protocol. I have sniffed a pcap
> composed by 22844 packets and if you open it up with both versions, v2.0
> lasts 0.520s and v2.1 lasts 1.433s. But as you saw before for GTP protocol
> is even worse, I’ll try to get a pcap example that I can share.
>
>
>
> Regards.
>
>
>
> *From:* wireshark-dev-boun...@wireshark.org [
> mailto:wireshark-dev-boun...@wireshark.org
> ] *On Behalf Of *POZUELO Gloria
> (BCS/PSD)
> *Sent:* Wednesday 2 December 2015 09:13
> *To:* alexis.lagou...@gmail.com; Developer support list for Wireshark
> *Subject:* Re: [Wireshark-dev] Wireshark Performance
>
>
>
> I can’t share this one, because it has user data and it’s confidential,
> but we are going to generate another one that can be share. We are using
> GTP protocol, if that gives you a clue.
>
>
>
> *From:* wireshark-dev-boun...@wireshark.org [
> mailto:wireshark-dev-boun...@wireshark.org
> ] *On Behalf Of *Alexis La Goutte
> *Sent:* Wednesday 2 December 2015 09:08
> *To:* Developer support list for Wireshark
> *Subject:* Re: [Wireshark-dev] Wireshark Performance
>
>
>
> You can directly add the text output of load time...
>
> It is possible to share your pcap ?
>
>
>
> On Wed, Dec 2, 2015 at 9:04 AM, POZUELO Gloria (BCS/PSD) <
> gloria.pozu...@bics.com> wrote:
>
> I attach the screen captures better.
>
>
>
> *From:* wireshark-dev-boun...@wireshark.org [mailto:
> wireshark-dev-boun...@wireshark.org] *On Behalf Of *POZUELO Gloria
> (BCS/PSD)
> *Sent:* Wednesday 2 December 2015 08:53
> *To:* Developer support list for Wireshark
> *Subject:* [Wireshark-dev] Wireshark Performance
>
>
>
> Hello,
>
> Here is the loading time difference between the v2.0 and the last
> automated build for win64 Wireshark-win64-2.1.0-875-g9779ae3.exe
> 
>
> [image: Imágenes integradas 2][image: Imágenes integradas 1]
>
> Regards.
>
>
> --
>
>
>  DISCLAIMER
> http://www.bics.com/maildisclaimer/
>
>
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org
> ?subject=unsubscribe
>
>
>
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org
> ?subject=unsubscribe
>
___
Sent via:Wireshark-dev mailing list 
Archives:https://www

Re: [Wireshark-dev] Unix compiling errors

[Evan Huus]

On Tue, Dec 1, 2015 at 10:25 AM, POZUELO Gloria (BCS/PSD)
 wrote:
> Hi all,
>
>
>
> I’d like to ask you, how could I fix this error, since I’m working on a
> Windows environment and this error only appears by compiling for Unix.
>
>
>
> error: request for implicit conversion from ‘void *’ to ‘void **’ not
> permitted in C++ [-Werror=c++-compat]
>
>  while (!found && g_hash_table_iter_next(&iter, (gpointer)>p_info,
> (gpointer)&f)) {
>
>  ^
>
> Looking at the Glib reference we can see that g_hash_table_iter_next needs 2
> gpointer parameters, but it seems to me that this is the cause of the
> error…. gtp_info is a struct and f is a guint32*.

It expects the second parameter to be a `gpointer *`, but you are only
casting it to a gpointer - you should try `(gpointer *)&f` for the key
parameter.

> gboolean
>
> g_hash_table_iter_next (GHashTableIter *iter,
>
> gpointer *key,
>
> gpointer *value);
>
>
>
> And finally I have some doubts about this other error:
>
> error: cast to pointer from integer of different size
> [-Werror=int-to-pointer-cast]
>
>  g_slist_foreach(teid_list, (GFunc)teid_loop,
> (gpointer)pinfo->fd->num);
>
>   ^
>
> This can be solve by using GINT_TO_POINTER function?

It should be.

>
> Thank you very much in advance,
>
>
>
> Regards.
>
>
> 
>
>  DISCLAIMER
> http://www.bics.com/maildisclaimer/
>
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Is it better to have dissected and lost than never to have dissected at all?

[Evan Huus]

On Thu, Nov 19, 2015 at 9:57 PM, Michael Mann  wrote:
> This question has probably been asked before, so I thought I'd at least put
> a Tennyson twist on it.
>
> I started getting more serious about converting dissectors to the "new
> style".  I submitted a bunch of patches where it was obvious that the
> dissectors fell into the "give me everything" category.  My biggest worry is
> the comment made by Guy in bug 11134
> (https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=11134#c13), that some
> dissectors want to "accept" a tvb (packet) as their own, but don't actually
> parse any bytes (so it appears that they would "return 0" with the new
> style).  So the remaining ones I'm taking more slowly (with the attitude of
> unsure means leave as old style) and if anyone know of protocols that behave
> this way, feel free to convert them (or send me a note)
>
> The case I keep coming across that I'm not sure how to deal with is
> dissectors that get a few bytes in (and have already created trees/items for
> a few fields), and then decide they aren't going to dissect anymore because
> of a "bad" field value (most commonly "version" or "length").  Should we
> apply a consistent rule for this?  Like if you're not going to dissect
> "versions" you don't support, check before making trees and just not bother
> with expert info saying "version isn't supported" while ceasing dissection.
> Or dissect as "latest version" (or at least "a" version), but with the
> expert info applied that the version is unknown.  I'm not sure which
> scenario users would appreciate more, but I'd like to see it applied as
> consistently as possible. I believe my preference is for using expert info,
> but continuing dissection.

I'm OK with that.

> Are such rules more critical for popular protocols like Ethernet, IP and
> TCP/UDP where there are possibly "shared" values for a subdissector
> identifier?
>
> Also, should we clean up a tree if a new-style dissector returns 0 (within
> the functions in epan/packet.c)?  I think the expert info would be harder to
> clean up, but I'm also not sure of the difficult of the trees either.

As Guy said, a dissector should not be returning 0 if it's added any
tree items. If we can tell when this occurs, we should make it a
DISSECTOR_BUG.

> Opinions welcome, but I'd like to see the "new" style be the "only" style by
> the 2.2 release.

This would be amazing.
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Buildbots

[Evan Huus]

As you said, petri-dish is triggered by core devs for unmerged gerrit
changes to test them before merging. Master is triggered on every merge to
build the actual git master branch.

On Thu, Nov 19, 2015 at 11:45 AM, Dario Lombardo <
dario.lombardo...@gmail.com> wrote:

> I've found 2 different buildbot projects for wireshark
>
> https://buildbot.wireshark.org/petri-dish/
>
> and
>
> https://buildbot.wireshark.org/wireshark-master/
>
> Can anyone explain me the difference? I've understood that petri-dish is
> manually triggered by core-devs from gerrit. Who triggers the
> wireshark-master?
> Sorry if it's a stupid question, but I like to understand all the code
> audit tools that run around wireshark.
> Thanks.
> Dario.
>
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org
> ?subject=unsubscribe
>
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] NEW_PROTO_TREE_API status

[Evan Huus]

If I remember correctly, Jakub added the new API because it is
marginally more efficient in binary size and start-up cost per field.
Given we have many thousands of fields at this point, the savings of
converting the entire code base would be non-trivial.

That said, I'm not sure if conversion stopped because we ran into
problems with it or just because it was more work than people wanted
to do. I agree we should pick one and stick with it. The old API is
much more widely used still, which is a point in its favour (a lot
less work to revert) but the efficiency gains are rather appealing.

Overall I think I'd vote to keep the new API, but that is not a
particularly strong position. What do others think?

Evan

On Tue, Nov 10, 2015 at 7:40 AM, Michal Labedzki
 wrote:
> I have a plan to update Bluetooth dissector to new api/style (in
> future). Should I do that?
> Or maybe we should start merging only new style/API dissectors.
>
> On 10 November 2015 at 13:34, Alexis La Goutte
>  wrote:
>>
>>
>> On Tue, Aug 18, 2015 at 3:52 PM, Alexis La Goutte
>>  wrote:
>>>
>>> Hi,
>>>
>>> What the status of this change ?
>>> Because no change from 2 years about this...
>>>
>>> Revert the code and feature ? or for 2.2 after cleanup proto_tree_add_text
>>> ? ;-)
>>>
>>> Cheers,
>>>
>> Bump the topic...
>> because there is on review, a new protocol using this API
>> https://code.wireshark.org/review/#/c/11680/1
>>
>> I think it is better to reverse the code (and feature)...
>>
>> Regards,
>>
>>
>> ___
>> Sent via:Wireshark-dev mailing list 
>> Archives:https://www.wireshark.org/lists/wireshark-dev
>> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>>  mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
>
>
>
> --
>
> Pozdrawiam / Best regards
> -
> Michał Łabędzki, Software Engineer
> Tieto Corporation
>
> Product Development Services
>
> http://www.tieto.com / http://www.tieto.pl
> ---
> ASCII: Michal Labedzki
> location: Swobodna 1 Street, 50-088 Wrocław, Poland
> room: 5.01 (desk next to 5.08)
> ---
> Please note: The information contained in this message may be legally
> privileged and confidential and protected from disclosure. If the
> reader of this message is not the intended recipient, you are hereby
> notified that any unauthorised use, distribution or copying of this
> communication is strictly prohibited. If you have received this
> communication in error, please notify us immediately by replying to
> the message and deleting it from your computer. Thank You.
> ---
> Please consider the environment before printing this e-mail.
> ---
> Tieto Poland spółka z ograniczoną odpowiedzialnością z siedzibą w
> Szczecinie, ul. Malczewskiego 26. Zarejestrowana w Sądzie Rejonowym
> Szczecin-Centrum w Szczecinie, XIII Wydział Gospodarczy Krajowego
> Rejestru Sądowego pod numerem 124858. NIP: 8542085557. REGON:
> 812023656. Kapitał zakładowy: 4 271500 PLN
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Send comments in Gerrit

[Evan Huus]

Hit the "Reply..." button on the review page, and then hit "Post" in
the popup that appears.

Evan

On Thu, Oct 29, 2015 at 1:53 PM, Juan Jose Martin Carrascosa
 wrote:
> Hi guys,
>
> I don't remember how to send the answers to the comments I got in a
> Code-Review. They are all drafts right now.
>
> Can anybody help me? Sorry for the dumb question :)
>
> Thanks,
> Juanjo Martin
>
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

[Wireshark-dev] -fPIC on Ubuntu Wily

[Evan Huus]

After recently upgrading to Ubuntu 15.10, my cmake configure failed with:
-- Performing Test WORKS_WITH_FPIC - Failed
CMake Error at CMakeLists.txt:938 (message):
  Couldn't compile Qt without -fPIC nor with -fPIC

Digging into the logs, the test being run (and its output) is as follows:

/usr/bin/c++-Wall -W -Wextra -Wendif-labels -Wpointer-arith
-Warray-bounds -Wformat-security -fwrapv -fno-strict-overflow
-fno-delete-null-pointer-checks -Wvla -Waddress -Wattributes
-Wdiv-by-zero -Wignored-qualifiers -Wpragmas -Wno-overlength-strings
-Wwrite-strings -Wno-long-long -fexcess-precision=fast
-DWORKS_WITH_FPIC -fPIC -fPIE -I/usr/include/x86_64-linux-gnu/qt5
-I/usr/include/x86_64-linux-gnu/qt5/QtCore
-I/usr/lib/x86_64-linux-gnu/qt5/mkspecs/linux-g++-64-o
CMakeFiles/cmTryCompileExec1538407922.dir/src.cxx.o -c
/home/eapache/pkg/linux_amd64/wireshark.org/wireshark/CMakeFiles/CMakeTmp/src.cxx
In file included from
/usr/include/x86_64-linux-gnu/qt5/QtCore/qnamespace.h:37:0,
 from /usr/include/x86_64-linux-gnu/qt5/QtCore/qobjectdefs.h:41,
 from /usr/include/x86_64-linux-gnu/qt5/QtCore/qobject.h:40,
 from
/usr/include/x86_64-linux-gnu/qt5/QtCore/qabstractanimation.h:37,
 from /usr/include/x86_64-linux-gnu/qt5/QtCore/QtCore:4,
 from
/home/eapache/pkg/linux_amd64/wireshark.org/wireshark/CMakeFiles/CMakeTmp/src.cxx:1:
/usr/include/x86_64-linux-gnu/qt5/QtCore/qglobal.h:1052:4: error:
#error "You must build your code with position independent code if Qt
was built with -reduce-relocations. " "Compile your code with -fPIC
(-fPIE is not enough)."
 #  error "You must build your code with position independent code if
Qt was built with -reduce-relocations. "\
^

I suspect because we are passing both -fPIC *and* -fPIE (and that
-fPIE is being passed second) something is not working correctly? I'm
not familiar with how those flags work together.

Thoughts?
Evan
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Do we still need/want -Wc++-compat?

[Evan Huus]

On Fri, Oct 9, 2015 at 1:40 PM, Guy Harris  wrote:
>
> On Sep 30, 2015, at 9:59 PM, Evan Huus  wrote:
>
>> On Thu, Oct 1, 2015 at 12:38 AM, Guy Harris  wrote:
>>>
>>> On Sep 30, 2015, at 6:53 PM, Guy Harris  wrote:
>>>
>>>> I think the intent was to be able to run Wireshark's C code through C++ 
>>>> compilers; I can't find the mail where this was discussed, but, as I 
>>>> remember, the issue was that Microsoft were dragging their feet on C99 
>>>> support, and we wanted to be able to use at least some features present in 
>>>> both C99 and the versions of C++ supported by the Microsoft compiler.
>>>>
>>>> Microsoft have gotten more receptive to C99 features; is this something we 
>>>> still want to contemplate - and to try to keep open as a possibility, by 
>>>> compiling with -Wc++-compat?
>>>>
>>>> If I try to build what's currently in master, it fails on my Yosemite 
>>>> machine, with Xcode 7.0.1
>>>
>>> Not after rebuilding and reinstalling all the development libraries and 
>>> doing make maintainer-clean/autogen/configure/make.
>>>
>>> But what was the reason for adding checks for C++ compatibility, and does 
>>> it still apply?
>>
>> My memory matches yours: it was about MSVC (and other more obscure
>> compilers we theoretically support, on platforms I have never actually
>> used**) not having C99 features.
>>
>> Part of me would like to take a hard line and say: "these are the C99
>> features we require, deal with it" but I don't know how much screaming
>> that would entail. Another part of me would like to just switch to use
>> C++ compilers on all our common platforms and start gradually
>> introducing some of the useful, not-insanely-complex bits of C++ into
>> the code-base, but I already know how much screaming that would entail
>> :P
>>
>> ** `doc/README.developer` references IBM's compiler for AIX as one
>> which lacks even basic C99 support like // comments.
>
> Some experimenting with The Written Word's machines found that:
>
> XL C on AIX, with -qlanglvl=extc89, accepts variadic macros, but does 
> *not* accept // comments;
>
> XL C on AIX, with -qlanglvl=extc99, accepts variadic macros and // 
> comments.
>
> Looking at the XL C 7.0 documentation:
>
> http://www-01.ibm.com/support/docview.wss?uid=swg27005410&aid=1
>
> indicates that -qlanglvl=extc89 -qcpluscmt should also handle // comments.
>
> There are probably old enough versions of XL C that cannot be made to handle 
> // comments, but, unless they handle macros with a variable number of 
> arguments, they can't handle the current 2.x Wireshark source.
>
> We're now using AC_PROG_CC_STDC rather than AC_PROG_CC in the configure 
> script in 2.x, and, at least for versions of XL C that support C99, that will 
> enable all C99 features.
>
> I think, at this point, that the only compiler we'll be dealing with that's 
> limited in its C99 capabilities is MSVC, and, so far, we haven't used 
> anything it can't handle.
>
> My inclination is to keep using AC_PROG_CC_STDC, let whatever C99isms that 
> lets get through remain as long as MSVC can handle them (if it can't, that'll 
> show up in the build), and allow // comments.

+1
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Best algorithmic way to implement MPTCP sequence number space analysis ?

[Evan Huus]

You should just be able to call `epan_get_frame_ts` and pass it
`pinfo->epan` plus your frame number.

On Thu, Oct 8, 2015 at 4:26 PM, Matt  wrote:
> I managed to get the interval tree working with only a few
> modifications to the core R/B tree.
>
> I now would like to compute the sequence number inter arrival times
> (multipath may provoke more out of order hence it is a metric of
> interest). To do that I need to get access to the time arrival of a
> specific frame (i.e., I know the frame number) from packet-tcp.c.
> For instance I have a packet with Sequence Number (=SN) 100 in packet
> 5 and I know that SN 99 is in packet 2 or in packet 8 (out of order)
> and I would like to compute the delta time of arrival between the 2
> packets.
>
> I found the frame_data_sequence_find() function but it expects a list
> of frames as first parameter. Any idea how to retrieve that list from
> packet-tcp.c ?
>
> Regards
>
>
> 2015-10-02 18:11 GMT+02:00 Matt :
>> Hi,
>>
>> (Question is at the end, I start with an Multipath TCP introduction (MPTCP) 
>> ).
>> I would be interested in adding MPTCP sequence number analysis to
>> wireshark, similar to what is done with TCP but taking into account
>> MPTCP specifics:
>> - MPTCP sequence number is 64 bits.
>> - MPTCP uses a global sequence number (SN) space and maps this global
>> SN to a TCP SN. For instance, an MPTCP socket wants to send the bytes
>> 1 to 10. It may send 6 bytes on TCP subflow 1 and the 4 other bytes on
>> another subflow 2. On each subflow (=TCP connection), it will send a
>> mapping (via a TCP option called DSS=Data Sequence Signaling) saying
>> for instance
>> on subflow 1 I map MPTCP global SN 1-6 to local subflow SN 21-26,
>> on subflow 2 I map MPTCP global SN 7-10 to local TCP SN 60-63.
>>
>> Keeping track of those DSS options/mappings would help analyzing the
>> behavior of an MPTCP connection:
>> - does it duplicate some packets over different paths (<=> do some DSS
>> overlap on different subflows?)
>> - it would allow to generate an MPTCP RTT/application latency since
>> striping packets over several paths is likely to increase the
>> application latency
>> - also allow to deduce if we've captured all subflows or if there are
>> holes in the MPTCP sequence number (maybe one subflow was emitting on
>> the wifi interface and we didn't capture it)
>> etc...
>>
>> Now here is my problem: what datastructure should I use to achieve
>> what I previously describe in a way that could be accepted upstream ?
>> or to put it differently how to retrieve a list of ranges (MPTCP start
>> SN and end SN) from another SN range ? The interval tree sounds like a
>> good solution (http://www.geeksforgeeks.org/interval-tree/) but I
>> wonder if there is any advice on an alternate solution ? or ways to
>> build the tree efficiently (like disabling rotations and balancing the
>> tree only at the end or stuff like that, I am not an algorithmic
>> expert).
>>
>> In any case, I plan to add an option to turn this DSS analysis on/off.
>>
>> Regards
>>
>> Matt
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Best algorithmic way to implement MPTCP sequence number space analysis ?

[Evan Huus]

On Fri, Oct 2, 2015 at 12:11 PM, Matt  wrote:
> Hi,
>
> (Question is at the end, I start with an Multipath TCP introduction (MPTCP) ).
> I would be interested in adding MPTCP sequence number analysis to
> wireshark, similar to what is done with TCP but taking into account
> MPTCP specifics:
> - MPTCP sequence number is 64 bits.
> - MPTCP uses a global sequence number (SN) space and maps this global
> SN to a TCP SN. For instance, an MPTCP socket wants to send the bytes
> 1 to 10. It may send 6 bytes on TCP subflow 1 and the 4 other bytes on
> another subflow 2. On each subflow (=TCP connection), it will send a
> mapping (via a TCP option called DSS=Data Sequence Signaling) saying
> for instance
> on subflow 1 I map MPTCP global SN 1-6 to local subflow SN 21-26,
> on subflow 2 I map MPTCP global SN 7-10 to local TCP SN 60-63.
>
> Keeping track of those DSS options/mappings would help analyzing the
> behavior of an MPTCP connection:
> - does it duplicate some packets over different paths (<=> do some DSS
> overlap on different subflows?)
> - it would allow to generate an MPTCP RTT/application latency since
> striping packets over several paths is likely to increase the
> application latency
> - also allow to deduce if we've captured all subflows or if there are
> holes in the MPTCP sequence number (maybe one subflow was emitting on
> the wifi interface and we didn't capture it)
> etc...
>
> Now here is my problem: what datastructure should I use to achieve
> what I previously describe in a way that could be accepted upstream ?
> or to put it differently how to retrieve a list of ranges (MPTCP start
> SN and end SN) from another SN range ? The interval tree sounds like a
> good solution (http://www.geeksforgeeks.org/interval-tree/) but I
> wonder if there is any advice on an alternate solution ? or ways to
> build the tree efficiently (like disabling rotations and balancing the
> tree only at the end or stuff like that, I am not an algorithmic
> expert).
>
> In any case, I plan to add an option to turn this DSS analysis on/off.

Sounds interesting. Regarding data-structures, the key thing you have
to figure out is what operations exactly you want the data-structure
to have. When you're not sure, I find it helpful to sketch out how the
code would work if you had some magic black-box that could do
anything.

For example, one operation you're probably going to want is something like:
add_mapping(global_sn_start, global_sn_end, local_sn_start,
local_sn_end, local_id);

What else do you need to be able to do to it to be able to calculate
the things you want?
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Should an IPv4 netmask be its own fieldtype?

[Evan Huus]

> On Oct 1, 2015, at 08:35, mman...@netscape.net wrote:
> 
> But doesn't any of these potential representations (mostly network prefix) 
> require a specific field type (and not a display type) for display filtering 
> purposes?
>  

I don't think so. You can use an FT_UINT32 and just tweak the dfilter grammar 
to recognize /## as a shortcut for integers generally.

>  
> -Original Message-
> From: Jeffrey Smith 
> To: Developer support list for Wireshark 
> Sent: Thu, Oct 1, 2015 1:46 am
> Subject: Re: [Wireshark-dev] Should an IPv4 netmask be its own fieldtype?
> 
> RFC950: "Since the bits that identify the subnet are specified by a bitmask, 
> they need not be adjacent in the address. However, we recommend that the 
> subnet bits be contiguous and located as the most significant bits of the 
> local address."
> So essentially any mask IS legal (even if not recommended).
> The two standard subnets notations are dotted decimal (e.g. 255.255.255.0) 
> and network prefix (e.g. /24).  So recognizing just "24" may not be terrible, 
> but I find no precedent for doing so.
>> On Sep 30, 2015 11:03 PM, "Guy Harris"  wrote:
>> 
>> On Sep 30, 2015, at 9:00 PM, Evan Huus  wrote:
>> 
>> > A pure netmask (without an associated address) is representable as
>> > just a UINT8. Would it be terrible to write `protocolXYZ.netmask ==
>> > 24`?
>> 
>> Some are sent over the wire as a 32-bit mask, which could, conceivably, have 
>> holes in the middle.
>> ___
>> Sent via:Wireshark-dev mailing list 
>> Archives:https://www.wireshark.org/lists/wireshark-dev
>> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>>  mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
> 
> ___
> Sent
> via:Wireshark-dev mailing list 
> Archives:   
> https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe:
> https://wireshark.org/mailman/options/wireshark-dev
> 
> mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
> mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Should an IPv4 netmask be its own fieldtype?

[Evan Huus]

On Thu, Oct 1, 2015 at 12:03 AM, Guy Harris  wrote:
>
> On Sep 30, 2015, at 9:00 PM, Evan Huus  wrote:
>
>> A pure netmask (without an associated address) is representable as
>> just a UINT8. Would it be terrible to write `protocolXYZ.netmask ==
>> 24`?
>
> Some are sent over the wire as a 32-bit mask, which could, conceivably, have 
> holes in the middle.

Right, so I guess a UINT32, with some sort of dfilter syntax shortcut
for "/x" == (2^x)-1?
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Do we still need/want -Wc++-compat?

[Evan Huus]

On Thu, Oct 1, 2015 at 12:38 AM, Guy Harris  wrote:
>
> On Sep 30, 2015, at 6:53 PM, Guy Harris  wrote:
>
>> I think the intent was to be able to run Wireshark's C code through C++ 
>> compilers; I can't find the mail where this was discussed, but, as I 
>> remember, the issue was that Microsoft were dragging their feet on C99 
>> support, and we wanted to be able to use at least some features present in 
>> both C99 and the versions of C++ supported by the Microsoft compiler.
>>
>> Microsoft have gotten more receptive to C99 features; is this something we 
>> still want to contemplate - and to try to keep open as a possibility, by 
>> compiling with -Wc++-compat?
>>
>> If I try to build what's currently in master, it fails on my Yosemite 
>> machine, with Xcode 7.0.1
>
> Not after rebuilding and reinstalling all the development libraries and doing 
> make maintainer-clean/autogen/configure/make.
>
> But what was the reason for adding checks for C++ compatibility, and does it 
> still apply?

My memory matches yours: it was about MSVC (and other more obscure
compilers we theoretically support, on platforms I have never actually
used**) not having C99 features.

Part of me would like to take a hard line and say: "these are the C99
features we require, deal with it" but I don't know how much screaming
that would entail. Another part of me would like to just switch to use
C++ compilers on all our common platforms and start gradually
introducing some of the useful, not-insanely-complex bits of C++ into
the code-base, but I already know how much screaming that would entail
:P

** `doc/README.developer` references IBM's compiler for AIX as one
which lacks even basic C99 support like // comments.
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Should an IPv4 netmask be its own fieldtype?

[Evan Huus]

A pure netmask (without an associated address) is representable as
just a UINT8. Would it be terrible to write `protocolXYZ.netmask ==
24`?

On Wed, Sep 30, 2015 at 10:59 PM,   wrote:
> There's a discussion in a patch review
> (https://code.wireshark.org/review/10438/), that I think should get more
> visibility.
>
> The question is "should an IPv4 netmask field be its own fieldtype?"  The
> main problem being that netmasks are being treated as IPv4 fields and are
> attempted to be named resolved, which shouldn't be.  The original patch
> created an "IPv4_MASK" field type to handle this.  Recent discussions about
> field types (on this mailing list and other patch reviews) have consistently
> resulted in new "display types" being created over new field types.
> Following this, I amended the original patch to use a "display type" instead
> of a field type.  The argument for the field type by the original patch
> author (Jeffrey Smith, CCed here in case he's not on -dev) is:
>
> "... the display filter "protocolXYZ.netmask == 10.0.0.1/24" is currently
> valid but semantically makes no sense.  Also, I think "protocolXYZ.netmask
> == /24" does make sense but does not work.  This change makes the sensible
> thing happen in those cases, but a display-only change would not have the
> same effect."
>
> I'm not familiar enough with using this filter notation or know how popular
> it is to know how much this impact should be considered.  But I know there
> are others on the list that may have stronger and more educated opinions.
>
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Should we require Flex with reentrant scanner support?

[Evan Huus]

On Sun, Sep 20, 2015 at 11:20 PM, Guy Harris  wrote:
> Currently, we require Flex, rather than Lex, but we don't require a version 
> of Flex sufficiently new to support reentrant scanners.
>
> That's not a major issue yet, but it could potentially be an issue if we make 
> more use of threading and have two threads in the same process
>
> 1) both reading Lucent/Ascend ISDN device text output files;
>
> 2) both reading Tektronix K12 text files;
>
> 3) both importing text files as captures;
>
> as those all involve Flex scanners.  It *might* also come up if any of the 
> other Flex-scanner code is run in more than one thread at once.
>
> If we also require a version of Flex that supports --header-file=, it could 
> also let us clean up or even eliminate the runlex.sh script, as those 
> versions of Flex can generate a .h files that declares functions.
>
> Flex 2.5.6 (from some time in 2002, I think) adds support for reentrant 
> scanners.  It also supports --header=, which was renamed to --header-file in 
> Flex 2.5.19, released 2002-09-05.
>
> We'd also want to require Bison or Berkeley YACC, to generate reentrant 
> parsers, for the Lucent/Ascend ISDN device text file reader.

I think requiring software released in 2002 is probably safe, we
already require much more recent versions of most other libraries.

Evan
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] [Wireshark-commits] master f50ff01: Squelch 64-bit-to-32-bit warnings by just casting to int.

[Evan Huus]

On Sun, Sep 13, 2015 at 4:28 PM, Wireshark code review
 wrote:
> URL: 
> https://code.wireshark.org/review/gitweb?p=wireshark.git;a=commit;h=f50ff0149e32158b11413715acaeef77478d3fd9
> Submitter: Guy Harris (g...@alum.mit.edu)
> Changed: branch: master
> Repository: wireshark
>
> Commits:
>
> f50ff01 by Guy Harris (g...@alum.mit.edu):
>
> Squelch 64-bit-to-32-bit warnings by just casting to int.
>
> Those lengths had better fit in an int if they're added to packet offsets.
>
> (BTW, gsize is the spawn of Satan; it should never be used except when
> you're dealing with GLib.  It *should* have just been another name for
> size_t, but it's 32 bits on 64-bit Windows, which means it's narrower
> than size_t, which causes us some pain with g_snprintf().)

Today I learned.

> Change-Id: Icd8f0632242303dbea0d80e0dad45b317097daaa
> Reviewed-on: https://code.wireshark.org/review/10516
> Reviewed-by: Guy Harris 
>
>
> Actions performed:
>
> from  eed56ee   bootp: simplify avaya parameter parsing
> adds  f50ff01   Squelch 64-bit-to-32-bit warnings by just casting to int.
>
>
> Summary of changes:
>  epan/dissectors/packet-bootp.c |6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> ___
> Sent via:Wireshark-commits mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-commits
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-commits
>  
> mailto:wireshark-commits-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] using wmem in wiretap

[Evan Huus]

On Fri, Sep 4, 2015 at 11:42 AM, Hadriel Kaplan
 wrote:
> Howdy,
> I've begun changing wiretap to enable us to handle pcapng files fully,
> as described in:
> https://wiki.wireshark.org/WiretapPcapng
>
> One of the tangential issues I've hit is the memory management of the
> various SHB/IDB/etc. structs/members. The previous model for wiretap
> was somewhat mixed: wiretap internally handled cleanup of things in
> the wtap struct, but not for wtap_dumper. This resulted in a lot of
> tedious and error-prone g_free'ing calls in the applications using
> wiretap, and often had leaks. (in fact, I'm pretty sure there are
> still various mem leaks today)
>
> Originally I thought wiretap should just be in charge of handling
> cleanup all itself - but that isn't as easy as one would think, given
> various error scenarios and unknown block support.
>
> So now I'm thinking perhaps it should use the wmem framework - give
> each wtap/wtap_dumper instance its own wmem pool, and all
> blocks/members are created using it, and it's all auto-cleaned up on
> file closure.
>
> Does that sound reasonable? Or is it overkill?

Don't know enough about the "various error scenarios and unknown block
support" you mention to really say.

> The one big issue I see is that currently wmem is in epan, and part of
> libwireshark. But there's nothing about it that appears to be
> epan-specific, other than a few global singleton pools it maintains in
> wmem_scopes.c. As far as I can tell, though, those are effectively
> just specific accessor clients of the wmem "library" and could be
> separated from wmem - the rest of wmem could be used by anyone if it
> were separated out of libwireshark. Right?

Spot on. Moving wmem into wsutil (with the sole exception of
wmem_scopes.[ch]) is perfectly reasonable and probably pretty easy.

> -hadriel
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] tvb_captured_length or tvb_reported_length?

[Evan Huus]

Many systems support packet capture such that only the first n bytes
of each captured packet is saved, as this is far more efficient and
frequently enough if you're only interested in the headers. When that
occurs, "captured" is the number of bytes actually captured, while
"reported" is the original number of bytes on the wire.

The vast majority of the time, dissectors need to use the length
reported on the wire; the captured length is only useful in specific
circumstances like reassembling fragmented messages.

Evan

On Wed, Sep 2, 2015 at 1:33 PM, Robert Cragie
 wrote:
> I am trying to understand the changes to the previous use of tvb_length().
> There are now two functions (and their associates):
>
> * tvb_captured_length()
> * tvb_reported_length()
>
> As far as I can tell, tvb_captured_length() is the direct replacement for
> tvb_length() but tvbuff.h says "You probably want tvb_reported_length
> instead.". The use of both seems to be mixed throughout the files and it's
> difficult to follow the relationship between the two. So any guidance on
> this would be appreciated.
>
> Thanks
>
> Robert
>
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] RFC: Internally Generated "Records"

[Evan Huus]

On Tue, Aug 18, 2015 at 10:49 AM, Roland Knall  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.

Evan

> regards,
> Roland
>
> On Tue, Aug 5, 2014 at 12:14 AM, Roland Knall  wrote:
>>
>> Yes, that it what I was saying.
>>
>> Cool, you can look forward to the openSAFETY patch, the minute the change
>> hit the official repo ;-)
>>
>> regards,
>> Roland
>>
>>
>> On Mon, Aug 4, 2014 at 11:51 PM, Evan Huus  wrote:
>>>
>>>
>>> On Aug 4, 2014, at 17:21, Roland Knall  wrote:
>>>
>>>
>>> Am 04.08.2014 um 23:16 schrieb Evan Huus :
>>>
>>>
>>>
>>> On Aug 4, 2014, at 17:11, Roland Knall  wrote:
>>>
>>>
>>>
>>>
>>> On Mon, Aug 4, 2014 at 10:40 PM, Evan Huus  wrote:
>>>>
>>>> Right now you can't filter on field combinations that must appear
>>>> "together" in one of those application frames: if fieldA appears in frame 
>>>> 1,
>>>> and fieldB appears in frame 2, then that packet will match "fieldA &&
>>>> fieldB" even if they never appear "together" in the way a normal human 
>>>> would
>>>> intend. 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 change behavior
>>> of the display filters in a way, the end-user may never see coming. We would
>>> have to come up with a syntax in wireshark, where we allow either "(fieldA
>>> && fieldB)" meaning, record1.fieldA and record2.fieldB or fieldA and fieldB
>>> in the same record. The end-user does not necessarily make that distinction.
>>> If he simply selects frame fields, he may end up with display filters which
>>> do not filter the intended or any packages, but he has no clue why simply
>>> because the display filter interprets the syntax in a way the end-user could
>>> not foresee.
>>>
>>>
>>> Yes, I was thinking some additional syntax like wrapping an expression in
>>> {} or something to indicate it should only match within a single record.
>>>
>>>
>>> It should be the other way around. The new syntax should emphasize the
>>> fact that it should match in different records, otherwise you are going to
>>> break compatibility with the current usability.
>>>
>>>
>>> ?
>>>
>>> Right now we match regardless of records - that should continue to be the
>>> default so that existing display filters don't break. We should introduce a
>>> new syntax for the new feature... Or is that what you are already saying?
>>>
>>>
>>> On the rest, I see your point.
>>>
>>> regards,
>>> Roland
>>>
>>>
>>>
>>> ___
>>> Sent via:Wireshark-dev mailing list 
>>> Archives:http://www.wireshark.org/lists/wireshark-dev
>>> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>>>
>>> mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
>>>
>>>
>>> ___
>>> Sent via:Wireshark-dev mailing list 
>>> Archives:http://www.wireshark.org/lists/wireshark-dev
>>> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>>>
>>> mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
>>>
>>>
>>> ___
>>> Sent via:Wireshark-dev mailing list 
>>> Archives:http://www.wireshark.org/lists/wireshark-dev
>>> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>>>
>>> mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
>>>
>>>
>>>
>>> ___
>>> Sent via:Wireshark-dev mailing list 
>>> Archives:http://www.wireshark.org/lists/wireshark-dev
>>> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>>>
>>> mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
>>
>>
>
>
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Crash during fuzzing

[Evan Huus]

The best way to reproduce fuzzer bugs is with ./tools/test-captures.sh
which sets all the same environment variables and flags as the main
fuzz script.

Since the error was in a memory canary, valgrind and/or ASAN may also
prove useful.

Evan

On Mon, Aug 10, 2015 at 3:52 PM, Dario Lombardo
 wrote:
> Hi list
> II was fuzzing a protocol, and I experienced a crash. The fuzz-test.sh gave
> me this output
>
> $ ../tools/fuzz-test.sh -b run ../data/hpfeed_all_packets_sample.pcap
> [...]
> Starting pass 130:
> ../data/hpfeeds_all_packets_sample.pcap: (-nVxr) (-nr)  OK
> Starting pass 131:
> ../data/hpfeeds_all_packets_sample.pcap: (-nVxr) (-nr)  OK
> Starting pass 132:
> ../data/hpfeeds_all_packets_sample.pcap: (-nVxr) (-nr)  OK
> Starting pass 133:
> ../data/hpfeeds_all_packets_sample.pcap: (-nVxr) ../tools/fuzz-test.sh:
> line 189:  8725 Segmentation fault  (core dumped) "$RUNNER" $COMMON_ARGS
> $ARGS $TMP_DIR/$TMP_FILE > /dev/null 2>> $TMP_DIR/$ERR_FILE
>
>  ERROR
> Processing failed. Capture info follows:
>
>   Input file: ../data/hpfeed_all_packets_sample.pcap
>   Output file: /tmp/fuzz-2015-08-10-7120.pcap
>
> stderr follows:
>
> Input file: ../data/hpfeed_all_packets_sample.pcap
>
> Build host information:
> Linux hardcore 3.13.0-61-generic #100-Ubuntu SMP Wed Jul 29 11:21:34 UTC
> 2015 x86_64 x86_64 x86_64 GNU/Linux
> Distributor ID: Ubuntu
> Description: Ubuntu 14.04.3 LTS
> Release: 14.04
> Codename: trusty
>
> Return value:  139
>
> Dissector bug:  0
>
> Valgrind error count:  0
>
>
>
>
> Command and args: run/tshark -nVxr
>
> **
> ERROR:../epan/wmem/wmem_allocator_strict.c:77:wmem_strict_block_check_canaries:
> assertion failed: (canary[i] == WMEM_CANARY_VALUE)
>
> So I tried to reproduce the error, but when I issued
>
> run/tshark -nVxr /tmp/fuzz-2015-08-10-7120.pcap
>
> no crash happened. Is this the right way to reproduce a bug the fuzzer
> found? If yes, why it is not crashing?
> Thanks for your suggestions.
> Dario.
>
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] unicode replacement character in online docs

[Evan Huus]

On Wed, Aug 5, 2015 at 9:49 AM, Hadriel Kaplan
 wrote:
> Anyone else seeing the unicode replacement character all over the
> online auto-generated docs? (user guide and developer guide)

Yup, and that's new AFAIK. Anybody know if something's change on the
server or on the build bot with respect to character encoding?

Based on the byte-values of something I expect should be a copyright
symbol, it looks like it's using ISO8859-1 and/or Windows-1252.

> I don't recall having seen them there before, though maybe they've
> always been there.
>
> https://www.wireshark.org/docs/wsdg_html_chunked/index.html
> https://www.wireshark.org/docs/wsug_html_chunked/index.html
>
> -hadriel
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] mailing list test

[Evan Huus]

> On Jul 22, 2015, at 02:38, Martin Mathieson 
>  wrote:
> 
> Got this, and didn't need to fish it out of spam this time (where is
> where your yahoo mails live for me).

Ya, something about the way you send from your yahoo account ruins the DKIM 
header so most mail clients auto-spam them and refuse to hear otherwise. I 
actually have a gmail filter just for you to not do a spam check on your 
address :)

> Martin
> 
> On Wed, Jul 22, 2015 at 12:36 AM, Hadriel Kaplan
>  wrote:
>> Testing the list, since emails from my normal account aren't getting
>> through apparently...
>> 
>> -hadriel
>> ___
>> Sent via:Wireshark-dev mailing list 
>> Archives:https://www.wireshark.org/lists/wireshark-dev
>> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>> mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
> mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

[Wireshark-dev] Buildbot Lua Init Tests

[Evan Huus]

The buildbot test suite is currently failing on the lua step, I
believe because Peter's recent init/cleanup split has changed the
number of times the init function is called, which is breaking
expectations in the lua bindings somewhere.

The fix may be as simple as changing the "expected number of calls" in
the test suite, but I'm not sure if there may be other things the lua
bindings use init routines for that also need fixing?

Evan
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] hadoop dissector

[Evan Huus]

On Fri, Jul 3, 2015 at 11:53 AM, Helge  wrote:
> Am Fri, 3 Jul 2015 11:26:08 +0200
> schrieb Pascal Quantin :
>
>> if could go into the master:
>> >
>> > 1) it is written in c++. Would it be acceptable?
>>
>> No for now we are not accepting any C++ dissector.
>>
>> > 2) it uses stl maps. Would it be acceptable or should it be
>> > replaced by
>> some "wmem maps" (maps with custom allocator)?
>>
>> It should be replaced by wmem maps, like all the other C++ code ;)
>>
>
> Well, there may be some rules for dissectors that shall be added the
> the Wireshark master branch. But I just want to note that I wrote all
> of my dissectors "in the wild" (except the first one) in C++.
> Especially the allocators one must be careful and consider the live
> time of the objects. But as long as you build maps at the load time you
> can use the standard allocators.
>
> C++ provides so many features that it would be a waste of time to
> mimic all of them in C.

It's worth noting that wmem is not a replacement for the C++ std
library and allocators, it works somewhat differently due to the
lifetimes that occur naturally in Wireshark (e.g. per-packet lifetime,
etc) and the way exceptions are handled internally to wireshark. We
would need something like wmem in order to avoid memory leaks, even if
we were to write all our dissectors in C++.

> Probably my dissectors won't get to the
> Wireshark master source code. But I can live with my plug-ins. Some of
> them implement a proprietary protocol anyway.
>
> Best regards
> Helge
>
> --
> GnuPG fingerprint: EDCE F8C8 B727 6CC5 7006  05C1 BD3F EADC 8922 1F61
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Qt Interface Profiling

[Evan Huus]

On Fri, Jun 26, 2015 at 7:03 PM, Guy Harris  wrote:
>
> On Jun 26, 2015, at 2:45 PM, Evan Huus  wrote:
>
>> I just ran the Qt interface through callgrind while loading a fairly
>> large capture. Stripping out all the dissector-related expenses, the
>> following two UI functions show up as hot spots:
>>
>> qt_blurImage()
>> This is a Qt internal function for blurring, presumably from the fancy
>> start-up screen, but showed up as *surprisingly* expensive given the
>> fact that the startup screen was only a tiny fraction of the time
>> profiled. Is it possible it's still getting run with a blur factor of
>> 0 on every screen or something?
>
> It sounds, from the documentation, as if callgrind calculates a call graph; 
> does it show who's calling qt_blurImage - from a quick look at the Qt 5.3.2 
> source, it's called from a couple of pixmap routines - and who's calling 
> those routines?

I'll dig into this a bit more, it might just be that my profiling host
doesn't implement any OpenGL, so it's doing software raster which is
expensive

>> PacketListModel::recordLessThan()
>> This is ours, used for sorting the packet list. Not immediately sure
>> how to make it better, the GTK version is entirely different.
>
> What columns do you have in your display?

100% default, so sorted by ID.

> The custom column sort will look up the column's field over and over again, 
> but if you're not using a custom column, that won't be an issue.
>
> For columns that don't come from frame data, it does a string compare, or 
> converts the string column data to a number, which probably does more work 
> than it needs to if the underlying column isn't just a text string.
>
> On the other hand, if you're just *loading* the capture, there shouldn't *be* 
> any sorting - the frames should just be displayed in the order in which 
> they're read!
>
> According to
>
> http://doc.qt.io/qt-4.8/model-view-programming.html
>
> (I'm using 4.8 documentation to avoid making Wireshark 5.x-only, so that it 
> doesn't require the latest shiniest version of $DISTRIBUTION):
>
> There are two ways of approaching sorting in the model/view 
> architecture; which approach to choose depends on your underlying model.
>
> If your model is sortable, i.e, if it reimplements the 
> QAbstractItemModel::sort() function, both QTableView and QTreeView provide an 
> API that allows you to sort your model data programmatically. In addition, 
> you can enable interactive sorting (i.e. allowing the users to sort the data 
> by clicking the view's headers), by connecting the 
> QHeaderView::sortIndicatorChanged() signal to the QTableView::sortByColumn() 
> slot or the QTreeView::sortByColumn() slot, respectively.

I believe we are currently using this approach. Our PacketListModel
implements sort(), which just dispatches to qSort() using
recordLessThan() as the comparator.

> The alternative approach, if your model do not have the required 
> interface or if you want to use a list view to present your data, is to use a 
> proxy model to transform the structure of your model before presenting the 
> data in the view. This is covered in detail in the section on Proxy Models.
>
> That section says:
>
> In the model/view framework, items of data supplied by a single model 
> can be shared by any number of views, and each of these can possibly 
> represent the same information in completely different ways. Custom views and 
> delegates are effective ways to provide radically different representations 
> of the same data. However, applications often need to provide conventional 
> views onto processed versions of the same data, such as differently-sorted 
> views onto a list of items.
>
> Although it seems appropriate to perform sorting and filtering 
> operations as internal functions of views, this approach does not allow 
> multiple views to share the results of such potentially costly operations. 
> The alternative approach, involving sorting within the model itself, leads to 
> the similar problem where each view has to display items of data that are 
> organized according to the most recent processing operation.
>
> To solve this problem, the model/view framework uses proxy models to 
> manage the information supplied between individual models and views. Proxy 
> models are components that behave like ordinary models from the perspective 
> of a view, and access data from source models on behalf of that view. The 
> signals and slots used by the model/view framework ensure that each view is 
> updated appropriately no matter how many proxy 

[Wireshark-dev] Qt Interface Profiling

[Evan Huus]

I just ran the Qt interface through callgrind while loading a fairly
large capture. Stripping out all the dissector-related expenses, the
following two UI functions show up as hot spots:

qt_blurImage()
This is a Qt internal function for blurring, presumably from the fancy
start-up screen, but showed up as *surprisingly* expensive given the
fact that the startup screen was only a tiny fraction of the time
profiled. Is it possible it's still getting run with a blur factor of
0 on every screen or something?

PacketListModel::recordLessThan()
This is ours, used for sorting the packet list. Not immediately sure
how to make it better, the GTK version is entirely different.

Cheers,
Evan
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Autogenerated files in source tree [Was: asn2wrs problem]

[Evan Huus]

On Thu, Jun 25, 2015 at 2:36 PM, Joerg Mayer  wrote:
> On Thu, Jun 25, 2015 at 02:24:05PM -0700, Pascal Quantin wrote:
>> Yeah that's my fault: I did some API change yesterday and did not realize
>> that CREDSSP was an autogenerated dissector. I will fix this in a few
>> minutes.
>
> OK, which brings me back to the topic that we should have as few autogenerated
> dissectors in our source tree as possible. I don't think the additional 
> compile
> time qualifies as a counter argument, and phython is required to build 
> Wireshark
> as well.
>
> So why keep doing that? If it's OK, I'd like to do a PoC patch for asn1.

I'd be happy to see that, I tried once but my build-system skills were
not up to it.

> For those instances where we want to keep the generated dissectors in the 
> source
> tree: Is there a way to prevent accidental changes (i.e. opening the file not 
> at
> the top but at a given line or automated search/replace scripts? Does setting 
> these
> files to read only look like a possible solution?
>
>> Sorry about that,
>
> No problem - I was just testing the new old cmake asn1 generation and it
> gave me the opportunity to once again start this discussion ;-)
> --
> Joerg Mayer   
> We are stuck with technology when what we really want is just stuff that
> works. Some say that should read Microsoft instead of technology.
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Cmake on Yosemite can't find Core Foundation

[Evan Huus]

Hmm, it seems my xcode install had gotten subtly corrupted somehow.
Removing it and re-installing everything made this work.

On Fri, Jun 5, 2015 at 10:17 AM, Evan Huus  wrote:
> Recently wiped away and tried to rebuild my cmake config on my osx
> yosemite machine. Build is now failing with:
>
> /Users/eapache/src/wireshark.org/wireshark/wsutil/cfutils.c:29:10:
> fatal error: 'CoreFoundation/CoreFoundation.h' file not found
> #include 
>
> The complete cc command being run is:
>
> cd /Users/eapache/src/wireshark.org/build/wsutil &&
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc
>  -DG_DISABLE_DEPRECATED -DG_DISABLE_SINGLE_INCLUDES
> -DTOP_SRCDIR=\"/Users/eapache/src/wireshark.org/wireshark\"
> -DWS_BUILD_DLL -Dwsutil_EXPORTS -Wall -W -Wextra -Wendif-labels
> -Wpointer-arith -Warray-bounds -Wformat-security -fwrapv -Wvla
> -Waddress -Wattributes -Wdiv-by-zero -Wignored-qualifiers -Wpragmas
> -Wno-overlength-strings -Wwrite-strings -Wno-long-long -Wheader-guard
> -Wunused-const-variable -Wc++-compat -Wdeclaration-after-statement
> -Wshadow -Wno-pointer-sign -Wold-style-definition -Wstrict-prototypes
> -Wshorten-64-to-32  -fvisibility=hidden -O2 -g -DNDEBUG  -fPIC
> -I/Users/eapache/src/wireshark.org/build
> -I/Users/eapache/src/wireshark.org/wireshark
> -I/Users/eapache/src/wireshark.org/wireshark/epan
> -I/Users/eapache/src/wireshark.org/wireshark/tools/lemon
> -I/Users/eapache/src/wireshark.org/wireshark/wiretap -isystem
> /usr/local/opt/gettext/include -isystem /usr/local/include -isystem
> /usr/local/Cellar/geoip/1.6.5/include -isystem
> /usr/local/Cellar/glib/2.44.1/include/glib-2.0 -isystem
> /usr/local/Cellar/glib/2.44.1/lib/glib-2.0/include -isystem
> /usr/local/include/gtk-2.0 -isystem
> /Library/Frameworks/Mono.framework/Headers/fontconfig -isystem
> /usr/local/include/glib-2.0 -isystem /usr/local/lib/glib-2.0/include
> -isystem /usr/local/include/atk-1.0 -isystem
> /usr/local/include/gdk-pixbuf-2.0 -isystem /usr/local/include/cairo
> -isystem /usr/local/include/pango-1.0 -isystem
> /usr/local/lib/gtk-2.0/include -isystem
> /usr/local/Cellar/portaudio/19.20140130/include-Werror -o
> CMakeFiles/wsutil.dir/cfutils.c.o   -c
> /Users/eapache/src/wireshark.org/wireshark/wsutil/cfutils.c
>
> Anybody know what check is failing? I imagine it's missing an include
> path, since xcode is installed and it was building fine before I blew
> away my cmake build directory.
>
> Thanks,
> Evan
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

[Wireshark-dev] Cmake on Yosemite can't find Core Foundation

[Evan Huus]

Recently wiped away and tried to rebuild my cmake config on my osx
yosemite machine. Build is now failing with:

/Users/eapache/src/wireshark.org/wireshark/wsutil/cfutils.c:29:10:
fatal error: 'CoreFoundation/CoreFoundation.h' file not found
#include 

The complete cc command being run is:

cd /Users/eapache/src/wireshark.org/build/wsutil &&
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc
 -DG_DISABLE_DEPRECATED -DG_DISABLE_SINGLE_INCLUDES
-DTOP_SRCDIR=\"/Users/eapache/src/wireshark.org/wireshark\"
-DWS_BUILD_DLL -Dwsutil_EXPORTS -Wall -W -Wextra -Wendif-labels
-Wpointer-arith -Warray-bounds -Wformat-security -fwrapv -Wvla
-Waddress -Wattributes -Wdiv-by-zero -Wignored-qualifiers -Wpragmas
-Wno-overlength-strings -Wwrite-strings -Wno-long-long -Wheader-guard
-Wunused-const-variable -Wc++-compat -Wdeclaration-after-statement
-Wshadow -Wno-pointer-sign -Wold-style-definition -Wstrict-prototypes
-Wshorten-64-to-32  -fvisibility=hidden -O2 -g -DNDEBUG  -fPIC
-I/Users/eapache/src/wireshark.org/build
-I/Users/eapache/src/wireshark.org/wireshark
-I/Users/eapache/src/wireshark.org/wireshark/epan
-I/Users/eapache/src/wireshark.org/wireshark/tools/lemon
-I/Users/eapache/src/wireshark.org/wireshark/wiretap -isystem
/usr/local/opt/gettext/include -isystem /usr/local/include -isystem
/usr/local/Cellar/geoip/1.6.5/include -isystem
/usr/local/Cellar/glib/2.44.1/include/glib-2.0 -isystem
/usr/local/Cellar/glib/2.44.1/lib/glib-2.0/include -isystem
/usr/local/include/gtk-2.0 -isystem
/Library/Frameworks/Mono.framework/Headers/fontconfig -isystem
/usr/local/include/glib-2.0 -isystem /usr/local/lib/glib-2.0/include
-isystem /usr/local/include/atk-1.0 -isystem
/usr/local/include/gdk-pixbuf-2.0 -isystem /usr/local/include/cairo
-isystem /usr/local/include/pango-1.0 -isystem
/usr/local/lib/gtk-2.0/include -isystem
/usr/local/Cellar/portaudio/19.20140130/include-Werror -o
CMakeFiles/wsutil.dir/cfutils.c.o   -c
/Users/eapache/src/wireshark.org/wireshark/wsutil/cfutils.c

Anybody know what check is failing? I imagine it's missing an include
path, since xcode is installed and it was building fine before I blew
away my cmake build directory.

Thanks,
Evan
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] master-1.10 out-of-memory fuzz failures

[Evan Huus]

And https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=11149 is
potentially the same issue for 1.12 although it seems to have only
happened the once.

On Sat, May 30, 2015 at 10:27 PM, Evan Huus  wrote:
> https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=11147 and its many
> duplicates suggest a similar issue with the master buildbot.
>
> On Sat, May 30, 2015 at 10:22 PM, Jeff Morriss
>  wrote:
>> There have been plenty of fuzz failures from the 1.10 branch in the past few
>> months, including:
>>
>> https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=11050
>> https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=11065
>> https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=11077
>> https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=11090
>> https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=11094
>> https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=11150
>> https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=11239
>>
>> All of the captures associated with those bugs run fine for me.  The last
>> one's error:
>>
>>>
>>> /home/wireshark/builders/wireshark-1.10-fuzz/fuzztest/build/.libs/lt-tshark:
>>> error while loading shared libraries: libwireshark.so.3: failed to map
>>> segment from shared object: Cannot allocate memory
>>
>>
>> really supports the theory that it's not the software that has the problem
>> but the buildbot itself.
>>
>> Is there something wrong with the box?
>>
>> In the mean time I'll close all those bugs as WORKSFORME.
>> ___
>> Sent via:Wireshark-dev mailing list 
>> Archives:https://www.wireshark.org/lists/wireshark-dev
>> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>> mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] master-1.10 out-of-memory fuzz failures

[Evan Huus]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=11147 and its many
duplicates suggest a similar issue with the master buildbot.

On Sat, May 30, 2015 at 10:22 PM, Jeff Morriss
 wrote:
> There have been plenty of fuzz failures from the 1.10 branch in the past few
> months, including:
>
> https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=11050
> https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=11065
> https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=11077
> https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=11090
> https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=11094
> https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=11150
> https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=11239
>
> All of the captures associated with those bugs run fine for me.  The last
> one's error:
>
>>
>> /home/wireshark/builders/wireshark-1.10-fuzz/fuzztest/build/.libs/lt-tshark:
>> error while loading shared libraries: libwireshark.so.3: failed to map
>> segment from shared object: Cannot allocate memory
>
>
> really supports the theory that it's not the software that has the problem
> but the buildbot itself.
>
> Is there something wrong with the box?
>
> In the mean time I'll close all those bugs as WORKSFORME.
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
> mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] [Wireshark-commits] master e16500e: Fix check for NUL at the end of a string.

[Evan Huus]

Argh, one of these days I will learn to just put parentheses in rather
than taking guesses at C operator precedence :(

On Tue, May 12, 2015 at 6:10 PM, Wireshark code review
 wrote:
> URL: 
> https://code.wireshark.org/review/gitweb?p=wireshark.git;a=commit;h=e16500e80f85641b28971498c3fc580eab800055
> Submitter: Guy Harris (g...@alum.mit.edu)
> Changed: branch: master
> Repository: wireshark
>
> Commits:
>
> e16500e by Guy Harris (g...@alum.mit.edu):
>
> Fix check for NUL at the end of a string.
>
> *seq[slength - 1] means *(seq[slength - 1]), where seq points to a
> "const gchar *", so it fetches the pointer at an offset of slength - 1
> from the pointer to which seq points, and dereferences that pointer.
> What's wanted is (*seq)[slength - 1], i.e. fetch the pointer to which
> seq points, and fetch the byte at an offset of slength - 1 from the byte
> to which said pointer points.
>
> Change-Id: I7246f5e6093d035bad59be530893f3fc54dad97e
> Reviewed-on: https://code.wireshark.org/review/8441
> Reviewed-by: Guy Harris 
>
>
> Actions performed:
>
> from  99ca421   Qt: Display filter completion fixes.
> adds  e16500e   Fix check for NUL at the end of a string.
>
>
> Summary of changes:
>  epan/dissectors/packet-giop.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> ___
> Sent via:Wireshark-commits mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-commits
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-commits
>  
> mailto:wireshark-commits-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] proto.h extension

[Evan Huus]

On Fri, May 8, 2015 at 3:09 PM, Guy Harris  wrote:
>
> On May 8, 2015, at 7:06 AM, "John Dill"  wrote:
>
>>> Message: 3
>>> Date: Thu, 7 May 2015 11:29:22 -0700
>>> From: Guy Harris 
>>> To: Developer support list for Wireshark 
>>> Subject: Re: [Wireshark-dev] proto.h extension
>>> Message-ID: 
>>> Content-Type: text/plain; charset=iso-8859-1
>>>
>>> On May 7, 2015, at 8:13 AM, "John Dill"  wrote:
>>>
 I have a couple of extensions that I created for the Wireshark baseline
>>> that we're using (1.10.x).  The diffs to proto.h and proto.c show the code
>>> changes to add a couple of features that I've found useful, unit strings
>>> and hiding the bits for bitmask header fields.

 http://codepad.org/KTGdEL1t
>>>
>>> You need more than
>>>
>>>  /* Following constants have to be ORed with a base_display_e when 
>>> dissector
>>>   * want to control aspects of the display string for a 
>>> header_field_info */
>>>
>>> as a comment there - you need comments explaining what each of those flags 
>>> actually *does*.
>>
>> Guy,
>>
>> Sorry it wasn't clear.  Starting from this snippet...
>>
>> /*
>> * BASE_UNIT_STRING - Append a unit string to the numeric value
>
> That one's reasonable; I've thought of a similar option.
>
>> *
>> * When active, Wireshark will append a unit string declared as a
>> * simple 'char *' for the 'strings' to the numeric value.
>
> You might want to, instead, have it be a structure with a pair of strings, so 
> that if the field has the value 1, you can print the singular rather than the 
> plural, e.g.:
>
> struct unit_names {
> char *singular; /* name to use for 1 unit */
> char *plural;   /* name to use for < 1 or > 1 units */
> };
>
> struct unit_names feet {
> "foot",
> "feet"
> };
>
> {
>  &hf_MFD_State_Data_Slew_Elevation_Ch1,
>  {
>"Slew_Elevation_Ch1",
>"ndo.MFD_State_Data.Slew_Elevation_Ch1",
>FT_FLOAT,
>BASE_NONE | BASE_UNIT_STRING,
>&feet,
>0x0,
>NULL,
>HFILL
>  }
> },
>
> (For floating-point numbers, "1 unit" means "*exactly* 1 unit", i.e. an exact 
> floating-point comparison with 1x2^0.)
>
> We could either
>
> 1) require that both be non-null
>
> or
>
> 2) assume that, if the plural is null, you can pluralize using the 
> standard rules of English.
>
> Does anybody have a preference there?
>
> As the last word of the last item in the list above indicates, that limits 
> the output to English; however, the same applies to, for example
>
> { &hf_ip_hdr_len,
>   { "Header Length", "ip.hdr_len", FT_UINT8, BASE_DEC,
> NULL, 0x0F, NULL, HFILL }},
>
> and I don't expect to see the full names of every single field in Wireshark:
>
> $ ./tshark -G fields | wc -l
>   151035
>
> to be translated to any other language any time soon, and it also applies to
>
> static const value_string ipopt_timestamp_flag_vals[] = {
> {IPOPT_TS_TSONLY,"Time stamps only"  },
> {IPOPT_TS_TSANDADDR, "Time stamp and address"},
> {IPOPT_TS_PRESPEC,   "Time stamps for prespecified addresses"},
> {0,  NULL}};
>
> and translating all value_string tables would also be difficult.
>
> So should we think about localization of the packet summary and detail fields 
> (which would, I suspect, be a huge project), and possibly leave the unit 
> strings open for localization, or not?
>
>> /*
>> * BASE_NO_BITMASK_DISPLAY - Hide the bitfield display of a data
>> *   element.
>> *
>> * In Wireshark, any time the 'bitmask' argument is non-zero, a
>> * bitfield display showing the location of 1's and 0's is
>> * display is shown.  In certain situations, the display of
>> * bitmask fields next to non-bitmask fields is quite jarring
>> * because the display of these bitfields do not align the
>> * data elements in an easy to scan column.
>> *
>> * 1010  Data Element 1
>> *  0101 Data Element 2
>> * Data Element 3
>
> Presumably that would be used by people who don't care enough about the 
> individual bits of the octet(s) to be willing to sacrifice that for having 
> the elements line up.
>
> That might depend on the protocol, with protocols doing more bit-packing 
> being more likely to have a mix of octet-aligned and non-octet-aligned 
> fields.  Presumably avionics has some low-bit-rate links and needs to do more 
> bit-packing; I think some telephony protocols have the same issue - that 
> might be why ASN.1 PER was created.
>
> So is this something that should be done on a per-field basis, as a 
> preference, or both?

It would be simpler and smarter if we just accounted for the fact when
aligning fields: if a field does not have a bitmask, but something
above/below it (in the same tree) does then indent it with the
appropriate number of spaces.
___
Sent via:Wireshark-dev mailing l

Re: [Wireshark-dev] [Wireshark-commits] master 9b5a09a: [Automatic update for 2015-04-26]

[Evan Huus]

Now that the translation files are being updated every week, we really
need to remove the binary files from the repo. I know it's been
discussed before, but anybody with a working qt-dev installation
should be able to generate the .qm files from the .ts files, yes?

On Sun, Apr 26, 2015 at 11:07 AM, Wireshark code review
 wrote:
> URL: 
> https://code.wireshark.org/review/gitweb?p=wireshark.git;a=commit;h=9b5a09aa3479b56b111439222397f239b477cda8
> Submitter: Gerald Combs (ger...@wireshark.org)
> Changed: branch: master
> Repository: wireshark
>
> Commits:
>
> 9b5a09a by Gerald Combs (ger...@wireshark.org):
>
> [Automatic update for 2015-04-26]
>
> Update manuf, services enterprise-numbers, translations, and other items.
>
> Change-Id: I431063783434a6f7a9a4f4b8186316ed3f98005b
> Reviewed-on: https://code.wireshark.org/review/8199
> Reviewed-by: Gerald Combs 
>
>
> Actions performed:
>
> from  0437280   C15ch: fix o previous prototype for function 
> [-Wmissing-prototypes]
> adds  9b5a09a   [Automatic update for 2015-04-26]
>
>
> Summary of changes:
>  epan/dissectors/usb.c|   76 ++---
>  epan/enterprise-numbers  |  116 +++-
>  epan/sminmpec.c  |   30 -
>  manuf|   46 +++-
>  services |   18 +--
>  ui/qt/wireshark_it.qm|  Bin 239430 -> 239746 bytes
>  ui/qt/wireshark_it.ts|4 +-
>  ui/qt/wireshark_zh_CN.qm |  Bin 173107 -> 173233 bytes
>  ui/qt/wireshark_zh_CN.ts |  272 
> +++---
>  9 files changed, 398 insertions(+), 164 deletions(-)
> ___
> Sent via:Wireshark-commits mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-commits
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-commits
>  
> mailto:wireshark-commits-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Gerrit upgrade schedule

[Evan Huus]

Hi Gerald, I'm looking forward to the new Gerrit! I note in the 2.9
release notes that the bugzilla integration has been rewritten;
hopefully that migration goes smoothly.

Evan

On Wed, Apr 1, 2015 at 7:06 PM, Gerald Combs  wrote:
> As was discussed last month, Google's OpenID is going away on the 20th.
> Logins to code.wireshark.org using Google will break on that date. The
> Gerrit development team has been busy making releases recently to account
> for this. Unfortunately, a change which would allow both OpendID and OAuth2
> logins[1] and which would be useful in our case is still under review and
> hasn't made it into an official release.
>
> This Friday (April 3) I plan on upgrading to Gerrit from 2.8.6.1 to 2.10.2.
> This will make the "new change screen" the default along with many other
> changes listed in [2] and [3]. The authentication configuration will not
> change for now, but we'll be in a better position to do so in the future.
>
> Sorry for the short notice. I'm trying to balance Gerrit's release
> schedule, the impending OpenID apocalypse, and upcoming travel.
>
>
> [1]https://gerrit-review.googlesource.com/#/c/66313/
> [2]http://gerrit-documentation.storage.googleapis.com/ReleaseNotes/ReleaseNotes-2.9.html#_new_features
> [3]http://gerrit-documentation.storage.googleapis.com/ReleaseNotes/ReleaseNotes-2.9.html#_new_features
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] enum preferences vs Go Fish

[Evan Huus]

On Mon, Mar 16, 2015 at 4:19 PM,   wrote:
> The SocketCan dissector has an enumerated preference to pick its
> subdissector, manually finding all enumerated options through
> find_dissector().  This doesn't work well for plugins and they are not going
> to modify enum preference source as the whole point is to not have to modify
> Wireshark source to get a plugin to work.
>
> So I feel I have a few choices:
> 1. Change enumeration to "string" preference to have user put it dissector
> by name.  I think this requires too much intimate knowledge of Wireshark and
> results in "Go Fish" (either to get the dissector name right or incorrectly
> trying to dissect protocols that don't run over CAN)
> 2. I'd like a dissector table with for the dissectors to register with
> dissector_add_for_decode_as (there is no "value" that distinguishes
> subdissectors), but that either leaves the enum preference "useless" or it
> just gets in the way of Decode As (which seems like the proper place for
> this all along).  And I can't seem to figure out how I would populate a enum
> list with the dissectors in time to register the preference.
>
> Is there a best/preferred solution for this?  I'm leaning towards just
> removing the enum preference in favor of strictly using Decode As (and using
> User Specific Decodes as any notion of a "saved" preference)

+1

If I remember correctly, Wireshark Qt saves Decode As settings by
default anyways.
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] My recent build of Wireshark from the master branch consumes 99-100% of the CPU

[Evan Huus]

I believe there is a known issue with the Qt auto-scroll feature that
is being investigated.

Evan

On Tue, Mar 10, 2015 at 11:15 PM, Richard Sharpe
 wrote:
> Hi,
>
> Has anyone else experienced this?
>
> What causes it?
>
> --
> Regards,
> Richard Sharpe
> (何以解憂？唯有杜康。--曹操)
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Will there be a 1.99.3 release soon?

[Evan Huus]

P.S. Practically there isn't much real difference between those
releases and the ones available via
https://www.wireshark.org/download/automated/ - if you need a more
recent pre-built version in the mean time that's probably where you
should go.

On Wed, Mar 4, 2015 at 5:08 PM, Evan Huus  wrote:
> Gerald might have one in mind, but typically we seem to be hitting
> about 2 months between dev snapshots. 1.99.2 was released at the
> beginning of February, so that suggests to me around the beginning of
> April.
>
> Evan
>
> On Wed, Mar 4, 2015 at 5:06 PM, Richard Sharpe
>  wrote:
>> Hi folks,
>>
>> Is there a schedule for a 1.99.3 release?
>>
>> --
>> Regards,
>> Richard Sharpe
>> (何以解憂？唯有杜康。--曹操)
>> ___
>> Sent via:Wireshark-dev mailing list 
>> Archives:http://www.wireshark.org/lists/wireshark-dev
>> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>>  mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Will there be a 1.99.3 release soon?

[Evan Huus]

Gerald might have one in mind, but typically we seem to be hitting
about 2 months between dev snapshots. 1.99.2 was released at the
beginning of February, so that suggests to me around the beginning of
April.

Evan

On Wed, Mar 4, 2015 at 5:06 PM, Richard Sharpe
 wrote:
> Hi folks,
>
> Is there a schedule for a 1.99.3 release?
>
> --
> Regards,
> Richard Sharpe
> (何以解憂？唯有杜康。--曹操)
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Make CMake reuse Makefile.common?

[Evan Huus]

On Wed, Mar 4, 2015 at 2:04 PM, Jeff Morriss  wrote:
> On 03/04/15 11:55, Graham Bloice wrote:
>>
>> On 4 March 2015 at 16:44, Jeff Morriss > > wrote:
>>
>> On 03/04/15 04:07, Michal Labedzki wrote:
>>
>> On 03/03/15 11:50, Alexis La Goutte wrote:
>>
>> And also if i remember the target is only have CMake for
>> build system
>> (and remove autofoo...)
>>
>>
>> I hope there will be only CMake in near future (imply remove
>> autotools). As I know cmake aka build systems working for all
>> platforms. What about remove building part of autotools, use
>> cmake for
>> that and use autotools for other tasks?
>>
>>
>> It may work but last I checked it didn't work too well: there's a
>> bunch of stuff that works when running from an autotools build
>> directory that doesn't from a cmake directory.  And it doesn't
>> appear many people have been working on that.
>>
>>
>> Maybe that should be enumerated somewhere.  I've only built (off
>> Windows) on Ubuntu using CMake and it worked for me.  On Windows there
>> are a few bits left to finish off, but I think the nmake usage is coming
>> to an end.
>
>
> It generally works it's just missing features.  A bunch are documented in
> README.cmake but not all.  For example I think Evan found that the test
> suite--at least the Lua portion--don't work in cmake builds; I fixed that in
> autotools (starting with https://code.wireshark.org/review/3348) but I don't
> think anyone has touched the cmake part (I gave up even thinking about cmake
> a while ago).

Yes, the last time I checked the lua test suite on an out-of-tree
cmake build failed because it couldn't find the right init.lua file.
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Menagerie

[Evan Huus]

Sorry, after Chris's concerns I took it down until we could get a final answer 
there, just to be safe.

Gerald would have to be the one to expose it via anything other than a torrent, 
I think, since he controls the website. He also probably knows more about the 
privacy restrictions on those files...

The fastest way to get a decent menagerie right now might be to write a script 
that scrapes all public bugzilla attachments... That's where the majority of 
our menagerie comes from anyways.

Evan

> On Mar 2, 2015, at 05:42, Dario Lombardo  wrote:
> 
> Evan,
> I'm not still able to download the torrent. Anyone tried and succeded?
> Can't the daily menagerie be exposed via a more convenient interface like 
> http? I don't think the generated traffic would flood the server, especially 
> if the files are compressed in a tar.bz2 or a zip.
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
> mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Undissected reserved fields

[Evan Huus]

Should Wireshark have an internal _ws.reserved FT_BYTES field and a
proto_tree_add_reserved(tvb, offset, len) API?

On Fri, Feb 27, 2015 at 2:36 PM, Jeff Morriss  wrote:
> +1
>
> On 02/27/15 14:04, mman...@netscape.net wrote:
>>
>> What I've done is usually setup a FT_UINT32 and/or a FT_BYTES (with
>> different abbreviations) and that's usually inclusive enough (maybe if
>> I'm feeling generous setup a FT_UINT8 though FT_UINT32).  If dissectors
>> only have FT_UINT8 "reserved" fields, then I just add that.  But I
>> rarely look to give each reserved field a unique name.
>> -Original Message-
>> From: Graham Bloice 
>> To: Developer support list for Wireshark 
>> Sent: Fri, Feb 27, 2015 1:43 pm
>> Subject: Re: [Wireshark-dev] Undissected reserved fields
>>
>> How do we handle the case where a protocol has many reserved fields, do
>> they each need an hf and a name?
>
>
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
> mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Menagerie

[Evan Huus]

On Fri, Feb 27, 2015 at 10:20 AM, Christopher Maynard
 wrote:
> Evan Huus  writes:
>
>> I have a local copy that I grabbed by logging into the host server -
>> I've created a torrent of it (attached) which I am currently seeding,
>> so you should be able to grab it from me (and if you do, please seed
>> to others in return!).
>>
>> Gerald hopefully this is OK, as far as I know all of the relevant
>> captures are publicly available on Bugzilla or the wiki anyways.
>>
>> Evan
>>
>> P.S. This is a snapshot of the menagerie as of today, of course.
>
> I believe some of the capture files have been marked as "private" and should
> not be distributed.  At the very least, I would recommend holding off on
> publishing any torrent until that can be verified.

They are still publicly exposed every time the fuzz-bot finds a bug in
our dissection of one of them (unless it knows which ones those are,
and files the bugs as core-only)?

If they are truly private, they should be moved to a separate part of
the menagerie that is not fuzzed regularly.

> Also, some time ago, the folks at cloudshark offered a cloudshark appliance
> to the Wireshark project.  I would much rather see Wireshark take advantage
> of something like that than making the menagerie capture files in a way such
> as this or how Jakub did years ago.

That would certainly be more convenient.

> - Chris
>
> See also: http://goo.gl/oixnSm
>
>
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Menagerie

[Evan Huus]

1.8 GB

I think it's a routing problem, not a torrent problem, I probably need
to open a hole in my firewall or something. I'm at work now anyways,
so I'll look at it again tonight unless somebody beats me to it.

Evan

On Fri, Feb 27, 2015 at 9:07 AM, Dario Lombardo
 wrote:
> Should be supported by your torrent client (maybe create torrent or
> something). Once you succeded, send us the torrent.
> How large it is?
>
> On Fri, Feb 27, 2015 at 2:42 PM, Evan Huus  wrote:
>>
>> Although it seems it's not working for me to download on my laptop - I
>> need to figure out how to properly create/host/seed a torrent I
>> guess...
>>
>> Evan
>>
>> On Fri, Feb 27, 2015 at 8:26 AM, Evan Huus  wrote:
>> > I have a local copy that I grabbed by logging into the host server -
>> > I've created a torrent of it (attached) which I am currently seeding,
>> > so you should be able to grab it from me (and if you do, please seed
>> > to others in return!).
>> >
>> > Gerald hopefully this is OK, as far as I know all of the relevant
>> > captures are publicly available on Bugzilla or the wiki anyways.
>> >
>> > Evan
>> >
>> > P.S. This is a snapshot of the menagerie as of today, of course.
>> >
>> > On Fri, Feb 27, 2015 at 8:00 AM, Dario Lombardo
>> >  wrote:
>> >> On Fri, Feb 27, 2015 at 1:55 PM, Evan Huus  wrote:
>> >>>
>> >>>
>> >>> I'm not sure if there is a more convenient way to download the entire
>> >>> menagerie available to the general public.
>> >>
>> >>
>> >> Who can know that? Gerald maybe? It would be very useful when
>> >> conducting
>> >> large scale tests to have access to a local copy of them, just like the
>> >> buildbot.
>> >>
>> >>
>> >> ___
>> >> Sent via:Wireshark-dev mailing list 
>> >> Archives:http://www.wireshark.org/lists/wireshark-dev
>> >> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>> >>
>> >> mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
>>
>> ___
>> Sent via:Wireshark-dev mailing list 
>> Archives:http://www.wireshark.org/lists/wireshark-dev
>> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>>
>> mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
>
>
>
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Menagerie

[Evan Huus]

Although it seems it's not working for me to download on my laptop - I
need to figure out how to properly create/host/seed a torrent I
guess...

Evan

On Fri, Feb 27, 2015 at 8:26 AM, Evan Huus  wrote:
> I have a local copy that I grabbed by logging into the host server -
> I've created a torrent of it (attached) which I am currently seeding,
> so you should be able to grab it from me (and if you do, please seed
> to others in return!).
>
> Gerald hopefully this is OK, as far as I know all of the relevant
> captures are publicly available on Bugzilla or the wiki anyways.
>
> Evan
>
> P.S. This is a snapshot of the menagerie as of today, of course.
>
> On Fri, Feb 27, 2015 at 8:00 AM, Dario Lombardo
>  wrote:
>> On Fri, Feb 27, 2015 at 1:55 PM, Evan Huus  wrote:
>>>
>>>
>>> I'm not sure if there is a more convenient way to download the entire
>>> menagerie available to the general public.
>>
>>
>> Who can know that? Gerald maybe? It would be very useful when conducting
>> large scale tests to have access to a local copy of them, just like the
>> buildbot.
>>
>> ___
>> Sent via:Wireshark-dev mailing list 
>> Archives:http://www.wireshark.org/lists/wireshark-dev
>> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>>  mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Menagerie

[Evan Huus]

The menagerie consists mostly of files uploaded to bugzilla. Captures attached 
to bug tickets are automatically added to the menagerie, and most files in the 
menagerie can be downloaded from a bug report somewhere.

I'm not sure if there is a more convenient way to download the entire menagerie 
available to the general public. Adding files is as easy as filing a dummy bug 
and attaching files to that.

> On Feb 27, 2015, at 05:41, Dario Lombardo  wrote:
> 
> Browsing the buildbot site, I've read somewhere about menagerie. I suppose it 
> is a large set of file that is used as regression test. 
> Is it correct? Is it possible to download it? And to upload new samples to it?
> Thanks.
> Dario.
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
> mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Google deprecating OpenID 2.0

[Evan Huus]

>From the looks of it [1] Gerrit upstream is planning to just drop
support for logging in with Google.

[1] https://code.google.com/p/gerrit/issues/detail?id=2715

On Sun, Feb 22, 2015 at 9:01 AM, Graham Bloice
 wrote:
> See https://developers.google.com/accounts/docs/OpenID
>
> Does this affect our use of Gerrit if we use a Google account to
> authenticate?
>
> --
> Graham Bloice
>
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] The RSVD dissector and 32-bit builds ...

[Evan Huus]

On Mon, Feb 16, 2015 at 10:08 AM, Richard Sharpe
 wrote:
> On Mon, Feb 16, 2015 at 6:55 AM, Evan Huus  wrote:
>> Create the wmem_map using g_int64_equal instead of g_direct_equal and
>> wmem_int64_hash instead of g_direct_hash. Create a wmem_file_scope()
>> copy of the key, and pass the resulting pointer to the insert
>> function.
>
> Hmmm, why do we need a wmem_file_scope() copy of the key? We get the
> key in each request and response and I don't store the key anywhere.

The map itself has to store the key in order to use it for future
lookups. When the key is only 32 bits you can make the pointer itself
store the key, and since the pointer gets copied you don't need an
explicit copy of the key. But when the pointer is just a pointer, you
need a file-scope copy of the key.
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] The RSVD dissector and 32-bit builds ...

[Evan Huus]

Create the wmem_map using g_int64_equal instead of g_direct_equal and
wmem_int64_hash instead of g_direct_hash. Create a wmem_file_scope()
copy of the key, and pass the resulting pointer to the insert
function.

Evan

On Mon, Feb 16, 2015 at 9:31 AM, Richard Sharpe
 wrote:
> Hi,
>
> Guy has identified a problem with my handling of SCSI dissection in
> the RSVD dissector.
>
> I am using a 64-bit value as the key for a wmem_map_insert and this
> will not work on 32-bit systems.
>
> Having looked at the key values some more what it seems that Windows
> is doing here is taking a 32-bit thread-ID and a 32-bit SCSI request
> number and concatenating them. The one capture I have shows that I
> cannot simply use either half of the 32-bit value.
>
> Perhaps I need to hash the two halves into a 32-bit value.
>
> Does anyone have a suggestion?
>
> --
> Regards,
> Richard Sharpe
> (何以解憂？唯有杜康。--曹操)
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Making gcc less pedantic

[Evan Huus]

The last time something like this came up (admittedly a while ago)
somebody dug up a compiler we still wanted to support that only knew
about C90 - we left the current state of things so we'd catch
incompatibilities with that toolchain.

I'm kind of hoping that's no longer a concern :)

On Fri, Feb 13, 2015 at 3:54 PM, Gerald Combs  wrote:
> Would it make sense to make gcc's "-pedantic" warnings a bit less
> pedantic, e.g. with "-std=c99"? One of my recent commits changed the
> type of a bit field from unsigned int to an enum, which results in the
> following warning:
>
> ../epan/frame_data.h:75:5: warning: type of bit-field 'encoding' is a
> GCC extension [-Wpedantic]
>  packet_char_enc encoding: 1; /**< Character encoding (ASCII,
> EBCDIC...) */
>  ^
>
> In this particular case having a "packet_char_enc" encoding instead of
> an "unsigned int" encoding is useful, otherwise you have to cast back to
> packet_char_enc further down the line. It also compiles under Clang,
> Visual C++, and Solaris Studio without warning.
>
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] [Wireshark-commits] master 5b62526: OK, try cmake -E copy.

[Evan Huus]

A combination of `make clean`, `rm -rf run`, and `cmake .` seems to
have done the trick, thanks for the suggestions.

On Fri, Feb 6, 2015 at 12:25 PM, Gerald Combs  wrote:
> Can you try building from scratch? This might be due to g2cae320 and
> gdeabe64, which enabled then disabled running osx-app.sh on the
> application bundle. osx-app.sh runs macdeployqt and install_name_tool,
> both of which rewrite library paths.
>
> I was hoping to bring the OS X build in line with the Windows build,
> which is 1) portable, and 2) impervious to QTBUG-15234. Unfortunately
> osx-app.sh slows down the build and leaves wireshark-gtk unusable.
>
> [1] Qt loads shared libraries from hard-coded paths.
> https://bugreports.qt.io/browse/QTBUG-15234.
>
> On 2/6/15 7:21 AM, Evan Huus wrote:
>> The last few days (possibly correlating with this commit or with some
>> other cmake change) my out-of-tree cmake build on OSX has failed to
>> launch the qt gui:
>>
>> ---
>> Application Specific Information:
>> abort() called
>>
>> Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
>> 0   libsystem_kernel.dylib0x7fff8c7b6286 __pthread_kill + 10
>> 1   libsystem_c.dylib 0x7fff8e5aab53 abort + 129
>> 2   org.qt-project.QtCore 0x0001140a9159
>> qt_message_fatal(QtMsgType, QMessageLogContext const&, QString const&)
>> + 9
>> 3   org.qt-project.QtCore 0x0001140aa611
>> QMessageLogger::fatal(char const*, ...) const + 161
>> 4   org.qt-project.QtGui  0x000113afb307
>> QGuiApplicationPrivate::createPlatformIntegration() + 6359
>> 5   org.qt-project.QtGui  0x000113afb32b
>> QGuiApplicationPrivate::createEventDispatcher() + 27
>> 6   org.qt-project.QtCore 0x0001142c4b11
>> QCoreApplication::init() + 113
>> 7   org.qt-project.QtCore 0x0001142c4a87
>> QCoreApplication::QCoreApplication(QCoreApplicationPrivate&) + 39
>> 8   org.qt-project.QtGui  0x000113af879e
>> QGuiApplication::QGuiApplication(QGuiApplicationPrivate&) + 14
>> 9   org.qt-project.QtWidgets  0x0001131cf3be
>> QApplication::QApplication(int&, char**, int) + 206
>> 10  org.wireshark.Wireshark   0x00010dedb7d1
>> WiresharkApplication::WiresharkApplication(int&, char**) + 33
>> (wireshark_application.cpp:478)
>> 11  org.wireshark.Wireshark   0x00010dd39512 main + 690
>> (wireshark-qt.cpp:629)
>> 12  libdyld.dylib 0x7fff8d2125c9 start + 1
>> ---
>>
>> When I launch it by hand:
>>
>> ---
>> objc[16899]: Class NotificationReceiver is implemented in both
>> /usr/local/opt/qt5/lib/QtWidgets.framework/Versions/5/QtWidgets and
>> /Users/eapache/src/wireshark.org/build/run/Wireshark.app/Contents/Frameworks/QtWidgets.framework/Versions/5/QtWidgets.
>> One of the two will be used. Which one is undefined.
>> objc[16899]: Class QCocoaPageLayoutDelegate is implemented in both
>> /usr/local/opt/qt5/lib/QtPrintSupport.framework/Versions/5/QtPrintSupport
>> and 
>> /Users/eapache/src/wireshark.org/build/run/Wireshark.app/Contents/Frameworks/QtPrintSupport.framework/Versions/5/QtPrintSupport.
>> One of the two will be used. Which one is undefined.
>> objc[16899]: Class QCocoaPrintPanelDelegate is implemented in both
>> /usr/local/opt/qt5/lib/QtPrintSupport.framework/Versions/5/QtPrintSupport
>> and 
>> /Users/eapache/src/wireshark.org/build/run/Wireshark.app/Contents/Frameworks/QtPrintSupport.framework/Versions/5/QtPrintSupport.
>> One of the two will be used. Which one is undefined.
>> QObject::moveToThread: Current thread (0x7fcaf9d1c9f0) is not the
>> object's thread (0x7fcaf9c1e380).
>> Cannot move to target thread (0x7fcaf9d1c9f0)
>>
>> On Mac OS X, you might be loading two sets of Qt binaries into the
>> same process. Check that all plugins are compiled against the right Qt
>> binaries. Export DYLD_PRINT_LIBRARIES=1 and check that only one set of
>> binaries are being loaded.
>> This application failed to start because it could not find or load the
>> Qt platform plugin "cocoa".
>>
>> Available platform plugins are: cocoa.
>>
>> Reinstalling the application may fix this problem.
>> ---
>>
>> So it looks like the build is now copying files into the frameworks
>> folder and the app doesn't know which lib to pick?
>>
>> On Wed, Feb 4, 2015 at 7:47 PM, Wireshark code review
>>  wrote:
>>> URL: 
>>> https://code.wireshark.org/review/gitweb?p=wires

Re: [Wireshark-dev] [Wireshark-commits] master 5b62526: OK, try cmake -E copy.

[Evan Huus]

The last few days (possibly correlating with this commit or with some
other cmake change) my out-of-tree cmake build on OSX has failed to
launch the qt gui:

---
Application Specific Information:
abort() called

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libsystem_kernel.dylib0x7fff8c7b6286 __pthread_kill + 10
1   libsystem_c.dylib 0x7fff8e5aab53 abort + 129
2   org.qt-project.QtCore 0x0001140a9159
qt_message_fatal(QtMsgType, QMessageLogContext const&, QString const&)
+ 9
3   org.qt-project.QtCore 0x0001140aa611
QMessageLogger::fatal(char const*, ...) const + 161
4   org.qt-project.QtGui  0x000113afb307
QGuiApplicationPrivate::createPlatformIntegration() + 6359
5   org.qt-project.QtGui  0x000113afb32b
QGuiApplicationPrivate::createEventDispatcher() + 27
6   org.qt-project.QtCore 0x0001142c4b11
QCoreApplication::init() + 113
7   org.qt-project.QtCore 0x0001142c4a87
QCoreApplication::QCoreApplication(QCoreApplicationPrivate&) + 39
8   org.qt-project.QtGui  0x000113af879e
QGuiApplication::QGuiApplication(QGuiApplicationPrivate&) + 14
9   org.qt-project.QtWidgets  0x0001131cf3be
QApplication::QApplication(int&, char**, int) + 206
10  org.wireshark.Wireshark   0x00010dedb7d1
WiresharkApplication::WiresharkApplication(int&, char**) + 33
(wireshark_application.cpp:478)
11  org.wireshark.Wireshark   0x00010dd39512 main + 690
(wireshark-qt.cpp:629)
12  libdyld.dylib 0x7fff8d2125c9 start + 1
---

When I launch it by hand:

---
objc[16899]: Class NotificationReceiver is implemented in both
/usr/local/opt/qt5/lib/QtWidgets.framework/Versions/5/QtWidgets and
/Users/eapache/src/wireshark.org/build/run/Wireshark.app/Contents/Frameworks/QtWidgets.framework/Versions/5/QtWidgets.
One of the two will be used. Which one is undefined.
objc[16899]: Class QCocoaPageLayoutDelegate is implemented in both
/usr/local/opt/qt5/lib/QtPrintSupport.framework/Versions/5/QtPrintSupport
and 
/Users/eapache/src/wireshark.org/build/run/Wireshark.app/Contents/Frameworks/QtPrintSupport.framework/Versions/5/QtPrintSupport.
One of the two will be used. Which one is undefined.
objc[16899]: Class QCocoaPrintPanelDelegate is implemented in both
/usr/local/opt/qt5/lib/QtPrintSupport.framework/Versions/5/QtPrintSupport
and 
/Users/eapache/src/wireshark.org/build/run/Wireshark.app/Contents/Frameworks/QtPrintSupport.framework/Versions/5/QtPrintSupport.
One of the two will be used. Which one is undefined.
QObject::moveToThread: Current thread (0x7fcaf9d1c9f0) is not the
object's thread (0x7fcaf9c1e380).
Cannot move to target thread (0x7fcaf9d1c9f0)

On Mac OS X, you might be loading two sets of Qt binaries into the
same process. Check that all plugins are compiled against the right Qt
binaries. Export DYLD_PRINT_LIBRARIES=1 and check that only one set of
binaries are being loaded.
This application failed to start because it could not find or load the
Qt platform plugin "cocoa".

Available platform plugins are: cocoa.

Reinstalling the application may fix this problem.
---

So it looks like the build is now copying files into the frameworks
folder and the app doesn't know which lib to pick?

On Wed, Feb 4, 2015 at 7:47 PM, Wireshark code review
 wrote:
> URL: 
> https://code.wireshark.org/review/gitweb?p=wireshark.git;a=commit;h=5b6252654f173a79e5f4c31f9d584cc3870df1da
> Submitter: Guy Harris (g...@alum.mit.edu)
> Changed: branch: master
> Repository: wireshark
>
> Commits:
>
> 5b62526 by Guy Harris (g...@alum.mit.edu):
>
> OK, try cmake -E copy.
>
> It didn't fail with cp, so maybe that's just random luck, or maybe the
> built-in copy functions have an issue, or maybe just copy_if_different
> has an issue (64-bit inode number issues?).  Try just copy, and see what
> happens.
>
> Change-Id: I84abf3846af9305c19ad4a78d5c9df31b1e1e61e
> Reviewed-on: https://code.wireshark.org/review/6961
> Reviewed-by: Guy Harris 
>
>
> Actions performed:
>
> from  a2e48c6   On OS X, temporarily use cp to install some files.
> adds  5b62526   OK, try cmake -E copy.
>
>
> Summary of changes:
>  CMakeLists.txt |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> ___
> Sent via:Wireshark-commits mailing list 
> Archives:http://www.wireshark.org/lists/wireshark-commits
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-commits
>  
> mailto:wireshark-commits-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Undissected packet bytes

[Evan Huus]

Please just upload it Gerrit - it's much easier to review there. You
can upload it as a draft (pass the -D flag to git-review) if you want
to avoid cluttering up the main review list yet.

On Thu, Feb 5, 2015 at 11:49 AM, Dario Lombardo
 wrote:
> Evan,
> please find attached a patch that implements what I was trying to do. I'd
> like to share it here with you and other devels in order to understand if it
> goes in the right direction and maybe to open discussions on it. If it seems
> good, I'll move it to gerrit for code review.
>
> To test it, simply comment any proto_tree_add_item() from a dissector of
> your choice, and open a packet with wireshark or with tshark -V.
>
> Comments are welcome.
> Dario.
>
> On Thu, Feb 5, 2015 at 1:41 PM, Dario Lombardo 
> wrote:
>>
>> On Thu, Feb 5, 2015 at 1:19 PM, Evan Huus  wrote:
>>>
>>> I believe g_log and friends go to standard out, but maybe not on all
>>> platforms. An expert info under conditional compilation would probably
>>> be enough though, I hadn't thought of that.
>>
>>
>> Another question. I've found a promising point to put the check
>> (packet.c:call_dissector_with_data()). This function is called many times (I
>> can count 4 times per packet). Sometimes when tree is open, sometimes when
>> it's closed. How can I navigate (and check) the tree only and only if it's
>> open?
>> Only in this case I can check if there are undecoded bytes.
>
>
>
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] [Wireshark-commits] out-of-tree plugins (Was: master 2bcd38f: ethercat: add default case in FoeFormatter)

[Evan Huus]

On Thu, Feb 5, 2015 at 9:41 AM, Jeff Morriss  wrote:
> On 02/05/15 03:51, Wireshark code review wrote:
>>
>> URL:
>> https://code.wireshark.org/review/gitweb?p=wireshark.git;a=commit;h=2bcd38fec409357d463193b55cecc446b5065b3f
>> Submitter: Anders Broman (a.broma...@gmail.com)
>> Changed: branch: master
>> Repository: wireshark
>>
>> Commits:
>>
>> 2bcd38f by Evan Huus (eapa...@gmail.com):
>>
>>  ethercat: add default case in FoeFormatter
>>
>>  Should probably fix an unintialized memory access caught by valgrind,
>> although I
>>  can't reproduce it because out-of-tree plugins are still broken.
>
>
> ... in cmake.  Just upgrade to autotools and you'll be better off. ;-) (In
> autotools almost everything works out-of-tree including plugins, Lua taps,
> and who knows what else.)
>
> Seriously, though, just keep 2 build directories around: I use _build/ for
> autotools builds and _build_cmake for cmake builds (for those rare times
> when I want to try something in cmake--or at least make sure I didn't break
> something).

I've been trying to fight through the pain in order to force myself to
fix the cmake pain points, but I don't know how to fix this one :P
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Undissected packet bytes

[Evan Huus]

I believe g_log and friends go to standard out, but maybe not on all
platforms. An expert info under conditional compilation would probably
be enough though, I hadn't thought of that.

On Thu, Feb 5, 2015 at 5:49 AM, Dario Lombardo
 wrote:
> On Wed, Feb 4, 2015 at 7:28 PM, Evan Huus  wrote:
>>
>> I suppose you could add a an expert info, but I think that might be
>> overkill, most users probably don't care that much.
>
>
> Expert infos could be added under conditional compilation. If enabled it
> would allow to filter packets that has expert info set, in order to find out
> incomplete dissectors against a large set of data (eg. menagerie).
>
>>
>> You could just log
>> it, or dissect it as data, or...
>
>
> You mean using g_log, don't you? Where those logs go? I'm not able to show
> them.
>
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Undissected packet bytes

[Evan Huus]

I suppose you could add a an expert info, but I think that might be
overkill, most users probably don't care that much. You could just log
it, or dissect it as data, or...

On Wed, Feb 4, 2015 at 11:58 AM, Dario Lombardo
 wrote:
> On Wed, Feb 4, 2015 at 5:25 PM, Evan Huus  wrote:
>>
>> I think you will need to add a function very similar to
>> proto_find_field_from_offset that makes use of
>> proto_tree_traverse_pre_order and tracks which bytes have been "seen"
>> as the traversal proceeds.
>
>
> And how the output could be shown to the user? With expert infos?
>
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Undissected packet bytes

[Evan Huus]

I think you will need to add a function very similar to
proto_find_field_from_offset that makes use of
proto_tree_traverse_pre_order and tracks which bytes have been "seen"
as the traversal proceeds.

On Wed, Feb 4, 2015 at 11:22 AM, Dario Lombardo
 wrote:
> On Wed, Feb 4, 2015 at 3:52 PM, Evan Huus  wrote:
>>
>>
>> As a side note, I would expect that method to be *very* slow, since it
>> traverses the entire tree for every byte of the packet. Traversing the
>> tree once and maintaining a set of covered/uncovered ranges would be
>> much more efficient.
>
>
> I can't figure out how to traverse the tree once.
>
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] [Wireshark-commits] master 7ced085: emem is dead! Long live wmem!

[Evan Huus]

Wmem does not use canaries under normal operation, but if you choose
the strict allocator (which the fuzz script, among others, does
automatically) then that allocator will do fuzzing, scrubbing of freed
memory, etc.

On Wed, Feb 4, 2015 at 10:44 AM, Jeff Morriss  wrote:
> So I deleted the EMEMification page from the wiki but I'm not sure what to
> do with the Canary page:
>
> http://wiki.wireshark.org/Development/Canary
>
> It looks like wmem does use canaries (under some circumstances?) so maybe it
> shouldn't be deleted.  But I'm not familiar enough with what wmem is doing
> to rewrite it either...
>
> On 02/04/15 10:04, Evan Huus wrote:
>>
>> Woohoo!
>>
>> On Wed, Feb 4, 2015 at 2:00 AM, Wireshark code review
>>  wrote:
>>>
>>> URL:
>>> https://code.wireshark.org/review/gitweb?p=wireshark.git;a=commit;h=7ced085550d030ea10525d650c8d5d8dc7c99684
>>> Submitter: Anders Broman (a.broma...@gmail.com)
>>> Changed: branch: master
>>> Repository: wireshark
>>>
>>> Commits:
>>>
>>> 7ced085 by Michael Mann (mman...@netscape.net):
>>>
>>>  emem is dead! Long live wmem!
>
>
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
> mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] [Wireshark-commits] master 7ced085: emem is dead! Long live wmem!

[Evan Huus]

Woohoo!

On Wed, Feb 4, 2015 at 2:00 AM, Wireshark code review
 wrote:
> URL: 
> https://code.wireshark.org/review/gitweb?p=wireshark.git;a=commit;h=7ced085550d030ea10525d650c8d5d8dc7c99684
> Submitter: Anders Broman (a.broma...@gmail.com)
> Changed: branch: master
> Repository: wireshark
>
> Commits:
>
> 7ced085 by Michael Mann (mman...@netscape.net):
>
> emem is dead! Long live wmem!
>
> Change-Id: Iddd1200e62bf3200cb1a68408378dd9d47120b77
> Reviewed-on: https://code.wireshark.org/review/6939
> Reviewed-by: Michael Mann 
>     Petri-Dish: Michael Mann 
> Reviewed-by: Evan Huus 
> Tested-by: Petri Dish Buildbot 
> Reviewed-by: Anders Broman 
>
>
> Actions performed:
>
> from  90a76e0   Convert val_to_str -> val_to_str_wmem.
> adds  7ced085   emem is dead! Long live wmem!
>
>
> Summary of changes:
>  debian/libwireshark0.symbols |4 -
>  doc/Makefile.am  |1 -
>  doc/README.malloc|   92 -
>  epan/CMakeLists.txt  |1 -
>  epan/Makefile.common |2 -
>  epan/emem.c  |  800 
> --
>  epan/emem.h  |  118 ---
>  epan/epan.c  |8 +-
>  epan/packet.c|   19 -
>  epan/reassemble_test.c   |4 -
>  epan/value_string.c  |1 -
>  tools/checkAPIs.pl   |4 -
>  12 files changed, 1 insertion(+), 1053 deletions(-)
>  delete mode 100644 doc/README.malloc
>  delete mode 100644 epan/emem.c
>  delete mode 100644 epan/emem.h
> ___
> Sent via:Wireshark-commits mailing list 
> Archives:http://www.wireshark.org/lists/wireshark-commits
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-commits
>  
> mailto:wireshark-commits-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Undissected packet bytes

[Evan Huus]

I'm not sure why it would work differently in the two places if those
print statements are the same. In general I would expect the
requirements for that method to be:
- *after* full dissection is finished
- dissection must have been run with the full tree enabled (as when
selecting a packet in the GUI)
If those two are met I think it should work.

As a side note, I would expect that method to be *very* slow, since it
traverses the entire tree for every byte of the packet. Traversing the
tree once and maintaining a set of covered/uncovered ranges would be
much more efficient.

On Wed, Feb 4, 2015 at 4:51 AM, Dario Lombardo
 wrote:
> Hi Evan
> This looks promising. Where can I use this call?
> If I run it from within a dissector
>
> packet-hpfeeds.c:344 (just an example... for purpose of testing)
>
> for (i = 0; i < len; i++) {
> fi = proto_find_field_from_offset(tree, i, tvb);
> g_print("TEST1 %p %d %p => %p\n", tree, i, tvb, fi);
> }
>
> it always returns NULL.
>
> If I run it from the gtk gui
>
> packet-panes.c:369
>
> g_print("TEST2 %p %d %p => %p\n", tree, byte, tvb, finfo);
>
> it returns a (valid?) pointer.
>
> The 2 prints show the same values of pointer/offsets.
>
> Where should a "for" routine like the above could be added in the code so it
> shows every undissected byte in every dissector?
> Thanks.
> Dario.
>
> On Tue, Feb 3, 2015 at 6:15 PM, Evan Huus  wrote:
>>
>> As far as I know this is not currently available, but it would
>> probably be fairly useful and easy. You just need to iterate the proto
>> tree and keep track of which byte ranges are claimed/unclaimed.
>> proto_find_field_from_offset does something related to this (it is
>> used for matching bytes to fields in the UI) so it's probably a good
>> place to start.
>>
>> On Tue, Feb 3, 2015 at 12:08 PM, Dario Lombardo
>>  wrote:
>> > Hi list
>> > I was wondering if there is a comfortable way to find out undissected
>> > bytes
>> > in packets. This would be useful to find incomplete dissectors.
>> > Any hint?
>> > Thanks!
>> > Dario.
>> >
>> >
>> > ___
>> > Sent via:Wireshark-dev mailing list 
>> > Archives:http://www.wireshark.org/lists/wireshark-dev
>> > Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>> >
>> > mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
>>
>> ___
>> Sent via:Wireshark-dev mailing list 
>> Archives:http://www.wireshark.org/lists/wireshark-dev
>> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>>
>> mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
>
>
>
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Undissected packet bytes

[Evan Huus]

As far as I know this is not currently available, but it would
probably be fairly useful and easy. You just need to iterate the proto
tree and keep track of which byte ranges are claimed/unclaimed.
proto_find_field_from_offset does something related to this (it is
used for matching bytes to fields in the UI) so it's probably a good
place to start.

On Tue, Feb 3, 2015 at 12:08 PM, Dario Lombardo
 wrote:
> Hi list
> I was wondering if there is a comfortable way to find out undissected bytes
> in packets. This would be useful to find incomplete dissectors.
> Any hint?
> Thanks!
> Dario.
>
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

[Wireshark-dev] American Fuzzy Lop - Menagerie Minimization

[Evan Huus]

Gerald and I have (independently) started playing with the American
Fuzzy Lop fuzzer recently [1] as a possibly more intelligent
alternative or complement to our current fuzzing set-up.

It includes a tool afl-cmin that uses its instrumentation to find
"unnecessary" files in a set of inputs (i.e. files that don't exercise
any new paths compared to the rest of the inputs). As an experiment, I
ran this tool against "tshark -nr" on our currently available public
menagerie folder and it cut it about in half.

Before: 5726 files, 1.8G
After: 2423 files, 764M

I suspect with "tshark -nxVr" there are more paths and fewer
duplicates (and it would also take a lot longer to run the script) but
it may be worth investigating regardless. If anybody else is curious
about the results I've made the minimized file list available at [2].

Cheers,
Evan

[1] http://lcamtuf.coredump.cx/afl/
[2] https://dl.dropboxusercontent.com/u/171647/mini-menagerie
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] [Wireshark-commits] master cf142c6: Get Wireshark to compile with afl-gcc.

[Evan Huus]

> On Jan 24, 2015, at 17:43, Gerald Combs  wrote:
> 
>> On 1/24/15 1:28 PM, Guy Harris wrote:
>> 
>>> On Jan 24, 2015, at 11:14 AM, Wireshark code review 
>>>  wrote:
>>> 
>>> cf142c6 by Gerald Combs (ger...@wireshark.org):
>>> 
>>>   Get Wireshark to compile with afl-gcc.
>>> 
>>>   Fix errors found by American Fuzzy Lop's afl-gcc
>>>   (http://lcamtuf.coredump.cx/afl/):
>>> 
>>>   peektagged.c:
>>>   error: 'fileVersion' may be used uninitialized in this function
>> 
>> So did AFL generate a test case for this one?  I'm not sure where it could 
>> ever be used uninitialized, given that wtap_file_read_number() should, if it 
>> returns a value that's neither -1 nor 0, fill in the variable to which it's 
>> handed a pointer; perhaps afl-gcc's data flow analysis missed something, or 
>> perhaps I did.
> 
> These were fixes that had to be made prior to fuzzing. As far as I can
> tell they fall into the "squelch a compiler warning" category. afl-gcc
> generates an instrumented executable, which you can then run under
> afl-fuzz (the actual fuzzer). According to the documentation the
> instrumentation isn't strictly necessary but it does enable more
> intelligent and efficient fuzzing.
> 
> BTW, I haven't found anything yet, but it looks like Evan has
> (gb2a5f15).

That was (like Gerald's) just a compiler warning to be squelched on the path to 
getting it built. I'm still playing with flags and haven't really run a proper 
fuzz pass yet.

AFL calls through to your existing gcc, it just instruments and sets its own 
batch of flags along the way. It's entirely possible that the errors it's 
causing are legitimate, but only exist when the additional instrumentation is 
in place.

> Hopefully we can add an AFL step to the buildbot at some
> point but I'm not sure if that's feasible with the current version.

My gut says that the input will have to be much more carefully curated than our 
current "ALL THE CAPTURES" approach (>5000 at last count). AFL seems to prefer 
fewer, smaller starting points, something like:
- one file for each capture type we support, containing a single instance of 
each record type (for file types like pcapng that support different record 
types)
- one short TCP conversation of just one or two data packets
etc.

It's not aware of capture formats, so it will give wiretap much more of a 
workout, but will probably be less efficient for the dissection engine.

> ___
> Sent via:Wireshark-dev mailing list 
> Archives:http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
> mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] [Wireshark-commits] master 6e6a129: CMake: Set an output directory for plugins.

[Evan Huus]

Huh, I did not even know about the latter, but it worked, I've always
just been running run/wireshark.

What's the similar trick for tshark et al so I can fuzz with plugins enabled?

On Tue, Jan 20, 2015 at 11:41 AM, Gerald Combs  wrote:
> Are you running Wireshark using the symlink (run/wireshark) or via "open
> run/Wireshark.app"? We might want to convert the symlink to a shell
> script that runs the latter.
>
> On 1/20/15 8:36 AM, Evan Huus wrote:
>> And if I manually specify WIRESHARK_RUN_FROM_BUILD_DIRECTORY then it
>> looks for plugins in run/plugins which doesn't exist.
>>
>> On Tue, Jan 20, 2015 at 11:34 AM, Evan Huus  wrote:
>>> They are there, but I don't think Wireshark is detecting that it's
>>> running from a build dir at all. My "global plugins" folder is set at
>>> /usr/local/lib/wireshark/plugins/1.99.2 according to the About
>>> dialogue.
>>>
>>> On Tue, Jan 20, 2015 at 11:31 AM, Gerald Combs  wrote:
>>>> Where do your plugins end up? They should be in
>>>> run/Wireshark.app/Contents/PlugIns/wireshark assuming that
>>>> ENABLE_APPLICATION_BUNDLE is "ON".
>>>>
>>>> On 1/20/15 8:21 AM, Evan Huus wrote:
>>>>> Plugins still aren't loaded on my out-of-tree MacOSX build, but I'm
>>>>> interested in getting this working (not that I really know how)...
>>>>>
>>>>> On Tue, Jan 20, 2015 at 11:12 AM, Wireshark code review
>>>>>  wrote:
>>>>>> URL: 
>>>>>> https://code.wireshark.org/review/gitweb?p=wireshark.git;a=commit;h=6e6a1291d0b36fe97d0f684e1abdfe546aaeae7f
>>>>>> Submitter: Gerald Combs (ger...@wireshark.org)
>>>>>> Changed: branch: master
>>>>>> Repository: wireshark
>>>>>>
>>>>>> Commits:
>>>>>>
>>>>>> 6e6a129 by Gerald Combs (ger...@zing.org):
>>>>>>
>>>>>> CMake: Set an output directory for plugins.
>>>>>>
>>>>>> Redefine PLUGIN_DIR similar to DATAFILE_DIR and use it on all
>>>>>> platforms. Add WiresharkPlugin.cmake so that we can start defining 
>>>>>> common
>>>>>> macros for plugins/*/CMakeLists.txt. Load plugins in out-of-tree 
>>>>>> builds.
>>>>>>
>>>>>> Change-Id: I8c1359ed3cf8a71788b8320ff89dfe2d3969def2
>>>>>> Reviewed-on: https://code.wireshark.org/review/6640
>>>>>> Reviewed-by: Gerald Combs 
>>>>>>
>>>>>>
>>>>>> Actions performed:
>>>>>>
>>>>>> from  af3924a   HTTP2: Add HPACK decode to test suite
>>>>>> adds  6e6a129   CMake: Set an output directory for plugins.
>>>>>>
>>>>>>
>>>>>> Summary of changes:
>>>>>>  CMakeLists.txt  |   89 
>>>>>> ---
>>>>>>  Makefile.am |2 +
>>>>>>  cmake/modules/WiresharkPlugin.cmake |   61 
>>>>>>  plugins/docsis/CMakeLists.txt   |   43 ++---
>>>>>>  plugins/ethercat/CMakeLists.txt |   43 ++---
>>>>>>  plugins/gryphon/CMakeLists.txt  |   43 ++---
>>>>>>  plugins/irda/CMakeLists.txt |   43 ++---
>>>>>>  plugins/m2m/CMakeLists.txt  |   43 ++---
>>>>>>  plugins/mate/CMakeLists.txt |   43 ++---
>>>>>>  plugins/opcua/CMakeLists.txt|   42 ++---
>>>>>>  plugins/profinet/CMakeLists.txt |   43 ++---
>>>>>>  plugins/stats_tree/CMakeLists.txt   |   47 ++
>>>>>>  plugins/tpg/CMakeLists.txt  |   25 +++---
>>>>>>  plugins/unistim/CMakeLists.txt  |   42 ++---
>>>>>>  plugins/wimax/CMakeLists.txt|   43 ++---
>>>>>>  plugins/wimaxasncp/CMakeLists.txt   |   43 ++---
>>>>>>  plugins/wimaxmacphy/CMakeLists.txt  |   43 ++---
>>>>>>  wsutil/plugins.c|   10 ++--
>>>>>>  18 files changed, 168 insertions(+), 580 deletions(-)
>>>>>>  create mode 100644 cmake/modules/WiresharkPlugin.cmake
>>>

Re: [Wireshark-dev] [Wireshark-commits] master 6e6a129: CMake: Set an output directory for plugins.

[Evan Huus]

And if I manually specify WIRESHARK_RUN_FROM_BUILD_DIRECTORY then it
looks for plugins in run/plugins which doesn't exist.

On Tue, Jan 20, 2015 at 11:34 AM, Evan Huus  wrote:
> They are there, but I don't think Wireshark is detecting that it's
> running from a build dir at all. My "global plugins" folder is set at
> /usr/local/lib/wireshark/plugins/1.99.2 according to the About
> dialogue.
>
> On Tue, Jan 20, 2015 at 11:31 AM, Gerald Combs  wrote:
>> Where do your plugins end up? They should be in
>> run/Wireshark.app/Contents/PlugIns/wireshark assuming that
>> ENABLE_APPLICATION_BUNDLE is "ON".
>>
>> On 1/20/15 8:21 AM, Evan Huus wrote:
>>> Plugins still aren't loaded on my out-of-tree MacOSX build, but I'm
>>> interested in getting this working (not that I really know how)...
>>>
>>> On Tue, Jan 20, 2015 at 11:12 AM, Wireshark code review
>>>  wrote:
>>>> URL: 
>>>> https://code.wireshark.org/review/gitweb?p=wireshark.git;a=commit;h=6e6a1291d0b36fe97d0f684e1abdfe546aaeae7f
>>>> Submitter: Gerald Combs (ger...@wireshark.org)
>>>> Changed: branch: master
>>>> Repository: wireshark
>>>>
>>>> Commits:
>>>>
>>>> 6e6a129 by Gerald Combs (ger...@zing.org):
>>>>
>>>> CMake: Set an output directory for plugins.
>>>>
>>>> Redefine PLUGIN_DIR similar to DATAFILE_DIR and use it on all
>>>> platforms. Add WiresharkPlugin.cmake so that we can start defining 
>>>> common
>>>> macros for plugins/*/CMakeLists.txt. Load plugins in out-of-tree 
>>>> builds.
>>>>
>>>> Change-Id: I8c1359ed3cf8a71788b8320ff89dfe2d3969def2
>>>> Reviewed-on: https://code.wireshark.org/review/6640
>>>> Reviewed-by: Gerald Combs 
>>>>
>>>>
>>>> Actions performed:
>>>>
>>>> from  af3924a   HTTP2: Add HPACK decode to test suite
>>>> adds  6e6a129   CMake: Set an output directory for plugins.
>>>>
>>>>
>>>> Summary of changes:
>>>>  CMakeLists.txt  |   89 
>>>> ---
>>>>  Makefile.am |2 +
>>>>  cmake/modules/WiresharkPlugin.cmake |   61 
>>>>  plugins/docsis/CMakeLists.txt   |   43 ++---
>>>>  plugins/ethercat/CMakeLists.txt |   43 ++---
>>>>  plugins/gryphon/CMakeLists.txt  |   43 ++---
>>>>  plugins/irda/CMakeLists.txt |   43 ++---
>>>>  plugins/m2m/CMakeLists.txt  |   43 ++---
>>>>  plugins/mate/CMakeLists.txt |   43 ++---
>>>>  plugins/opcua/CMakeLists.txt|   42 ++---
>>>>  plugins/profinet/CMakeLists.txt |   43 ++---
>>>>  plugins/stats_tree/CMakeLists.txt   |   47 ++
>>>>  plugins/tpg/CMakeLists.txt  |   25 +++---
>>>>  plugins/unistim/CMakeLists.txt  |   42 ++---
>>>>  plugins/wimax/CMakeLists.txt|   43 ++---
>>>>  plugins/wimaxasncp/CMakeLists.txt   |   43 ++---
>>>>  plugins/wimaxmacphy/CMakeLists.txt  |   43 ++---
>>>>  wsutil/plugins.c|   10 ++--
>>>>  18 files changed, 168 insertions(+), 580 deletions(-)
>>>>  create mode 100644 cmake/modules/WiresharkPlugin.cmake
>>>> ___
>>>> Sent via:Wireshark-commits mailing list 
>>>> 
>>>> Archives:http://www.wireshark.org/lists/wireshark-commits
>>>> Unsubscribe: https://wireshark.org/mailman/options/wireshark-commits
>>>>  
>>>> mailto:wireshark-commits-requ...@wireshark.org?subject=unsubscribe
>>> ___
>>> Sent via:Wireshark-dev mailing list 
>>> Archives:http://www.wireshark.org/lists/wireshark-dev
>>> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>>>  mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
>>>
>>
>> ___
>> Sent via:Wireshark-dev mailing list 
>> Archives:http://www.wireshark.org/lists/wireshark-dev
>> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>>  mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] [Wireshark-commits] master 6e6a129: CMake: Set an output directory for plugins.

[Evan Huus]

They are there, but I don't think Wireshark is detecting that it's
running from a build dir at all. My "global plugins" folder is set at
/usr/local/lib/wireshark/plugins/1.99.2 according to the About
dialogue.

On Tue, Jan 20, 2015 at 11:31 AM, Gerald Combs  wrote:
> Where do your plugins end up? They should be in
> run/Wireshark.app/Contents/PlugIns/wireshark assuming that
> ENABLE_APPLICATION_BUNDLE is "ON".
>
> On 1/20/15 8:21 AM, Evan Huus wrote:
>> Plugins still aren't loaded on my out-of-tree MacOSX build, but I'm
>> interested in getting this working (not that I really know how)...
>>
>> On Tue, Jan 20, 2015 at 11:12 AM, Wireshark code review
>>  wrote:
>>> URL: 
>>> https://code.wireshark.org/review/gitweb?p=wireshark.git;a=commit;h=6e6a1291d0b36fe97d0f684e1abdfe546aaeae7f
>>> Submitter: Gerald Combs (ger...@wireshark.org)
>>> Changed: branch: master
>>> Repository: wireshark
>>>
>>> Commits:
>>>
>>> 6e6a129 by Gerald Combs (ger...@zing.org):
>>>
>>> CMake: Set an output directory for plugins.
>>>
>>> Redefine PLUGIN_DIR similar to DATAFILE_DIR and use it on all
>>> platforms. Add WiresharkPlugin.cmake so that we can start defining 
>>> common
>>> macros for plugins/*/CMakeLists.txt. Load plugins in out-of-tree builds.
>>>
>>> Change-Id: I8c1359ed3cf8a71788b8320ff89dfe2d3969def2
>>> Reviewed-on: https://code.wireshark.org/review/6640
>>> Reviewed-by: Gerald Combs 
>>>
>>>
>>> Actions performed:
>>>
>>> from  af3924a   HTTP2: Add HPACK decode to test suite
>>> adds  6e6a129   CMake: Set an output directory for plugins.
>>>
>>>
>>> Summary of changes:
>>>  CMakeLists.txt  |   89 
>>> ---
>>>  Makefile.am |2 +
>>>  cmake/modules/WiresharkPlugin.cmake |   61 
>>>  plugins/docsis/CMakeLists.txt   |   43 ++---
>>>  plugins/ethercat/CMakeLists.txt |   43 ++---
>>>  plugins/gryphon/CMakeLists.txt  |   43 ++---
>>>  plugins/irda/CMakeLists.txt |   43 ++---
>>>  plugins/m2m/CMakeLists.txt  |   43 ++---
>>>  plugins/mate/CMakeLists.txt |   43 ++---
>>>  plugins/opcua/CMakeLists.txt|   42 ++---
>>>  plugins/profinet/CMakeLists.txt |   43 ++---
>>>  plugins/stats_tree/CMakeLists.txt   |   47 ++
>>>  plugins/tpg/CMakeLists.txt  |   25 +++---
>>>  plugins/unistim/CMakeLists.txt  |   42 ++---
>>>  plugins/wimax/CMakeLists.txt|   43 ++---
>>>  plugins/wimaxasncp/CMakeLists.txt   |   43 ++---
>>>  plugins/wimaxmacphy/CMakeLists.txt  |   43 ++---
>>>  wsutil/plugins.c|   10 ++--
>>>  18 files changed, 168 insertions(+), 580 deletions(-)
>>>  create mode 100644 cmake/modules/WiresharkPlugin.cmake
>>> ___
>>> Sent via:Wireshark-commits mailing list 
>>> 
>>> Archives:http://www.wireshark.org/lists/wireshark-commits
>>> Unsubscribe: https://wireshark.org/mailman/options/wireshark-commits
>>>  
>>> mailto:wireshark-commits-requ...@wireshark.org?subject=unsubscribe
>> ___
>> Sent via:Wireshark-dev mailing list 
>> Archives:http://www.wireshark.org/lists/wireshark-dev
>> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>>  mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
>>
>
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] [Wireshark-commits] master 6e6a129: CMake: Set an output directory for plugins.

[Evan Huus]

Plugins still aren't loaded on my out-of-tree MacOSX build, but I'm
interested in getting this working (not that I really know how)...

On Tue, Jan 20, 2015 at 11:12 AM, Wireshark code review
 wrote:
> URL: 
> https://code.wireshark.org/review/gitweb?p=wireshark.git;a=commit;h=6e6a1291d0b36fe97d0f684e1abdfe546aaeae7f
> Submitter: Gerald Combs (ger...@wireshark.org)
> Changed: branch: master
> Repository: wireshark
>
> Commits:
>
> 6e6a129 by Gerald Combs (ger...@zing.org):
>
> CMake: Set an output directory for plugins.
>
> Redefine PLUGIN_DIR similar to DATAFILE_DIR and use it on all
> platforms. Add WiresharkPlugin.cmake so that we can start defining common
> macros for plugins/*/CMakeLists.txt. Load plugins in out-of-tree builds.
>
> Change-Id: I8c1359ed3cf8a71788b8320ff89dfe2d3969def2
> Reviewed-on: https://code.wireshark.org/review/6640
> Reviewed-by: Gerald Combs 
>
>
> Actions performed:
>
> from  af3924a   HTTP2: Add HPACK decode to test suite
> adds  6e6a129   CMake: Set an output directory for plugins.
>
>
> Summary of changes:
>  CMakeLists.txt  |   89 
> ---
>  Makefile.am |2 +
>  cmake/modules/WiresharkPlugin.cmake |   61 
>  plugins/docsis/CMakeLists.txt   |   43 ++---
>  plugins/ethercat/CMakeLists.txt |   43 ++---
>  plugins/gryphon/CMakeLists.txt  |   43 ++---
>  plugins/irda/CMakeLists.txt |   43 ++---
>  plugins/m2m/CMakeLists.txt  |   43 ++---
>  plugins/mate/CMakeLists.txt |   43 ++---
>  plugins/opcua/CMakeLists.txt|   42 ++---
>  plugins/profinet/CMakeLists.txt |   43 ++---
>  plugins/stats_tree/CMakeLists.txt   |   47 ++
>  plugins/tpg/CMakeLists.txt  |   25 +++---
>  plugins/unistim/CMakeLists.txt  |   42 ++---
>  plugins/wimax/CMakeLists.txt|   43 ++---
>  plugins/wimaxasncp/CMakeLists.txt   |   43 ++---
>  plugins/wimaxmacphy/CMakeLists.txt  |   43 ++---
>  wsutil/plugins.c|   10 ++--
>  18 files changed, 168 insertions(+), 580 deletions(-)
>  create mode 100644 cmake/modules/WiresharkPlugin.cmake
> ___
> Sent via:Wireshark-commits mailing list 
> Archives:http://www.wireshark.org/lists/wireshark-commits
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-commits
>  
> mailto:wireshark-commits-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

[Wireshark-dev] Status of Emem Removal

[Evan Huus]

As of commit e333e4c90f0aca41b0a56cef22fd80d0b0e73e14 by Michael this
evening, the deprecated 'emem' API has exactly one remaining usage in
the wireshark core codebase, which is a pretty huge accomplishment
considering how widespread it was a few years ago. Big thanks to
Michael and everybody else who have been slowly chipping away at this
problem.

Of course, "one remaining use" is not enough for me - I would love to
have it entirely removed for the 2.0 release! Unfortunately, the
remaining use is a bit of a sticky one because it has so many diverse
callers: val_to_str and friends (val_to_str_ext, etc). A quick scan
with cscope shows that val_to_str alone (not counting any of the
related functions) has over 2000 call sites in Wireshark master right
now.

Our plan of attack for converting other similar functions has been to
add a wmem_scope_t* parameter to them, and then go through each call
site, passing in wmem_packet_scope() where it is actually appropriate,
and refactoring or reworking the code where it isn't (often passing in
NULL and then manually freeing the result). Doing this process for the
2000+ calls to val_to_str would be... tedious, so I'm open to other
suggestions.

Since it appears that the vast majority of such calls can legitimately
use wmem_packet_scope, my current thought is to hard-code
wmem_packet_scope in the existing API, and then for the remaining
cases either:
- add an otherwise-identical API that takes a wmem_scope
or
- convert them to use try_val_to_str and manually handle the "not
found" case as appropriate

Regardless it's going to be a bit of work: there are around 100 calls
in the ui/ directory alone that will have to be tweaked one way or
another.

Thoughts? Suggestions?

Evan
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] [Wireshark-commits] master 1e1d96f: Modify the errorcode defenition to suit ANSI MAP, this is (probably) OK as ANSI MAP is currently the only user of ANSI TCAP. Bug: 6112

[Evan Huus]

Public service announcement, since I've gotten a few emails from
people confused why bugzilla integration seems flaky:

The bugzilla integration will not automatically pick up on the Bug:
 line unless it is part of the footer (i.e. not separated by blank
lines from the rest of the Change-Id: lines and similar). The
following message will work:

> Make some change
>
> Bug: 1234
> Change-Id: Iblahblahblah

But this one won't:

> Make some change
> Bug: 1234
>
> Change-Id: Iblahblahblah

It seems a silly limitation, but that's how Gerrit works, *shrug*.

On Thu, Jan 15, 2015 at 10:05 AM, Wireshark code review
 wrote:
> URL: 
> https://code.wireshark.org/review/gitweb?p=wireshark.git;a=commit;h=1e1d96f108bde4284c1b2117a1fe9d46b4a82edc
> Submitter: Anders Broman (a.broma...@gmail.com)
> Changed: branch: master
> Repository: wireshark
>
> Commits:
>
> 1e1d96f by AndersBroman (anders.bro...@ericsson.com):
>
> Modify the errorcode defenition to suit ANSI MAP, this is (probably) OK as
> ANSI MAP is currently the only user of ANSI TCAP.
> Bug: 6112
>
> Change-Id: I49f89c862ddc8351091a9a939415e4ba6e7603f5
> Reviewed-on: https://code.wireshark.org/review/6546
> Reviewed-by: Anders Broman 
>
>
> Actions performed:
>
> from  ef0435b   ZigBee: don't use packet_scope outside of dissection
> adds  1e1d96f   Modify the errorcode defenition to suit ANSI MAP, this is 
> (probably) OK as ANSI MAP is currently the only user of ANSI TCAP. Bug: 6112
>
>
> Summary of changes:
>  .../TCAP-Remote-Operations-Information-Objects.asn |   20 +--
>  epan/dissectors/packet-ansi_tcap.c |   36 
> +---
>  2 files changed, 49 insertions(+), 7 deletions(-)
> ___
> Sent via:Wireshark-commits mailing list 
> Archives:http://www.wireshark.org/lists/wireshark-commits
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-commits
>  
> mailto:wireshark-commits-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

[Wireshark-dev] Ubuntu Petri-Dish Stuck?

[Evan Huus]

It has five pending builds and doesn't appear to be processing
anything, not sure what's up...
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] [Wireshark-commits] master b0e6fbf: umts_fp: Replace se_new0(...) by wmem_new0(wmem_file_scope(), ...)

[Evan Huus]

On Wed, Dec 31, 2014 at 1:17 PM, Bill Meier  wrote:
> On 12/31/2014 12:52 PM, Bill Meier wrote:
>>
>> On 12/31/2014 11:31 AM, Evan Huus wrote:
>>>
>>> This is an init routine, which can be called when no file is in scope,
>>> so wmem_file_scope() is incorrect (and se_* was also incorrect).
>>>
>>> I'm actually not sure what this routine is doing, since it deals with
>>> conversations but there will never be any conversations e.g. on
>>> startup when the init routine is actually called...
>>>
>>
>> I realized (after I did the commit) that there must be a reason why a
>> just a few ep/se calls remained (all to related to the use of UATs ?).
>> :)
>>
>> This thing looks like it's setting up conversations based upon UAT info
>> prior to dissection (presumably so that any subsequent dissection will
>> be able to take advantage of info stored in the conversation structs).
>>
>> Taking a quick look at things I see that in packet.c the init-routines
>> are called after setting up file scope and initializing the conversation
>> stuff, so it would seem that using file_scope might be OK.
>>
>>  se_free_all();
>>  wmem_enter_file_scope();
>>  ...
>>  epan_conversation_init();
>>  ...
>>  g_slist_foreach(init_routines, &call_init_routine, NULL);
>>
>> Am I missing something ?
>>
>> Are there other cases where the init routines are called out of file
>> scope ?
>>
>> A problem I do see: if the UAT is changed while a file is open, there's
>> no update of the conversation table from the UAT. I don't know if
>> there's something in the UAT info which might change the dissection.
>>
>> Maybe this is why the code checks to see if there'san existing
>> conversation (altho currently there can't be any since the code is only
>> exec'd as an init.
>>
>>
>
> Oops: I see that cleanup_dissection() also calls the init routines (after
> doing conversation_cleanup()), so I guess that trying to add info to the
> conversation structures at this point might not work too well.
>
> I'll have to dig a little deeper to see what really happens now and what
> might be done for all of this.

Ya, the scoping of memory allocated in UAT-related code is a bit of a
mess, because UATs can be edited while no file is open (and thus also
while no packet is being dissected). Ideally any UAT callbacks would
use manual memory (glib directly, or wmem's NULL scope) and then use a
subsequent UAT callback to free it. It's not as simple a conversion as
emem->wmem though, so I've never worked up the willpower to take a
crack at it. I believe (haven't checked) that doing this correctly may
involve adding another callback hook into the UAT code for cleanup
purposes.
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] [Wireshark-commits] master b0e6fbf: umts_fp: Replace se_new0(...) by wmem_new0(wmem_file_scope(), ...)

[Evan Huus]

This is an init routine, which can be called when no file is in scope,
so wmem_file_scope() is incorrect (and se_* was also incorrect).

I'm actually not sure what this routine is doing, since it deals with
conversations but there will never be any conversations e.g. on
startup when the init routine is actually called...

On Wed, Dec 31, 2014 at 11:11 AM, Wireshark code review
 wrote:
> URL: 
> https://code.wireshark.org/review/gitweb?p=wireshark.git;a=commit;h=b0e6fbf2d4ac4c5819d09b2a5072e74436b4f1c8
> Submitter: Bill Meier (wme...@newsguy.com)
> Changed: branch: master
> Repository: wireshark
>
> Commits:
>
> b0e6fbf by Bill Meier (wme...@newsguy.com):
>
> umts_fp: Replace se_new0(...) by wmem_new0(wmem_file_scope(), ...)
>
> Change-Id: I9d40ffd199147fb8b975c493253d5cf796be5983
> Reviewed-on: https://code.wireshark.org/review/6179
> Reviewed-by: Bill Meier 
>
>
> Actions performed:
>
> from  f7b6dcc   Lua: allow a Dissector object to be passed in for 
> register_heuristic
> adds  b0e6fbf   umts_fp: Replace se_new0(...) by 
> wmem_new0(wmem_file_scope(), ...)
>
>
> Summary of changes:
>  epan/dissectors/packet-umts_fp.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> ___
> Sent via:Wireshark-commits mailing list 
> Archives:http://www.wireshark.org/lists/wireshark-commits
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-commits
>  
> mailto:wireshark-commits-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] [Wireshark-commits] master f412c9a: Use ENC_BIG_ENDIAN when fetching FT_U?INT8 fields ...

[Evan Huus]

On Dec 14, 2014 3:04 PM, "Bill Meier"  wrote:
>
> On 12/14/2014 2:22 PM, Stephen Fisher wrote:
>>
>> On Sun, Dec 14, 2014 at 01:44:19PM -0500, Bill Meier wrote:
>>
>>> That being said, the convention (certainly not enforced) seems to be
>>> to use ENC_..._ENDIAN for fetching all integral types.
>>
>>
>> Could this be related to when we made the change from using FALSE / TRUE
>> to specify if its "big endian" in things like proto_tree_add_item() ?
>
>
>
> Good point !
>
> fix-encoding-args.pl (used to do the change) just converted FALSE|0 to
BIG_ENDIAN and etc, so the "convention" actually kind-of-happened because
previously TRUE|1 or FALSE|0 were the only choices for the 'encoding-arg".
>
> So, I stand corrected.
>
> Maybe what I should be doing is converting all the single-byte fetches to
use ENC_NA.
>
> Thoughts ?

This makes sense to me.

> Bill
>
>
>
>
___
> Sent via:Wireshark-dev mailing list 
> Archives:http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
> mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] [Wireshark-commits] master f412c9a: Use ENC_BIG_ENDIAN when fetching FT_U?INT8 fields ...

[Evan Huus]

I didn't think single-byte fields could really have an endianess, so I
thought ENC_NA was appropriate for them?

Evan

On Sat, Dec 13, 2014 at 1:45 PM, Wireshark code review
 wrote:
> URL: 
> https://code.wireshark.org/review/gitweb?p=wireshark.git;a=commit;h=f412c9a01aa031ef9f024ee1b8ec60bf4a73edb8
> Submitter: Bill Meier (wme...@newsguy.com)
> Changed: branch: master
> Repository: wireshark
>
> Commits:
>
> f412c9a by Bill Meier (wme...@newsguy.com):
>
> Use ENC_BIG_ENDIAN when fetching FT_U?INT8 fields ...
>
>   (for some dissectors which fetch all other integral fields using
>ENC_BIG_ENDIAN).
>
> Change-Id: Ic18e3172aad76af12b12d6732c88497be22aed56
> Reviewed-on: https://code.wireshark.org/review/5748
> Reviewed-by: Bill Meier 
>
>
> Actions performed:
>
> from  7592d39   GSM SMS: fix 'msg_class' may be used uninitialized in 
> this function warning
> adds  f412c9a   Use ENC_BIG_ENDIAN when fetching FT_U?INT8 fields ...
>
>
> Summary of changes:
>  epan/dissectors/packet-6lowpan.c   |2 +-
>  epan/dissectors/packet-acr122.c|   10 +-
>  epan/dissectors/packet-aim-generic.c   |2 +-
>  epan/dissectors/packet-ansi_801.c  |   68 ++---
>  epan/dissectors/packet-aodv.c  |2 +-
>  epan/dissectors/packet-arp.c   |8 +-
>  epan/dissectors/packet-aruba-erm.c |4 +-
>  epan/dissectors/packet-asterix.c   |2 +-
>  epan/dissectors/packet-auto_rp.c   |2 +-
>  epan/dissectors/packet-babel.c |   28 +-
>  epan/dissectors/packet-batadv.c|4 +-
>  epan/dissectors/packet-bgp.c   |   42 +--
>  epan/dissectors/packet-bzr.c   |4 +-
>  epan/dissectors/packet-carp.c  |2 +-
>  epan/dissectors/packet-cdp.c   |   20 +-
>  epan/dissectors/packet-chdlc.c |2 +-
>  epan/dissectors/packet-clnp.c  |2 +-
>  epan/dissectors/packet-cops.c  |   24 +-
>  epan/dissectors/packet-dcm.c   |   18 +-
>  epan/dissectors/packet-dhcp-failover.c |2 +-
>  epan/dissectors/packet-diameter_3gpp.c |2 +-
>  epan/dissectors/packet-dis.c   |   50 ++--
>  epan/dissectors/packet-dlsw.c  |   52 ++--
>  epan/dissectors/packet-dns.c   |   28 +-
>  epan/dissectors/packet-dtn.c   |4 +-
>  epan/dissectors/packet-dtp.c   |8 +-
>  epan/dissectors/packet-elmi.c  |2 +-
>  epan/dissectors/packet-epon.c  |2 +-
>  epan/dissectors/packet-erldp.c |4 +-
>  epan/dissectors/packet-etch.c  |6 +-
>  epan/dissectors/packet-etsi_card_app_toolkit.c |   56 ++--
>  epan/dissectors/packet-fcels.c |   26 +-
>  epan/dissectors/packet-fcswils.c   |   22 +-
>  epan/dissectors/packet-fmtp.c  |6 +-
>  epan/dissectors/packet-foundry.c   |4 +-
>  epan/dissectors/packet-giop.c  |   10 +-
>  epan/dissectors/packet-gmr1_common.c   |2 +-
>  epan/dissectors/packet-gsm_a_dtap.c|   72 ++---
>  epan/dissectors/packet-gsm_a_gm.c  |4 +-
>  epan/dissectors/packet-gsm_a_rr.c  |   16 +-
>  epan/dissectors/packet-gsm_sim.c   |6 +-
>  epan/dissectors/packet-gtp.c   |   48 ++--
>  epan/dissectors/packet-gtpv2.c |   10 +-
>  epan/dissectors/packet-h264.c  |4 +-
>  epan/dissectors/packet-hpsw.c  |2 +-
>  epan/dissectors/packet-http2.c |   30 +--
>  epan/dissectors/packet-iapp.c  |4 +-
>  epan/dissectors/packet-igmp.c  |2 +-
>  epan/dissectors/packet-igrp.c  |   10 +-
>  epan/dissectors/packet-ipp.c   |2 +-
>  epan/dissectors/packet-ipv6.c  |   22 +-
>  epan/dissectors/packet-isis-hello.c|   28 +-
>  epan/dissectors/packet-isis-lsp.c  |   42 +--
>  epan/dissectors/packet-isl.c   |6 +-
>  epan/dissectors/packet-kink.c  |4 +-
>  epan/dissectors/packet-knxnetip.c  |2 +-
>  epan/dissectors/packet-l2tp.c  |   10 +-
>  epan/dissectors/packet-lacp.c  |   16 +-
>  epan/dissectors/packet-lisp-tcp.c  |2 +-
>  epan/dissectors/packet-lisp.c  |   32 +--
>  epan/dissectors/packet-llrp.c  |   16 +-
>  epan/dissectors/packet-lmp.c   |   20 +-
>  epan/dissectors/packet-lon.c   |   54 ++--
>  epan/dissectors/packet-maccontrol.c|   10 +-
>  epan/dissectors/packet-macsec.c|   16 +-
>  epan/dissectors/packet-marker.c|4 +-
>  epan/dissectors/

Re: [Wireshark-dev] Ubuntu PPA for Wireshark stable branch

[Evan Huus]

Very cool, thanks Balint!

Also on the topic of Ubuntu and Wireshark, it looks like the packages
that ship with Ubuntu are finally getting some security love:
https://bugs.launchpad.net/ubuntu/+source/wireshark/+bug/1397091

Evan

On Fri, Dec 12, 2014 at 4:53 PM, Bálint Réczey  wrote:
> Hi All,
>
> I have created a PPA for the stable Wireshark branch point releases:
> https://launchpad.net/~wireshark-dev/+archive/ubuntu/stable
>
> The packages are back-ported from latest packaged version in Debian
> unstable to prevent upgrade problems.
>
> Since in Debian we are in "freeze" phase I can't upload 1.12.2-1, but
> when it is over in a few weeks I will follow the Wireshark releases
> closely again.
>
> It is not an official announcement, just a short status update. The
> packages are building on Launchpad for the first time and haven't been
> tested yet. If you feel so please try them and send feedback.
>
> Currently packages for Ubuntu 14.10 (Trusty) are building, and I plan
> adding all supported Ubuntu versions.
>
> Cheers,
> Balint
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe