Always set is_removed when insert data in a node.
Change-Id: I8fb50932a369e3f4fe8a1f743462683fff705cc2
Reviewed-on: https://code.wireshark.org/review/9978
Reviewed-by: Stig Bjørlykke <stig@bjorlykke.org>
As the comment says, "Entries must be sorted by
WTAP_FILE_TYPE_SUBTYPE_xxx values in ascending order." If they're not,
the file type to file type string routines don't give the right answer.
Change-Id: I06afe7bb98cb36c54ddc831113bb632598ab2eb0
Reviewed-on: https://code.wireshark.org/review/9975
Reviewed-by: Guy Harris <guy@alum.mit.edu>
This will allow integer value 0 again.
Change-Id: Ibfa4249ea8b887971d3b3214ad9e4d095d20d155
Reviewed-on: https://code.wireshark.org/review/9973
Reviewed-by: Stig Bjørlykke <stig@bjorlykke.org>
This is initial support for reloading Lua plugins without
restarting the application.
Still todo:
- Deregister FileHandlers
- Support deregister ProtoField with existing abbrev (same_name_hfinfo)
- Add a progress dialog when reloading many plugins
- Search for memory leakages in wslua functions
Change-Id: I48870d8741251705ca15ffe1068613fcb0cb18c1
Reviewed-on: https://code.wireshark.org/review/5028
Reviewed-by: Stig Bjørlykke <stig@bjorlykke.org>
to 0.
Change-Id: I837bf8ac9d5724dd485f0bc62f3fe32bedd3eb0e
Reviewed-on: https://code.wireshark.org/review/9970
Reviewed-by: Anders Broman <a.broman58@gmail.com>
==5932== 33 (32 direct, 1 indirect) bytes in 1 blocks are definitely lost in loss record 2,124 of 4,121
==5932== at 0x4C28BED: malloc (vg_replace_malloc.c:263)
==5932== by 0xA024F30: g_malloc (gmem.c:159)
==5932== by 0xA03A9E5: g_memdup (gstrfuncs.c:384)
==5932== by 0x70754D2: gp_init_zbee_security (packet-zbee-nwk-gp.c:1459)
==5932== by 0xA03A78C: g_slist_foreach (gslist.c:840)
==5932== by 0x67E867C: init_dissection (packet.c:249)
==5932== by 0x67DC202: epan_new (epan.c:160)
==5932== by 0x414B16: cf_open (tshark.c:2464)
==5932== by 0x40CF8A: main (tshark.c:2169)
Change-Id: I7c0ce0717957525ca18eb4888ed3389debc89a49
Reviewed-on: https://code.wireshark.org/review/9967
Petri-Dish: Martin Kaiser <wireshark@kaiser.cx>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Change-Id: I81b46ec7d9d919ff2779d1005063e9ef6c92e097
Reviewed-on: https://code.wireshark.org/review/9966
Reviewed-by: Martin Kaiser <wireshark@kaiser.cx>
Change-Id: Ib0f4cc47ede7b840cba38ecad04bd17bb6bccd55
Reviewed-on: https://code.wireshark.org/review/9965
Reviewed-by: Martin Kaiser <wireshark@kaiser.cx>
Right now the output encapsulation type is ignored if the output (default) format is set to pcapng.
Change-Id: Ibffaaed5979bf63ed4e3fa3b1f859a82b401d80b
Reviewed-on: https://code.wireshark.org/review/9911
Petri-Dish: Pascal Quantin <pascal.quantin@gmail.com>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Anders Broman <a.broman58@gmail.com>
It's not clear that the decryption code can handle an incomplete
payload. If it can, please fix this (bear in mind that you won't have
all the MIC, and may not have *any* of the MIC, so...).
Bug: 11389
Change-Id: Ie863ddc5c4aa7fbf6cde317823a413d226a41c0d
Reviewed-on: https://code.wireshark.org/review/9954
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Use the captured length to know how much data to decrypt. Use the
reported length to determine whether we have a null payload and to se
the reported length of the decrypted payload and of tvbuffs for the
un-decrypted payload.
Bug: 11389
Change-Id: I4395c5a48c16110fcf31b611b99749c61000d489
Reviewed-on: https://code.wireshark.org/review/9953
Reviewed-by: Guy Harris <guy@alum.mit.edu>
==17992== 4 bytes in 1 blocks are definitely lost in loss record 68 of 4,102
==17992== at 0x4C28BED: malloc (vg_replace_malloc.c:263)
==17992== by 0x9FB2F30: g_malloc (gmem.c:159)
==17992== by 0x9FC89E5: g_memdup (gstrfuncs.c:384)
==17992== by 0x703F977: dissect_zbee_aps (packet-zbee-aps.c:1300)
==17992== by 0x67B4F1E: call_dissector_through_handle (packet.c:618)
==17992== 8 bytes in 1 blocks are definitely lost in loss record 580 of 4,102
==17992== at 0x4C272B8: calloc (vg_replace_malloc.c:566)
==17992== by 0x9FB2F88: g_malloc0 (gmem.c:189)
==17992== by 0x703F962: dissect_zbee_aps (packet-zbee-aps.c:1299)
==17992== by 0x67B4F1E: call_dissector_through_handle (packet.c:618)
second version that uses glib memory routines and does not mix
g_hash_table and wmem
remove an obsolete comment and an unnecessary return; while at it
Change-Id: I2e92db0613f01b6c3009e8ad82ceb65a87cba12e
Reviewed-on: https://code.wireshark.org/review/9830
Petri-Dish: Martin Kaiser <wireshark@kaiser.cx>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Anders Broman <a.broman58@gmail.com>
While I was at it, some (mostly) duplicate functionality allowed rearranging of functions to eliminate most forward declarations.
Change-Id: I2d7027d336c391d81dfe81c7a1ebf0d56c0826b2
Reviewed-on: https://code.wireshark.org/review/9951
Reviewed-by: Michael Mann <mmann78@netscape.net>
Petri-Dish: Michael Mann <mmann78@netscape.net>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Anders Broman <a.broman58@gmail.com>
this length is used for allocating a buffer and for crypto calculations
we should use the bytes that were actually captured, not the reported
length
the capture in https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=11389
has one packet with a stupidly large reported length and a reasonable
capture length (and one completely bogus packet) - this fix ensures that
the decryption does not break for the former packet
also, tvb_reported_length_remaining() does not return values < 0 any
more, remove the check for this
Bug: 11389
Change-Id: I42cb4526483160416b51e3cb72442148b5fac4f3
Reviewed-on: https://code.wireshark.org/review/9950
Reviewed-by: Anders Broman <a.broman58@gmail.com>
packet-skinny.c is generated from packet-skinny.in and etc.
So: Change committed in gceb8d95 to packet-skinny.c should really
have been applied as well to packet-skinny.c.in.
Minor cleanup:
Remove a few unneeded initializers;
Remove unneeded code in proto_reg_handoff_skinny();
Replace a tab by spaces;
Change editor tab-width specification to be 8 (not 2). No actual
indentation change since tabs not used in the file.
packet-skinny.c regenerated using 'cog'
Change-Id: Ib3510c257e0b98bb7da8fae9aa010e134ec381cb
Reviewed-on: https://code.wireshark.org/review/9948
Reviewed-by: Bill Meier <wmeier@newsguy.com>
Change-Id: Ifd0dcc220cfdd0809f2e7cf2fc54fc8bdeb987be
Reviewed-on: https://code.wireshark.org/review/9947
Reviewed-by: Martin Kaiser <wireshark@kaiser.cx>
[There were no actual indentation changes since since none of the files
contained tabs].
Change-Id: I92ff551e70274f459c466e1c1d449905e0e7dc92
Reviewed-on: https://code.wireshark.org/review/9945
Reviewed-by: Bill Meier <wmeier@newsguy.com>
Add custom {developer,user}_guide_docbook targets for docbook output. Make
sure the HTML, PDF, and CHM outputs depend on their associated docbook
target and not on the output .xml file. This keeps us from running a2x
instances in parallel.
Change-Id: I73b0db50ae92f62eb08ae284d498cdf2d697ac00
Reviewed-on: https://code.wireshark.org/review/9920
Petri-Dish: Gerald Combs <gerald@wireshark.org>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Gerald Combs <gerald@wireshark.org>
Change-Id: I2990cb3432ad377cbed7039ad8fe15019eb7e7f5
Reviewed-on: https://code.wireshark.org/review/9927
Petri-Dish: Alexis La Goutte <alexis.lagoutte@gmail.com>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Alexis La Goutte <alexis.lagoutte@gmail.com>
Reviewed-by: Michael Mann <mmann78@netscape.net>
Change-Id: I0ea06451861412b642d033a70e0a639aae753beb
Reviewed-on: https://code.wireshark.org/review/9926
Reviewed-by: Alexis La Goutte <alexis.lagoutte@gmail.com>
Reviewed-by: Michael Mann <mmann78@netscape.net>
Bug: 11417
Change-Id: I62c6d94923dcda2ef8297086faac7d7c4b85a3fb
Reviewed-on: https://code.wireshark.org/review/9923
Reviewed-by: Michael Mann <mmann78@netscape.net>
Petri-Dish: Michael Mann <mmann78@netscape.net>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Alexis La Goutte <alexis.lagoutte@gmail.com>
Change-Id: Ibe55260e837f0a839649675c08e1bf66d8bcdb52
Reviewed-on: https://code.wireshark.org/review/9924
Reviewed-by: Michael Mann <mmann78@netscape.net>
Change-Id: I8161423ae270f685c28003eac36adf15be83c5fd
Reviewed-on: https://code.wireshark.org/review/9922
Reviewed-by: Michael Mann <mmann78@netscape.net>
Change-Id: I7836360ae4fe67098776911a496ecc969d3e093d
Reviewed-on: https://code.wireshark.org/review/9921
Reviewed-by: Michael Mann <mmann78@netscape.net>
If a host name is *so* long that an entry for it won't fit in a
65535-byte Name Resolution Block record, ignore the entry for that host.
Use more appropriate data types (guint32 for sizes that are 32-bit
unsigned integers, guint16 for the host name length as it'd better fit
in 16 bits).
Clean up some comments.
Remove a _U_ that's applied to a variable that *is* used.
Change-Id: I153d5aa885105149c62a5e5d2b78b54cf6ed7b4e
Reviewed-on: https://code.wireshark.org/review/9917
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Fix a couple of issues in the way we calculate the splash overlay
progress.
Avoid unnecessary repaints.
Change-Id: I1f4800b2c2836b67ca9ff3d6d24af150f4379ba9
Reviewed-on: https://code.wireshark.org/review/9916
Reviewed-by: Gerald Combs <gerald@wireshark.org>
Try to fix
packet-btl2cap.c: In function 'btl2cap_cid_value':
packet-btl2cap.c:425: warning: cast to pointer from integer of different size
packet-btl2cap.c: In function 'btl2cap_psm_value':
packet-btl2cap.c:448: warning: cast to pointer from integer of different size
packet-btrfcomm.c: In function 'btrfcomm_directed_channel_value':
packet-btrfcomm.c:287: warning: cast to pointer from integer of different size
packet-btobex.c: In function 'btobex_profile_value':
packet-btobex.c:1134: warning: cast to pointer from integer of different size
on the 32-bit OS X builder.
Change-Id: Ieb2fe6c31fdad0cf776c24bada7a6a83e8aa91ec
Reviewed-on: https://code.wireshark.org/review/9915
Reviewed-by: Gerald Combs <gerald@wireshark.org>
