Warn Dissector bug, protocol CAPWAP-CONTROL, in packet 1: proto.c:7802: field capwap.control.message_element.wtp_frame_tunnel_mode is not of an FT_{U}INTn type
Warn Dissector bug, protocol CAPWAP-CONTROL, in packet 2: proto.c:7802: field capwap.control.message_element.ac_descriptor.security is not of an FT_{U}INTn type
...
Change-Id: I03f70ca664d99771ad27457052e6df11f9d5ad9e
Reviewed-on: https://code.wireshark.org/review/6964
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Change-Id: I39ff2e15b91981111f8de091e6e5dfb7586b4599
Reviewed-on: https://code.wireshark.org/review/6937
Reviewed-by: Michael Mann <mmann78@netscape.net>
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Change-Id: I62886bda3220d9aa3a5b3aee8b40063a8bb7745d
Reviewed-on: https://code.wireshark.org/review/6843
Petri-Dish: Alexis La Goutte <alexis.lagoutte@gmail.com>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Michael Mann <mmann78@netscape.net>
Based from FortiAP/WiFi 5.2.x
Change-Id: Ia78d15d54db01939a3d91947db39e35b3abc2519
Reviewed-on: https://code.wireshark.org/review/5646
Petri-Dish: Alexis La Goutte <alexis.lagoutte@gmail.com>
Reviewed-by: Alexis La Goutte <alexis.lagoutte@gmail.com>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Anders Broman <a.broman58@gmail.com>
* IEEE 802.11 Information Element (1029)
Add add_tagged_field to packet-ieee80211.h (will be used by other dissector)
Change-Id: Icd13be416ccc47fb2309b9962e9a47c339885d1e
Reviewed-on: https://code.wireshark.org/review/6524
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>
* Delete Station (18)
Change-Id: I33afa96d183b8ff22725d2e00dcfeccea3fdfa04
Reviewed-on: https://code.wireshark.org/review/6508
Reviewed-by: Michael Mann <mmann78@netscape.net>
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Specifically:
- Set packet.h to be the first wireshark #include after
config.h and "system" #includes.
packet.h added as an #include in some cases when missing.
- Remove some #includes included (directly/indirectly) in
packet.h. E.g., glib.h.
(Done only for those files including packet.h).
- As needed, move "system" #includes to be after config.h and
before wireshark #includes.
- Rework various #include file specifications for consistency.
- Misc.
Change-Id: Ifaa1a14b50b69fbad38ea4838a49dfe595c54c95
Reviewed-on: https://code.wireshark.org/review/5923
Petri-Dish: Alexis La Goutte <alexis.lagoutte@gmail.com>
Reviewed-by: Bill Meier <wmeier@newsguy.com>
* AC Timestamp (6)
* Add Station (6)
* CAPWAP Local IPv4 Address (30)
* CAPWAP Local IPv6 Address (50)
* CAPWAP Transport Protocol (51)
* MTU Discovery Padding (52)
* ECN Support (53)
Change-Id: Ib8b2768d5df4b0e1b5b8b5bd28ae66e825020205
Reviewed-on: https://code.wireshark.org/review/3986
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>
When it is the mininum wrong length for Message Element Type or
when the Message Element Type is not yet decoded by Wireshark
Change-Id: I49aca0df5ba5ec70d8fb764fef39c17c46ee22a0
Reviewed-on: https://code.wireshark.org/review/3956
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Avoid to have all subtree has expended
Only 2 ett actually and there is > 20 subtree...
Change-Id: Ia4af85345a6f1963d24d1fd589ff8ee09a8ef412
Reviewed-on: https://code.wireshark.org/review/3955
Reviewed-by: Jeff Morriss <jeff.morriss.ws@gmail.com>
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Avoid to have 2 CAPWAP in Decode as (and more easy to use too...)
Change-Id: I3a332e9b4b069b9215c38b5c08872bd07ac4c2c3
Reviewed-on: https://code.wireshark.org/review/3954
Reviewed-by: Jeff Morriss <jeff.morriss.ws@gmail.com>
Reviewed-by: Anders Broman <a.broman58@gmail.com>
For hf field, reindent code
Use 0x0 by default for bitmask
Remove also some "boilerplate" comment..
Change-Id: I552ccca2e444f3686ee9ecdad456f2ecfbaa5cba
Reviewed-on: https://code.wireshark.org/review/3953
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Thanks to Massimo Velluci for sample
Change-Id: Ibab2658c2c11c9940d3fdebb0bdc42752d57e1ae
Reviewed-on: https://code.wireshark.org/review/3871
Reviewed-by: Alexis La Goutte <alexis.lagoutte@gmail.com>
Also make repetition_coding_indications[] standard terminated.
Change-Id: Ice20e1f27f5ab4d111f893608a230b83899efc9f
Reviewed-on: https://code.wireshark.org/review/2288
Reviewed-by: Alexis La Goutte <alexis.lagoutte@gmail.com>
Reviewed-by: Evan Huus <eapache@gmail.com>
* Wireless data ieee80211 RSSI (dBm) is a signed integer. In the wireless radio the dBm value is negative.
* Wireless data ieee80211 Data Rate (Mbps) is a 100Kbps. You need divide this value by 10.
Issue found by Massimo Vellucci (SmartCAPWAP)
Change-Id: I04dd8a9e38a5f60ee5bf64cd304db1b11413c809
Reviewed-on: https://code.wireshark.org/review/2094
Reviewed-by: Anders Broman <a.broman58@gmail.com>
For a number of protocols that encapsulate 802.11 frames inside packets,
whether the frame includes an FCS or not is specified by the protocol,
not by whether the link-layer frame carrying the packets *itself*
includes an FCS. As we've done with Ethernet, add "_withfcs" and
"_withoutfcs" dissectors, which *don't* check the pseudo-header FCS
length indication, and call those, rather than dissectors that check the
pseudo-header length indication, from the dissectors for those protocols.
Change-Id: Ib8c8ecdd872e1782fdfc66e7573415d91911a62e
Reviewed-on: https://code.wireshark.org/review/1866
Reviewed-by: Guy Harris <guy@alum.mit.edu>
(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>
Found by Massimo Vellucci
Change-Id: Ibbe2d0a4d1e421e647028262baf0398d05905c8d
Reviewed-on: https://code.wireshark.org/review/246
Reviewed-by: Alexis La Goutte <alexis.lagoutte@gmail.com>
Tested-by: Alexis La Goutte <alexis.lagoutte@gmail.com>
be done on flows from one address to another; reassembly for protocols
running atop TCP should be done on flows from one TCP endpoint to
another.
We do this by:
adding "reassembly table" as a data structure;
associating hash tables for both in-progress reassemblies and
completed reassemblies with that data structure (currently, not
all reassemblies use the latter; they might keep completed
reassemblies in the first table);
having functions to create and destroy keys in that table;
offering standard routines for doing address-based and
address-and-port-based flow processing, so that dissectors not
needing their own specialized flow processing can just use them.
This fixes some mis-reassemblies of NIS YPSERV YPALL responses (where
the second YPALL response is processed as if it were a continuation of
a previous response between different endpoints, even though said
response is already reassembled), and also allows the DCE RPC-specific
stuff to be moved out of epan/reassembly.c into the DCE RPC dissector.
svn path=/trunk/; revision=48491
The problem is when Wireshark dissect CAPWAP packets from Cisco without preference "Cisco Wireless Controller Support"
In this case the whole packet decoded wrong, not only Wireless Specific Information field in CAPWAP header
I suggest following patch to dissect_capwap_header function to always return correct length of CAPWAP header based on HLEN header field
From me:
Add expert info to display a warning about Calculate length and Header length are different (and suggest to activate Cisco Wireless Controller Support Preference)
svn path=/trunk/; revision=47793
The reassembled fragments tree in the Packet Details view is awesome, but it
lacks one thing: a field that exposes the reassembled data.
tcp.data already exists for exposing a single TCP segment's payload as a byte
array. It would be handy to have something similar for a single application
layer PDU when TCP segment reassembly is involved. I propose
tcp.reassembled.data, named and placed after the already existing field
tcp.reassembled.length.
My primary use case for this feature is outputting tcp.reassembled.data with
tshark for further processing with a script.
The attached patch implements this very feature. Because the reassembled
fragment tree code is general purpose, i.e. not specific to just TCP, any
dissector that relies upon it can add a similar field very cheaply. In that
vein I've also implemented ip.reassembled.data and ipv6.reassembled.data, which
expose reassembled fragment data as a single byte stream for IPv4 and IPv6,
respectively. All other protocols that use the reassembly code have been left
alone, other than inserting NULL into their initializer lists for the newly
introduced struct field reassemble.h:fragment_items.hf_reassembled_data.
svn path=/trunk/; revision=44802
