Why would a plugin dissector ever be better than a builtin? I see development
speed mentioned as a plus, but isn't the lack of platform independent code a
much greater detriment?
Is there any reason why the current plugins couldn't be converted to built-in
dissectors? I dove in and
(just added myself to the mailing list so I can include reply history to the
topic. This message touches on both Jaap's and Roland's comments)
Profinet and Ethercat were the 2 protocols I was most looking at to convert to
built-ins. Being in the industrial protocol space, they are (could be)
Pardon my ignorance on a few of these points, still learning the ropes. I
don't mean to incite protocol flame wars, just trying to analyze code.
However reading README.plugin I still get the impression that
1. Plugins aren't supported on all platforms. The Windows only was just a BIG
I was greatly intrigued by the patch from bug 6086 and my expectation was that
1. It would work on all protocols that had a FT_ABSOLUTE_TIME item (satisfying
most of bug 1381)
2. Missing date/time fields in the filter would be set to 0 and considered
don't care (ie frame.time == 2011-08-02
Already noted in bug 6144
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=6144
-Original Message-
From: Stephen Fisher st...@stephen-fisher.com
To: Developer support list for Wireshark wireshark-dev@wireshark.org
Sent: Tue, Aug 30, 2011 11:45 am
Subject: Re: [Wireshark-dev] source
Could the display filter crash be related to:
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=5284 or
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=6031 (duplicate of 5284,
but the description is closer to yours)
or
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=6172
Mike
Is it possible to setup a display filter to catch all malformed packets (those
noted as [Malformed Packet] in Info column)? I'm working with a dissector that
could probably use a little more graceful error checking and I have a few
large capture files that I'd like to use to catch any
After submitting patches for
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=6446 (IMAP)
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=6470 (SMTP)
I started thinking that there probably is a more general solution to
implementing filtering for line based protocols (dissectors that
How exactly does the BuildBot fuzztesting work? Do the BuildBots take all of
the mined capture files for fuzztesting and if a fuzz-generated capture file
generates a fatal error, that generated file is automatically posted as a bug?
So in tracking down the error, the supplied capture file in
I'm working with a dissector that implements request/response tracking
modeled after README.request_response_tracking. The one problem I noticed with
the dissector is that it checks the if visited flag
(pinfo-fd-flags.visited) per the example, but it also checks to see if the
protocol tree
Yea, I've had to do a distclean when switching between the two platforms
since they share common folders (and thus object files). Alan's methodology of
installing the source twice and keeping both platforms separate is probably
the only way to avoid the distclean and why there's the
I'd like to get back to working on bug 2794 (Questionable display filter
fields) and hopefully have it ready for the 1.8 release. I realize its a lot
of brute force work of search/replace but I will gladly volunteer in the name
of consistency. I feel the script (checkfiltername.pl) was a
I assume you're refering to
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=3760
Of course any help/patches would be appreciated.
-Original Message-
From: Paul Teeter ptee...@gmail.com
To: wireshark-dev wireshark-dev@wireshark.org
Sent: Sat, May 26, 2012 1:53 pm
Subject:
I was looking at the possibility of implementing an API for statistics
preferences (for say, stats_tree plugin). The preference module (prefs.[ch])
seems to be written generically enough to support such a concept, however I'm
having a little trouble with the implementation. I'd like to
packet-cip.[ch] exposes some value_string variables, you should be able to use
that as an example.
-Original Message-
From: Richard Sharpe realrichardsha...@gmail.com
To: Developer support list for Wireshark wireshark-dev@wireshark.org
Sent: Tue, Jul 3, 2012 10:51 am
Subject:
Also, prefs_nameres.c shouldn't be building anymore. The top of the tree
should have it removed from any makefiles (unless I screwed up the patch). The
functionality of prefs_nameres.c was replaced with the generic handling of
preferences that used to be unique to only protocol preferences.
Yes, the following files can now be deleted:
\wireshark\ui\gtk\prefs_nameres.c
\wireshark\ui\gtk\prefs_nameres.h
\wireshark\ui\gtk\prefs_print.c
\wireshark\ui\gtk\prefs_print.h
\wireshark\ui\gtk\prefs_protocols.c
\wireshark\ui\gtk\prefs_protocols.h
\wireshark\ui\gtk\prefs_taps.c
Just let me know if you want me to keep track of the changed first field of a
protocol filter for release note purposes. Per bug 2794, I planned on
changing a bunch once I can come up with a consistent naming convention (and
then change dissectors to follow that convention). The two biggest
I was running checkfiltername.pl and discovered that the idl2wrs generated
dissectors don't follow the convention of using the filter name registered with
the protocol as the start of any display filter name. Was this just an
oversight, or was it intentional?
I believe the attached patch
I guess where I (and the .pl script) got tripped up was the fact that there
were separate protocols registered and they gave the impression they were
unique and not just one big protocol broken up over several files. The
script just generates the questionable filters, I was using human
The code won't look as clean, but I can add the backwards compatibility
functionality.
-Original Message-
From: Stig Bjørlykke s...@bjorlykke.org
To: Developer support list for Wireshark wireshark-dev@wireshark.org
Sent: Wed, Aug 1, 2012 6:51 am
Subject: [Wireshark-dev] Warnings when
Technically the prefences aren't obsolete, they are just renamed for
(internally) optimized code. Should the old names still be noted as such in
a current preferences file? The main reason for the new optimized code was
to get the general preferences to use the preference API, like all of
I can fix all but the void** cast issues fairly quickly. Do you want me to
undo the custom preferences until there is a better solution? I don't
think it's something we can just throw an #if 0 around.
-Original Message-
From: Guy Harris g...@alum.mit.edu
To: wireshark-dev
Sort of brute force rethinking, but r44359 should compile now.
-Original Message-
From: Guy Harris g...@alum.mit.edu
To: wireshark-dev wireshark-dev@wireshark.org
Sent: Wed, Aug 8, 2012 1:55 pm
Subject: Re: [Wireshark-dev] [Wireshark-commits] rev 44348: /trunk/
/trunk/epan/:
This should be fixed in r44359
-Original Message-
From: Stig Bjørlykke s...@bjorlykke.org
To: Developer support list for Wireshark wireshark-dev@wireshark.org
Sent: Wed, Aug 1, 2012 6:51 am
Subject: [Wireshark-dev] Warnings when loading preferences
Hi.
After upgrading my local
Fixed in r44370
-Original Message-
From: Michael Tuexen michael.tue...@lurchi.franken.de
To: Developer support list for Wireshark wireshark-dev@wireshark.org
Sent: Wed, Aug 8, 2012 5:47 pm
Subject: Re: [Wireshark-dev] Warnings when loading preferences
It seems that there is a problem
Does this patch help? If not, I would consider blaming guids_add_guid for not
initializing the key member of the emem_tree_key_t structure. Even though I
think either would be caught by the DISSECTOR_ASSERT_NOT_REACHED macro. Also,
are there warning for emem_tree_lookup32_array() as well?
I believe you're referring to this bug:
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=4561
-Original Message-
From: John Powell jrp...@gmail.com
To: Developer support list for Wireshark wireshark-dev@wireshark.org
Sent: Fri, Aug 10, 2012 8:58 am
Subject: Re: [Wireshark-dev]
Would it be possible to make g_convert_with_iconv an ep_ or se_ type function
or is there something obvious I'm missing if I turned this into an official
enhancement request in bugzilla? Could/Would this be related to Wireshark
providing better UTF8
I did some grepping and converted a bunch of g_ calls to use ep_ and se_
memory. The only true memory leaks were in rev 44491, the rest just had
potential (or philosophically shouldn't be using g_ calls), mostly through
possible exception handling. Because of this, I'm only scheduling rev
It's a bit clunky, but would ws_strlen() be a solution? Wrapping strlen() but
ensuring the NULL check is done?
-Original Message-
From: Jeff Morriss jeff.morriss...@gmail.com
To: Developer support list for Wireshark wireshark-dev@wireshark.org
Sent: Wed, Aug 15, 2012 10:17 am
Subject:
Would it be possible to have the buildbot note its revision when it generates a
bug?
-Original Message-
From: Bill Meier wme...@newsguy.com
To: wireshark-dev wireshark-dev@wireshark.org
Sent: Fri, Aug 17, 2012 8:47 am
Subject: Re: [Wireshark-dev] [Wireshark-bugs] [Bug 7647] Buildbot
Is pcapr.net still granting new user access? I entered by email address,
assuming an automated script response, last week and got nothing. I tried a
few days later thinking maybe I fatfingered my email address, still no
response. Is there a real person behind the curtain and they just don't
Burned by the ASN.1 compiler again (I'll eventually learn to double-check the
top of a dissector file when looking for general improvements with dissectors).
However, I think the better fix would be to make the key
session-scope_allocated as well. That was just an oversight on my part (apart
In an attempt to minimize g_ allocated memory in the dissectors, I have the
following questions/observations:
1. Is there any advantage to a dissector having a make printable string
function (basically allocating memory to walk a tvb picking out printable
characters and leaving the rest as
Sylvain,
The checkdisplayfilter.pl script reflects my interpretation of the desired
display filter format, and since there hasn't been that much feedback on the
outputted results (with Pascal's comments on the GSM dissectors being the
exception), I continue to plod along manually checking
Would the patch from Bug 2047
(https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=2047) also be
helpful/relevant?
-Original Message-
From: Jakub Zawadzki darkjames...@darkjames.pl
To: Developer support list for Wireshark wireshark-dev@wireshark.org
Sent: Mon, Aug 20, 2012 9:09 am
I guess this makes #3 from
http://www.wireshark.org/lists/wireshark-dev/201208/msg00164.html an
unfortunate yes. I guess I had the same idea you did - slowly replacing all
g_ alloced memory in dissectors with se_ alloced memory where possible, and
replace the rest of the g_ alloced memory
Unfortunately the CIP in DeviceNet is drastically different than the CIP that
runs over Ethernet/IP. I think you'd be much better off just writing a pure
DeviceNet dissector because I think you'd spend just as much time trying to
manipulate packets (if its even possible) to make them look
SCTP isn't the only dissector doing it's own reassembly (at least from what I
can see grepping g_ allocation calls), but I agree having it use the reassembly
API (if possible) would be preferred over reverting my se_ alloc changes.
Unfortunately, sometimes ignorance is the reason a provided
I'll revert the GMR-1 display filter name changes and update
checkdisplayfilter.pl to accept periods in the base filter name, but I will
note their existance in another FILE LIST grouping in case other dissectors
don't have a valuable reason to do so.
-Original Message-
From: Pascal
Did you borrow much of the actual dissection (ie make extern functions) from
CIP or was it mostly copy/paste (just curiosity on my part)? I assume some of
the display filters may have shared names.
As far as the fragementation goes, I have 2 suggestions:
1. The fragmentation API provided in
It appears that the reassembly API doesn't handle inserting known middle
fragments (preferring them to be known consecutively). This appears to be at
least one of the reasons the SCTP dissector does its own reassembly and why the
new Bluetooth dissector from bug 7675
In working on bug 3534, one of the review comments was that a tree != NULL
check placed near the start of the dissector should be removed as it prevented
some of the COL_INFO/expert info data from being populated if tree was NULL.
While I agree the tree != NULL check should probably be
While trying to remove calls, I came across some curious code in
packet-ieee80211.c
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
(sorry about the previous email; trigger happy enter key)
While trying to remove decode_numeric_bitfield() calls, I came across some
curious code in packet-ieee80211.c.
hf_ieee80211_block_ack_control_multi_tid_info and
hf_ieee80211_block_ack_control_compressed_tid_info both use
Isn't this bug 2892? (https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=2892)
Or 4314? (https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=4314)
-Original Message-
From: Ed Beroset bero...@mindspring.com
To: Developer support list for Wireshark wireshark-dev@wireshark.org
Sent:
I ran some fuzztesting overnight (on a 32-bit WinXP VM, off of trunk), and when
I checked on it this morning, I had WARNING **: Too many taps queued so many
times, it scrolled beyond the top of my window.
I've never seen this before. Could it be a result of the files I was testing?
New bug
You would be correct, it's a loop over a tapping point. Logged bug 7845 and
CCed the original author just because the specs aren't free. Probably a
trivial fix though.
-Original Message-
From: Jaap Keuter jaap.keu...@xs4all.nl
To: Developer support list for Wireshark
Pascal,
Did you settle on the value, value+1? I think I have the exact same problem in
bug 7728 (https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=7768)
-Original Message-
From: Pascal Quantin pascal.quan...@gmail.com
To: Developer support list for Wireshark
This was broken and fixed with bug 7661
(https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=7661).Perhaps its
broken again (and bug needs to be reopened)?
-Original Message-
From: Sho Amano samano@gmail.com
To: wireshark-dev wireshark-dev@wireshark.org
Sent: Fri, Oct 19,
I can't build from SVN 47583 on Windows (after doing a distclean). I get
the following compilation errors:
mate_parser.c
mate_parser.l(47) : fatal error C1083: Cannot open include file:
'mate_parser_lex.h': No such file or directory
NMAKE : fatal error U1077: 'C:\Program Files\Microsoft
After trying rev 47586, I get comparible build errors with the wimaxasncp
plugin (which is built after (successful) mate plugin). Do comparible changes
need to be made there as well?
-Original Message-
From: Anders Broman a.bro...@bredband.net
To: Developer support list for
I can build, but I can't use the VS2010 step-through debugger. The usual cause
of this is VS thinking its source is out of sync (like when I forget to
recompile a dissector change, even if its just a comment change). Based on
recent developments, I suspect the problem is this:
There were a bunch of hfs that were boolean parameters for the existance of a
specific command (where it was proto_tree_add_boolean + proto_tree_add_tree),
rather than an enumeration for all commands (which is what hf_beep_cmd is).
This removed the need for hf_beep_end.
However, the
I think you need a combination of a conversation and frame data.
Only on the first pass (!pinfo-fd-flags-visited), create and track the
conversation. Also write the current sequence number to the frame data
(p_add_proto_data).
On subsequence passes (pinfo-fd-flags-visited), just use the
I've tried to clean up most of them (along with a few other of the decode_*
functions) to be replaced with proto_tree_add_item (with masks in the hf items
as needed), but I think the few remaining were a bit hard to decipher without a
sample capture (which I didn't have). If I could get rid
I was looking at making the PIM dissector more filterable and noticed that it
has been labelled a tunnelling protocol (per revision 827), so that
subsequent layers (ie IPv4/IPv6) are branched from within the PIM dissector and
not on the main tree. Is this (still) standard practice? Taking
I stumbled across the use of a packet_info* global variable (g_info) in some of
the GSM dissectors. Is this really necessary? I thought it could have been
just like the IEEE802.11 dissector in that it just didn't want to proliferate
passing the packet_info structure everywhere, but I see
#3 appears to be bug 7393
(https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=7393) in bugzilla. If you
feel the others are bugs (or enhancements), add them to bugzilla
(https://bugs.wireshark.org/bugzilla/) so the issues don't get lost. Of
course, patches with fixes for those
Actually, this is where I need help as to which documentation I should update.
I did a search for expert over the whole Wireshark directory and none of the
docs explicitly mentioned expert_add_info_format(). Most just refered to the
expert API. I can update the doxygen comments in expert.h
: Christopher Maynard christopher.mayn...@gtech.com
To: wireshark-dev wireshark-dev@wireshark.org
Sent: Sat, May 25, 2013 10:10 am
Subject: Re: [Wireshark-dev] Expert info is now filterable!
mmann78@... writes:
Quick synopsis:
expert_add_info - used for static strings
expert_add_info_format_text - used
expert_add_info_format_text()
Per some of the other discussions, this may not be the best name, but I would
like to eventually replace it with the existing expert_add_info_format name,
just with the expert info structure as an argument (an no severity, group
arguments), so that the formating
User: etxrab
Date: 2013/06/11 09:35 AM
Log:
Show DisplayString as a string.
Directory: /trunk/epan/dissectors/
ChangesPath Action
+8 -4 packet-snmp.cModified
Directory: /trunk/epan/
ChangesPath Action
+1 -1 oids.cModified
Directory:
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=7752
-Original Message-
From: Richard Sharpe realrichardsha...@gmail.com
To: Developer support list for Wireshark wireshark-dev@wireshark.org
Sent: Sat, Jun 15, 2013 11:03 pm
Subject: [Wireshark-dev] It would be useful to be able to
Bug 8858 (https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=8858) reminded me
of something I noticed when trying to apply the new filterable expert info API
- there isn't a consistency among dissectors to note a good or bad checksum.
I've seen
1. Checksum field (no verification)
2. Checksum
filterable fields
mmann78@... writes:
The ones that really seem excessive are 5 6 - do we really need this
duplication? dissector.bad_checksum = TRUE equals
dissector.good_checksum = FALSE. Could we consolidate all (that have
checksum verification) to
Checksum field + good boolean field filter
Basically the problem is that XMPP needs to be registered to work with SSL.
See bug 8625 (https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=8625) and
revs 49152 (http://anonsvn.wireshark.org/viewvc?view=revisionrevision=49152)
and 49183
: Thu, Jun 27, 2013 3:38 pm
Subject: Re: [Wireshark-dev] Checksum filterable fields
mmann78@... writes:
Perhaps all checksum validations could be an enumeration of
-1 (or 2?) - unknown/disabled
0 - good
1 - bad
The TCP dissector does something similar for the window scaling factor
In doing some of the conversion to make expert info items filterable it seems
there's need for a proto_tree_add_expert function. It would solve the cases
of when proto_tree_add_text + expert_add_info or proto_tree_add_none_format
+ expert_add_info are used, but what's really desired is expert
.
-Original Message-
From: Alexis La Goutte alexis.lagou...@gmail.com
To: mmann78 mman...@netscape.net
Cc: Developer support list for Wireshark wireshark-dev@wireshark.org
Sent: Tue, Jul 2, 2013 3:29 pm
Subject: Re: [Wireshark-dev] Checksum filterable fields
On Tue, Jul 2, 2013 at 9:17 PM
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
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 consider
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 the
No, the issue is a dissector wants to use reserved or Unknown field name,
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)
-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, it
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
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
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
some
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
is
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
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 ger...@wireshark.org
To: Developer support list for Wireshark
Fixed in r52670.
-Original Message-
From: Toralf Förster toralf.foers...@gmx.de
To: wireshark-dev wireshark-dev@wireshark.org
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
These are independent of the bugs logged to Bugzilla, correct?
-Original Message-
From: Matthieu Patou m...@samba.org
To: Joerg Mayer jma...@loplof.de
Cc: Developer support list for Wireshark wireshark-dev@wireshark.org; Samba
Technical samba-techni...@samba.org; Andrew Bartlett
Checked most of the patches into r52744
(http://anonsvn.wireshark.org/viewvc?view=revisionrevision=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 a.bro...@bredband.net
To: Developer support list for Wireshark wireshark-dev@wireshark.org
Sent: Mon, Oct
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 alexis.lagou...@gmail.com
To:
the fix in the Wireshark source.
-Original Message-
From: Matthieu Patou m...@samba.org
To: mmann78 mman...@netscape.net; wireshark-dev wireshark-dev@wireshark.org
Cc: abartlet abart...@samba.org; samba-technical samba-techni...@samba.org
Sent: Sat, Oct 26, 2013 7:26 pm
Subject: Re: [Wireshark
I believe that was already addressed in r52965. (r52971 also has some
compiler cleanup)
-Original Message-
From: Toralf Förster toralf.foers...@gmx.de
To: wireshark-dev wireshark-dev@wireshark.org
Sent: Wed, Oct 30, 2013 10:13 am
Subject: [Wireshark-dev] r52963 introduced a build
for dissectors to compile on Windows.
Michael
-Original Message-
From: Matthieu Patou m...@samba.org
To: mmann78 mman...@netscape.net; wireshark-dev wireshark-dev@wireshark.org
Cc: abartlet abart...@samba.org; samba-technical samba-techni...@samba.org
Sent: Sun, Oct 27, 2013 1:41 pm
Subject: Re
Message-
From: Matthieu Patou m...@samba.org
To: mmann78 mman...@netscape.net; wireshark-dev wireshark-dev@wireshark.org
Cc: abartlet abart...@samba.org; samba-technical samba-techni...@samba.org
Sent: Mon, Nov 4, 2013 3:25 am
Subject: Re: [Wireshark-dev] Wireshark PIDL generated dissectors
Reverted change in r53130.
-Original Message-
From: Guy Harris g...@alum.mit.edu
To: wireshark-dev wireshark-dev@wireshark.org
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
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
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
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 some
1 - 100 of 208 matches
Mail list logo
