Where is tshark -T jsonraw documented?

asked 2019-09-20 23:52:11 +0000

Ross Jacobs
71 ●3 ●32 ●13

Problem

I am trying to understand how to use jsonraw as an option, as I saw it on the manpage. The major difference between it and json is that jsonraw includes the hex for each field.

Example Packet Capture/Packet

For example, packet 4 of this PacketLife capture is an ARP packet.

If we run tshark on this capture, and then grep for a specific field (eth.src-raw), we see that there is the raw hex 881544b14f70, but also 4 other values.

$ tshark -r STP\ UplinkFast.pcapng -T jsonraw -Y "frame.number == 4" | grep eth.src_raw -A 6
"eth.src_raw": [
            "881544b14f70",
            6,
            6,
            0,
            29
          ],

Speculation Time

It's fair to assume that the two 6's in json["eth.src_raw"][1:3] have something to do with the fact that a MAC address takes up 6 bytes. 29 might be where this value starts? And then 0 is...?

Searching for Info

Searching for jsonraw in the User Guide turns up no results. Tshark's manpage admits that it exists, but not much more.

Question

Where can I find more information on tshark -T jsonraw?

edit retag flag offensive close merge delete

add a comment

3 Answers

Sort by » oldest newest most voted

answered 2020-06-01 11:23:00 +0000

Martin K
1

The intended use of jsonraw was to reduce the "tshark -T json -x" output size and still to allow to dissect the protocol layers on raw/byte level and provide information regarding the dissected field. For possible use see the json2pcap script (however not all information are preserved in jsonraw compared to -T json -x, as frame timestamp).

The values in raw fields are:

          "eth.src_raw": [
            "881544b14f70",    # hex string
            6,                 # position in frame
            6,                 # length
            0,                 # bitmask
            29                 # type
          ],

The json2pcap script is flattening back the json into raw frame from highest layers to lowest. Certain fields are not byte aligned and then the bitmask is also used.

edit flag offensive delete link

add a comment

answered 2019-09-21 14:06:57 +0000

Chuckc
2858 ●5 ●567 ●19

Frame types is an enum and looks like it might be different from what the dissector doc shows:

 1 /* ftypes.h
   2  * Definitions for field types


  23 /* field types */
  24 enum ftenum {
  25         FT_NONE,        /* used for text labels with no value */
  26         FT_PROTOCOL,
  27         FT_BOOLEAN,     /* TRUE and FALSE come from <glib.h> */
  28         FT_CHAR,        /* 1-octet character as 0-255 */
  29         FT_UINT8,
  30         FT_UINT16,
  31         FT_UINT24,      /* really a UINT32, but displayed as 6 hex-digits if FD_HEX*/
  32         FT_UINT32,
  33         FT_UINT40,      /* really a UINT64, but displayed as 10 hex-digits if FD_HEX*/
  34         FT_UINT48,      /* really a UINT64, but displayed as 12 hex-digits if FD_HEX*/
  35         FT_UINT56,      /* really a UINT64, but displayed as 14 hex-digits if FD_HEX*/
  36         FT_UINT64,
  37         FT_INT8,
  38         FT_INT16,
  39         FT_INT24,       /* same as for UINT24 */
  40         FT_INT32,
  41         FT_INT40, /* same as for UINT40 */
  42         FT_INT48, /* same as for UINT48 */
  43         FT_INT56, /* same as for UINT56 */
  44         FT_INT64,
  45         FT_IEEE_11073_SFLOAT,
  46         FT_IEEE_11073_FLOAT,
  47         FT_FLOAT,
  48         FT_DOUBLE,
  49         FT_ABSOLUTE_TIME,
  50         FT_RELATIVE_TIME,
  51         FT_STRING,
  52         FT_STRINGZ,     /* for use with proto_tree_add_item() */
  53         FT_UINT_STRING, /* for use with proto_tree_add_item() */
  54         FT_ETHER,
  55         FT_BYTES,
  56         FT_UINT_BYTES,
  57         FT_IPv4,
  58         FT_IPv6,
  59         FT_IPXNET,
  60         FT_FRAMENUM,    /* a UINT32, but if selected lets you go to frame with that number */
  61         FT_PCRE,        /* a compiled Perl-Compatible Regular Expression object */
  62         FT_GUID,        /* GUID, UUID */
  63         FT_OID,         /* OBJECT IDENTIFIER */
  64         FT_EUI64,
  65         FT_AX25,
  66         FT_VINES,
  67         FT_REL_OID,     /* RELATIVE-OID */
  68         FT_SYSTEM_ID,
  69         FT_STRINGZPAD,  /* for use with proto_tree_add_item() */
  70         FT_FCWWN,
  71         FT_NUM_TYPES /* last item number plus one */
  72 };
  73

edit flag offensive delete link

add a comment

answered 2019-09-21 13:48:10 +0000

