Ok, so that's definitively a point for me to work on in the future.
For the time being, let's note that the new dissectors improve slightly over the current ones:
>egrep -c "static.*hf_" packet-ua3g.c packet-ua.c packet-uaudp.c packet-uasip.c packet-noe.c
packet-ua3g.c:5
packet-ua.c:0
packet-uaudp.c:13
packet-uasip.c:13
packet-noe.c:12
=>43
versus
>egrep -c "static.*hf_" packet-ua.c.old packet-uaudp.c.old
packet-ua.c.old:30
packet-uaudp.c.old:4
=>34
Those 43 fields up there are the most important ones of course and sufficient for effective filtering most of the time.
Lars
-----Original Message-----
From: wireshark-dev-bounces@xxxxxxxxxxxxx [mailto:wireshark-dev-bounces@xxxxxxxxxxxxx] On Behalf Of Jeff Morriss
Sent: mercredi 15 février 2012 16:11
To: Developer support list for Wireshark
Subject: Re: [Wireshark-dev] Bug 6844 - Universal Alcatel Protocol - Reloaded - Review for check-in requested
Why not practical?
> $ egrep -c "static .?int hf" epan/dissectors/* | sort -t : -n -k 2 |
> tail -3
> epan/dissectors/packet-nbap.c:3284
> epan/dissectors/x11-declarations.h:7119
> epan/dissectors/packet-rrc.c:8403
(Admittedly those 3 are all generated dissectors, but I also imagine you're not dealing with *quite* that many fields...) But these dissectors are both manually generated:
> epan/dissectors/packet-ieee80211.c:931
> epan/dissectors/packet-cigi.c:957
The point, anyway, is that dissection without fields is only mildly useful. Wireshark's real power is those fields which allow you to filter, graph, and do other good stuff.
RUOFF, LARS (LARS)** CTR ** wrote:
> You're right, Anders,
> I'll note this for further improvement.
> Any chances the dissector gets admitted anyway?
> The protocol suite is rather large and dissects several hundreds of different fields and suboptions. Registering every field would not be practicable i guess.
>
> Regards,
> Lars
>
> -----Original Message-----
> From: wireshark-dev-bounces@xxxxxxxxxxxxx
> [mailto:wireshark-dev-bounces@xxxxxxxxxxxxx] On Behalf Of Anders
> Broman
> Sent: mercredi 15 février 2012 10:32
> To: Developer support list for Wireshark
> Subject: Re: [Wireshark-dev] Bug 6844 - Universal Alcatel Protocol -
> Reloaded - Review for check-in requested
>
> Hi,
> At a glance it contains a lot of "proto_tree_add_text()" which is
> frowned on
> -- snip --
>>> Joerg Mayer wrote:
>>> [...]
>>>> So more than half of all the stuff is added by using proto_tree_add_text.
>>>> As long as the ratio is that way, people are likely to continue
>>>> using it inside this dissector.
>>>> Any volunteer(s) to get this down to some sane level by replacing
>>>> it by proto_tree_add_item and adding hf_ entries where possible to
>>>> make these Elements filterable?
>>>>
>>>> Should something like the above check be added to one of the check
>>>> scripts to complain if the add_text percentage is above 10% or so?
>>> Done in r40930
>> Good!
> --- end snip ---
>
> Regards
> Anders
>
> -----Original Message-----
> From: wireshark-dev-bounces@xxxxxxxxxxxxx
> [mailto:wireshark-dev-bounces@xxxxxxxxxxxxx] On Behalf Of RUOFF, LARS
> (LARS)** CTR **
> Sent: den 15 februari 2012 10:26
> To: Developer support list for Wireshark
> Subject: [Wireshark-dev] Bug 6844 - Universal Alcatel Protocol -
> Reloaded - Review for check-in requested
>
> Hi,
>
> i've been maintaining an inhouse dissector for Alcatel-Lucent Enterprise's Universal Alcatel (UA) protocol and sub-protocols for many years now.
> To my regret, this protocol suite used to be classified and i didn't get the authorization for releasing it to the Wireshark tree as open source.
>
> Therefore, it is with much surprise that i realized that Marek Tews has committed a UA dissector to the trunk last year.
> Upon quick inspection of the code, i cannot directly link it to any previous version of our private trunk, so i guess Marek developed this on his own. (Maybe you can confirm, Marek?).
>
> Now it happens that this gave me some new arguments to deal with my management and the good news is that Alcatel-Lucent Enterprise has agreed to submit all available source code of our in-house UA- and subprotocol-dissectors to the Wireshark source tree.
>
> This is interesting because from what i see the current dissector lacks a lot of functionality compared to our inhouse plug-in which features support for the latest protocol specifiaction, more detailed dissection and filtering possibilities on subprotocols, RTP stream setup, NOE over SIP, etc., to name just a few.
>
> Thus i am submitting our complete sources for complete replacement of the existing dissector:
> https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=6844
> The dissector has been tested by a large user base over several years during inhouse use as a plugin.
> It has not been fuzz-tested though.
>
> Naturally, i'd be very happy if the dissector would be accepted before release of WS 1.8.0.
>
> Thank you,
> best regards,
> Lars Ruoff
> ___________________________________________________________________________
> Sent via: Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
> Archives: http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>
> mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
> ___________________________________________________________________________
> Sent via: Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
> Archives: http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>
> mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
> ___________________________________________________________________________
> Sent via: Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
> Archives: http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>
> mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
>
___________________________________________________________________________
Sent via: Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives: http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe