Re: [Wireshark-dev] [Wireshark-commits] rev 39350: /trunk/epan/dissectors/ /trunk/epan/dissectors/: packet-bittorrent.c packet-manolito.c
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_add_item() 'encoding' args were incorrect. A lot of these bugs appear to be the result of developers typing "item" when they mean "uint" - i.e., they extracted a field from the packet in order to use its value later in the dissection, and then, in order to put it into the protocol tree without re-fetching it, they intended to do proto_tree_add_uint(..., value); but instead typed proto_tree_add_item(..., value); (Another reason why I'm more and more inclined to believe that the current way dissectors are written is much too low-level.) ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] query on adding new field in trace record...
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 so, what file format is it? ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] [Wireshark-commits] rev 39328: /trunk/epan/dissectors/ /trunk/epan/dissectors/: packet-2dparityfec.c packet-acn.c packet-ancp.c packet-ansi_a.c packet-aodv.c packet-aruba-papi.c pa
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 encoding information *solely* within the hf_register_info structure and get rid of the encoding argument to proto_tree_add_item()", the answer is "no"; there are protocols for which not all instances of a given field in all captures use the same encoding (whilst one could have multiple instances of the same field, with different encodings, and choose which one to use at run time, the prospect of fixing bug 6084 by introducing duplicates of all string fields and having all calls that add string fields choose which instance to use based on the character encoding struck me as such a pain that I introduced ENC_EBCDIC and ENC_UTF_8 and went with having a single encoding variable for strings and using that in all the proto_tree_add_item() calls). If you mean "might it make sense to provide encoding information in the hf_register_info structure, have calls to add items using the "default" encoding in the hf_register_info, and calls to add items with a run-time-specified encoding that overrides the default", that might be the case. Another possibility might be to make more use of the ptvcursor routines, add encoding information to the ptvcursor, and have ptvcursor routines that add items using the encoding from the ptvcursor and routines that add items using a run-time-specified encoding, or have calls that push and pop encodings, or This is somewhat like the way byte order is specified in WSGD: http://wsgd.free.fr/ where there's a command to specify a byte order globally: http://wsgd.free.fr/fdesc_format.html#cmd that can be individually overriden for a particular field: http://wsgd.free.fr/fdesc_format.html#byte_order_local ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] [Wireshark-commits] rev 39328: /trunk/epan/dissectors/ /trunk/epan/dissectors/: packet-2dparityfec.c packet-acn.c packet-ancp.c packet-ansi_a.c packet-aodv.c packet-aruba-papi.c pa
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 ENC_UTF_8/ 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? Ed ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Replace TRUE/FALSE with proper ENC_* in proto_tree_add_item() using a script.
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 protocols support UTF-8; older ones either only specify ASCII or use various legacy encodings. Automated replacement will get it wrong for some protocols regardless of whether we use ENC_ASCII or ENC_UTF_8; the question is which of those would be worse, for some value of "worse". ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Replace TRUE/FALSE with proper ENC_* in proto_tree_add_item() using a script.
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 endianness will be relevant. > > Should we always specify an endianness for strings, or only for those > character encodings where it's relevant? 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 the approach of always specifying an endianness to be consistent with other usage. After all, we're already using ENC_NA for FT_BYTES, FT_NONE & etc. Thoughts ? --- 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) ? Currently: the encoding arg instance count for proto_tree_add_item() calls in epan/dissectors is as follows: FT_STRING/FT_STRINGZ: 593 FALSE 124 TRUE 38 0 394 ENC_BIG_ENDIAN 105 ENC_LITTLE_ENDIAN 85 ENC_NA 17 ENC_ASCII|ENC_BIG_ENDIAN 1 ENC_ASCII|ENC_LITTLE_ENDIAN 25 ENC_UTF_8|ENC_BIG_ENDIAN 14 ENC_UTF_8|ENC_LITTLE_ENDIAN 2 ENC_UTF_8|ENC_NA 1 ENC_UTF_8 29 ENC_EBCDIC|ENC_NA FT_UINT_STRING (9 or so files): 36 ENC_BIG_ENDIAN 14 ENC_LITTLE_ENDIAN 10 ENC_UTF_8|ENC_BIG_ENDIAN ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Replace TRUE/FALSE with proper ENC_* in proto_tree_add_item() using a script.
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. = --> packet-gmhdr.c FT_ABSOLUTE_TIME: proto_tree_add_item(gmhdr_tree, hf_gmhdr_timestamp, tvb, offset, fl, [[FALSE]-->[???]]); -->packet-netflow.c FT_ABSOLUTE_TIME: proto_tree_add_item(pdutree, hf_pie_ntop_rtp_first_ts, tvb, offset, length, [[FALSE]-->[???]]); FT_ABSOLUTE_TIME: proto_tree_add_item(pdutree, hf_pie_ntop_rtp_last_ts, tvb, offset, length, [[FALSE]-->[???]]); FT_ABSOLUTE_TIME: proto_tree_add_item(pdutree, hf_pie_plixer_origination_time, tvb, offset, length, [[FALSE]-->[???]]); FT_ABSOLUTE_TIME: proto_tree_add_item(pdutree, hf_pie_plixer_date_time, tvb, offset, length, [[FALSE]-->[???]]); -->packet-reload.c FT_ABSOLUTE_TIME: proto_tree_add_item(local_tree, hf_reload_diagnostic_expiration, tvb, offset, 8, [[ENC_TIME_NTP]-->[???]]); FT_ABSOLUTE_TIME: proto_tree_add_item(local_tree, hf_reload_diagnostic_expiration, tvb, offset, 8, [[ENC_TIME_NTP]-->[???]]); FT_ABSOLUTE_TIME: proto_tree_add_item(local_tree, hf_reload_diagnosticrequest_timestampinitiated, tvb, offset+local_offset, 8, [[ENC_TIME_NTP]-->[???]]); FT_ABSOLUTE_TIME: proto_tree_add_item(local_tree, hf_reload_diagnosticresponse_timestampreceived, tvb, offset+local_offset, 8, [[ENC_TIME_NTP]-->[???]]); ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] [Wireshark-commits] rev 39328: /trunk/epan/dissectors/ /trunk/epan/dissectors/: packet-2dparityfec.c packet-acn.c packet-ancp.c packet-ansi_a.c packet-aodv.c packet-aruba-papi.c pa
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 separate EMail on the earlier "Replace TRUE/FALSE with proper ENC..." thread with questions re how the encoding field should be handled for FT_STRING/FT_STRINGZ/FT_UINT_STRING proto_tree_add_item() calls currently specified with no character encoding). Bill ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] FW: [Wireshark-commits] rev 39333: /trunk/ /trunk/asn1/HI2Operations/: Makefile.common /trunk/asn1/acp133/: Makefile.common /trunk/asn1/acse/: Makefile.common /trunk/asn1/ansi_map/
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 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) Program Maintenance Utility Version 9.00.30729.01 Copyright (C) Microsoft Corporation. All rights reserved. NMAKE : fatal error U1073: don't know how to make 'generate_dissector' Stop. Or C:\wireshark\trunk\asn1>nmake -f makefile.nmake gsm_map Microsoft (R) Program Maintenance Utility Version 9.00.30729.01 Copyright (C) Microsoft Corporation. All rights reserved. cd gsm_map "c:\Program Files\Microsoft Visual Studio 9.0\VC\BIN\nmake.exe" / -f Makefile.nmake copy_files Microsoft (R) Program Maintenance Utility Version 9.00.30729.01 Copyright (C) Microsoft Corporation. All rights reserved. NMAKE : fatal error U1073: don't know how to make 'generate_dissector' Stop. NMAKE : fatal error U1077: '"c:\Program Files\Microsoft Visual Studio 9.0\VC\BIN \nmake.exe"' : return code '0x2' Stop. Regards Anders -Original Message- From: wireshark-commits-boun...@wireshark.org [mailto:wireshark-commits-boun...@wireshark.org] On Behalf Of morr...@wireshark.org Sent: den 10 oktober 2011 04:31 To: wireshark-comm...@wireshark.org Subject: [Wireshark-commits] rev 39333: /trunk/ /trunk/asn1/HI2Operations/: Makefile.common /trunk/asn1/acp133/: Makefile.common /trunk/asn1/acse/: Makefile.common /trunk/asn1/ansi_map/: Makefile.common /trunk/asn1/ansi_tcap/: ... http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=rev&revision=39333 User: morriss Date: 2011/10/09 07:31 PM Log: Build the ASN.1 dissectors directly into epan/dissectors (rather than building them and then copying them over). The "all" target to builds these dissectors now (instead of "generate_files" and/or "copy_files"). asn2wrs's "-O" option now means "the dissector goes in this directory" (rather than "all output goes in this directory"); it also means that the "-s" (single output file) option is now required. Fix things up so that it's possible to build all of the ASN.1 dissectors in one shot. Fix building of conformance files when doing out-of-source-tree builds. Unfortunately "make all" in the asn1 directory always builds something--I think because of circular depedencies. Directory: /trunk/asn1/HI2Operations/ ChangesPath Action +0 -2 Makefile.commonModified Directory: /trunk/asn1/acp133/ ChangesPath Action +12 -16Makefile.commonModified Directory: /trunk/asn1/acse/ ChangesPath Action +3 -7 Makefile.commonModified Directory: /trunk/asn1/ansi_map/ ChangesPath Action +3 -7 Makefile.commonModified Directory: /trunk/asn1/ansi_tcap/ ChangesPath Action +0 -4 Makefile.commonModified Directory: /trunk/asn1/ ChangesPath Action +8 -7 Makefile.inc Modified +10 -3 Makefile.inc.nmake Modified +0 -3 Makefile.preinc Modified +2 -0 Makefile.preinc.nmakeModified Directory: /trunk/asn1/camel/ ChangesPath Action +6 -10 Makefile.commonModified (90 files not shown) ___ Sent via:Wireshark-commits mailing list Archives:http://www.wireshark.org/lists/wireshark-commits Unsubscribe: https://wireshark.org/mailman/options/wireshark-commits mailto:wireshark-commits-requ...@wireshark.org?subject=unsubscribe ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] query on adding new field in trace record...
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 trace record it wont work. Plugin is not working for me and i had to build the complete package and install new setup. -- Regards, Krishna ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] FW: [Wireshark-commits] rev 39333: /trunk/ /trunk/asn1/HI2Operations/: Makefile.common /trunk/asn1/acp133/: Makefile.common /trunk/asn1/acse/: Makefile.common /trunk/asn1/ansi_map/
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) Program Maintenance Utility Version 9.00.30729.01 Copyright (C) Microsoft Corporation. All rights reserved. NMAKE : fatal error U1073: don't know how to make 'generate_dissector' Stop. Or C:\wireshark\trunk\asn1>nmake -f makefile.nmake gsm_map Microsoft (R) Program Maintenance Utility Version 9.00.30729.01 Copyright (C) Microsoft Corporation. All rights reserved. cd gsm_map "c:\Program Files\Microsoft Visual Studio 9.0\VC\BIN\nmake.exe" / -f Makefile.nmake copy_files Microsoft (R) Program Maintenance Utility Version 9.00.30729.01 Copyright (C) Microsoft Corporation. All rights reserved. NMAKE : fatal error U1073: don't know how to make 'generate_dissector' Stop. NMAKE : fatal error U1077: '"c:\Program Files\Microsoft Visual Studio 9.0\VC\BIN \nmake.exe"' : return code '0x2' Stop. Regards Anders -Original Message- From: wireshark-commits-boun...@wireshark.org [mailto:wireshark-commits-boun...@wireshark.org] On Behalf Of morr...@wireshark.org Sent: den 10 oktober 2011 04:31 To: wireshark-comm...@wireshark.org Subject: [Wireshark-commits] rev 39333: /trunk/ /trunk/asn1/HI2Operations/: Makefile.common /trunk/asn1/acp133/: Makefile.common /trunk/asn1/acse/: Makefile.common /trunk/asn1/ansi_map/: Makefile.common /trunk/asn1/ansi_tcap/: ... http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=rev&revision=39333 User: morriss Date: 2011/10/09 07:31 PM Log: Build the ASN.1 dissectors directly into epan/dissectors (rather than building them and then copying them over). The "all" target to builds these dissectors now (instead of "generate_files" and/or "copy_files"). asn2wrs's "-O" option now means "the dissector goes in this directory" (rather than "all output goes in this directory"); it also means that the "-s" (single output file) option is now required. Fix things up so that it's possible to build all of the ASN.1 dissectors in one shot. Fix building of conformance files when doing out-of-source-tree builds. Unfortunately "make all" in the asn1 directory always builds something--I think because of circular depedencies. Directory: /trunk/asn1/HI2Operations/ ChangesPath Action +0 -2 Makefile.commonModified Directory: /trunk/asn1/acp133/ ChangesPath Action +12 -16Makefile.commonModified Directory: /trunk/asn1/acse/ ChangesPath Action +3 -7 Makefile.commonModified Directory: /trunk/asn1/ansi_map/ ChangesPath Action +3 -7 Makefile.commonModified Directory: /trunk/asn1/ansi_tcap/ ChangesPath Action +0 -4 Makefile.commonModified Directory: /trunk/asn1/ ChangesPath Action +8 -7 Makefile.inc Modified +10 -3 Makefile.inc.nmake Modified +0 -3 Makefile.preinc Modified +2 -0 Makefile.preinc.nmakeModified Directory: /trunk/asn1/camel/ ChangesPath Action +6 -10 Makefile.commonModified (90 files not shown) ___ Sent via:Wireshark-commits mailing list Archives:http://www.wireshark.org/lists/wireshark-commits Unsubscribe: https://wireshark.org/mailman/options/wireshark-commits mailto:wireshark-commits-requ...@wireshark.org?subject=unsubscribe ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] FW: [Wireshark-commits] rev 39333: /trunk/ /trunk/asn1/HI2Operations/: Makefile.common /trunk/asn1/acp133/: Makefile.common /trunk/asn1/acse/: Makefile.common /trunk/asn1/ansi_map/: Ma
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 : fatal error U1073: don't know how to make 'generate_dissector' Stop. Or C:\wireshark\trunk\asn1>nmake -f makefile.nmake gsm_map Microsoft (R) Program Maintenance Utility Version 9.00.30729.01 Copyright (C) Microsoft Corporation. All rights reserved. cd gsm_map "c:\Program Files\Microsoft Visual Studio 9.0\VC\BIN\nmake.exe" / -f Makefile.nmake copy_files Microsoft (R) Program Maintenance Utility Version 9.00.30729.01 Copyright (C) Microsoft Corporation. All rights reserved. NMAKE : fatal error U1073: don't know how to make 'generate_dissector' Stop. NMAKE : fatal error U1077: '"c:\Program Files\Microsoft Visual Studio 9.0\VC\BIN \nmake.exe"' : return code '0x2' Stop. Regards Anders -Original Message- From: wireshark-commits-boun...@wireshark.org [mailto:wireshark-commits-boun...@wireshark.org] On Behalf Of morr...@wireshark.org Sent: den 10 oktober 2011 04:31 To: wireshark-comm...@wireshark.org Subject: [Wireshark-commits] rev 39333: /trunk/ /trunk/asn1/HI2Operations/: Makefile.common /trunk/asn1/acp133/: Makefile.common /trunk/asn1/acse/: Makefile.common /trunk/asn1/ansi_map/: Makefile.common /trunk/asn1/ansi_tcap/: ... http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=rev&revision=39333 User: morriss Date: 2011/10/09 07:31 PM Log: Build the ASN.1 dissectors directly into epan/dissectors (rather than building them and then copying them over). The "all" target to builds these dissectors now (instead of "generate_files" and/or "copy_files"). asn2wrs's "-O" option now means "the dissector goes in this directory" (rather than "all output goes in this directory"); it also means that the "-s" (single output file) option is now required. Fix things up so that it's possible to build all of the ASN.1 dissectors in one shot. Fix building of conformance files when doing out-of-source-tree builds. Unfortunately "make all" in the asn1 directory always builds something--I think because of circular depedencies. Directory: /trunk/asn1/HI2Operations/ ChangesPath Action +0 -2 Makefile.commonModified Directory: /trunk/asn1/acp133/ ChangesPath Action +12 -16Makefile.commonModified Directory: /trunk/asn1/acse/ ChangesPath Action +3 -7 Makefile.commonModified Directory: /trunk/asn1/ansi_map/ ChangesPath Action +3 -7 Makefile.commonModified Directory: /trunk/asn1/ansi_tcap/ ChangesPath Action +0 -4 Makefile.commonModified Directory: /trunk/asn1/ ChangesPath Action +8 -7 Makefile.inc Modified +10 -3 Makefile.inc.nmake Modified +0 -3 Makefile.preinc Modified +2 -0 Makefile.preinc.nmakeModified Directory: /trunk/asn1/camel/ ChangesPath Action +6 -10 Makefile.commonModified (90 files not shown) ___ Sent via:Wireshark-commits mailing list Archives:http://www.wireshark.org/lists/wireshark-commits Unsubscribe: https://wireshark.org/mailman/options/wireshark-commits mailto:wireshark-commits-requ...@wireshark.org?subject=unsubscribe ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Correct and efficient way of displaying bit fields?
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 set): > Example: > 05 00 00 00 > > 1 0 0 0 Feature A - set > 0 0 0 0 ... Feature B - not set > 0 0 1 0 ... Feature C - Set > > > 1. Do I really have to create a hf_xxx for each? And use something like > proto_tree_add_bits_item() ? I was hoping to do it in a single > proto_tree_add_xxx() and pass it a single HF that would hold a VALS(...) > which will describe all the attributes. Take a look at proto_tree_add_bitmask(). You still have to create each hf_xxx since each bit (or group of bits) is a different parameter, but then a single call to proto_tree_add_bitmask will set up the subtree for the whole bitfield. Glenn ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Global conversation
> 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 conversation which was created with a different key, then > >> add the new key to the existing conversation, otherwise create a new > >> conversation with the new key. > >> * Allow conversations to be associated with conversations in other > >> protocols. The set of associated conversations becomes the global > >> conversation, but is flexible in terms of the sequence of build-up of > >> supporting protocols. > >> * A dissector can use a protocol/key pair to find a potentially > >> associated conversion already existing in another protocol. > >> * A dissector can access the set of keys for any protocol in an > >> associated conversation > How about something like > > * proto_conv_new(proto ,key(s)) > Check if global/top/main conversation exist by matching the key with > other protocols using that key. > ( string key looking in a (hash)table of strings finding list of > proto_conv ?) > if not create it and create the proto_conv. > Return proto_conv and possible top_conv > > * proto_conv_add_key(proto, key(s)); > if a new key has turned up in the conversation look if there are matching > proto_convs with a > different top_conv if true join them. > > I'm sure there are many pitfall here and with phone call as an example what > if two consecutive calls are made how to differentiate between them. Not sure that this as big a problem as it first seems: at some layer at least the protocol itself has this ambiguity, so it can provide an "end of conversation" explicitly - in fact I have previously thought this would be a good thing to add to the current conversations to distinguish re-use of identifiers in a new conversation. > Another mater is performance and memory consumption. One awkward relationship to consider is that conversations in different protocols at different layers have different multiplicity relationships with the conversations above and below them, e.g. a MAC layer conversation may have multiple RLC conversations carried over it (or specifically in 3G, an RRC connection can be associated with multiple RABs), and in some cases a high level "call" may be carried over several different bearers (e.g. in 3G SRBs and RABs associated with voice call). It would be really useful to be able to filter on this relationship at any level, so a filter on a conversation at a layer which includes a multiplexor may get multiple higher layer conversations included, and filtering on any one of these higher conversations excludes the other higher layer conversations, but still includes the lower layer multiplex conversation which carries it. Perhaps you could consider "conversations" to be any such general relationship between endpoints, no matter how dynamic, e.g. in 3G TCP/IP/Ethernet terms, an Ethernet "conversation" can carry multiple IP conversations (and other protocol conversations), each of which can carry the TCP conversations, each of which may carry signalling for (typically more dynamic) higher layer conversations. Or has this abstracted too far? If the above could be made to work in a general way, the current bloat of the packet info structure might be reduced, as it tends to get custom data to handle some of the specific relationships. Neil This message contains confidential information and may be privileged. If you are not the intended recipient, please notify the sender and delete the message immediately. ip.access Ltd, registration number 3400157, Building 2020, Cambourne Business Park, Cambourne, Cambridge CB23 6DW, United Kingdom ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] [Wireshark-commits] rev 39305: /trunk/epan/dissectors/ /trunk/epan/dissectors/: packet-sdp.c
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 resolve this, other than changing my compiler, which isn't an easy option right now. Martin On Fri, Oct 7, 2011 at 5:42 PM, wrote: > http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=rev&revision=39305 > > User: etxrab > Date: 2011/10/07 09:42 AM > > Log: > - Put a TRY/CATCH block around dissect_h264_nal_unit() in case > a bogus nal unit was sent. > - Delete an unused hf entry. > > https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=6407 > > Directory: /trunk/epan/dissectors/ > ChangesPathAction > +11 -7 packet-sdp.cModified > > ___ > Sent via:Wireshark-commits mailing list < > wireshark-comm...@wireshark.org> > Archives:http://www.wireshark.org/lists/wireshark-commits > Unsubscribe: https://wireshark.org/mailman/options/wireshark-commits > mailto:wireshark-commits-requ...@wireshark.org > ?subject=unsubscribe > ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] FW: [Wireshark-commits] buildbot failure in Wireshark (development) on Ubuntu-10.04-x64
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/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] FW: [Wireshark-commits] buildbot failure in Wireshark (development) on Ubuntu-10.04-x64
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 dissectors/packet-sv.c + dissectors/packet-t38.c dissectors/packet-ulp.c dissectors/packet-wlancertextn.c dissectors/packet-x224.c @@ -1009,7 +1010,6 @@ dissectors/packet-synphasor.c dissectors/packet-syslog.c dissectors/packet-t30.c - dissectors/packet-t38.c dissectors/packet-tacacs.c dissectors/packet-tali.c dissectors/packet-tapa.c Unfortunatly I can't check it in, company FW rules must have changed. Regards Anders -Original Message- From: wireshark-commits-boun...@wireshark.org [mailto:wireshark-commits-boun...@wireshark.org] On Behalf Of buildbot-no-re...@wireshark.org Sent: den 10 oktober 2011 05:24 To: wireshark-comm...@wireshark.org Subject: [Wireshark-commits] buildbot failure in Wireshark (development) on Ubuntu-10.04-x64 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/320 Buildbot URL: http://buildbot.wireshark.org/trunk/ Buildslave for this Build: ubuntu-10.04-x64 Build Reason: scheduler Build Source Stamp: 39333 Blamelist: morriss,wmeier BUILD FAILED: failed cmake sincerely, -The Buildbot ___ Sent via:Wireshark-commits mailing list Archives:http://www.wireshark.org/lists/wireshark-commits Unsubscribe: https://wireshark.org/mailman/options/wireshark-commits mailto:wireshark-commits-requ...@wireshark.org?subject=unsubscribe ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Decompress Data
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 example of tvb_child_uncompress() is in the HTTP dissector, epan/dissectors/packet-http.c. ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe hmm okay it seems to do the right way if i make it like that next_tvb =tvb_new_subset(tvb,offset2,-1,-1); compress_tvb=tvb_uncompress(next_tvb,0,tvb_length(next_tvb)); add_new_data_source(pinfo,compress_tvb,"Decompressed TVB"); ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Decompress Data
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 example of tvb_child_uncompress() is in the
HTTP
dissector, epan/dissectors/packet-http.c.
___
Sent via:Wireshark-dev mailing list
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Iam using the tvb_umcompress function now.
Code:
if(compress==67){
offset2=loh+20;
compress_tvb=tvb_uncompress(tvb,offset2,tvb_length(tvb));
add_new_data_source(pinfo,compress_tvb,"Decompressed TVB");
}
But it didnt work ..i get a failer when i get a uncompress packet.
[Malformed Packet:NOS]
[Expert Info (Error/Malformed):Malformed Packet (Exception
occurred)]
I guess that means i cant uncompress my packet with that function ?
___
Sent via:Wireshark-dev mailing list
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
