The description of a "field type" for and hf_ field doesn't always correspond
to its length on the wire. While many times that is the case for integers
(FT_UINTx), it wouldn't be the case for strings or byte arrays (or many of the
other field types).
You also have cases were an integer field c
Anders kind of beat me too it, but there are ways other than storing it in
packet_info to exchange the data. I don't know enough about the dissectors
themselves to suggest the "best" way, but please don't consider packet_info as
an option.
-Original Message-
From: Richard Shar
Another "I *think*" is that FT_PROTOCOL is more intended for hf_ items that are
actually a protocol (typically a proto_xxx variable that uses the value
returned from proto_register_protocol), then any "independent" fields
registered through proto_register_field_array.
The tree you pass into p
... begins with a single step - Lao Tzu
The thousand mile journey has been completed as all proto_tree_add_text calls
within the Wireshark source have been converted to a "better" API. Because
they have been converted, I think proto_tree_add_text should be removed from
the Wireshark API. To
There is the "Major API changes" section of the release notes that I added a
note to in the patch.
-Original Message-
From: Graham Bloice
To: Developer support list for Wireshark
Sent: Mon, Sep 21, 2015 5:05 am
Subject: Re: [Wireshark-dev] The journey of a thousand miles...
Thank you. It felt good to hit the button.
What I'm hoping this change can do is open up better optimizations in proto.c
I don't know enough to know how/what those optimizations could be, I just saw
proto_tree_add_text as a roadblock. We still have a few other "text node" APIs
if that i
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
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?
-Original Message-
From: Jeffrey Smith
To: Developer support list for Wireshark
Sent: Thu, Oct 1, 2015 1:46 am
Subject:
While reviewing the DOF dissectors (https://code.wireshark.org/review/8869), I
noticed that all of the registered dissectors used proto_set_cant_toggle() and
proto_mark_private(). I don't think either is appropriate for a "regular"
dissector, but I had never seen proto_mark_private(), so I loo
expert_checksum_vals.
-Original Message-
From: Alexis La Goutte
To: mmann78
Cc: Developer support list for Wireshark
Sent: Tue, Jul 2, 2013 3:29 pm
Subject: Re: [Wireshark-dev] Checksum filterable fields
On Tue, Jul 2, 2013 at 9:17 PM, wrote:
I like your idea better as it pr
Done in rev 50323.
-Original Message-
From: Maynard, Chris
To: wireshark-dev
Sent: Tue, Jul 2, 2013 4:04 pm
Subject: Re: [Wireshark-dev] [Wireshark-commits] rev 50322: /trunk/epan/
/trunk/epan/: expert.c expert.h
Should we separate "Unknown/Disabled"?
Checksum validation may be dis
No explicit plans, it was just a copy/paste/merge of hf_ and preference
functionality. While I think the GUI could take advantage of it, I was torn as
to which GUI (GTK or qt) any new functionality would be developed. Since I
don't know either that well, I remain concentrated on making all
What about dissectors that register fields from other protocols? See the
output of checkfiltername.pl run over the dissectors directory. Many of the
display filters it (falsely) complains about are legitimate filter names
because dissectors "share" fields.
-Original Message-
From:
I wrote a utlity to help convert proto_tree_add_text calls into
proto_tree_add_item calls. The script is convert_proto_tree_add_text.pl and it
can be found in the tools directory. I wanted to share the data (attached) of
my first test run on packet-dlsw.c as a guide to those interested in usi
Or possibly merge all of the small packet-scsi-*.h files into a single header
file and add the necessary osd values there? I'm torn between encapsulation
and too many files. The dissectors themselves are large enough to warrant
their own files, but all of the header files are rather small.
The problem is that all "external" expert APIs end up calling static functions
within expert.c and I really don't want to have that much copy/paste for
something that will hopefully be removed shortly. Since the word is now out
through the -commit and -dev mailing lists, people should conside
Is there a way to provide the "unknown string" for the val_to_str call made in
hf_ registration (ie some derivation of the VALS() macro)? There are many
proto_tree_add_[u]int_format[_value] calls that are done strictly to provided
an "unknown string" for the val_to_str that is different than
Is there a way to provide the "unknown string" for the val_to_str call made in
hf_ registration (ie some derivation of the VALS() macro)? There are many
proto_tree_add_[u]int_format[_value] calls that are done strictly to provided
an "unknown string" for the val_to_str that is different than
No, the issue is a dissector wants to use "reserved" or "Unknown ",
etc instead of the strict "Unknown". Providing the numeric value that
accompanies that enumeration is almost secondary.
I think Jakub's idea is a good one, just didn't know if we wanted to convert
all (most) value_strings
-1 from me. It's my debugger of choice. While an integrated solution would be
better, I'm okay with the current project files. The default solution is nice
to add the dissectors/files you're working on/consistently modify for quick
reference. Outside of the debugger, I realize it is just a
I guess I like the overall setup of the solution file and the ability to jump
between tshark and Wireshark easily without opening new files. I don't believe
the "setup Windows development" steps (which I thought were very good) mention
supporting building Wireshark through the solution file, i
The check_col function in the Wireshark source has been deprecated for awhile,
but never officially removed. I've been modifying the source (removing calls)
so that it can be officially removed. The last big hurdle was the DCE/RPC
generated dissector files. I've had a difficult time trying t
The check_col function in the Wireshark source has been deprecated for awhile,
but never officially removed. I've been modifying the source (removing calls)
so that it can be officially removed. The last big hurdle was the DCE/RPC
generated dissector files. I've had a difficult time trying t
I like the suggestion of a "_ws." prefix, but my hesitation is backwards
compatibility. The only "not real" protocol filter I use consistently is
"malformed" and I like that simplicity. And the other "protocols" in
show_exception.c seem reasonable, but like you said, it starts to get ugly for
The attached patch implements the "_ws." prefix for "wireshark (internal)
protocols". Taps were (intentionally) left alone. The filters themselves work,
but it exposes a bug (?) with the display filter dialog - the
intellisense/autocomplete doesn't look for "protocols" after the first period
I think the issue is that not all generated dissectors can be generated on all
platforms Wireshark supports (for varying reasons). There were "separate
steps" (outside of the Wireshark build process) to generate the PIDL dissector
source as well as idl2wrs (GIOP) ones and I thought there were
Anders brought up a question in bug 9241 that I've always been curious about
(and I think the discussion is better served on -dev than the bug). We have
many TCP/UDP dissectors that don't have an IANA assigned port number or are not
setup as heuristic dissectors. In these cases their port numb
Done in r52474.
-Original Message-
From: Joerg Mayer
To: wireshark-dev
Sent: Wed, Oct 9, 2013 1:57 pm
Subject: Re: [Wireshark-dev] [Wireshark-commits] rev 52462: /trunk/
/trunk/docbook/: release-notes.asciidoc /trunk/epan/: expert.c packet.c proto.c
show_exception.c /trunk/ui/gtk/:
My vote would be to install in a central location and make it just another step
in http://www.wireshark.org/docs/wsdg_html_chunked/ChSetupWin32.html, just like
installing Visual Studio.
-Original Message-
From: Gerald Combs
To: Developer support list for Wireshark
Sent: Wed, Oct 9, 2
Fixed in r52670.
-Original Message-
From: Toralf Förster
To: wireshark-dev
Sent: Fri, Oct 18, 2013 10:35 am
Subject: [Wireshark-dev] compile error in latest svn tree at a 32 bit Gentoo
Linux
introduced between 52661:52666 :
CC libdissectors_la-packet-dplay.lo
packet-dns.c: In
These are independent of the bugs logged to Bugzilla, correct?
-Original Message-
From: Matthieu Patou
To: Joerg Mayer
Cc: Developer support list for Wireshark ; Samba
Technical ; Andrew Bartlett
Sent: Mon, Oct 21, 2013 10:17 am
Subject: Re: [Wireshark-dev] Wireshark PIDL generated d
Checked most of the patches into r52744
(http://anonsvn.wireshark.org/viewvc?view=revision&revision=52744)
Didn't integrate
0010-frsrpc-Regenerate-frsrpc-due-to-changes-in-the-pidl-.patch
0016-Regenerate-the-dnserver.patch
due to compile errors on Windows from applying the patch in bug 9301
These PIDL APIs do a wrapper of "add integer to tree" + "add integer to column
(info) data", not just a simple "add integer to tree, return value"
-Original Message-
From: Anders Broman
To: Developer support list for Wireshark
Sent: Mon, Oct 21, 2013 3:54 pm
Subject: [Wireshark-dev]
Moving sctp_stat.c to the "independent" ui directory causes to not
be found, causing a bunch of compile errors. Cursory glance says makefiles
(.nmake) should be setup to have the necessary GTK include directories as part
of the build, but apparently not.
I only tried to remove it in ui/sctp_stat.c, not the .h file (if it exists
there too) and it didn't work. ui/sctp_stat.c still includes other ui/gtk/
header files, so I'm guessing the dependency is still there.
-Original Message-
From: Alexis La Goutte
To: Developer support list for
ant to make the fix in the Wireshark source.
-Original Message-
From: Matthieu Patou
To: mmann78 ; wireshark-dev
Cc: abartlet ; samba-technical
Sent: Sat, Oct 26, 2013 7:26 pm
Subject: Re: [Wireshark-dev] Wireshark PIDL generated dissectors
On 10/21/2013 12:48 PM, mman...@net
I believe that was already addressed in r52965. (r52971 also has some
"compiler cleanup")
-Original Message-
From: Toralf Förster
To: wireshark-dev
Sent: Wed, Oct 30, 2013 10:13 am
Subject: [Wireshark-dev] r52963 introduced a build error
dissectors to compile on Windows.
Michael
-Original Message-
From: Matthieu Patou
To: mmann78 ; wireshark-dev
Cc: abartlet ; samba-technical
Sent: Sun, Oct 27, 2013 1:41 pm
Subject: Re: [Wireshark-dev] Wireshark PIDL generated dissectors
On 10/27/2013 09:16 AM
oth places is enough.
-Original Message-
From: Matthieu Patou
To: mmann78 ; wireshark-dev
Cc: abartlet ; samba-technical
Sent: Mon, Nov 4, 2013 3:25 am
Subject: Re: [Wireshark-dev] Wireshark PIDL generated dissectors
On 11/03/2013 08:26 AM, mman...@netscape.net wrote:
> Matthieu,
>
Reverted change in r53130.
-Original Message-
From: Guy Harris
To: wireshark-dev
Sent: Wed, Nov 6, 2013 5:50 pm
Subject: Re: [Wireshark-dev] [Wireshark-commits] rev 53118: /trunk/epan/
/trunk/epan/: reassemble.c
On Nov 6, 2013, at 1:59 PM, mm...@wireshark.org wrote:
> http://anons
Should tcp_dissect_pdus() add a data parameter to allow "private data" that was
passed to a dissector running over TCP to be used by the dissector itself?
I debated this when removing the pinfo->private data used to pass struct
tcpinfo data in r53036. The only current dissector that uses
tc
I was looking at making the "Decode As" functionality more generic, but my
current solution involves having dissectors handle a callback function that
passes in a capture_file* as an argument. Is that valid or does it cross
library boundaries creating unwanted dependencies?_
The ulterior motive is actually to reduce members in the packet_info*
structure. Some members could be converted to using
p_get_proto_data/p_add_proto_data, but the "protocol ID" is required for that
API. While I've seen it hacked into a few places in the GUI, I think it's
better design if
I don't think the GUI should have any specific dissector knowledge unless
"absolutely necessary" (separating "business logic" from UI). I know that's
not how all the code is written now, but I think it's something to strive for,
especially with the switch to qt (and how I've interpreted som
No, Decode As is currently quite limited (hardcoded) in what you can change
dissection to. But I'm guessing ethernet, IP, TCP/UDP (which are all
supported) cover a large majority of users.
There can be multiple factors to consider and that's why (I'm guessing) it's as
complex as it is (Haven'
A related question - Is packet_info->phdr == capture_file->phdr? That would
allow me to get the data I need always from packet_info* and not need the
capture_file*
-Original Message-
From: Jakub Zawadzki
To: Developer support list for Wireshark
Sent: Wed, Nov 13, 2013 3:39 pm
Subje
My similar, but less thorough idea was to have the "GUI" (GTK+/Qt/tshark) do
the proto_* value lookup (of only the protocols it needed) during some
"initialize" function, just like dissectors grab the "handles" of the other
dissectors they need in the proto_reg_handoff function.
Could making t
Of the ones I needed/interested in ("eth", "ip", "ipv6", "tcp", "udp", "sctp")
only "ip" had its proto_* variable in a header (in the dissectors directory).
Am I looking in the wrong place? Do you think that's something I should add
for the other dissectors? I know string compares are more e
Should there be separate APIs or should p_add_proto_data have a memory
allocator function and packet_scope() would go to info->pool and everything
else (NULL or file_scope) would go to where it is now?
-Original Message-
From: Evan Huus
To: Developer support list for Wireshark
Sent:
I developed convert_proto_tree_add_text.pl (in tools dir) for just this reason.
See http://www.wireshark.org/lists/wireshark-dev/201307/msg00073.html for
brief explanation.
If you're looking specifically at packet-ansi_a.c, I'm not sure how
straightforward the conversion will be. Without an
Is proto_field_is_references still a valid function?
In looking at the intent, it either looks completely useless or should be used
on almost all dissectors. I was leaning more towards useless because I can't
think of a scenario where tree (is already) != NULL, yet a dissector would be
called
So are you generating the dissector and then manually modifying it with your
"timecodeString" function? If so, then I believe you want
proto_tree_add_*_format_value
Using your example:
int s_octet4 = get_CDR_long(tvb,offset,stream_is_big_endian, boundary);
proto_tree_add_int_format_value(
If your type is FT_INT64 you use proto_tree_add_int64[_format_value]
If your type is FT_UINT64 you use proto_tree_add_uint64[_format_value]
Same is true for 32-bit values- signed and unsigned types have different APIs.
-Original Message-
From: andy.ling
To: Developer support list for
I don't think a solution currently exists with the parser.
I think you need to modify the omniorb parser (patches welcome!), either by
adding support for "additional" fields in the IDL or somehow providing a
"custom" data hook (as I don't think one is currently provided), perhaps in a
file s
Fixed in r53621.
-Original Message-
From: Guy Harris
To: wireshark-dev
Sent: Thu, Nov 28, 2013 1:10 am
Subject: Re: [Wireshark-dev] [Wireshark-commits] rev 53620:
/trunk/epan/dissectors/ /trunk/epan/dissectors/: packet-fc.c packet-fc.h
packet-fcp.c
On Nov 27, 2013, at 5:49 PM, mm.
Including config.h for the "conditional" codecs (sbc/G722/G726) breaks the
build on Windows. I originally had removed it (because it wasn't present on
the existing codecs), but I guess the "right" fix is adding an include
directory to the makefile.___
+1
-Original Message-
From: Pascal Quantin
To: Developer support list for Wireshark
Sent: Thu, Dec 5, 2013 3:33 pm
Subject: Re: [Wireshark-dev] Windows build setup - Concept required
Personally I find the GTK2 GUI much more polished than GTK3 on Windows (maybe
just a matter of ta
The best would be
proto_tree_add_item(seg_param_tree, hf_scsi_reserved, tvb, offset, 2,
ENC_BIG_ENDIAN) (obviously may need adjusting for your specfic situation)
offset += 2
so it's filterable (and users can possibly find situtions where reserved fields
aren't 0)
Different hf_ filters varia
There is a bug in Wireshark when a dissector has an hf_ variable of type
FT_INT64 and the requested length of the field is < 8 bytes. There is no
accounting for the sign bit (which has led dissectors to come up with their own
solutions). The attached patch attempts to address it. The questio
I believe I just missed committing that file when I added the FT_SYSTEM_ID
type. Committed (functionality) to rev 54394 and thanks for the catch!
-Original Message-
From: Martin Mathieson
To: Developer support list for Wireshark
Sent: Mon, Dec 23, 2013 12:44 pm
Subject: [Wireshark-d
Isn't it simple enough to add a proto_tree_add_gsm_sms_item (or similar) API
and enforce the hf_ variables have ENC_3GPP_TS_23_038 encoding? Shouldn't that
be able to wrap the gsm_sms_char_7bit_unpack() / gsm_sms_chars_to_utf8()? I
don't think the meaning of the length field of proto_tree_add
I started working on the "Fileshark" concept [1]. As part of the
architecture, I don't believe "Fileshark" should include the dissector.lib as
noted in the original discussion [2], but should include the rest of the epan
directory ($LIBWIRESHARK_OBJECTS). I hacked the nmake configuration i
Although I have to say I kinda liked Michal's suggestion of Omnivoroushark (or
something similar with "omni") if fileshark doesn't work out. My only
complaint with Omnivoroushark is that we want to separate capture files
(Wireshark) from non-capture (fileshark) files, so it's not really "omni"
My guess is that it doesn't like the commented out tfshark-tap-register.c (that
I was using as a placeholder). The attached patch fixes that.
-Original Message-
From: Joerg Mayer
To: wireshark-dev
Sent: Wed, Jan 8, 2014 3:01 am
Subject: [Wireshark-dev] Linking error tfshark
Linking
One of the "features" that could be added now that expert items are
registered/filtered is user assigned error levels for individual expert items
(because certain expert scenarios may be more/less important to various users).
Patches welcome!
-Original Message-
From: Gerald Combs
To:
Unfortunately, yes it still needs to link with libwiretap. I believe my
initial copy/paste tried to remove it but I ended up restoring it so I could at
least commit the "initial" version of fileshark. Perhaps I didn't restore it
in all build configurations. You can send me a patch for autoto
per support list for Wireshark ; mmann78
Sent: Fri, Jan 10, 2014 8:07 am
Subject: Re: [Wireshark-dev] Linking error tfshark
Ok, I sent patch to you.
I have one more question: how tfshark works?
./tshark -V -r file.elf # works ok
./tfshark -V -r file.elf # does not work
How to display dissector
Without looking at the details of the patch, my thoughts are:
1. I like the fact that a "workaround" has been created for insufficient
heuristics. I just hope it doesn't have the unintended consequence of weaker
heuristics being created.
2. What I don't like is getting non capture file sup
On a related note, it seems like Gerrit encourages more comments within its
interface when discussing a bug/enhancement then doing it Bugzilla (where all
outside patches used to go through). It was (is) always nice to have a
"masochist" (-bugs subscriber) interject something into a bug in Bug
The reason I put "list" in quotes was because I wasn't sure of the form. I've
never followed -bugs, but I do frequently skim the archive. And I understand
why others follow or skim -commits. I was okay with the interface TortoiseSVN
provided me when grabbing the latest code if I wanted to f
My biggest frustration is noted by the statement:
"However, as most use on other platforms tends to be command-line git, most
books and guides tend to concentrate on that so windows users may actually find
it easier to start with the command line and then move to graphical clients
when they ar
I can't consistently view the code of patches submitted to Gerrit (the
Side-by-Side or Unified links). I've tried on IE8 and 9 as well as Firefox v28
(all on Windows) and get the same consistently inconsistent results (some
patches work, some don't. Some files within a particular patch are vi
See doc/README.request_response_tracking
-Original Message-
From: qiaoyin_yang
To: wireshark-dev
Sent: Tue, Apr 1, 2014 10:14 am
Subject: [Wireshark-dev] how to decode a packet based on the flags in the
previous packet.
Hello All,
I am writing a dissector. The capturedtraffic has
You don't need to open a Bugzilla ticket strictly for an enhancement. However
you may want to open a Bugzilla ticket to supply a capture that exercises a
dissector enhancement (for fuzzbot and regression testing) if one hasn't
already been provided. You can then reference the Gerrit link in th
I've taken the pre-commit hook file provided in \tools and put it in my git
hooks folder. However, whenever I commit something (I've focused mostly on
dissector patches and they all fail this way), it fails with "Search pattern
not terminated at ./tools/checkhf.pl line 564."
When I run checkh
Many thanks! Fix was committed in https://code.wireshark.org/review/#/c/971/
(Still not sure of the "why" it failed , but I'll gladly take this solution)
-Original Message-
From: Hadriel Kaplan
To: Developer support list for Wireshark
Sent: Fri, Apr 4, 2014 11:56 pm
Subject: Re: [Wir
I've seen a handful of patches submitted to Gerrit with [WIP] in the title.
Obviously this means "work in progress", but what does it mean for reviewers of
the patch? Should reviews be held off until more/better patches are submitted
(with help accepted)? Notification that a feature is being
He's not the only one! ;)
https://en.wikipedia.org/wiki/Usage_share_of_operating_systems
-Original Message-
From: Graham Bloice
To: Developer support list for Wireshark
Sent: Wed, Apr 16, 2014 11:20 am
Subject: Re: [Wireshark-dev] Visual studio versions
On 16 April 2014 16:03, Ande
Congratulations Roland! You have just won yourself a free copy of Wireshark on
the platform of your choice. Just go to http://www.wireshark.org/download.html
to claim your prize and enter "Bug1" in the checkout screen.
(Wait... maybe I shouldn't give out the free copy checkout code t
The short answer is "write it as a builtin" if you plan on submitting the
dissector code to Wireshark. Plugins come with more "file bloat", so they are
discouraged when becoming part of the official Wireshark source.
Many developers start with the plugin for faster build time, when the dissec
After looking at this, I'd have to say the DTLS decryption test is "flawed".
It sets up a key to decifer traffic as HTTP, but it's not really HTTP, it's
just a bunch of ASCII strings. I can change it to any of the valid dissectors
and presuming the DTLS decyption is done correctly (which I pr
I have found myself from time to time needing to temporarily disable the
pre-commit hook (ie error is ignorable). The situation I ran into today I
don't think should have been.
I created a patch that removed a header file from epan\dissectors
(packet-ipsec.h). When I tried to commit it, th
I believe I just deleted the file in Windows Explorer, but the "commit list"
(and their file status) doesn't look any different than if I had used the git
menu.
-Original Message-
From: Evan Huus
To: Developer support list for Wireshark
Sent: Sat, Apr 26, 2014 10:24 pm
Subject: R
Yes. I would say that it's down.
-Original Message-
From: Anders Broman
To: Developer support list for Wireshark ; Gerald
Combs
Sent: Sat, May 3, 2014 6:37 am
Subject: [Wireshark-dev] Gerrit down?
Hi,
Is any one else having problem accessing Gerrit?
Regards
Anders
___
I wanted to add a "conversation filter" for a dissector. I followed the "GUI
independent" API of register_dissector_filter() and successfully added my
filter under the Analyze -> Conversation Filter menu item. However, I noticed
a "different" conversation filter menu when right-clicking on a
I'm okay with leaving them out. I was hoping they would have been farther
along by now. I also thought Sharkfest will infuse some life back into them as
I think the topic of "managing multi-frame or bundled PDU"s is critical to
taking "Fileshark" any farther.
Michael
-Original Messa
In an effort to further remove proto_tree_add_text calls from the Wireshark
source, I've created proto_tree_add_subtree and proto_tree_add_subtree_format.
The use case is to combine proto_tree_add_text + proto_item_add_subtree into a
single call when the intent of the dissector is to create a
To the discussion on "generated" source files - I still can't build the DCERPC
files on Windows (I blame Yapp, but it could also be ignorance). It would be
GREAT if the build magicians could fix that.
However, thanks to Evan at Sharkfest, I now have a lubuntu setup that I am
trying to learn.
I have no objection to adding G_GNUC_WARN_UNUSED_RESULT to
proto_tree_add_subtree[_format] as it appears to already be used on
proto_item_add_subtree.
The intent of proto_tree_add_subtree[_format] is more directed at trying to
remove proto_tree_add_text calls. The use of proto_tree_add_text
Yes I think tcp_dissect_pdus should be used as much as possible. I even made a
list (at least a few months ago) of "potential" dissectors that could be
converted:
packet-banana.c
packet-beep.c - maybe
packet-bzr.c
packet-cigi.c
packet-classicstun.c
packet-distcc.c
packet-dtn.c
packet-dtpt.c
p
The list I provided
(http://www.wireshark.org/lists/wireshark-dev/201407/msg00018.html) follows the
criteria mentioned by Guy. The "maybes" are where it appeared at first/quick
glance that the "contents can be calculated within the first N bytes", but
there was too much logic/code to follow t
I finished the conversion of proto_tree_add_text calls that were acting as
"subtree labels" into proto_tree_add_subtree[_format]. This removed almost
4000 calls in the dissector directory (over 4000 if you include the plugins)
and brings the current total proto_tree_add_text count in the disse
The "not useless" probably fall under 2 categories:
1. Field label with no printf style arguments, usually for a byte array.
Popular ones would be "Data", "Padding" or "Reserved". I know these aren't
filterable, but sometimes I like (understand) how it's displayed (just
highlighting bytes) in
Adding a subtree requires (up to) 2 additional arguments (ett and if
proto_item* is still going to be used), and I just thought it would be "API
bloat" to add a proto_tree_add_item_with_subtree (and all of the other possible
combinations). proto_item_add_subtree still has its uses ;)
Next pi
The proto_tree_add_subtree[_format] code refactoring was very intentionally
post-1.12 and I don't see much point to just having the API there without it.
Further refactoring of specific dissectors like SSL and DTLS probably won't be
backported either, but if it is breaking a proto_tree_add_su
Yes "expert info" APIs (even the deceiving proto_tree_add_expert and
proto_tree_add_expert_format) need to be called independent of the presence of
a tree (just like column APIs). It can sometimes be difficult to detect that
expert API calls are "hidden" under an if (tree) call,
-Ori
+1
I was trying to hold out until the CMake stuff for Windows is complete. Since
it sounds close, I thought I could just deal with merging the removal of O2
option for awhile.
-Original Message-
From: Anders Broman
To: Developer support list for Wireshark
Sent: Mon, Jul 28, 20
I think a lot of similar refactoring can be done in the area of "statistics
taps". The GUI layer for many of them is (or should be) fairly thin, mostly
separated by number and types of columns. By using epan (and ui) directory as
a "middle layer", we can achieve more standard usage of "stati
proto_tree_add_subtree should be proto_tree_add_text + proto_item_add_subtree
(where the return value of proto_tree_add_text is input to
proto_item_add_subtree).
When I originally created proto_tree_add_subtree, I thought it would be "more
optimized" to include the function body of proto_tre
I thought we intentionally wanted a (core?) developer to bless the patch (with
+1) before we sent it to the Petri-Dish. No sense in testing for compile
errors if someone doesn't at least like the idea of the patch. This may
dilute the meaning of +1 review a little, but we also didn't necessa
1 - 100 of 225 matches
Mail list logo
