On 1/9/2012 1:20 AM, Gerald Combs wrote:
On 1/7/12 9:48 AM, Bill Meier wrote:
There were a number of leaks fixed (of the type wherein the data buffer
associated with a created REAL_DATA wasn't freed).
In addition, I fixed a number of cases wherein a REAL_DATA buffer was
created but not added
On 1/9/2012 1:20 AM, Gerald Combs wrote:
On 1/7/12 9:48 AM, Bill Meier wrote:
On 1/6/2012 4:07 PM, Maynard, Chris wrote:
... Also, what of Bill's recent work with
tvbuff's? I believe he fixed a lot of memory leaks there as well.
There were a number of leaks fixed (of the type wherein
On 1/9/2012 1:56 PM, Gerald Combs wrote:
On 1/8/12 12:08 PM, Balint Reczey wrote:
Hi,
I have run tools/git-compare-abis.sh on latest master-1.6
(wireshark-1.6.4-21-ga6c3642).
The ABI is almost totally stable [1], which is very good sign for plugin
developers and for anyone using Wireshark's
On 1/6/2012 4:07 PM, Maynard, Chris wrote:
... Also, what of Bill's recent work with
tvbuff's? I believe he fixed a lot of memory leaks there as well.
There were a number of leaks fixed (of the type wherein the data buffer
associated with a created REAL_DATA wasn't freed).
In addition, I
On 1/6/2012 5:59 AM, Ed Beroset wrote:
Ed Beroset wrote:
Then you've found your problem. Either rename the other cat or fiddle
with the path to point to the cygwin version of cat first. If that
doesn't do it, let us know and we'll dig a little deeper.
So:
We should add 'cat' to the list
On 1/5/2012 2:49 PM, Anders Broman wrote:
Hi,
Is it time to change default MSVC_VARIANT to MSVC2010?
Regards
Anders
+1
Bill
(I've also been meaning to remove support for anything earlier than
MSVC2005 as discussed some time ago. I'll take care of that shortly).
On 12/12/2011 4:55 PM, Bill Meier wrote:
Summary
---
I've recently been digging into the tvbuff code.
After doing so, I've come to the conclusion that the current tvbuff
implementation of managing tvb's with usage_counts and used_in lists:
- doesn't really provide some of what I understand
On 12/21/2011 12:40 PM, Bill Meier wrote:
ToDo:
- Update epan/tvbtest.c
- Test composite tvbs (They might now even work).
Done ...
I've updated tvbtest.c slightly to reflect the recent tvbuff.c revisions.
I've also fixed an issue in tvbtest.c which caused some of the composite
tvb tests
On 12/18/2011 1:31 PM, wme...@wireshark.org wrote:
Create Dehunked Entity Body with O(N) rather than O(N^2) efffort.
[Actually 1 g_malloc() + N tvb_memcpy() instead of
~ N g_malloc()/g_free() + N*(N+1)/2 tvb_memcpy() where N = number of chunks].
Correction: the above should have been:
On 12/12/2011 4:55 PM, Bill Meier wrote:
Summary
---
I've recently been digging into the tvbuff code.
snip
... and then describe how tvbuff can be simplified.
snip
I think the long description boils down to the following:
Consider the collection of tvbs (chain) as a stack of tvbs
On 12/13/2011 11:37 PM, Andrew Kampjes wrote:
I've got a buffer of guint8s in a dissector that I'd like to turn
into a tvb that I can then use as a parameter to add_new_data_source().
Is that possible/how?
Andrew.
Basically:
[allocate and fill buffer: data_p = ]
my_tvb =
On 12/12/2011 4:55 PM, Bill Meier wrote:
I've attached new versions of tvbuff-int.h and tvbuff.c with revised
code for managing REAL_DATA and SUBSET tvb's. The changes are fairly
simple. Wireshark seems to work AOK with the new versions (although I
certainly haven't yet done extensive testing
My curiosity was piqued by Guy's comment in SVN #40078:
Bitfields indicate how many bits they are; guint8 foo:4 is
self-contradictory (it's 4 bits, not 8). Furthermore, the C language
doesn't support unsigned char as a bitfield type;some compilers might
accept that, but if you crank up the
On 11/23/2011 9:07 AM, kellingw...@aol.com wrote:
Hallo,
when running the aktual version SVN Rev 39992 and selecting a packet that
allows the conversation filter (is a PNIO paket) the filter routines do not
become active!
when using the old SVN Rev 39068 there is no problem using this filter.
On 11/22/2011 6:19 PM, Kenny Ho wrote:
Hi,
I am writing my first dissector and it needs to dissect a packet base
on some information in previous packets. The protocol also allows
multiple of these stream mux together. What is the best way to
create a stateful dissector? From the dev guide, I
On 11/22/2011 6:38 PM, Bill Meier wrote:
On 11/22/2011 6:19 PM, Kenny Ho wrote:
Hi,
I am writing my first dissector and it needs to dissect a packet base
on some information in previous packets. The protocol also allows
multiple of these stream mux together. What is the best way to
create
On 11/22/2011 7:02 PM, Bill Meier wrote:
So, it may be the case that you'll need to store per-frame info about
any decisions made as to how to dissect a particular packet based upon a
previous packet.
When an arbitrary packet is then dissected again later the associated
per-packet info is used
On 11/17/2011 8:18 PM, ger...@wireshark.org wrote:
http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=revrevision=39924
User: gerald
Date: 2011/11/17 05:18 PM
Log:
Maybe it's not a good idea to modify configure.in or config.nmake during
compilation. Add a --set-svn option which only
On 11/18/2011 11:55 AM, Gerald Combs wrote:
Are you using a native SVN client on Windows?
Yes ...
I don't see the problem on
Cygwin (or on Linux or OS X for that matter). I checked in changes to
preserve line endings in r39938 (trunk) and r39939 (trunk-1.6).
On 11/12/2011 6:59 AM, Andreas Sikkema wrote:
Hi,
After being away for close to 10 years I finally have a need for a new
protocol dissector so I started developing again. I've got one working,
but since I don't have access to Visual Studio anymore, I downloaded the
Express version. I'm
On 11/12/2011 1:45 PM, buildbot-no-re...@wireshark.org wrote:
The Buildbot has detected a new failure on builder Ubuntu-10.04-x64 while
building Wireshark (development).
Full details are available at:
http://buildbot.wireshark.org/trunk/builders/Ubuntu-10.04-x64/builds/582
Buildbot URL:
On 11/9/2011 3:45 PM, s...@wireshark.org wrote:
http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=revrevision=39775
User: stig
Date: 2011/11/09 12:45 PM
Log:
As reported by Michael Speck:
Removed last occurrences of USE_THREADS.
Directory: /trunk/
ChangesPath Action
On 10/28/2011 11:25 PM, mman...@netscape.net wrote:
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
On 10/4/2011 1:53 PM, Bill Meier wrote:
I propose to use a perl script to automate as much as reasonable the
replacement of TRUE/FALSE in the encoding parameter of the
proto_tree_add_item() calls in dissectors as follows:
OK: Unless there are concerns, there will be one last massive change
On 10/18/2011 9:34 AM, Bill Meier wrote:
On 10/18/2011 9:13 AM, Jeff Morriss wrote:
morr...@wireshark.org wrote:
Directory: /trunk/epan/dissectors/
Changes Path Action
+13 -6 packet-pcep.c Modified
Bill,
Just FYI this file doesn't appear to have been caught by your
encoding-fixing script
On 10/4/2011 1:53 PM, Bill Meier wrote:
I propose to use a perl script to automate as much as reasonable the
replacement of TRUE/FALSE in the encoding parameter of the
proto_tree_add_item() calls in dissectors as follows:
OK: To summarize: (Note ??? at end)
Fixes done (when possible
On 10/19/2011 7:46 PM, Guy Harris wrote:
FT_PROTOCOL Not yet fixed: Should be ???
ENC_NA. It's like FT_NONE.
Q: Does it make any sense for an entry in hf[] in a dissector to have a
field type of FT_PROTOCOL ? (e.g., packet-extreme.c)
I just noticed that there are a few cases like
On 10/18/2011 9:13 AM, Jeff Morriss wrote:
morr...@wireshark.org wrote:
Directory: /trunk/epan/dissectors/
Changes Path Action
+13 -6 packet-pcep.c Modified
Bill,
Just FYI this file doesn't appear to have been caught by your
encoding-fixing script. Looking at the hf variables, I can see
On 10/12/2011 3:30 PM, Bill Meier wrote:
Based upon the comments:
I propose to do the following for
the FT_STRING, FT_STRINGZ, FT_UINT_STRING encoding parameter:
Conversions:
1. For other than FT_UINT_STRING, always use ENC_NA
(replacing any existing True/1/FALSE/0
Re:
Should these functions be modified to take an encoding argument instead of a
little_endian argument, then the Perl script run on them as well to convert
TRUE/FALSE to ENC_LITTLE_ENDIAN/ENC_BIG_ENDIAN?
I think so.
tvb_fake_unicode()
; no remaining usage in Wireshark;leave as
On 10/12/2011 1:42 PM, Guy Harris wrote:
(Paging LTE experts here)
On Oct 12, 2011, at 8:02 AM, wme...@wireshark.org wrote:
http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=revrevision=39384
User: wmeier
Date: 2011/10/12 08:02 AM
Log:
Fix a benign bug: Use correct
On 10/12/2011 2:20 PM, Bill Meier wrote:
On 10/12/2011 1:42 PM, Guy Harris wrote:
(Paging LTE experts here)
On Oct 12, 2011, at 8:02 AM, wme...@wireshark.org wrote:
http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=revrevision=39384
User: wmeier
Date: 2011/10/12 08:02 AM
Log:
Fix
On 10/10/2011 2:44 PM, Bill Meier wrote:
For FT_STRING..., rather than cluttering up the encoding arg with
ENC_NA, I would be sightly inclined to specify endianness only where
relevant.
For FT_UINT_STRING obviously ENC_[BIG|LITTLE]_... would be needed for all.
However, I can understand
On 10/10/2011 8:03 PM, Guy Harris wrote:
[...]
and went with having a single encoding
variable for strings and using that in all the proto_tree_add_item()
calls).
FWIW: there are currently only 12 dissectors which do this.
On 10/10/2011 1:07 AM, Guy Harris wrote:
FT_UINT_STRING
For FT_UINT_STRING, what character encoding was used? FT_UTF_8 or FT_ASCII?
Actually: for the FT_UINT_STRING cases I just changed TRUE/FALSE to
ENC_LITTLE_ENDIAN/ENC_BIG_ENDIAN
None of them had ENC_UTF_8/
(I'll send a
On 10/4/2011 2:45 PM, Guy Harris wrote:
Presumably all the uses of
proto_tree_add_item() and the like for FT_ABSOLUTE_TIME values
already have the encoding specified and already use
ENC_LITTLE_ENDIAN/ENC_BIG_ENDIAN.
Not quite all :)See below.
On 10/4/2011 2:45 PM, Guy Harris wrote:
... FT_STRING, FT_STRINGZ, and FT_UINT_STRING, for which an
encoding should also be supplied.
The endianness is irrelevant for ENC_UTF_8, ENC_ASCII, and
ENC_EBCDIC.
In the future, there will be ENC_UTF_16 and possibly ENC_UCS_2, for
which the
On 10/6/2011 10:23 AM, Marc Petit-Huguenin wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
We submitted a patch for Wireshark trunk one month ago
(https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=6317), without any action
done on it during all this time. Now we have to do a massive
As you may have noticed: :)
I'm in the midst of updating the Wireshark dissector sources step by
step to use ENC_NA|ENC_LITTLE_ENDIAN|ENC_BIG_ENDIAN for the encoding
parameter of function calls such as proto_tree_add_item() as appropriate.
I'm using a Perl script to make those changes
On 10/5/2011 4:57 AM, Kaul wrote:
It worked before the massive updates of last night (which I'm not sure
unrelated). It's a bit more difficult to dissect in SVN, so hopefully
someone has a clue what went wrong.
Y.
Wireshark (SVN #39269) works OK on my Windows and Fedora 32-bit systems.
I propose to use a perl script to automate as much as reasonable the
replacement of TRUE/FALSE in the encoding parameter of the
proto_tree_add_item() calls in dissectors as follows:
First step:
For hf[] entries with type
FT_NONE
FT_BYTES
FT_IPV6
FT_IPXNET
FT_UID
convert the
On 10/4/2011 1:53 PM, Bill Meier wrote:
I propose to use a perl script to automate as much as reasonable the
replacement of TRUE/FALSE in the encoding parameter of the
proto_tree_add_item() calls in dissectors as follows:
First step:
For hf[] entries with type
FT_NONE
FT_BYTES
FT_IPV6
FT_IPXNET
On 10/4/2011 4:08 PM, Jeff Morriss wrote:
I had a fair amount of luck with the (currently not run)
checkAPIsCalledWithTvbGetPtr() function in checkAPIs.pl . It
definitely is not 100%, but it served my purposes well. It avoids
dealing with parenthesis by assuming the only semi-colon it will find
On 10/4/2011 1:53 PM, Bill Meier wrote:
I propose to use a perl script to automate as much as reasonable the
replacement of TRUE/FALSE in the encoding parameter of the
proto_tree_add_item() calls in dissectors as follows:
First step:
For hf[] entries with type
FT_NONE
FT_BYTES
FT_IPV6
FT_IPXNET
On 10/4/2011 4:48 PM, Guy Harris wrote:
On Oct 4, 2011, at 10:53 AM, Bill Meier wrote:
I propose to use a perl script to automate as much as reasonable the
replacement of TRUE/FALSE in the encoding parameter of the
proto_tree_add_item() calls in dissectors as follows:
First step:
For hf
On 10/4/2011 2:49 PM, David Young wrote:
On Tue, Oct 04, 2011 at 11:38:48AM -0700, Dirk Jagdmann wrote:
Sounds like a perfect job for Coccinelle,http://coccinelle.lip6.fr/.
Looks like an interesting tool; I'll have to spend a little time reading
the documentation. Thanks for the reference
On 9/28/2011 5:55 AM, suad alasady wrote:
dear all
i have linux fedora 15 operating system installed on my computer, can i
install wireshark on it
with my great thanks
Yes:
There's a Fedora package for Wireshark so install Wireshark however you
normally install packages on Fedora
On 9/30/2011 10:58 AM, Bill Meier wrote:
On 9/28/2011 5:55 AM, suad alasady wrote:
dear all
i have linux fedora 15 operating system installed on my computer, can
i install wireshark on it
with my great thanks
Yes:
There's a Fedora package for Wireshark
in the Fedora repository
so
On 9/28/2011 4:57 PM, Jeff Morriss wrote:
I'll argue that *tab*stops should be 8 until someone shows me how to
tell all the various terminal programs I end up using that the file I'm
currently looking at (in 'less' or 'grep' or plain old 'cat') that the
file in question is using an alternative
On 9/27/2011 3:56 PM, Jeff Morriss wrote:
Actually a quick test indicates that we only build the column info on
the 2nd pass (for those frames which are currently displayed).
In other words, if you've got 10,000 frames of which 25 are displayed in
your Wireshark window, your dissector is
On 9/27/2011 4:27 PM, Guy Harris wrote:
On Sep 27, 2011, at 12:42 PM, David Aggeler wrote:
Maybe I am I the only one, but today it was once too many, where I had to
'convert different .sh files (e.g. win32-setup.h) to use UNIX style end of line
instead of Windows.
Paging Bill Meier
On 9/22/2011 4:27 AM, Rajesh P S wrote:
But I am facing another issue where in when I try to run wireshark.exe I
am getting this run time error.
The issue is exactly as the message says:
Check your ett array to be sure all are initialized to -1 and that there
are no duplicate entries
On 9/21/2011 5:05 PM, Guy Harris wrote:
On Sep 21, 2011, at 1:59 PM, Guy Harris wrote:
As for full integration with Wireshark, they appear to use Wireshark's dissectors in the packet view - they
have a collection of Wireshark DLLs in the wireshark subdirectory, along with a bunch of the DLLs
On 9/21/2011 5:12 PM, Bill Meier wrote:
On 9/21/2011 5:05 PM, Guy Harris wrote:
On Sep 21, 2011, at 1:59 PM, Guy Harris wrote:
As for full integration with Wireshark, they appear to use
Wireshark's dissectors in the packet view - they have a collection of
Wireshark DLLs in the wireshark
On 9/21/2011 6:26 PM, Guy Harris wrote:
On Sep 21, 2011, at 2:44 PM, Gisle Vanem wrote:
Guy Harrisg...@alum.mit.edu wrote:
Is there an MSVC tool to look find out what DLLs an executable uses? (I.e.,
the equivalent of, say, ldd on many systems using ELF, or otool on Mac OS X.)
cygcheck
On 9/19/2011 9:53 AM, mart...@wireshark.org wrote:
http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=revrevision=39045
User: martinm
Date: 2011/09/19 06:53 AM
Log:
Add expert 'Group' to output.
Directory: /trunk/
ChangesPathAction
+21 -2 tap-expert.cModified
On 9/19/2011 1:41 PM, Bill Meier wrote:
On 9/19/2011 9:53 AM, mart...@wireshark.org wrote:
http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=revrevision=39045
User: martinm
Date: 2011/09/19 06:53 AM
Log:
Add expert 'Group' to output.
Directory: /trunk/
Changes Path Action
+21 -2 tap
On 9/15/2011 9:06 AM, Yosi Saggi wrote:
I have updated via SVN my wireshark code files, When trying to verify
the tools with:
nmake -f Makefile.nmake verify_tools
C:\wireshark_1_6nmake -f Makefile.nmake verify_tools
Microsoft (R) Program Maintenance Utility Version 9.00.30729.01
Copyright
On 9/15/2011 9:44 AM, Bill Meier wrote:
I'm not sure why verify_tools says can't find ...
However, the above error message about current_tag.txt being incorrect
means that the various libraries for Windows (GTK etc) aren't up-to-date.
I suggest fixing this known error first by doing
On 9/15/2011 9:06 AM, Yosi Saggi wrote:
I have updated via SVN my wireshark code files, When trying to verify
the tools with:
nmake -f Makefile.nmake verify_tools
I get the following:
C:\wireshark_1_6nmake -f Makefile.nmake verify_tools
Microsoft (R) Program Maintenance Utility Version
On 8/31/2011 12:34 PM, wme...@wireshark.org wrote:
http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=revrevision=38824
User: wmeier
Date: 2011/08/31 09:34 AM
Log:
Fix build (automake) error: WIRESHARK_CUSTOM_HEADERS is ng but
WIRESHARK_CUSTOM_HDRS is OK ??
I've never particularly
On 8/30/2011 9:46 AM, s...@wireshark.org wrote:
http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=revrevision=38800
User: stig
Date: 2011/08/30 06:46 AM
Log:
Move all crc routines to libwsutil.
This way we can use the crc routines in wiretap.
Directory: /trunk/epan/crc/
Changes
On 8/30/2011 10:24 AM, Stig Bjørlykke wrote:
I have reverted the crc move for now.
I have to split the crc files into crc and crc_tvb routines, I think.
I think something got messed up when the reversion was done...
For instance: epan/crc/Makefile.nmake has missing history in SVN and has
2
On 8/30/2011 11:14 AM, Bill Meier wrote:
On 8/30/2011 10:24 AM, Stig Bjørlykke wrote:
I have reverted the crc move for now.
I have to split the crc files into crc and crc_tvb routines, I think.
I think something got messed up when the reversion was done...
For instance: epan/crc
On 8/30/2011 11:22 AM, Bill Meier wrote:
On 8/30/2011 11:14 AM, Bill Meier wrote:
On 8/30/2011 10:24 AM, Stig Bjørlykke wrote:
I have reverted the crc move for now.
I have to split the crc files into crc and crc_tvb routines, I think.
I think something got messed up when the reversion
On 8/30/2011 11:42 AM, Stephen Fisher wrote:
On Tue, Aug 30, 2011 at 11:14:30AM -0400, Bill Meier wrote:
On 8/30/2011 10:24 AM, Stig Bjørlykke wrote:
I have reverted the crc move for now.
I have to split the crc files into crc and crc_tvb routines, I think.
I think something got messed up
On 8/30/2011 11:22 AM, Bill Meier wrote:
On 8/30/2011 11:14 AM, Bill Meier wrote:
On 8/30/2011 10:24 AM, Stig Bjørlykke wrote:
I have reverted the crc move for now.
I have to split the crc files into crc and crc_tvb routines, I think.
I think something got messed up when the reversion
On 8/30/2011 12:01 PM, Stephen Fisher wrote:
On Tue, Aug 30, 2011 at 11:22:29AM -0400, Bill Meier wrote:
On 8/30/2011 11:14 AM, Bill Meier wrote:
For instance: epan/crc/Makefile.nmake has missing history in SVN and
has 2 copies of the body in the file.
Ditto for epan/crc
Makefile.am
On 8/30/2011 12:02 PM, Bill Meier wrote:
On 8/30/2011 11:22 AM, Bill Meier wrote:
On 8/30/2011 11:14 AM, Bill Meier wrote:
On 8/30/2011 10:24 AM, Stig Bjørlykke wrote:
I have reverted the crc move for now.
I have to split the crc files into crc and crc_tvb routines, I think.
I think
On 8/30/2011 12:16 PM, Bill Meier wrote:
Am I missing something??
I did an 'svn checkout ...' a fresh Wireshark copy from the main
repository (on my Windows machine).
The epan/crc/Makefile.nmake and etc have two copies of the body.
Bill
On 8/22/2011 6:06 PM, kahou lei wrote:
00 10 94 00 00 02 00 10 94 00 00 01 08 00 45 00 ..E.
0010 00 6e 00 2c 00 00 ff 06 3a 05 c0 55 01 02 c0 00 .n.,:..U
0020 00 01 04 00 04 00 00 01 e2 40 00 03 94 47 50 10 .@...GP.
0030 10 00 35 e5 00 00 00 00 00 00 00
On 8/15/2011 12:21 PM, Stephen Fisher wrote:
This call:
gtk_quit_add_destroy(gtk_main_level(), GTK_OBJECT(streamwindow));
Appears to tell GTK to destroy the object streamwindow if Wireshark is
being closed entirely. This then calls the signal that was connected a
few lines earlier:
On 8/15/2011 2:28 PM, Guy Harris wrote:
On Aug 15, 2011, at 10:47 AM, Bill Meier wrote:
Exiting Wireshark (with no gtk_quit_destroy()) in the follow_stream
code left a file in the temp directory.
Is there some reason why we don't delete the file when the {TCP,SSL}
Stream window is destroyed
On 8/15/2011 2:54 PM, Bill Meier wrote:
On 8/15/2011 2:28 PM, Guy Harris wrote:
On Aug 15, 2011, at 10:47 AM, Bill Meier wrote:
Exiting Wireshark (with no gtk_quit_destroy()) in the follow_stream
code left a file in the temp directory.
Is there some reason why we don't delete the file when
capture_dlg.c: In function ‘insert_new_rows’:
capture_dlg.c:665:18: warning: variable ‘cap_settings’ set but not used
[-Wunused-but-set-variable]
capture_dlg.c:664:8: warning: variable ‘linktype_select’ set but not
used [-Wunused-but-set-variable]
capture_dlg.c: In function
On 8/2/2011 11:19 AM, Marc Petit-Huguenin wrote:
I had the same exact problem when my Debian sid distribution updated the gcc 4.6
compiler. I use 4.5 instead, and everything works.
Um... I suspect you had a slightly different problem when compiling
with GCC 4.6 which added a check for
On 7/28/2011 5:27 PM, Alex Lindberg wrote:
I am creating a dissector that overlays a complicated struct (bit
fields, unions, etc) on the the tvb.
Unfortunately, you can't do that; :)
From doc/README.developer
Don't use structures that overlay packet data, or into which you copy
packet
On 7/28/2011 5:39 PM, Bill Meier wrote:
On 7/28/2011 5:27 PM, Alex Lindberg wrote:
I am creating a dissector that overlays a complicated struct (bit
fields, unions, etc) on the the tvb.
Unfortunately, you can't do that; :)
From doc/README.developer
Don't use structures that overlay packet
On 7/21/2011 3:35 PM, Jeff Morriss wrote:
Guy Harris wrote:
On Jul 18, 2011, at 10:19 PM, Maynard, Chris wrote:
Assuming the reporter of bug 5769 is correct and the Info column
displays the values of the low and high limits correctly, then the
protocol is ENC_BIG_ENDIAN. All of the fields
On 7/19/2011 9:15 AM, Helge Kruse wrote:
The config.nmake defines general settings like
WIRESHARK_LIBS=C:\wireshark-$(WIRESHARK_TARGET_PLATFORM)-libs-1.6
This is useful on most machines. But I have to build Wireshark on a
machine where the system partition is on drive B:
My build steps are:
-
Re:
AC_WIRESHARK_GCC_CFLAGS_CHECK(-Wno-unused-but-set-variable)
Is there a (reasionably easy) way to use this option only when compiling
in the .../dissectors directory ?
(I think that I've previously addressed the unused_but_set warnings
for many (all ?) of the other directories). (SVN
On 7/13/2011 7:38 PM, Guy Harris wrote:
Haven't you (and maybe others) been fixing the same issues already,
as a result of Coverity warnings about the same thing?
And how many of those are
static void
dissect_whatever(...)
{
...
proto_tree_add_item(tree, hf_foo,
On 6/8/2011 10:46 AM, Дмитрий Дьяченко wrote:
[FYI] http://gcc.gnu.org/ml/gcc/2010-05/msg00657.html
[snip]
As the compiler documentation states, warn_unused_result was intended
for cases where failing to check the return value is always a security
risk or a bug. The documentation cites the
On 6/8/2011 3:34 PM, Дмитрий Дьяченко wrote:
Look as # if __USE_FORTIFY_LEVEL 0 take place
For example, Fedora 15 /usr/include/sys/cdefs.h contains
/* If fortification mode, we warn about unused results of certain
function calls which can lead to problems. */
#if __GNUC_PREREQ (3,4)
#
On 6/7/2011 2:08 AM, محـسنـ ایمانیـ wrote:
Hi
I've tried to buil wireshark on windows.But it has some problem with
mt.exe and zlib that I couldn't resolve.
the output of nmake -f Makefila.nmake setup command is:
Microsoft (R) Program Maintenance Utility
On 6/6/2011 3:24 PM, Garcia, Luis Antonio wrote:
Details about the crash:error messages/ etc.
I don't really receive any error messages. The program just doesn't
start up and seems to freeze the system. I've tried to manually
debug the situation by running the capture through the Wireshark
Thanks everyone for the research
It turned out the the cause of the OSX compiler error when compiling
radius_dict.c was text that I had put in a comment which included the
string [^[:blank:]] .
Bill
___
Sent
But I'm not sure this is the right way to fix this. Can someone comment ?
Thanks,
Pascal.
I've copied the above over to Bug #5855 since your suggested fix also
seems to address recent Buildbot fuzz-test crashes.
Thanks for the report and analysis.
In the proto_reg_handoff_ansi_637() code the variable
'ansi_637_trans_app_handle' is set but never used.
(Coverity 835).
My suspicion is that this handle should be used in the following iso
'ansi_637_trans_handle':
/* Dissect messages embedded in SIP */
On 4/1/2011 12:57 PM, Chaswi Przellczyk wrote:
Dear Stephen,
that would be a good way to get this solved. I went ahead and
modified packet-rtp.c to add a field for a sampling-rate preference.
That works nice. BUT the preferences are typically used in the
dissectors, which is not true for my
On 3/30/2011 11:37 AM, Palleske, Carsten wrote:
Hello all,
- I've got Windows and I've got MS-VS 2010 Pro.
- I downloaded Source-Code for Wireshark v1.44.
- I downloaded CygWin and Perl and a bunch of tools and got them installed.
- After getting used to the makefiles and stuff I got wireshark
On 3/23/2011 2:01 AM, Roland Knall wrote:
Hi
Another issue, at least for me, has been the Windows file endings. In
the file win-setup.sh, there are several file-endings written with
\r\n, which is Windows specific. The cygwin bash can not handle this
file with those endings. Open the file with
On 3/22/2011 11:48 PM, Risto Paasila wrote:
Hi,
I'm using http://www.wireshark.org/docs/wsdg_html_chunked/ChSetupWin32.html to
set up the environment, in order to compile wireshark under windows.
However, while doing the verify tools check, I keep getting this problem
(tried on 2 seperate
On 2/17/2011 5:14 PM, Gerald Combs wrote:
On 2/16/11 7:22 PM, Guy Harris wrote:
It looks like this is a known bug:
http://connect.microsoft.com/VisualStudio/feedback/details/99397/warning-c6011-at-wspiapi-h-1001
From the bug report...:)
Posted by Microsoft on 4/4/2006 at 10:59 AM
Thanks
On 2/16/2011 11:42 PM, Guy Harris wrote:
What's the default process stack size in Win32?
==From the VC2008 docs[1]:
The /STACK option sets the size of the stack in bytes. Use this option
only when you build an .exe file.
The reserve value specifies the total stack allocation in virtual
User: gerald
Date: 2011/02/14 10:58 AM
Log:
Enable Enterprise Code Analysis via the ENABLE_CODE_ANALYSIS environment
variable.
Directory: /trunk/
ChangesPathAction
+2 -2 config.nmakeModified
Gerald: I expect you meant to remove the # from the !IFDEF
On 2/15/2011 11:25 AM, Bill Meier wrote:
Gerald: I expect you meant to remove the # from the !IFDEF !ENDIF ...
#!IFDEF ENABLE_CODE_ANALYSIS
LOCAL_CFLAGS= $(LOCAL_CFLAGS) /analyze:WX-
#!ENDIF
I committed this change in SVN #35951:)
Bill
(TVs, DVD/Bluray recorders).
-
(From Bill Meier)
I see that this dissector is coded to dissect
DVB-CI bytes received as the payload of UDP
(in a manner somewhat similar to that used by packet-gsmtap).
I also see that there's a program (not part of this patch)
which is used to read
Do you know of a better way to encode the direction in a pcap file or
should I keep the direction byte? (If we go for pcap files and a new
DLT, we should agree on this before I can apply for a DLT value).
..
--To use a pcap format file to contain your captured DVBCI info:
1. As you note:
On 2/10/2011 2:38 PM, Bill Meier wrote:
1. libpcap processes the pseudo-header and fills in a dissector-specific
Clarification:
libpcap above means the Wireshark libpcap.c (not the libpcap library).
___
Sent via
201 - 300 of 631 matches
Mail list logo
