On Oct 10, 2011, at 4:34 PM, wme...@wireshark.org wrote:
> http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=rev&revision=39350
>
> User: wmeier
> Date: 2011/10/10 04:34 PM
>
> Log:
> Fix bugs which caused certain fields to display with the wrong endianness;
> Specifically: some proto_tree_ad
On Oct 10, 2011, at 7:55 AM, Krishna Khanal wrote:
> When i add a new field in trace record header,
To what "trace record header" are you referring? Are these "trace records" in
some protocol? If so, what protocol is it? Or are they "trace records" in
some capture file format? If
On Oct 10, 2011, at 2:06 PM, Ed Beroset wrote:
> Perhaps it's a bit late, but if this only affects hf_ variables when used
> within proto_add_item() calls, might it make more sense to keep this
> information within the hf_register_info struct?
If you mean "might it make more sense to keep all
Bill Meier wrote:
>
>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 EN
On Oct 10, 2011, at 11:44 AM, Bill Meier wrote:
> In any case, no matter what is decided, changes will be needed for FT_STRING
> & etc.
>
> Is it OK to just change all the instances with no character encoding to
> ENC_ASCII (with or without ENC_NA) ?
That, or ENC_UTF_8. I suspect most new pr
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 endia
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/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 sep
Apparently I forgot to delete one line from the preinc file (which I had
changed in the .am version), but more importantly had completely missed
the complexity/difference-from-automake in asn1/Makefile.nmake . I
think 39337 should fix that.
Jeff Morriss wrote:
Hmmm, looks like my Windows
Hi all,
When i add a new field in trace record header, do i need to build
everything and intall new wireshark setup package or i can just create
plugin and use it? My understanding is that, plugin will work only if
dissection capability is added in wireshark but if new field is added in
tr
Hmmm, looks like my Windows changes didn't work the way I intended. Let
me see what's wrong.
Anders Broman wrote:
Hi,
How do you generate a single dissector whuich is useful during development for
instance now I get
C:\wireshark\trunk\asn1\gsm_map>nmake -f makefile.nmake
Microsoft (R) P
Hi,
How do you generate a single dissector whuich is useful during development for
instance now I get
C:\wireshark\trunk\asn1\gsm_map>nmake -f makefile.nmake
Microsoft (R) Program Maintenance Utility Version 9.00.30729.01
Copyright (C) Microsoft Corporation. All rights reserved.
NMAKE : fata
On Oct 7, 2011, at 5:22 PM, Kaul wrote:
> I'm struggling for some time now with displaying bitfields, I'm sure there
> must be something I'm overlooking, or it's just a bit difficult to do in
> Wireshark.
>
> I have a 32bit, little endian field, which I'd like to parse the bits (as
> set/not
> Anders Broman skrev 2011-10-07 18:10:
> > Mike Morrin skrev 2011-10-07 17:48:
> >>
> >> I think that it should be a bit more flexible:
> >> * Have conversations per protocol, with 1 or more identifier keys.
> >> * When a new identifier is observed, if it can be associated with an
> >> existing co
This is giving me a warning
packet-sdp.c:1302 'data_tvb' might get clobbered by 'longjmp' or 'vfork'
Making 'data_tvb' volatile doesn't work as I then get warnings about
discarding the volatile qualifier by passing data_tvb to the various
sub-dissectors. I've never been sure of the best way to
On Mon, Oct 10, 2011 at 10:45 AM, Anders Broman
wrote:
> Could some one try this patch?
Committed in revision 39334.
--
Stig Bjørlykke
___
Sent via:Wireshark-dev mailing list
Archives:http://www.wireshark.org/list
Hi,
Could some one try this patch?
Index: epan/CMakeLists.txt
===
--- epan/CMakeLists.txt (revision 39333)
+++ epan/CMakeLists.txt (working copy)
@@ -240,6 +240,7 @@
dissectors/packet-smrse.c
dissectors/packet-spnego.c
On Fri, 7 Oct 2011 09:34:53 -0600, Stephen Fisher
wrote:
On Fri, Oct 07, 2011 at 11:31:24AM +0200, Marcel Haas wrote:
I have some packets witch are compress witz zlib.
I want to uncompress them.
Take a look at the tvb_uncompress() or tvb_child_uncompress()
functions
in epan/tvbuff.c. An
On Fri, 7 Oct 2011 09:34:53 -0600, Stephen Fisher
wrote:
On Fri, Oct 07, 2011 at 11:31:24AM +0200, Marcel Haas wrote:
I have some packets witch are compress witz zlib.
I want to uncompress them.
Take a look at the tvb_uncompress() or tvb_child_uncompress()
functions
in epan/tvbuff.c. An
19 matches
Mail list logo