Chuckc
2858 ●5 ●567 ●19

 912 /**
 913  * Writes the hex dump of a node. A json array is written containing the hex dump, position, length, bitmask and type of
 914  * the node.
 915  */

 958     /* Dump raw hex-encoded dissected information including position, length, bitmask, type */
 959     json_dumper_value_anyf(pdata->dumper, "%" G_GINT32_MODIFIER "d", fi->start);
 960     json_dumper_value_anyf(pdata->dumper, "%" G_GINT32_MODIFIER "d", fi->length);
 961     json_dumper_value_anyf(pdata->dumper, "%" G_GUINT64_FORMAT, fi->hfinfo->bitmask);
 962     json_dumper_value_anyf(pdata->dumper, "%" G_GINT32_MODIFIER "d", (gint32)fi->value.ftype->ftype);

 190 BITMASK         Used to mask a field not 8-bit aligned or with a size other
 191                 than a multiple of 8 bits


1201 bitmask (BITMASK)
1202 -----------------
1203 If the field is a bitfield, then the bitmask is the mask which will
1204 leave only the bits needed to make the field when ANDed with a value.
1205 The proto_tree routines will calculate 'bitshift' automatically
1206 from 'bitmask', by finding the rightmost set bit in the bitmask.
1207 This shift is applied before applying string mapping functions or
1208 filtering.
1209 
1210 If the field is not a bitfield, then bitmask should be set to 0.


 type (FIELDTYPE)
 825 ----------------
 826 The type of value this field holds. The current field types are:
 827 
 828     FT_NONE     No field type. Used for fields that
 829                 aren't given a value, and that can only
 830                 be tested for presence or absence; a
 831                 field that represents a data structure,
 832                 with a subtree below it containing
 833                 fields for the members of the structure,
 834                 or that represents an array with a
 835                 subtree below it containing fields for
 836                 the members of the array, might be an
 837                 FT_NONE field.
 838     FT_PROTOCOL Used for protocols which will be placing
 839                 themselves as top-level items in the
 840                 "Packet Details" pane of the UI.
 841     FT_BOOLEAN  0 means "false", any other value means
 842                 "true".
 843     FT_FRAMENUM A frame number; if this is used, the "Go
 844                 To Corresponding Frame" menu item can
 845                 work on that field.
 846     FT_CHAR     An 8-bit ASCII character. It's treated similarly to an
 847                 FT_UINT8, but is displayed as a C-style character
 848                 constant.
 849     FT_UINT8    An 8-bit unsigned integer.
 850     FT_UINT16   A 16-bit unsigned integer.
 851     FT_UINT24   A 24-bit unsigned integer.
 852     FT_UINT32   A 32-bit unsigned integer.
 853     FT_UINT40   A 40-bit unsigned integer.
 854     FT_UINT48   A 48-bit unsigned integer.
 855     FT_UINT56   A 56-bit unsigned integer.
 856     FT_UINT64   A 64-bit unsigned integer.
 857     FT_INT8     An 8-bit signed integer.
 858     FT_INT16    A 16-bit signed integer.
 859     FT_INT24    A 24-bit signed integer.
 860     FT_INT32    A 32-bit signed integer.
 861     FT_INT40    A 40-bit signed integer.
 862     FT_INT48    A 48-bit signed integer.
 863     FT_INT56    A 56-bit signed integer.
 864     FT_INT64    A 64-bit signed integer.
 865     FT_FLOAT    A single-precision floating point number.
 866     FT_DOUBLE   A double-precision floating point number.
 867     FT_ABSOLUTE_TIME    An absolute time from some fixed point in time,
 868                 displayed as the date, followed by the time, as
 869                 hours, minutes, and seconds with 9 digits after
 870                 the decimal point.
 871     FT_RELATIVE_TIME    Seconds (4 bytes) and nanoseconds (4 bytes)
 872                 of time relative to ...

(more)

edit flag offensive delete link

Comments

The question is "Where is it documented?" This technically answers the question because you show where it's documented, but the answer should include "It is only documented in the code."

Ross Jacobs ( 2019-09-22 17:21:24 +0000 )edit

Looks like it is the complement to json2pcap:

https://github.com/wireshark/wireshark/blob/master/tools/json2pcap/json2pcap.py

Perhaps Martin can comment about intended use.

From the "authors" file:

3686 Martin Kacer    <kacer.martin[AT]gmail.com> {
3687         JSON and Elasticsearch tshark output
3688         json2pcap
3689
}

Chuckc ( 2019-09-22 19:31:45 +0000 )edit

Cheers @bubbasnmp

Ross Jacobs ( 2019-09-23 16:10:30 +0000 )edit

add a comment

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Where is tshark -T jsonraw documented?

Problem

Example Packet Capture/Packet

Speculation Time

Searching for Info

Question

3 Answers

Comments

Your Answer

Question Tools

Stats

Related questions

Where is tshark -T jsonraw documented? edit

Problem

Example Packet Capture/Packet

Speculation Time

Searching for Info

Question

3 Answers

Comments

Your Answer

Question Tools

Stats

Related questions

Where is tshark -T jsonraw documented?