Wireshark · Wireshark-dev: Re: [Wireshark-dev] Enrich tshark data

[Michael Mann <mmann78@xxxxxxxxxxxx>]

Adding on to Jaap's comments, because this is a particularly interesting case that you picked.

 

There are 2 fields here, the "HTTP status code" (as an integer), "http.response.code" and the "HTTP status code 'meaning'" (as a string, i.e. "OK"), "http.response.code.desc".  The "HTTP status code as string" is populated through a "value_string" which is a structure that translates integers to strings.  Typically value_strings are part of the definition of an integer field, so that "both" can be displayed for the field (typically string first).

 

One question is if its possible to filter on the string of a field that is defined as a "integer", but has a value_string associated with it.  I thought I remember some special cases (like tcp.port), but it may be that in general, you can't do it.  That's one reason why there is the additional "HTTP status code as string" field.

 

Now I presume you can pick the fields outputted for JSON, and it may be that you're just not including the "http.response.code.desc" field in your list.  "http.response.code.desc" is also considered a "generated" field by the dissector and I'm not sure if JSON would specifically filter those out, but if it is, that's a bug.

 

In writing this up, I thought it may make sense to just have the "http.response.code" field have the value_string used by "http.response.code.desc", but I'm guessing it's intentionally separate because users want to make columns out of the "http.response.code" field and it would need to be "extra wide" to accommodate the long strings of the "meaning" (which is probably undesirable to many).

 

So Conall, I think the "resolution" to your problem is just to include the "http.response.code.desc" field in your JSON output.  If it then doesn't become part of the output, file a bug (https://bugs.wireshark.org) and we can take a look at it.

 

 

 

-----Original Message-----
From: Jaap Keuter <jaap.keuter@xxxxxxxxx>
To: Developer support list for Wireshark <wireshark-dev@xxxxxxxxxxxxx>
Sent: Sat, Sep 9, 2017 6:25 am
Subject: Re: [Wireshark-dev] Enrich tshark data

Hi Conall,

You’re quite in the right place here to put forward these questions. I’ll have a go and try to answer them.

What you spotted is the HTTP dissector adding the HTTP status field to the protocol tree (https://code.wireshark.org/review/gitweb?p=wireshark.git;a=blob;f=epan/dissectors/packet-http.c;hb=HEAD#l1778)

Now we’ve to look a bit at Wireshark’s design. In its core there’s EPAN, the dissection engine. This is where the HTTP dissector lives.

The output of the dissection engine is used in various ways. In Wireshark it’s used to fill the GUI, in tshark it’s used to generate the text output. 

What format this tshark text output has is determined by the command line parameters. Then it’s up to the output routines to include the data in the selected format.

Now, the question remains how is the HTTP response code description processed by the JSON output routines. 

On 8 Sep 2017, at 15:21, Conall Prendergast <conall.prendergast@xxxxxxxx> wrote:

Hi All,

Wireshark has the ability to enrich some of the numeric values it sees. For example, if is sees a http status code of 200, it might print "OK" beside it, because HTTP 200 means OK (This is just a guess, Im not sure what it does for HTTP status codes).

Is it possible to add this kind of enrichment to tshark's json output? 

Regards,

Conall

___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx> Archives: https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe