ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
July 17th, 2024 | 10:00am-11:55am SGT (UTC+8) | Online

Wireshark-bugs: [Wireshark-bugs] [Bug 12086] New: -T fields inconsistent in how it shows fields

Date: Fri, 05 Feb 2016 15:16:16 +0000
Bug ID 12086
Summary -T fields inconsistent in how it shows fields that are protocol layers
Product Wireshark
Version 1.12.3
Hardware x86
OS Windows 7
Status UNCONFIRMED
Severity Normal
Priority Low
Component TShark
Assignee [email protected]
Reporter [email protected]

Created attachment 14309 [details]
Capture file from example

Build Information:
$ tshark -v
TShark 1.12.3 (Git Rev Unknown from unknown)

Copyright 1998-2015 Gerald Combs <[email protected]> and contributors.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Compiled (32-bit) with GLib 2.38.0, with WinPcap (4_1_3), with libz 1.2.5, with
SMI 0.4.8, with c-ares 1.9.1, with Lua 5.2, without Python, with GnuTLS 3.2.15,
with Gcrypt 1.6.2, with MIT Kerberos, with GeoIP.

Running on 64-bit Windows 7 Service Pack 1, build 7601, without WinPcap.
        Intel(R) Core(TM) i5-2500 CPU @ 3.30GHz, with 8148MB of physical
memory.


Built using Microsoft Visual C++ 12.0 build 31101
--
Inconsistency in the way "-T fields" handles "fields" that are protocols -
"frame" shows the top-level line in the display of frame,
"ipx"/"ipxrip"/"wlan_mgt"/etc. show the protocol's "filter name", and "data"
shows the data.
A field name that is a protocol layer, such as wlan_mgt should display the
byte string payload of that complete layer in the same way that the field
"data" displays for frames that include a "data" layer.  I also think "frame"
should give the byte string of the complete frame rather than a frame
summary or there should be a way to do that such as "frame.payload".

Example:
Frames 1-7 are WLAN management frames, frames 8-11 are wlan data frames with
EAPOL protocol and frames 12-15 are wlan data frames with encrypted data.

I would expect the field "frame" to display the complete frame byte string,
and the field "wlan_mgt" to display the byte string of the wlan_mgt layer the
same as "data" displays the byte string of frames 12-15.

$ tshark -r wpa.full.cap -2 -O wlan -T fields -e frame -e wlan.fc.type -e
wlan.fc.subtype -e wlan_mgt -e data -E separator=,
Frame 1: 109 bytes on wire (872 bits), 109 bytes captured (872
bits),0,8,wlan_mgt,
Frame 2: 42 bytes on wire (336 bits), 42 bytes captured (336
bits),0,4,wlan_mgt,
Frame 3: 103 bytes on wire (824 bits), 103 bytes captured (824
bits),0,5,wlan_mgt,
Frame 4: 30 bytes on wire (240 bits), 30 bytes captured (240
bits),0,11,wlan_mgt,
Frame 5: 30 bytes on wire (240 bits), 30 bytes captured (240
bits),0,11,wlan_mgt,
Frame 6: 79 bytes on wire (632 bits), 79 bytes captured (632
bits),0,0,wlan_mgt,
Frame 7: 60 bytes on wire (480 bits), 60 bytes captured (480
bits),0,1,wlan_mgt,
Frame 8: 131 bytes on wire (1048 bits), 131 bytes captured (1048 bits),2,0,,
Frame 9: 155 bytes on wire (1240 bits), 155 bytes captured (1240 bits),2,0,,
Frame 10: 155 bytes on wire (1240 bits), 155 bytes captured (1240 bits),2,0,,
Frame 11: 131 bytes on wire (1048 bits), 131 bytes captured (1048 bits),2,0,,
Frame 12: 183 bytes on wire (1464 bits), 183 bytes captured (1464
bits),2,0,,3e71a281c4c01e01f06998bc85cb64a3189f078ab63f9a4e7a09765f5e8fa2d4f3b3db4a3fc0eeb7afc74317a502f8c5e25979800f93501534bd29a28f730763f7eea056cb18988973e786ad2ede9e5f071d16ae9de80bdd80d142ce0734f4159701299da1c983e45f5f0f05bf5adf3bf8924b6b79c9693276058b339246adacc874ab71f74fba491eaa0a4676a58f8962e95005f22ba1
Frame 13: 151 bytes on wire (1208 bits), 151 bytes captured (1208
bits),2,0,,4411d8802a3e6e78f2cd4ddb5ea64eb924be098c899523400239a1ee540e507df10d71d2bff287f73794557511181ca990ce591b53f36b614f046feb63bc2c5bbad9cd73e144ec300d5b2466b05dd4a6f6c1a207bc50c24bde2d36d3decfe3451cb142942d5b41515d998beecd74ee65a21f49a289f186
Frame 14: 183 bytes on wire (1464 bits), 183 bytes captured (1464
bits),2,0,,1c298090eea7b6bff21cc6b5ba5f12e9bc61bc36dffc54b3c5bf2ebf5e9cffd85fe09c2a7075c8aad9e13cebc41bac7a20d22a317a3410e6ef4ce31db513fa14fadb6da3d90fb93bfb7a7f4c49cee4280d0a233f5917a7145f0a232dfcb8fb8421730b84a80b427d878f36fa1bed43daf311b7c2a5a7bba2193c3e684905d08218c63cee9803f9c14d51ab73e0367c609b3feb546cbfdc
Frame 15: 151 bytes on wire (1208 bits), 151 bytes captured (1208
bits),2,0,,e477ec0e08f4b1bad6fb565a119d99c862e1e0ef804627d36a308b2f19fb1ea489eb07a9e386b59c941fa9e3b15e463d57f792a720deb618effb9c7fbad2727d8c4b82f90ecc23fde45aeebc2a4651a84bfeeb887aea68ed9fe9aa96c721e569930da0154af1c1ae9084abc29179bf4cba1be19a6b1338


You are receiving this mail because:
  • You are watching all bug changes.