Change-Id: I3b5afb8a59f6443624708b9fecfdcbe93dad59ef
Note: Some of the filters, when/if used, could have caused Wireshark crashes.
Reviewed-on: https://code.wireshark.org/review/5575
Reviewed-by: Bill Meier <wmeier@newsguy.com>
Fix AS Path Heuristic
Issue reported by Jon
Bug: 10742
Change-Id: Ie5e4108bd93464a2d1076dcc4f322171ea8e68cb
Reviewed-on: https://code.wireshark.org/review/5564
Reviewed-by: Alexis La Goutte <alexis.lagoutte@gmail.com>
The offset used for BGP community tag dissection is a wrong one.
Bug: 10746
Change-Id: I1d1d443568bb97a0b3b95a312762ac0a3102326a
Reviewed-on: https://code.wireshark.org/review/5562
Reviewed-by: Alexis La Goutte <alexis.lagoutte@gmail.com>
Change-Id: I13197cc48068bb35ee12a7023cfe5f76bbc4e264
Reviewed-on: https://code.wireshark.org/review/5486
Petri-Dish: Michael Mann <mmann78@netscape.net>
Reviewed-by: Michael Mann <mmann78@netscape.net>
For:
- FT_BYTES: Always use just ENC_NA
- integral/floating (other than FT_[U]INT8): Do ENC_NA --> ENC_BIG_ENDIAN
Also:
- FT_UINT... --> FT_UINT8 in a few cases (to match proto_tree_add_item...)
- Change one case of incorrect '||' to '|'
Change-Id: I427e0e61618ff8faf55691c8a695930f67d455b0
Reviewed-on: https://code.wireshark.org/review/4184
Reviewed-by: Bill Meier <wmeier@newsguy.com>
Create filters (expert and hf_) that have the "most bang for the buck" (ie have many instances for a single filter)
Change-Id: I61995e41c5b298df77e084e65cdf30ebe95da1e6
Reviewed-on: https://code.wireshark.org/review/4086
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>
Add also a expert info when unable determine ASN length (2 or 4 bytes)
Bug: 10399
Change-Id: I24978e29e24f38c2e01e4b953a5a51496f0cf5a6
Reviewed-on: https://code.wireshark.org/review/3831
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>
What mystical new compiler upgrade is this?
Change-Id: I89b3bfb53b9a19bbfb1cc8339d38cdc4a4652c62
Reviewed-on: https://code.wireshark.org/review/3347
Reviewed-by: Evan Huus <eapache@gmail.com>
Change-Id: Ib60ca75b7da8cfa21cfe2999c9b9448a02c332df
Reviewed-on: https://code.wireshark.org/review/2560
Tested-by: Michael Mann <mmann78@netscape.net>
Reviewed-by: Michael Mann <mmann78@netscape.net>
(Using sed : sed -i '/^ \* \$Id\$/,+1 d')
Fix manually some typo (in export_object_dicom.c and crc16-plain.c)
Change-Id: I4c1ae68d1c4afeace8cb195b53c715cf9e1227a8
Reviewed-on: https://code.wireshark.org/review/497
Reviewed-by: Anders Broman <a.broman58@gmail.com>
The majority of the fixes are for calls to uat_new(). Instead of
having each caller cast its private data to (void**), we use void*
in the uat_new() API itself. Inside uat_new(), we cast the void*
to void**.
Some dissectors use val64_string arrays, so a VALS64() macro was
added for those, to avoid using VALS(), which is useful only for
value_string arrays.
packet-mq.c was changed because dissect_nt_sid() requires
a char**, not a guint**. All other callers of dissect_nt_sid() use
char*'s (and take the address of it) for their local storage. So,
this was changed to follow the other practices.
A confusion between gint and absolute_time_display_e in packet-time.c
was cleared up.
The ugliest fix is the addition of ip6_guint8_to_str(), for exactly
one caller. The caller uses one type of ip6 address byte array,
while ip6_to_str() expects another. This new function is in place
until the various address implementations can be consolidated.
Add VALS64() to the developer documentation.
Change-Id: If93ff5c6c8c7cc3c9510d7fb78fa9108e4552805
Reviewed-on: https://code.wireshark.org/review/48
Reviewed-by: Evan Huus <eapache@gmail.com>
Reviewed-by: Stig Bjørlykke <stig@bjorlykke.org>
Reviewed-by: Alexis La Goutte <alexis.lagoutte@gmail.com>
Tested-by: Alexis La Goutte <alexis.lagoutte@gmail.com>
an hf[] entry but defined as a 'value_string' intead of
as a 'val64_string'.
Caused 'tshark -G values' to crash
(and presumably would also cause a crash when the value-string
is referenced in a dissection):
Introduced in svn #54728
(Note: There's still another 'tshark -G values' crash to to found & fixed)
svn path=/trunk/; revision=54983
BGPTYPE_LINK_STATE_ATTR is temporarily set to 99, would need change when IANA allocate a Path Attribute value for BGP-LS
From me :
* Fix indent
* fix arg encoding (via encoding-args tools)
svn path=/trunk/; revision=54728
obvious that the returned string is ephemeral, and opens up the original names
in the API for versions that take a wmem pool (and thus can work in any scope).
svn path=/trunk/; revision=54249
Step 4 : Convert proto_tree_add_text calls to proto_tree_add_item and use new name of RFC4271 ( Withdrawn Routes Length ...)
svn path=/trunk/; revision=51184
Enhance BGP Dissector
Step 3 :Variable consistency and renaming, adding RFC and draft as comments (Preperation for next enhance...)
From me :
Fix some typo/whitespace
Make checkhf happy...
Signed-off-by: Alexis La Goutte <alexis.lagoutte@gmail.com>
svn path=/trunk/; revision=51182
Within BGP Update message for BGP VPLS (RFC 4761) some parts of Extended Community "Layer2 Info" are incorrectly decoded:
1. Encapsulation - Unknown (0x13). Per RFC 4761 encap type 0x13 is "VPLS" (clause 3.2.4);
2. Control Flags - per RFC 4761 (clause 3.2.4) two least-significant bits (6 and 7) are defined as:
"C" (bit 6, Control Word): value 1 - Control Word is required - and value 0 - Control Word is not required; decoding is correct (at least for value 0);
"S" (bit 7, Sequence delivery): value 1 - Sequence delivery is required - and value 0 - Sequence delivery is not required; decoding is incorrect, because for value 0 (sequence delivery is not required) you provide description that "Sequence delivery is required".
Also, there is description (at the same string) "F Flag (reserved) set. IETF document draft-ietf-l2vpn-vpls-multihoming (clause 3.3.1) updates RFC 4761 and defines two additional bits within Control Flags byte - D (bit 0, "Down") and F (bit 2, "Flush"). You provide description that "F Flag (reserved) set" when this flag actually is not set (value 0). Furthermore, you don't provide description about status of flag D (in attached dump in the first packet flag D is set and unset in the second packet).
svn path=/trunk/; revision=50085