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
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:
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
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 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...
... 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
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
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
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
I started looking at the long options, but I thought they also needed a
corresponding mnemonic letter as well. I'll take a look at what you put in
Gerrit. Thanks for the head start!
-Original Message-
From: Jim Young
To: Developer support list for Wireshark
Sent: Tue, Jul 14, 2015
Command-line option sounds good, but it will probably take longer to figure out
the option letter (how many do we have left?) than the functionality that does
the enable/disable. Suggestions for option "letter" to use? Have we gone
beyond just letters yet? A letter for each enable and disabl
I thought somebody might complain about something like this, but I was more
focused on the Wireshark (packet) context menu, where I was less inclined to
make changes. This however seems like a more valid use case to consider. My
question back would be - what "string" should be used by tshark?
in general", it certainly has some
flexibility to do so. Unless there are major issues/comments, I'll submit in a
few days (presuming all pass Petri-Dish)
-Original Message-
From: mmann78
To: wireshark-dev
Sent: Fri, Jul 10, 2015 8:45 pm
Subject: Re: [Wireshark-de
Some more thoughts about enabling/disabling heuristic dissectors based on some
of the comments in the Gerrit review as well as this thread.
1. I'm now leaning more towards heuristic dissectors having their own name so
something "more intelligible" can be presented to the user. Right now we h
I think there's a mixture of both "Heuristic Protocols" and "Heuristic
dissectors" and I'm not sure how clean the list would look if you merged the
two into a single list (this just being anecdotal evidence browsing the lists
in both tabs).
The original motivation for this patch came from bug
uot; the context menu
preferences for any protocol that has a heuristic dissector would be a good
compromise?
-Original Message-
From: Hadriel Kaplan
To: Developer support list for Wireshark
Cc: mmann78
Sent: Sat, Jul 4, 2015 2:38 pm
Subject: Enabling/disabling ANY heuristic dissector
Howd
em to whatever "global" structure ends
up being created.
-Original Message-
From: Hadriel Kaplan
To: Developer support list for Wireshark
Cc: mmann78
Sent: Sat, Jul 4, 2015 2:38 pm
Subject: Enabling/disabling ANY heuristic dissector
Howdy,
as part of the discussion for several
I'd recommend attaching the capture file to a Bugzilla ticket (with all of the
links mentioned here) and possibly your patch of the internal dissector.
Perhaps somebody can take it from there.
As a side note, I still don't know how I feel about dissectors being "pulled
from the wild" from d
+1.
I know the ASN.1 dissectors can be generated on all platforms, it's a few of
the others I'm worried about (DCE/RPC)
-Original Message-
From: Evan Huus
To: Developer support list for Wireshark
Sent: Thu, Jun 25, 2015 5:38 pm
Subject: Re: [Wireshark-dev] Autogenerated files in s
-Original Message-
From: Guy Harris
To: Developer support list for Wireshark
Sent: Wed, Jun 10, 2015 7:43 pm
Subject: Re: [Wireshark-dev] SRT vs RTD
On Apr 28, 2015, at 7:32 AM, mman...@netscape.net wrote:
> I started
working on ensuring that SRT (service response time) stats th
Are you talking about protocol preferences having "dependencies" on each other
so that one preference field effects another?
Are you talking about other GUI items in the (main) menu being based on
protocol preferences?
-Original Message-
From: Robert Cragie
To: Developer support l
Someone can correct me, but I believe Decode As works off of the numeric value
passed into dissector_try_uint and associates it with a dissector (function).
UDP/TCP/IP/Ethernet (and others) have a "unique" numeric value (port/protocol)
to pass into dissector_try_uint, while PCLI (and a few oth
Do you want to post your current progress to the existing review and I can take
a look at it from there? That's probably the easiest way to look at the "rough
edges". You definitely want a dissector table with type FT_UINT32 (not a
string)
-Original Message-
From: Luke Mewburn
Certainly fine to move the discussion here IMO. I get better "text formatting"
in email form than I do from Gerrit anyway.
Some comments:
1. I'm of the opinion that no NEW development should have enum preferences for
choosing subdissectors. Dissectors that need to give user an option to cha
>From the "maybe you were curious, but afraid to ask" file, some stats I've
>collected on proto_tree_add_text calls:
1292 calls in the dissector directory [1] from 86 files (for an average of 15
calls per dissector that have at least one)
21 calls outside of the dissector directory, mostly
I started working on ensuring that SRT (service response time) stats that are
available in Wireshark are also available in TShark (taking bug 9363 a step
farther). I initially collected my data by doing a grep on ",srt" and
comparing the filenames it showed up on in \ui\cli and \ui\gtk. The
I ran into the same issue and just downloaded zlib128.zip manually through web
browser (IE)
-Original Message-
From: Pascal Quantin
To: Developer support list for Wireshark
Sent: Thu, Apr 9, 2015 9:47 am
Subject: Re: [Wireshark-dev] nmake setup target failing for me
2015-
So are you thinking along the lines of prefs_register_dissector_preference that
would create a dropdown list (like an enum preference) based on dissector table
entries? I think my only real objection to Stig's suggestions was the thought
of using something outside of a dissector table controll
Right now there is no way to include a "Decode As" protocol list as a specific
preference of a dissector.
I thought I may get some resistance here because I broke "backwards
compatibility", but I thought the trade off of more easily adding dissectors to
a Decode As list and having an "overall"
I code
anymore.
-Original Message-
From: mmann78
To: wireshark-dev
Sent: Mon, Mar 16, 2015 4:19 pm
Subject: enum preferences vs Go Fish
The SocketCan dissector has an enumerated preference to pick its subdissector,
manually finding all enumerated options through find_dissector(). This doesn&#
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 sour
To me this is a granularity/filter issue. For dissectors that I don't
personally use (but want to increase filterability), I try to put as many
reserved bytes into a single hf_ field, mostly out of laziness (for those that
care more about the protocol to clean up/decide granularity). But it
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 gi
Working on address types with name resolution, it seems it would perform better
if get_manuf_name didn't have wmem_allocator with it. Looking into the code, I
can model it after the ethernet name lookup where there's always a "hex string
backup" in its hash table if name can't be found. But w
Made a "first draft" at https://code.wireshark.org/review/7019/
-Original Message-
From: Guy Harris
To: Developer support list for Wireshark
Sent: Fri, Jan 16, 2015 10:55 pm
Subject: Re: [Wireshark-dev] address to string optimization
On Jan 16, 2015, at 11:34 AM, mman...@netscape.
It's the preferred way to exchange data between dissectors because you're a lot
more sure of its scope than some of the other methods. For most cases, you're
just passing the data between a dissector and it's subdissector (rarely does it
go farther than that).
If TCP is passing its data to S
I agree with most of the commit, but the reason I left of some of the
proto_tree_add_text/proto_item_add_subtree calls alone in the dissectors was
that I thought they should be converted to use proto_tree_add_bitmask (or
something similar). When I did the original "conversion", I just didn't w
I still like the idea of the address types being "centrally registered" (in
epan directory) and not put into the dissector code, mostly because many of the
address types are used in multiple dissector/protocols. You may also introduce
epan dependencies (like from proto.c) with the dissectors,
A few weeks ago I stumbled across the following comment in address_to_str.c:
/*XXX FIXME the code below may be called very very frequently in the future.
optimize it for speed and get rid of the slow sprintfs */
/* XXX - perhaps we should have individual address types register
a table of r
Looking for more feedback on https://code.wireshark.org/review/6304/
My thought process was that fields with a small number of bytes (< 8, maybe <
16), the field displays better with a space in between bytes. Some fields
however are variable length between "something small" and "something larg
One thing I noticed when I reviewed one of the .mailman patches you've
submitted was that some authors have multiple email addresses. Do we really
want to include them all? I thought the current AUTHORS file typically only
has one (hopefully "latest" email address)
-Original Message
Ok, so I'm trying to go down the route of adding different "BASE" types for
FT_BYTES. I thought it would be fairly straightforward, but the problem I'm
running into is that fvalue_to_string_repr() never gets the "BASE" value so I
can distinguish between BASE_NONE, BASE_DOT and BASE_DASH.
Coul
I was looking to add an FT_ enumeration for Fibre Channel addresses. See
https://code.wireshark.org/review/6098/ for my attempt. Because the Fibre
Channel address already had an "address type" (AT_FC), I thought a
corresponding FT_ was appropriate. That seems to be how many of the "address
While they were probably pushed from a single branch, the changes seem
"independent" enough, so I didn't try to find the "last" one to pick up all
changes. Hopefully it doesn't tie up the Petri-Dish too long...
-Original Message-
From: Alexis La Goutte
To: Developer support lis
I've kicked off the Petri-Dish for most (all?) of the changes. Am I correct in
understanding most of the patches introduce "optional" features, so they
shouldn't break existing cmake user setups (of platforms the Petri-Dish doesn't
have)?
Michael
-Original Message-
From: Maarte
I was noticing that we have 2 sets of "conversation filters"
1. The Conversation filters from the Analyze menu (GTK). These are controlled
as the "dissector level" where the dissector "registers" filters it wants.
Currently Profinet and EtherNet/IP dissectors use this.
2. The Conversation filt
I just submitted a patch for review that completely removes the private_data
member of the packet_info structure:
https://code.wireshark.org/review/5487
I'm mentioning it here for better visibility in case there are objections.
I've reworked all of the dissector code in the Wireshark master b
as much.
-Original Message-
From: mmann78
To: wireshark-dev
Sent: Sat, Nov 22, 2014 4:41 pm
Subject: [Wireshark-dev] media strings and pinfo->private_data
I'm looking into removing the use of pinfo->private_data in all current
dissectors in favor of only using the &
I'm looking into removing the use of pinfo->private_data in all current
dissectors in favor of only using the "data" parameter in new-style dissectors.
The last large remaining use of pinfo->private_data is to pass "string media"
between various dissectors. Some of the "receiving" dissectors
So for the Windows build is there nmake + cmake or cmake only? I thought I saw
some Petri-Dish runs with failed (cmake) Windows builds, but then some others
with successful (cmake?) builds. So is cmake fully functional for Windows now?
Is Petri Dish is going to be the only "user" that change
This and the subsequent commit (61676733b451bc8b3a83dee47df71c5ffe3f19dd) that
regenerated all of the DCE/RPC dissectors doesn't pass the "eye test" to me.
The newly generated code now has a lot of what appear to be "duplicative" calls
to ALIGN_TO_x_BYTES. The second call is effectively a "no
Unfortunately, I can't share the driver.
If these are "bugs", I can log them in bugzilla (as Extcap is now officially
part of the Wireshark source). I believe both issues could be tested with the
extcap example provided (extcap_example.py), although if someone asked/needed
it, I could proba
I created an Extcap driver in Windows and noticed a few things:
1. Configuration is only passed if I launch interfaceSettings from opening
Window. It is not saved or passed to driver every time. Is the driver
supposed to save the last configuration passed to it?
2. My extcap driver is a cons
You can group fields in whatever way makes sense for your protocol, it doesn't
always have to be flat or a "real" field (or a "real" structure). I would
think that you would just call proto_tree_add_subtree() and pass it the title
of or . You may have to call proto_item_set_len
later on the
I submitted a patch to be backported to the 1.12 branch [1]. I wanted to run
it through the Petri-Dish, but it failed on the Ubuntu build [2], but doesn't
seem related to my change. It appears a solution to the failure is provided
by this patch [3]. Could someone please take a look? I'm no
Yes it's true assuming "ti_channel" isn't otherwise used.
-Original Message-
From: Juan Jose Martin Carrascosa
To: Developer support list for Wireshark
Sent: Tue, Aug 26, 2014 11:32 am
Subject: Re: [Wireshark-dev] Equivalency between APIs
Thanks for your reply. Regarding the last
You are correct. proto_tree_add_subtree is for no printf-style arguments,
proto_tree_add_subtree_format is for when you need printf-style arguments for
your subtree.
One thing to check (if you're compiler doesn't do it for you because somebody's
will) is that you may no longer need the proto
The "Reply 'Done'" Button can be used by the developer making the changes, but
it doesn't have to be. There just needs to be some indication that it's been
addressed ("Reply Done" or a comment posted after another patch is uploaded is
fine) to make the next review go faster. In this particul
Is the list of protocols that IMSI goes across finite? Don't you really just
want a "Conversation filter" that would be generated to include all the
necessary protocols? The registering dissector has control over how the filter
is constructed. Perhaps modify "Conversation filter menu item" t
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
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 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
+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
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
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
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 "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
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 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
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
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
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.
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
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
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
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 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
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
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
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
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
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
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
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 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
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
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
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
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
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
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
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
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
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
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:
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
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"
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
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 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
1 - 100 of 225 matches
Mail list logo
