[Wireshark-dev] adding a Group filter option to the expert info dialog

[John Dill]

I have been implementing some extra categories in the severity and group level 
to help categorize events that happen in packet captures in my local wireshark 
source tree.


For example, I've added PI_UNEXPECTED, PI_DEGRADED, PI_FAIL, and PI_FATAL, and 
added PI_INTEGRITY and PI_OPERATION to the groups specific for my protocol 
domain.


I've been able to update the existing code for filtering the added severity 
levels, but I also want to add capability to filter on group from the Analyze 
-> Expert Info dialog box.  How difficult would that be?


Not expecting a detailed analysis, just want to know at a high level what I'd 
be getting into.  I'm not experienced in Qt development.


Thanks,

John D.

___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Wireshark-dev Digest, Vol 208, Issue 2

[John Dill]

>Message: 2
>Date: Tue, 12 Sep 2023 10:24:19 -0400
>From: John Thacker 
>To: Developer support list for Wireshark 
>Subject: Re: [Wireshark-dev] question on validation of a dissected
>string from a BASE_CUSTOM hf item
>Message-ID:
>
>Content-Type: text/plain; charset="utf-8"
>
>You may have noticed "proto_tree_add_item_ret_display_string()" and perhaps
>found that it doesn't do what you want; it produces the display string for
>a default display representation and doesn't use your custom function.
>(Perhaps it should?)


Hi John,


I did notice that proto_item_add_item_ret_display_string and friends, but the 
intent doesn't appear to be what I'm envisioning, since the list of FT types 
doesn't include any of the FT integer types, e.g. from proto.c (I'm still 3.6)


REPORT_DISSECTOR_BUG("field %s is not of type FT_STRING, FT_STRINGZ, 
FT_UINT_STRING, FT_STRINGZPAD, FT_STRINGZTRUNC, FT_BYTES, or FT_UINT_BYTES",


I parse 1553 data over ethernet and often times the encodings for certain data 
items can be... creative.  I would certainly prefer to mod a way in Wireshark 
to use the custom function once for the display and return the dissected 
display string as part of adding the item to the proto_tree for expert_info 
validation (an example expert_info is when something demarcated as spare in the 
expected data is non-zero, indicating some kind of data definition drift to 
equipment over time).


My use case is kind of an amalgam of 
proto_tree_add_item_ret_display_string_and_length, but the header field 
represents a 16-bit up to 64-bit integer that is set to BASE_CUSTOM with a 
function that returns the resulting dissected string from the custom function 
pointer.  Putting some equivalent into Wireshark proto.h/c pushes more custom 
code out of an already large plugin (160 kloc at this point in time, and I'm 
not anywhere near done).


This is kind of a side endeavor, so I'm not in a rush on this.  Thanks for your 
code sample.  I think I got my answer as far as I'm not missing an obvious 
method to accomplish this.


Thanks,

John D.



From: Wireshark-dev  on behalf of 
wireshark-dev-requ...@wireshark.org 
Sent: Tuesday, September 12, 2023 10:24:37 AM
To: wireshark-dev@wireshark.org
Subject: Wireshark-dev Digest, Vol 208, Issue 2

Send Wireshark-dev mailing list submissions to
wireshark-dev@wireshark.org

To subscribe or unsubscribe via the World Wide Web, visit
https://www.wireshark.org/mailman/listinfo/wireshark-dev
or, via email, send a message with subject or body 'help' to
wireshark-dev-requ...@wireshark.org

You can reach the person managing the list at
wireshark-dev-ow...@wireshark.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Wireshark-dev digest..."


Today's Topics:

   1. Re: question on validation of a dissected string from a
  BASE_CUSTOM hf item (John Thacker)
   2. Re: question on validation of a dissected string from a
  BASE_CUSTOM hf item (John Thacker)


--

Message: 1
Date: Tue, 12 Sep 2023 10:05:44 -0400
From: John Thacker 
To: Developer support list for Wireshark 
Subject: Re: [Wireshark-dev] question on validation of a dissected
string from a BASE_CUSTOM hf item
Message-ID:

Content-Type: text/plain; charset="utf-8"

In general you don't want to do that, if your goal is to create an expert
info. The string would not exist and thus the Expert Info would not show in
the "Analyze -> Expert Information" dialog, or in other situations where
the tree was not visible and the item was faked; you might have to
specifically filter for the item. (See
https://gitlab.com/wireshark/wireshark/-/issues/18955 for a similar
situation. Also somewhat relatedly
https://gitlab.com/wireshark/wireshark/-/issues/19216 ) For optimization
purposes, strings and display labels are not filled in unless necessary.

What you could do is allocate your own string buffer, and pass it and the
uint64_t to your Receive_Frequency function. You can simplify that by
replacing your proto_tree_add_item() call with:

uint64_t value;
char[ITEM_LABEL_LENGTH] label;
ti = proto_tree_add_item_ret_uint64(tree, hf_, tvb, start, length,
encoding, );
Receive_Frequency(label, value);
if () {
  expert_add_info(pinfo, ti, _);
}

However, since it's processor intensive and error prone to convert to a
string only to parse the string back to floating point, you'd probably be
better off retrieving the uint64_t value and passing it to a function that
converts it directly to the floating point you need, separate from your
custom display function.

Cheers,
John Thacker


On Thu, Sep 7, 2023 at 12:15 PM John Dill 
wrote:

> I have a question whether I can get the dissected string of the
> BASE_CUSTOM header field s

[Wireshark-dev] question on validation of a dissected string from a BASE_CUSTOM hf item

[John Dill]

I have a question whether I can get the dissected string of the BASE_CUSTOM 
header field so that I can do analysis on it and convert it to floating point 
to do range analysis so I can issue an expert info if the value is valid but 
out of range.


{
  _Receive_Frequency,
  {
"Receive Frequency",
"Receive_Frequency",
FT_UINT48,
BASE_CUSTOM,
CF_FUNC(Receive_Frequency),
0x0,
NULL,
HFILL
  }
},

...

ti = proto_tree_add_item(word_tree, hf_XTS_5000_APX_8000_Receive_Frequency, 
tvb, offset, 6, ENC_BIG_ENDIAN);

...

static void Receive_Frequency(gchar *result, guint64 value)
{
  guint16 w_Base_Frequency;
  guint16 w_1_MHz_BCD;
  guint16 w_100_KHz_BCD;
  guint16 w_10_KHz_BCD;
  guint16 w_Rx_KHz_Frequency_Field;

  guint32 MHz_Frequency;
  guint32 KHz_Frequency;

... processing ...

  switch (lut_Base_Frequency[w_Base_Frequency])
  {
case -1:
  g_snprintf(result, ITEM_LABEL_LENGTH, "Illegal");
  break;

case 0:
  g_snprintf(result, ITEM_LABEL_LENGTH, "Invalid");
  break;

default:
  /* Frequency is typically displayed in MHz with 4 significant digits */
  g_snprintf(result, ITEM_LABEL_LENGTH, "%" G_GUINT32_FORMAT ".%" 
G_GUINT32_FORMAT " MHz", MHz_Frequency, KHz_Frequency / 100);
  break;
  }
}

Is there a way for me to peel the dissected result string from "ti" after the 
proto_tree_add_item call so that I can do validation and range checking for 
expert info?

Can I try to hijack proto_item_fill_display_label to somehow push "tmp" out of 
the interface into a proto_tree_add_*_ret_processed_string?

\code
if (FIELD_DISPLAY(hfinfo->display) == BASE_CUSTOM) {
gchar tmp[ITEM_LABEL_LENGTH];
custom_fmt_func_t fmtfunc = (custom_fmt_func_t)hfinfo->strings;

DISSECTOR_ASSERT(fmtfunc);
fmtfunc(tmp, number);

label_len = protoo_strlcpy(display_label_str, tmp, label_str_size);
\endcode

This 'tmp' from fmtfunc is the string I want to grab for post-analysis, but it 
seems non-obvious how to get at it.

I might be completely overlooking an easy way to do this.

Any suggestions?  I already maintain a fork, so having a custom mod to pull 
this out is on the table for me.

Thanks,
John D.

___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Wireshark-dev Digest, Vol 207, Issue 3

[John Dill]

th = (int) (p - label_str);

/* Fill in the textual info using stored (shifted) value */
if (hfinfo->display == BASE_CUSTOM) {
gchar tmp[ITEM_LABEL_LENGTH];
const custom_fmt_func_64_t fmtfunc64 = (const 
custom_fmt_func_64_t)hfinfo->strings;

DISSECTOR_ASSERT(fmtfunc64);
fmtfunc64(tmp, value);
label_fill(label_str, bitfield_byte_length, hfinfo, tmp);
}
else if (hfinfo->strings) {
hf_try_val64_to_str_idx(value, hfinfo, );
const char* val_str =
hf_try_val64_to_str_const(
(hfinfo->display & BASE_DEFAULT_VALS && idx == -1) ? -1 : value, hfinfo, 
"Unknown");

out = hfinfo_number_vals_format64(hfinfo, buf, value);
if (out == NULL) /* BASE_NONE so don't put integer in descr */
label_fill(label_str, bitfield_byte_length, hfinfo, val_str);
else
label_fill_descr(label_str, bitfield_byte_length, hfinfo, val_str, out);
}
else {
out = hfinfo_number_value_format64(hfinfo, buf, value);

label_fill(label_str, bitfield_byte_length, hfinfo, out);
}
}

That should get someone in the ballpark if there's interest in pursuing this 
feature further.  I'm sure there's more stuff that could be tweaked, but this 
works for me at the moment.

Thanks,
John D.


>Message: 1
>Date: Mon, 14 Aug 2023 15:22:01 +
>From: John Dill 
>To: "wireshark-dev@wireshark.org" 
>Subject: [Wireshark-dev] add a BASE_DEFAULT_VALS
>Message-ID: <7842e9e621b04ca6a8749b5286f2d...@greenfieldeng.com>
>Content-Type: text/plain; charset="iso-8859-1"
>
>I've recently been doing a lot of enums that have multiple illegal values, and

>the illegal value shouldn't be displayed as "Unknown" as it's hard coded in

>proto.c (in 3.6.x).
>
>Any chance you could go for an attribute to signal that -1 can be used as the

>name of the fall-through text if defined?
>
>Looks like it would be mostly proto that gets updated.
>
>#define BASE_DEFAULT_VALS 0x0004  /**< field will use -1 value 
>instead

>of "Unknown" if value_string match is not found */
>
>static const value_string Port_Test_Control_enum_vals[] =
>{
>  { -1, "Disable Manual Port Test Control" },
>  { 0x5A, "Enable Manual Port Test Control" },
>  { 0, NULL }
>};
>
>Here's a hf definition
>

>{
>  _Port_Test_Control_Enable,
>  {
>"Port Test Control Enable",
>"mil_1553.Port_Test_Control_Enable",
>FT_UINT16,
>BASE_HEX | BASE_DEFAULT_VALS,
>VALS(Port_Test_Control_Enable_enum_vals),
>0x00FF,
>"This byte is always set to 0x00 when not in debug mode.  Only special 
> debug functions may set this byte to 0x5A.",
>HFILL
>  }
>},
>

>Most of the time, my enum fields don't use -1 as a valid value, so UINT32(-1)

>should be pretty feasible.
>
>There are _idx functions in value_string, so may be able to rig something 
>there.

>  I have made my own version of it but I'm sure someone more experienced can

>do it the "right" way in the code base.
>
>Just an idea.  I'm still on 3.6 so I haven't checked if a similar feature is 
>in 4.0.
>
>Thanks,
>John D.



From: Wireshark-dev  on behalf of 
wireshark-dev-requ...@wireshark.org 
Sent: Tuesday, August 15, 2023 8:00:01 AM
To: wireshark-dev@wireshark.org
Subject: Wireshark-dev Digest, Vol 207, Issue 3

Send Wireshark-dev mailing list submissions to
    wireshark-dev@wireshark.org

To subscribe or unsubscribe via the World Wide Web, visit
https://www.wireshark.org/mailman/listinfo/wireshark-dev
or, via email, send a message with subject or body 'help' to
wireshark-dev-requ...@wireshark.org

You can reach the person managing the list at
wireshark-dev-ow...@wireshark.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Wireshark-dev digest..."


Today's Topics:

   1. add a BASE_DEFAULT_VALS (John Dill)


--

Message: 1
Date: Mon, 14 Aug 2023 15:22:01 +
From: John Dill 
To: "wireshark-dev@wireshark.org" 
Subject: [Wireshark-dev] add a BASE_DEFAULT_VALS
Message-ID: <7842e9e621b04ca6a8749b5286f2d...@greenfieldeng.com>
Content-Type: text/plain; charset="iso-8859-1"

I've recently been doing a lot of enums that have multiple illegal values, and 
the illegal value shouldn't be displayed as "Unknown" as it's hard coded in 
proto.c (in 3.6.x).


Any chance you could go for an attribute to signal that -1 can be used as the 
name of the fall-through text if defined?


Looks like it would be mostly proto that gets updated.


#define BASE_DEFAULT_VALS 0x0004  /**< field will use -1 value 
instead of "Unknown" if value_string match is not f

[Wireshark-dev] add a BASE_DEFAULT_VALS

[John Dill]

I've recently been doing a lot of enums that have multiple illegal values, and 
the illegal value shouldn't be displayed as "Unknown" as it's hard coded in 
proto.c (in 3.6.x).


Any chance you could go for an attribute to signal that -1 can be used as the 
name of the fall-through text if defined?


Looks like it would be mostly proto that gets updated.


#define BASE_DEFAULT_VALS 0x0004  /**< field will use -1 value 
instead of "Unknown" if value_string match is not found */

static const value_string Port_Test_Control_enum_vals[] =
{
  { -1, "Disable Manual Port Test Control" },
  { 0x5A, "Enable Manual Port Test Control" },
  { 0, NULL }
};


Here's a hf definition


{
  _Port_Test_Control_Enable,
  {
"Port Test Control Enable",
"mil_1553.Port_Test_Control_Enable",
FT_UINT16,
BASE_HEX | BASE_DEFAULT_VALS,
VALS(Port_Test_Control_Enable_enum_vals),
0x00FF,
"This byte is always set to 0x00 when not in debug mode.  Only special 
debug functions may set this byte to 0x5A.",
HFILL
  }
},

Most of the time, my enum fields don't use -1 as a valid value, so UINT32(-1) 
should be pretty feasible.


There are _idx functions in value_string, so may be able to rig something 
there.  I have made my own version of it but I'm sure someone more experienced 
can do it the "right" way in the code base.


Just an idea.  I'm still on 3.6 so I haven't checked if a similar feature is in 
4.0.


Thanks,

John D.

___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] wireshark capture/filtering question

[John Dill]

>Message: 1
>Date: Fri, 20 Nov 2020 17:43:33 -0800
>From: Guy Harris 
>To: Developer support list for Wireshark 
>Subject: Re: [Wireshark-dev] wireshark capture/filtering question
>Message-ID: <31e12e1e-224b-4223-af81-659e1b6bf...@sonic.net>
>Content-Type: text/plain;   charset=us-ascii
>
>On Nov 20, 2020, at 11:02 AM, John Dill  wrote:
>
>> Not exactly.  What I'm looking to do is to merge our existing 1553 capture
>> C code and wireshark capture code (inspired from tshark or dumpcap) into
>> the same application.
>>
>> The 1553 data part would get passed records as is over a TCP socket to a
>> dashboard application for display (not injected into Wireshark).  This
>> application interfaces with a PCMCIA card and the 1553 data is stored
>> in a queue of fixed length records.  Those records are then read and
>> streamed by a C program using TCP packets to a dashboard application
>> that reads them, decodes all the data fields and puts them on a GUI for
>> display.
>
>OK, so what programs are involved here?
>
>Is the PCMCIA card something that plugs into the (presumably) MIL-STD-1553
>serial bus and captures traffic from it?

First off, I appreciate the time spent in your response.  Sorry, I don't know
how far into the weeds to go with this, but I'll do my best.  Thanks for your
patience in advance.

The MIL-STD-1553 interface is an avionics 10 MHz serial data bus that has its 
own
message interface.  All the equipment is connected via BNC connectors to bus
terminals.  There is a central application called the Bus Controller that 
schedules
messages between various avionics devices.  The serial bus is shared between
all avionics, so each message is seen by all the devices, but unless the message
remote terminal (RT) address matches the avionics device, the message is 
ignored.

The PCMCIA card is able to read the 10 MHz waveform and save these messages
into the local vendor's "frame" format.  Most vendors provide a standard bus
monitor program that reads the message data from the PCMCIA card, but they
don't have a mechanism to translate the data into engineering units for display.
They have an application library that takes care of the low level device driver 
issues
to read 1553 packets into their vendor "frame" format.  They typically provide
several proof of concept tasks that you can perform with their 1553 card using
their API, but nothing complex enough to be really useful.

>If so, is that what your existing 1553 capture C code reads from?

The 1553 capture C code reads from a Excalibur Systems EXC-1553 PCMCIA/EP
card.  It is a custom written application that reads 1553 messages in the vendor
"frame" format using the vendor provided 1553 library, and has the capability
to write the messages to disk, or to send the 1553 messages as packets over TCP
to a Java based dashboard application for display.

So far, all of this code is written in house (and was not written by me either).

>What program sends those records on a TCP socket?  Is that the existing C code?

The existing in house capture application sends 1553 messages over a custom
protocol using the TCP as the connection layer.  It doesn't send TCP data until 
a
client application establishes a connection.  After the dashboard initiates
a socket connection, there is a simple control protocol to the 1553 capture
application to start and stop sending 1553 traffic to the dashboard application.

>What program reads from the TCP socket?  The dashboard application?

The dashboard (Java) application reads 1553 packet frames sent from the capture
application (C).

>And are you describing the code that exists *now*, or the code you're talking
>about that, in some fashion, includes some Wireshark code?

There is no Wireshark code at this point, it's all completely in-house built 
software.
This is how the code functions now.  As an aside, the PCMCIA operates in a Bus
Monitor mode, which means it's not supposed to interact in any way with the
existing avionics devices on the 1553 bus.

>> This application is also capable of writing captured 1553 data
>> in fixed length records to a file.  The application can also load a 1553 data
>> capture file and streaming the records to the dashboard application to
>> simulate a playback of a flight at varying playback speeds.
>
>> The packet part of the data would be captured from a mirror port and
>> get filtered by the bpf capabilities to eliminate packets of non-interest,
>
>BPF doesn't know anything about MIL-STD-1553.  You could write BPF filter
>language expressions that test fields at particular offsets (or
>generate your own BPF machine code), but that would only require a small
>part of libpcap's capability - it wouldn't require any Wireshark code at all.
>
>Or do you mean using BPF to f

Re: [Wireshark-dev] wireshark capture/filtering question

[John Dill]

>From: Graham Bloice 
>To: Developer support list for Wireshark 
>Subject: Re: [Wireshark-dev] wireshark capture/filtering question
>Message-ID:
>
>Content-Type: text/plain; charset="utf-8"
>
>On Fri, 20 Nov 2020 at 14:49, John Dill  wrote:
>
>> I've had some recent discussions about adding some network capture to our
>> avionics data capture dashboard program.  Currently, the architecture uses
>> a Java program as the GUI and a TCP socket interface for playback/record
>> control and data with a C program capturing 1553 data.  The C program has
>> the capability of reading from a file or the live card and streaming 1553
>> packets to file and to the GUI for processing.
>>
>>
>>
>> What I would like to try to do is sniff out the packets for Control
>> Display Unit (CDU) key presses and the Display screen data (which includes
>> a 24x15 grid of characters and attribute data for each character).
>> The initial goal of this is to provide a real time virtual CDU display, and
>> if things go well, store the display and key presses packet data so that
>> during playback of a recording, one can see a virtual display of what
>> happened between what the pilots are doing vs the 1553 data.  All of this
>> display data is on a single port, and we currently have a plugin that
>> processes all the Network Data Objects for that port.
>>
>>
>>
>> The idea that was passed around would be to either integrate the packet
>> capture portion in with the existing 1553 data capture program, or
>> integrate the 1553 data capture in with a Wireshark command line tool.
>> Another factor they are considering is looking at chapter 10 to multiplex
>> the 1553 and ethernet data into a single file format, so that complicates
>> matters further (although that should make the time sync of 1553 and
>> display playback easier).
>>
>>
>>
>> I'm just wondering if anyone here has had experience using Wireshark
>> utilities as a capture interface for streaming filtered network packets to
>> another application, and maybe I can follow in their footsteps.
>>
>>
>> The problem appears to be pretty complex, so hopefully I explained what I
>> want to try to do.  As a first pass, I think my goal will be to see if I
>> can wrangle a simple dashboard application that takes a live filtered
>> stream of packets from dumpcap or tshark, and forward that data to a GUI
>> for display (basically part of the backend for a virtual CDU display).
>>
>>
>>
>> Any ideas would be greatly appreciated.  If there's some source files to
>> study, that would be helpful too.  I've only implemented a few packet
>> dissector plugins for various avionics protocols, not gone this deep into
>> the internals.
>>
>>
>>
>> Thanks,
>>
>> John D.
>>
>>
> Hi John,
>
>To clarify, you want to feed the 1553 stream into the wireshark engine,
>apply some engine filtering and then output some products of that to
>another application?

Not exactly.  What I'm looking to do is to merge our existing 1553 capture
C code and wireshark capture code (inspired from tshark or dumpcap) into
the same application.

The 1553 data part would get passed records as is over a TCP socket to a
dashboard application for display (not injected into Wireshark).  This
application interfaces with a PCMCIA card and the 1553 data is stored
in a queue of fixed length records.  Those records are then read and
streamed by a C program using TCP packets to a dashboard application
that reads them, decodes all the data fields and puts them on a GUI for
display.  This application is also capable of writing captured 1553 data
in fixed length records to a file.  The application can also load a 1553 data
capture file and streaming the records to the dashboard application to
simulate a playback of a flight at varying playback speeds.

The packet part of the data would be captured from a mirror port and
get filtered by the bpf capabilities to eliminate packets of non-interest, and
then get passed in some manner to the same dashboard application over TCP.
I have a NDO dissector that can heuristically detect those packets of interest,
like "ndo.id == CDU_DM_Display_Buffer" or "ndo.id == CDU_DM_Key", so I'd
like to use that capability to detect when these payloads of certain packets
are found.

This includes the TCP desegmentation capabilities as well, since the CDU
Display packet is segmented over 3 packets.  Once a complete packet with
the NDOs of interest is detected, the dashboard would get a copy over a
separate TCP stream.  The NDOs would be packaged into new frames and
sent via TCP to the dashboard application for 

[Wireshark-dev] wireshark capture/filtering question

[John Dill]

I've had some recent discussions about adding some network capture to our 
avionics data capture dashboard program.  Currently, the architecture uses a 
Java program as the GUI and a TCP socket interface for playback/record control 
and data with a C program capturing 1553 data.  The C program has the 
capability of reading from a file or the live card and streaming 1553 packets 
to file and to the GUI for processing.



What I would like to try to do is sniff out the packets for Control Display 
Unit (CDU) key presses and the Display screen data (which includes a 24x15 grid 
of characters and attribute data for each character).  The initial goal of this 
is to provide a real time virtual CDU display, and if things go well, store the 
display and key presses packet data so that during playback of a recording, one 
can see a virtual display of what happened between what the pilots are doing vs 
the 1553 data.  All of this display data is on a single port, and we currently 
have a plugin that processes all the Network Data Objects for that port.



The idea that was passed around would be to either integrate the packet capture 
portion in with the existing 1553 data capture program, or integrate the 1553 
data capture in with a Wireshark command line tool.  Another factor they are 
considering is looking at chapter 10 to multiplex the 1553 and ethernet data 
into a single file format, so that complicates matters further (although that 
should make the time sync of 1553 and display playback easier).



I'm just wondering if anyone here has had experience using Wireshark utilities 
as a capture interface for streaming filtered network packets to another 
application, and maybe I can follow in their footsteps.



The problem appears to be pretty complex, so hopefully I explained what I want 
to try to do.  As a first pass, I think my goal will be to see if I can wrangle 
a simple dashboard application that takes a live filtered stream of packets 
from dumpcap or tshark, and forward that data to a GUI for display (basically 
part of the backend for a virtual CDU display).



Any ideas would be greatly appreciated.  If there's some source files to study, 
that would be helpful too.  I've only implemented a few packet dissector 
plugins for various avionics protocols, not gone this deep into the internals.



Thanks,

John D.


___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Building Wireshark 3.4.0 documentation on Windows

[John Dill]

>Message: 2
>Date: Mon, 2 Nov 2020 16:04:21 +
>From: Graham Bloice 
>To: Developer support list for Wireshark 
>Subject: Re: [Wireshark-dev] Building Wireshark 3.4.0 documentation on
>Windows
>Message-ID:
>
>Content-Type: text/plain; charset="utf-8"
>
>On Mon, 2 Nov 2020 at 15:06, Maynard, Chris via Wireshark-dev <
>wireshark-dev@wireshark.org> wrote:
>
> > > -Original Message-
> > > From: Wireshark-dev  On Behalf Of
> > > Gerald Combs
> > > Sent: Sunday, November 1, 2020 8:36 PM
> > > To: Developer support list for Wireshark ;
> > > Graham Bloice 
> > > Subject: Re: [Wireshark-dev] Building Wireshark 3.4.0 documentation on
> > > Windows
> > >
> > > On 11/1/20 2:29 PM, Graham Bloice wrote:
> > > >
> > > > On Sat, 31 Oct 2020 at 18:42, Maynard, Chris via Wireshark-dev
> >  > > d...@wireshark.org > wrote:
> > > >
> > > > Section 2.2.8 of the Wireshark Developer’s Guide[1] instructs you
> > to install
> > > asciidoctor, xsltproc and docbook if you want to build the Wireshark
> > > documentation; however, it doesn’t specify the minimum version
> > requirements
> > > of those tools.
> > > >
> > > > Attempting to build the documentation for the new 3.4.0 release
> > failed on
> > > my system.  Running "choco list --localonly" showed that I had these
> > relevant
> > > package versions installed:
> > > >
> > > > asciidoctorj 2.1.0
> > > > docbook-bundle 1.0.0
> > > > xsltproc 1.1.28.0
> > > >
> > > > … and running "choco outdated" revealed that asciidoctor was
> > outdated:
> > > >
> > > > Chocolatey v0.10.15
> > > > Outdated Packages
> > > > Output is package name | current version | available version |
> > pinned?
> > > >
> > > > asciidoctorj|2.1.0|2.3.0|false
> > > >
> > > > I updated the asciidoctor package to version 2.3.0 and was able to
> > > successfully build the documentation.  (NOTE: I actually ran "choco
> > upgrade all"
> > > to upgrade all packages.)  In any case, if building the documentation
> > fails for
> > > you, you may want to check your installed versions and upgrade to the
> > latest
> > > available packages if any are outdated.
> > > >
> > > > And perhaps the Developer’s Guide should mention minimum required
> > > versions, if possible?
> > > >
> > > >
> > > > I'm not sure about doing this, it's a never ending chase.
> > > >
> > > > I do agree that the CMake generation step could check minimum
> > > requirements.
> > >
> > > It does:
> > >
> > > find_package( Asciidoctor 1.5 )
> > >
> > > 1.5.0 (released in 2014) and later support the "modern" syntax described
> > at
> > > https://asciidoctor.org/docs/migration/), which is what we currently
> > use in our
> > > documentation. I can successfully build the user_guides,
> > developer_guides, and
> > > release_notes targets here on an Ubuntu system with AsciiDoctor 1.5.5
> > > installed. Chris, do you remember what error(s) you ran into with
> > AsciiDoctorJ
> > > 2.1.0?
> >
> > Unfortunately, I don't have the exact error, but IIRC, it was some
> > non-intuitive, rather generic "Error 1" output or something.
> >
> > So perhaps it wasn't the asciidoctor upgrade that resolved the problem.
> > As I mentioned, some other packages were upgraded as well.
> >
> > Here's the list of packages and versions installed before the upgrade:
> > choco list --localonly
> > Chocolatey v0.10.15
> > apache-fop 2.2
> > asciidoctorj 2.1.0
> > autohotkey.portable 1.1.32.00
> > chocolatey 0.10.15
> > chocolatey-core.extension 1.3.5.1
> > docbook-bundle 1.0.0
> > easy.install 0.6.11.4
> > html-help-workshop 1.32
> > jre8 8.0.231
> > pip 1.2.0
> > python 3.7.5
> > python3 3.7.5
> > speex 1.0.4
> > strawberryperl 5.30.1.1
> > windbg 10.0.10586.15
> > winflexbison 2.4.9.20170215
> > xsltproc 1.1.28.0
> > 17 packages installed.
> >
> > And here are those that were determined to be outdated:
> > choco outdated
> > Chocolatey v0.10.15
> > Outdated Packages
> >  Output is package name | current version | available version | pinned?
> >
> > apache-fop|2.2|2.4|false
> > asciidoctorj|2.1.0|2.3.0|false
> > autohotkey.portable|1.1.32.00|1.1.33.02|false
> > easy.install|0.6.11.4|0.6.11.4|false
> > jre8|8.0.231|8.0.271|false
> > python|3.7.5|3.9.0|false
> > python3|3.7.5|3.9.0|false
> > strawberryperl|5.30.1.1|5.32.0.1|false
> >
> > Chocolatey has determined 7 package(s) are outdated.
> >  1 package(s) had warnings.
> > Warnings:
> >  - easy.install
> >
> > And here's the list of packages and versions after the upgrade (Note:
> > strawberryperl failed to update):
> > choco list --localonly
> > Chocolatey v0.10.15
> > apache-fop 2.4
> > asciidoctorj 2.3.0
> > autohotkey.portable 1.1.33.02
> > chocolatey-core.extension 1.3.5.1
> > chocolatey-windowsupdate.extension 1.0.2
> > docbook-bundle 1.0.0
> > easy.install 0.6.11.4
> > html-help-workshop 1.32
> > jre8 8.0.271
> > KB2919355 1.0.20160915
> > KB2919442 1.0.20160915
> > KB2999226 1.0.20181019
> > KB3033929 1.0.3
> > 

[Wireshark-dev] Wireshark 3.0 msbuild nsis_package_prep error

[John Dill]

I've been unable to build the NSIS package for Wireshark 3.0 and one of the 
issues that I've traced it down to the following:

3>CUSTOMBUILD : warning : failed to load external entity "custom_layer_chm.xsl" 
[C:\Users\dillja\Desktop\wsbuild64\docbook\user_guide_chm.vcxproj]
    cannot parse custom_layer_chm.xsl

So I open the file and it has a remote link to import the main stylesheet:

---

http://docbook.sourceforge.net/release/xsl/current/htmlhelp/htmlhelp.xsl"/>
---

When I try to navigate to this page from my web browser, I get a blank page.  
If I go to the web address

http://docbook.sourceforge.net/release/xsl/current/htmlhelp/

and click on the link to htmlhelp.xsl, I get a blank page.

If I right click on the file and save as, I can remotely save the file on my 
desktop and the contents are there.

It appears as if the security policy for my network or browser is blocking all 
remote content that has an .xsl extension.

I could go the tedious route and create a local copy of the necessary files, 
since several include others.  Hoping someone has a better idea.

Thanks,
John D.
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Windows Platform FIPS error?

[John Dill]

Saw an article about changing SHA256Managed to SHA256Cng and now the powershell 
script seems to get past that error.

win-setup.ps1 - line 212: $sha256 = New-Object Security.Cryptography.SHA256Cng

Not sure how it'll eventually work, since I've run into another issue, but that 
seems to get me past the previous error about FIPS.

Thanks,
John D.

From: John Dill
Sent: Tuesday, March 5, 2019 12:40 PM
To: Developer support list for Wireshark
Subject: Windows Platform FIPS error?

Trying to build 3.0 on Windows 10, x64 for first time.  Ran into this error.  
Not sure what the proper fix is, has anyone run into this yet?  Could be 
something driven by an IA issue since I'm not the master of my machine.  
Thanks, John D.

---
C:\Users\dillja\Desktop\wsbuild64>cmake -G "Visual Studio 15 2017 Win64" 
..\wireshark-3.0-test
-- Selecting Windows SDK version 10.0.17763.0 to target Windows 10.0.17134.
-- Generating build using CMake 3.13.3
-- Building for win64 using Visual Studio 15 2017 Win64
Working in C:\Wireshark-win64-libs-3.0
Tag 2019-01-23 not found. Refreshing.
Found 7-zip at C:\Program Files\7-Zip\7z.exe
New-Object : Exception calling ".ctor" with "0" argument(s): "This 
implementation is not part of the Windows Platform
FIPS validated cryptographic algorithms."
At C:\Users\dillja\Desktop\wireshark-3.0-test\tools\win-setup.ps1:212 char:19
+ $sha256 = New-Object Security.Cryptography.SHA256Managed
+   ~~
+ CategoryInfo  : InvalidOperation: (:) [New-Object], 
MethodInvocationException
+ FullyQualifiedErrorId : 
ConstructorInvokedThrowException,Microsoft.PowerShell.Commands.NewObjectCommand

CMake Error at CMakeLists.txt:110 (message):
  Windows setup (win-setup.ps1) failed.


-- Configuring incomplete, errors occurred!
See also "C:/Users/dillja/Desktop/wsbuild64/CMakeFiles/CMakeOutput.log".
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

[Wireshark-dev] Windows Platform FIPS error?

[John Dill]

Trying to build 3.0 on Windows 10, x64 for first time.  Ran into this error.  
Not sure what the proper fix is, has anyone run into this yet?  Could be 
something driven by an IA issue since I'm not the master of my machine.  
Thanks, John D.

---
C:\Users\dillja\Desktop\wsbuild64>cmake -G "Visual Studio 15 2017 Win64" 
..\wireshark-3.0-test
-- Selecting Windows SDK version 10.0.17763.0 to target Windows 10.0.17134.
-- Generating build using CMake 3.13.3
-- Building for win64 using Visual Studio 15 2017 Win64
Working in C:\Wireshark-win64-libs-3.0
Tag 2019-01-23 not found. Refreshing.
Found 7-zip at C:\Program Files\7-Zip\7z.exe
New-Object : Exception calling ".ctor" with "0" argument(s): "This 
implementation is not part of the Windows Platform
FIPS validated cryptographic algorithms."
At C:\Users\dillja\Desktop\wireshark-3.0-test\tools\win-setup.ps1:212 char:19
+ $sha256 = New-Object Security.Cryptography.SHA256Managed
+   ~~
+ CategoryInfo  : InvalidOperation: (:) [New-Object], 
MethodInvocationException
+ FullyQualifiedErrorId : 
ConstructorInvokedThrowException,Microsoft.PowerShell.Commands.NewObjectCommand

CMake Error at CMakeLists.txt:110 (message):
  Windows setup (win-setup.ps1) failed.


-- Configuring incomplete, errors occurred!
See also "C:/Users/dillja/Desktop/wsbuild64/CMakeFiles/CMakeOutput.log".
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Attempted to build NSIS installer for 2.6.3

[John Dill]

Ack, should have typed 

@echo off
C:\cygwin64\bin\ruby.exe /bin/asciidoctor %*

for asciidoctor.bat
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Attempted to build NSIS installer for 2.6.3

[John Dill]

>From: Gerald Combs 
>Sent: Tuesday, October 2, 2018 3:39 PM
>To: John Dill; Developer support list for Wireshark
>Subject: Re: [Wireshark-dev] Attempted to build NSIS installer for 2.6.3
>
>What do `file /bin/asciidoctor` and `head -n1 /bin/asciidoctor` (assuming that 
>c:\cygwin64 is Cygwin's root path) print from a bash >prompt? If it's 
>something like
>
>/bin/asciidoctor: Ruby script, ASCII text executable

Yes

>and
>
>#!/usr/bin/ruby

and double Yes

>then that probably won't work from CMake since it's not a Windows executable 
>or a batch file. You can confirm this by trying to run 
>>`C:\cygwin64\bin\asciidoctor --version` from a non-Cygwin Command Prompt or a 
>Powershell prompt. You might be able to work >around this by placing an 
>asciidoctor.bat wrapper script somewhere in your path that contains something 
>like the following:
>
>
>echo off
>c:\cygwin64\bin\ruby /usr/bin/asciidoctor %*
>
>
>There are lots of things that work inside Cygwin but not from Windows such as 
>shebangs and symlinks, which is one of the reasons
>we've been migrating away from it.

I was able to run "C:\cygwin64\bin\ruby C:\cygwin64\bin\asciidoctor --version" 
from the cmd prompt and it seems to output the
proper text string.

I created an asciidoctor.bat in C:\cygwin64\bin like you suggested and put it 
in the list as a higher priority than asciidoctor

@echo off
ruby /bin/asciidoctor %*

FIND_PROGRAM(ASCIIDOCTOR_EXECUTABLE
NAMES
asciidoctorj
asciidoctor.bat
asciidoctor
PATHS
/bin
/usr/bin
/usr/local/bin
${CYGWIN_INSTALL_PATH}/bin
${CHOCOLATEY_BIN_PATH}
DOC "Path to Asciidoctor or AsciidoctorJ"
)

This allowed the initial cmake command to finish referencing asciidoctor.bat in 

The msbuild /m ... Wireshark.sln went fine, and now I'm at 
nsis_package_prep.vcxproj.

It makes it down to generate_user-guide.xml.vcxproj where it tries to run

"C:\Program Files\CMake\bin\cmake.exe" -E env TZ=UTC 
ASCIIDOCTORJ_OPTS="-Xmx800m" C:/cygwin64/bin/asciidoctor.bat --attribute 
build_dir=C:/Users/DillJA/Desktop/wsbuild64/docbook --require 
C:/Users/DillJA/Desktop/wireshark/docbook/asciidoctor-macros/commaize-block.rb 
--require 
C:/Users/DillJA/Desktop/wireshark/docbook/asciidoctor-macros/cveidlink-inline-macro.rb
 --require 
C:/Users/DillJA/Desktop/wireshark/docbook/asciidoctor-macros/wsbuglink-inline-macro.rb
 --require 
C:/Users/DillJA/Desktop/wireshark/docbook/asciidoctor-macros/wssalink-inline-macro.rb
 --backend docbook --out-file user-guide.xml 
C:/Users/DillJA/Desktop/wireshark/docbook/user-guide.asciidoc

and it has a problem with the include statements in user-guide.asciidoc

  asciidoctor : error : user-guide.asciidoc: line 4: include file not found: 
/cygdrive/c/Users/DillJA/Desktop/wsbuild64/docbook/C:/Users/DillJA/Desktop/wireshark/docbook/C:/Users/DillJA/Desktop/wireshark/docbook/attributes.asciidoc

The rest of the errors seem to correspond to each 'include::' statements in 
user-guide.asciidoc.

I'll have to pick this up tomorrow.  Thanks for the help, appreciate it.
John D.

___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Attempted to build NSIS installer for 2.6.3

[John Dill]

I've been able to whittle my issue down to a specific spot in the build 
process.  For those trying to follow, I'm trying to build
2.6.3 on Windows in Cygwin (since I don't have control of the build 
environment).  I've been able to install an asciidoctor
program on Cygwin64 when ruby and rubygems package is installed through 
setup-x86_64.exe using

gem install asciidoctor
cp ~/bin/asciidoctor /bin

Then, I see that FindAsciidoctor is only supporting Chocolatey.  I compare 
against FindYACC which does work with my
Cygwin64 installation to FindAsciidoctor.

I add the following statements to FindAsciidoctor

#
# - Find Asciidoctor
# Sets:
#  ASCIIDOCTOR_EXECUTABLE
#

+INCLUDE(FindCygwin)
INCLUDE(FindChocolatey)

FIND_PROGRAM(ASCIIDOCTOR_EXECUTABLE
NAMES
asciidoctorj
asciidoctor
PATHS
/bin
/usr/bin
/usr/local/bin
+  ${CYGWIN_INSTALL_PATH}/bin
${CHOCOLATEY_BIN_PATH}
DOC "Path to Asciidoctor or AsciidoctorJ"
)

if(ASCIIDOCTOR_EXECUTABLE)
# The AsciidctorJ wrapper script sets -Xmx256m. This isn't enough
# for the User's Guide.
set(_asciidoctorj_opts -Xmx800m $ENV{ASCIIDOCTORJ_OPTS})
execute_process( COMMAND ${ASCIIDOCTOR_EXECUTABLE} --version 
OUTPUT_VARIABLE _ad_full_version )
separate_arguments(_ad_full_version)
list(GET _ad_full_version 1 ASCIIDOCTOR_VERSION)

function(set_asciidoctor_target_properties _target)
...

At the 'list(GET _ad_full_version 1 ASCIIDOCTOR_VERSION)' command, I get a 
cmake error because the previous execute_process
command produces an _ad_full_version that's empty.  When I run 'asciidoctor 
--version' in my Cygwin prompt, I get

Asciidoctor 1.5.7.1 [https://asciidoctor.org]
Runtime Environment (ruby 2.3.6p384 (2017-12-14 revision 9808) [x86_64-cygwin])
(lc:UTF-8 fs:Windows-1252 in:UTF-8 ex:UTF-8)

If I put in a 'message( "ASCIIDOCTOR_EXECUTABLE " ${ASCIIDOCTOR_EXECUTABLE} )' 
I get something that looks like this

-- ZLIB libs: zlib
ASCIIDOCTOR_EXECUTABLE C:/cygwin64/bin/asciidoctor
CMake Error at cmake/modules/FindAsciidoctor.cmake:30 (list):
  list GET given empty list
Call Stack (most recent call first):
  docbook/CMakeLists.txt:15 (find_package)

I don't know exactly how execute_process is trying to run the asciidoctor 
program.

Any ideas why this execute_process CMake command isn't working?

Thanks,
John D.

____
From: John Dill
Sent: Tuesday, October 2, 2018 11:26 AM
To: Gerald Combs; Developer support list for Wireshark
Cc: graham.blo...@trihedral.com
Subject: Re: [Wireshark-dev] Attempted to build NSIS installer for 2.6.3

>From: Gerald Combs 
>Sent: Monday, October 1, 2018 3:30 PM
>To: Developer support list for Wireshark; John Dill
>Subject: Re: [Wireshark-dev] Attempted to build NSIS installer for 2.6.3
>
>On 10/1/18 10:57 AM, John Dill wrote:
>> I'm trying to build an installer for Wireshark 2.6.3 on Windows using NSIS 
>> and I'm getting the following when I run
>>
>> msbuild /m /p:Configuration=RelWithDebInfo nsis_package.vcxproj
>>
>> Here is the commands I used before hand:
>>
>> set CYGWIN=nodosfilewarning
>
>The Windows build doesn't rely on shell scripts (or Cygwin for that matter) so 
>this shouldn't be necessary.

As far as I understand it used to in the past, though it seems to have moved on 
from it.  I'm trying to update my local repo from
Wireshark 2.4.4 where my environment used to work fine to the current branch of 
2.6.3.

>> set WIRESHARK_LIB_DIR=C:\Wireshark-win64-libs-2.6
>> set PLATFORM=win64
>> set QT5_BASE_DIR=C:\Qt\Qt5.8.0\5.8\msvc2015_64
>>
>> cd wsbuild64
>>
>> cmake -G "Visual Studio 14 2015 Win64" ..\wireshark-src
>> msbuild /m /p:Configuration=RelWithDebInfo /p:Platform=x64 Wireshark.sln 
>> (... ok ...)
>>
>> msbuild /m /p:Configuration=RelWithDebInfo nsis_package_prep.vcxproj (... ok 
>> ...)
>> msbuild /m /p:Configuration=RelWithDebInfo nsis_package.vcxproj
>>
>> ...
>> Processing config: C:\Program Files (x86)\NSIS\nsisconf.nsh
>> File: "C:\Users\DillJA\Desktop\wsbuild64\docbook\user-guide.chm" -> 
>> no files found.
>
>By default the Windows packages require user-guide.chm, which is an HTMLHelp 
>file. The User's Guide itself is written in Asciidoctor >markup. Converting it 
>to .chm requires Asciidoctor, xsltproc + DocBook XSL, and HTMLHelp Compiler.
>
>> Usage: File [/nonfatal] [/a] ([/r] [/x filespec [...]] filespec [...]
>>   /oname=outfile one_file_only)
>> Error in script "wireshark.nsi" on line 1173 -- aborting creation 
>> process
>>
>> Then it errors out with Build FAILED.
>>
>> I noticed that I can finish the NSIS installer script if I comment out the 
>>

Re: [Wireshark-dev] Attempted to build NSIS installer for 2.6.3

[John Dill]

>From: Gerald Combs 
>Sent: Monday, October 1, 2018 3:30 PM
>To: Developer support list for Wireshark; John Dill
>Subject: Re: [Wireshark-dev] Attempted to build NSIS installer for 2.6.3
>
>On 10/1/18 10:57 AM, John Dill wrote:
>> I'm trying to build an installer for Wireshark 2.6.3 on Windows using NSIS 
>> and I'm getting the following when I run
>>
>> msbuild /m /p:Configuration=RelWithDebInfo nsis_package.vcxproj
>>
>> Here is the commands I used before hand:
>>
>> set CYGWIN=nodosfilewarning
>
>The Windows build doesn't rely on shell scripts (or Cygwin for that matter) so 
>this shouldn't be necessary.

As far as I understand it used to in the past, though it seems to have moved on 
from it.  I'm trying to update my local repo from
Wireshark 2.4.4 where my environment used to work fine to the current branch of 
2.6.3.

>> set WIRESHARK_LIB_DIR=C:\Wireshark-win64-libs-2.6
>> set PLATFORM=win64
>> set QT5_BASE_DIR=C:\Qt\Qt5.8.0\5.8\msvc2015_64
>>
>> cd wsbuild64
>>
>> cmake -G "Visual Studio 14 2015 Win64" ..\wireshark-src
>> msbuild /m /p:Configuration=RelWithDebInfo /p:Platform=x64 Wireshark.sln 
>> (... ok ...)
>>
>> msbuild /m /p:Configuration=RelWithDebInfo nsis_package_prep.vcxproj (... ok 
>> ...)
>> msbuild /m /p:Configuration=RelWithDebInfo nsis_package.vcxproj
>>
>> ...
>> Processing config: C:\Program Files (x86)\NSIS\nsisconf.nsh
>> File: "C:\Users\DillJA\Desktop\wsbuild64\docbook\user-guide.chm" -> 
>> no files found.
>
>By default the Windows packages require user-guide.chm, which is an HTMLHelp 
>file. The User's Guide itself is written in Asciidoctor >markup. Converting it 
>to .chm requires Asciidoctor, xsltproc + DocBook XSL, and HTMLHelp Compiler.
>
>> Usage: File [/nonfatal] [/a] ([/r] [/x filespec [...]] filespec [...]
>>   /oname=outfile one_file_only)
>> Error in script "wireshark.nsi" on line 1173 -- aborting creation 
>> process
>>
>> Then it errors out with Build FAILED.
>>
>> I noticed that I can finish the NSIS installer script if I comment out the 
>> USER_GUIDE_DIR section, but I'm trying to install
>>the right packages and can't seem to get this error to go away without 
>>modifying the wireshark.nsi script.
>>
>> I notice in the cmake that the build script can't find asciidoctor even 
>> though ruby is installed on Cygwin64, and if I do a
>>'gem list --local', I see 'asciidoctor (1.5.7.1)'.
>
>What does `asciidoctor --version` return? I'm not sure if `gem install` 
>results in something that you can run as a command on >Windows, e.g. via a 
>.bat wrapper or a command line shim. If it does, you need to make sure the 
>resulting command is in your PATH.

asciidoctor after setup_x86_64.exe for installing cygwin64 returns a '-bash: 
asciidoctor: command not found' cause there is no
package to install asciidoctor at least from the Cygwin setup-x86_64.exe 
program.

>> I tried to look for the packages asciidoctor in setup_x86_64.exe for Cygwin 
>> and couldn't find asciidoctorj, xsltproc, and
>>docbook-bundle.
>
>Those are all Chocolatey packages, not Cygwin. Asciidoctorj is a bundle 
>containing JRuby, Asciidoctor, and associated utilities. You >shouldn't need 
>it if you have a working plain-Ruby Asciidoctor. xsltproc is part of Cygwin's 
>libxslt package. The closest corresponding >DocBook Cygwin package is 
>docbook-xml45.

I know I selected docbook-xml45, but don't think I specifically picked up 
libxslt directly.  It may have been installed as a dependency.

The cmake script can find the following components

-- Could NOT find ASCIIDOCTOR (missing:  ASCIIDOCTOR_EXECUTABLE) 
-- Found XSLTPROC: C:/cygwin64/bin/xsltproc.exe  
-- Found HTMLHelp: C:/Program Files (x86)/HTML Help Workshop/hhc.exe  

>> Can someone familiar with the Windows build offer some hints?  Do I need to 
>> switch from Cygwin to Chocolatey (which I
>>haven't tried yet)?
>
>I'd recommend Chocolatey. We've largely moved away from requiring Cygwin for 
>Windows development and I'm not sure if anyone >has ever built the Asciidoctor 
>documentation using Cygwin.

I'd have to get Chocolately approved by govt IT and not sure if or how long 
that would take.  Wouldn't be a problem if this was
for personal use.

I can use 'gem install asciidoctor' to create an asciidoctor and 
asciidoctor-safe that is placed in a local /bin directory in the user's
/home in Cygwin and when I run that '~/bin/asciidoctor --version' I get

Asciidoctor 1.5.7.1 [https://asciidoctor.org]
Runtime Environment (ruby 2.3.6p384 (2017-12-14 revision 9808) [x86_64-cygwin])
(lc:UT

[Wireshark-dev] Attempted to build NSIS installer for 2.6.3

[John Dill]

I'm trying to build an installer for Wireshark 2.6.3 on Windows using NSIS and 
I'm getting the following when I run

msbuild /m /p:Configuration=RelWithDebInfo nsis_package.vcxproj

Here is the commands I used before hand:

set CYGWIN=nodosfilewarning
set WIRESHARK_LIB_DIR=C:\Wireshark-win64-libs-2.6
set PLATFORM=win64
set QT5_BASE_DIR=C:\Qt\Qt5.8.0\5.8\msvc2015_64

cd wsbuild64

cmake -G "Visual Studio 14 2015 Win64" ..\wireshark-src
msbuild /m /p:Configuration=RelWithDebInfo /p:Platform=x64 Wireshark.sln (... 
ok ...)

msbuild /m /p:Configuration=RelWithDebInfo nsis_package_prep.vcxproj (... ok 
...)
msbuild /m /p:Configuration=RelWithDebInfo nsis_package.vcxproj

...
    Processing config: C:\Program Files (x86)\NSIS\nsisconf.nsh
    File: "C:\Users\DillJA\Desktop\wsbuild64\docbook\user-guide.chm" -> no 
files found.
    Usage: File [/nonfatal] [/a] ([/r] [/x filespec [...]] filespec [...]
  /oname=outfile one_file_only)
    Error in script "wireshark.nsi" on line 1173 -- aborting creation 
process

Then it errors out with Build FAILED.

I noticed that I can finish the NSIS installer script if I comment out the 
USER_GUIDE_DIR section, but I'm trying to install the right packages and can't 
seem to get this error to go away without modifying the wireshark.nsi script.

I notice in the cmake that the build script can't find asciidoctor even though 
ruby is installed on Cygwin64, and if I do a 'gem list --local', I see 
'asciidoctor (1.5.7.1)'.

I tried to look for the packages asciidoctor in setup_x86_64.exe for Cygwin and 
couldn't find asciidoctorj, xsltproc, and docbook-bundle.

Can someone familiar with the Windows build offer some hints?  Do I need to 
switch from Cygwin to Chocolatey (which I haven't tried yet)?

Thanks,
John D.
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Duplicate dissectors (anonymous) and (anonymous) for protocol xxx

[John Dill]

>Date: Wed, 25 Oct 2017 16:56:30 -0400
>From: Michael Mann <m...@netscape.net>
>To: wireshark-dev@wireshark.org
>Subject: Re: [Wireshark-dev] Duplicate dissectors (anonymous) and
>(anonymous) for protocol xxx
>
>If you create separate dissector handles with a protocol, how is a user using 
>"Decode As" functionality supposed to know which >dissection function will be 
>picked?  That's why the check was added.
>You can have the same protocol ID between TCP and UDP, but you can't have the 
>same one twice in TCP.>
>
>To me there are 2 solutions
>1. Create "placeholder" protocols with proto_register_protocol().  The 
>"protocol lD" returned can be used to differentiate the
>different dissector function handles
>2. Create a "pino" (protocol in name only) with 
>proto_register_protocol_in_name_only.  This allows you to create "helper"
>protocols, with most of the "control" still with the "parent" protocol created 
>with proto_register_protocol.
>
>I believe #2 is the "preferred" solution.

Can you point me to a relatively simple dissector that implements a "pino"?  I 
read the README.dissector
section 2.9, but it wasn't enough description for me to grok it enough to know 
how to implement one.

>Date: Wed, 25 Oct 2017 14:29:14 -0700
>From: Guy Harris <g...@alum.mit.edu>
>To: Developer support list for Wireshark <wireshark-dev@wireshark.org>
>Subject: Re: [Wireshark-dev] Duplicate dissectors (anonymous) and
>(anonymous) for protocol xxx
>
>On Oct 25, 2017, at 1:44 PM, John Dill <john.d...@greenfieldeng.com> wrote:
>
>> I just happened to turn on console printing to troubleshoot a different 
>> problem and I'm getting
>>a couple of interesting messages when I change my protocol preferences.
>>
>> Duplicate dissectors (anonymous) and (anonymous) for protocol xxx in 
>> dissector table tcp.port
>
>...
>
>> I have a proto_reg_handoff_xxx that creates a couple of TCP port dissector 
>> handles using
>>'dissector_add_uint("tcp.port", MY_TCP_PORT, tcp_handle)',
>
>Why *two* handles?  You can register the handle tcp_handle twice with two 
>different TCP ports.
>
>If the format of the packets is the same for both ports, you *should* use the 
>same dissector
>handle; if *that* causes an error, that's a bug.
>
>If the format of the packets is *not* the same for both ports, then you should 
>use different
>dissector handles - with different dissector functions - *and* ensure that the 
>dissectors have
>different names (which means they have to *have* names, so use 
>"register_dissector()"
>rather than "create_dissector_handle()" to create the handles), so that, as 
>Michael Mann
>noted, the user can choose one or the other of them for "Decode As...".

I'm trying to get a handle on the dissector registration but I'm not really 
getting it.  I'm trying
to understand the usage of create_dissector_handle vs register_dissector, but I 
can't seem to
rearrange my dissector code in a way that gets rid of the error messages that 
are showing.
I've probably lost understanding somewhere on the way from porting 1.12 
dissector code to
2.4.x.

The README.dissector sections for register_dissector, create_dissector_handle, 
and the
heuristic stuff is a bit too sparse for me to grok how to use it (at least 
enough to get rid of
these messages):

Duplicate dissectors (anonymous) and (anonymous) for protocol NDO in dissector 
table tcp.port
Protocol Network Data Object Protocol is already registered in "udp" table

Wireshark still seems to dissect the messages fine, but I fear it's because I'm 
lucky it's working
out.  And I haven't been able to discern how it works by studying different 
packet-xxx.c in the
epan/dissectors folder.  There's so many different dissector implementations 
that I can't
quite nail down a dissector that matches what I'm doing in my implementation.

Here is a snippet of the code that I'm using, maybe the issue will be obvious 
to someone
on this list.

\code
/* Forward declare the Wireshark TCP packet dissector interface. */
static guint get_tcp_pdu_len(packet_info *pinfo, tvbuff_t *tvb, int offset, 
void *data);
static gint dissect_ndo_tcp(tvbuff_t *tvb, packet_info *pinfo, proto_tree 
*tree, void *data);
static gint dissect_ndo_tcp_pdu(tvbuff_t *tvb, packet_info *pinfo, proto_tree 
*tree, void *data);

/* Forward declare the Wireshark UDP packet dissector interface. */
static gboolean dissect_ndo_udp_heur(tvbuff_t *tvb, packet_info *pinfo, 
proto_tree *tree, void *data);

/* Forward declare the Wireshark protocol hand-off registration. */
void proto_register_ndo(void);
void proto_reg_handoff_ndo(void);

/* Forward declar

[Wireshark-dev] Duplicate dissectors (anonymous) and (anonymous) for protocol xxx

[John Dill]

I just happened to turn on console printing to troubleshoot a different problem 
and I'm getting a couple of interesting messages when I change my protocol 
preferences.



Duplicate dissectors (anonymous) and (anonymous) for protocol xxx in dissector 
table tcp.port

Protocol  is already registered in "udp" table.



I have a proto_reg_handoff_xxx that creates a couple of TCP port dissector 
handles using 'dissector_add_uint("tcp.port", MY_TCP_PORT, tcp_handle)', and a 
UDP heuristic dissector 'heur_dissector_add("udp", dissect_xxx_udp_heur, 
"", "xxx", proto_xxx, HEURISTIC_ENABLE)'.



My question is whether I'm doing something not recommended.  The protocol uses 
both TCP and UDP packets to send data, and I've lumped it under one "xxx" 
protocol.  For the most part, it hasn't been an issue operationally, but I'm 
wondering if there's a better way to do it so I don't have these messages.  I 
haven't looked at the console output in detail before, so I've missed this up 
till now.



Is there any advice about dissecting a protocol that appears on both TCP and 
UDP streams and using the same name, or what I'm doing specifically that's 
causing it?  The messages have the same format, but the packaging in the TCP vs 
the UDP streams is slightly different.



Best regards,

John D.


___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

[Wireshark-dev] Qt deploy problem when installing Wireshark

[John Dill]

I'm trying to run a Wireshark installer I build from Qt 5.8.0, 32-bit, for 
Wireshark 2.4.1 on a Windows 10 machine with Visual Studio 2015.  It runs fine 
when I execute run\RelWithDebInfo\Wireshark.exe on my local computer.  The 
installer needs to run on Vista 32-bit (lab computer) and the installer works 
fine, but afterwards the Wireshark application would not start due to missing 
DLLs.



First, I had to install the VS 2015 redistributable to fix the msvcp140.dll 
missing issue.  Now it has another problem that reads



The application failed to start because it could not find or load the Qt

platform plugin "windows"

in ""



Reinstalling the application may fix the problem.



The Vista computer doesn't have Qt installed on it.  I copied the Wireshark.exe 
from a wsbuild32 directory containing run\RelWithDebInfo\Wireshark.exe into a 
deploy32 folder and ran the x86 version of windeployqt.exe.



C:\Qt\Qt5.8.0_x86\5.8\msvc2015\bin\windeployqt.exe Wireshark.exe



It copied a lot of files into deploy32 but I'm not sure where these files are 
supposed to be deployed on the Vista machine.  Can someone let me know what to 
do from here, or if I'm off track?



Thanks,

John D.


___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Novice: Where do I place my own C dissector in Visual Studio 2015? Is it easy?

[John Dill]

>Message: 1
>Date: Wed, 20 Sep 2017 15:42:30 +
>From: christopher.lusa...@engilitycorp.com
>To: "wireshark-dev@wireshark.org" <wireshark-dev@wireshark.org>
>Subject: [Wireshark-dev] Novice: Where do I place my own C dissector
>in Visual Studio 2015? Is it easy?
>Message-ID:
><8ed2c429dae7624e8f5d89cfe58664db77dd9...@dag21.egl.engilitycorp.com>
>Content-Type: text/plain; charset="utf-8"
>
>By following the instructions in the Wireshark Developer's Guide Under Section 
>2.2. Win32/64: Step-by-Step Guide, I have been
>able to create and run Wireshark in Visual Studio 2015. I can load a capture 
>file.
>
>Question: If I want to create my own dissector dot c file where do I put the 
>dissector file? Is it as simple as putting my new file in
>a specific folder and rebuilding the solution? What are the steps to do this? 
>Do I have to create other files to accompany my dot
>c file.
>
>I have attached images showing what I see when I open Visual Studio 2015.

I couldn't see the images from the mailing list, but there's a couple options.  
The option I recommend to start with is to do your work in a plugins folder.

Copy one of the simple plugins folders like gryphon and rename the folder to 
your dissector name.  Go through each of the files and replace gryphon with the 
name of your dissector.  You should have a list of files like the following:

AUTHORS
CMakeLists.txt
COPYING
Makefile.am
moduleinfo.h
NEWS
packet-xxx.h
packet-xxx.c
plugin.c
plugin.rc.in
README

Then go through the Wireshark tree and change the following files.  I found 
this list by doing a recursive grep in the Wireshark source tree for gryphon 
and added lines for my plugins.  Just search for all instances of 'gryphon' and 
add corresponding lines to each of these files.

CMakeLists.txt
Makefile.am
configure.ac
epan/Makefile.am
packaging/nsis/wireshark.nsi (if you want to create a wireshark install package 
on Windows, I have good success with NSIS)
plugins/Makefile.am

Once you get your plugin working, you can copy your dissector to the 
epan/dissectors folder and submit a patch if you want your dissector to be 
integrated into the main Wireshark repo.  In my case, there's FOUO in the work 
that I've done, so I keep it as a plugin.

>Reference:
>Wireshark Developer's Guide Section 2.2 Win32/64: Step-by-Step 
>>Guide<https://www.wireshark.org/docs/wsdg_html_chunked/ChSetupWin32.html>
>
>Christopher Lusardi
>Engility Corporation
>43880 Commerce Avenue
>Hollywood, MD 20636
>301-373-9340 Ext.290

I'm actually work at Pax River, so it's nice to have a fellow sharker in the 
area.

Best regards,
John Dill
___
Sent via:Wireshark-dev mailing list <wireshark-dev@wireshark.org>
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] causes for losing COL_PROTOCOL or COL_INFO data

[John Dill]

>Message: 1
>Date: Mon, 18 Sep 2017 22:25:09 +0200
>From: Jaap Keuter 
>To: Developer support list for Wireshark 
>Subject: Re: [Wireshark-dev] causes for losing COL_PROTOCOL or
>   COL_INFO data
>Message-ID: <88d2443f-e363-4811-a5dc-c2bb18f2c...@xs4all.nl>
>Content-Type: text/plain; charset=utf-8
>
>Hi John,
>
>Rule of thumb: don’t use ‘if (tree)...’ constructs.
>They have little if any use, don’t really save processing time (all wireshark 
>functions are capable of handling tree==NULL),  and >cause more trouble than 
>it’s worth (as you’re in right now).
>
>Some of the finer details are that Wireshark runs the dissection engine, and 
>therefore your dissector, several times for various >purposes, once 
>sequentially, then at random.
>This is either with or without the tree parameter set. Dissectors must 
>function so that they dissect the buffer the same either with >or without tree 
>parameter.
>Data may be preserved of several stages, and that is why dissection needs to 
>be done in all situations.
>
>Hope it helps reworking your code.

Yep, I've gotten the issue worked out.  Thanks again to everyone for the help.

>Jaap

Best regards,
John D.
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] causes for losing COL_PROTOCOL or COL_INFO data

[John Dill]

>Message: 1
>Date: Sat, 16 Sep 2017 13:38:31 +0100
>From: Peter Wu <pe...@lekensteyn.nl>
>To: John Dill <john.d...@greenfieldeng.com>,
>"wireshark-dev@wireshark.org" <wireshark-dev@wireshark.org>
>Subject: Re: [Wireshark-dev] causes for losing COL_PROTOCOL or
>COL_INFO data
>Message-ID: <288553dc-6272-4581-a5e5-15b933be7...@lekensteyn.nl>
>Content-Type: text/plain; charset=utf-8
>
>Hi John,
>
>Are your col_* functions guarded/affected by a check like if(tree) or do they 
>depend on pinfo->fd.visited? Are the affected frames >triggering reassembly or 
>exceptions?

Part of it is.  I have a udp heuristic dissector that has a section that's kind 
of like this.  I have to be careful with actual content, so here is pseudo-code 
skeletal structure.

gboolean
dissect_protocol_udp_heur(tvbuff_t *tvb, packet_info *pinfo, proto_tree *tree, 
void *data)
{
  ...

  data_class = tvb_get_guint8(tvb, offset);

  if (data_class in list of recognized values)
  {
col_add_str(pinfo->cinfo, COL_INFO, val_to_str(data_class, 
data_class_enum_vals, "Unknown"); /*this always works*/
...

if (tree)
{
  if (data_class == XXX) {
dissect_xxx(tvb, pinfo, offset, tree);
  }
  if (data_class == YYY) {
...
  }
  ...
}
...
  }
}

And the COL_INFO that gets lost is in the dissect_xxx function, which has 
several col_append functions used.  It gets lost after using a filter 
expression and I never get it back after that.

I've noticed this 'if (tree)' issue in a couple of the searches I've done 
attributed to this problem, but I don't quite understand the impact it has on 
dissection and populating the COL_INFO and friends column.  Any explanation or 
pointer to how this interaction works would be greatly appreciated.

Best regards,
John Dill

P.S. Thanks to Michael for the follow up too.
___
Sent via:Wireshark-dev mailing list <wireshark-dev@wireshark.org>
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

[Wireshark-dev] causes for losing COL_PROTOCOL or COL_INFO data

[John Dill]

I'm setting the column fields and they appear to be set fine when I first open 
Wireshark, but when I apply a packet filter, I lose information from the fields 
even though it appears that I'm still calling the same col_* functions in the 
dissection.  Then when I remove the filter expression, and the COL_INFO I set 
is still missing.  Is there a usual cause for this behavior?  I can't seem to 
discover what's causing it.



Thanks,

John D.


___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Wireshark-dev Digest, Vol 136, Issue 14

[John Dill]

>Date: Mon, 11 Sep 2017 17:57:18 -0400
>From: Michael Mann <mman...@netscape.net>
>To: wireshark-dev@wireshark.org
>Subject: Re: [Wireshark-dev] unit_name_string for FT_STRING field
>    types?
>
>Are you suggesting "unit types" for "strings" or are you suggesting "unit 
>types" for "string values that should really be considered >integers or 
>floats"?

I suppose I'm suggesting allowing unit strings for FT_STRING when the content 
matches something like this "^[-+]?[0-9]*\.?[0-9]+$" or "^[-+]?[0-9]+".  
Granted, I'm likely the only one who has a use case that cares about such 
things.

>It certainly sounds like the latter and in which case I would suggest 
>converting them in your dissector.  Numeric fields that are >treated as 
>numbers have more flexibility with comparison and math operations.

Can you explain what you mean in more detail as it sounds good but I'm not sure 
how to go about this?  How do you dissect a number represented as an ASCII 
string in a packet's data but interpret it as a FT_INT32 or FT_FLOAT type, 
since those allow BASE_UNIT_STRING?  Even though the data is ASCII characters, 
it's still a number and it has units (defined in an outside document).  Do you 
create a tvbuff that contains a modified buffer containing actual integers or 
floating point numbers of the data and then pass that tvb to a 
proto_tree_add_item of the appropriate type?  I don't know how I'd maintain the 
link between the header field and the corresponding ASCII text in the packet 
details pane, but still interpret it as a kind of FT_INT or FT_FLOAT type?

I don't think there's interest in filters that allow real numeric comparisons 
against the strings, though that would be cool.  Right now it's display the 
ASCII string and units.  Lumping in a unit_name_string in the 'strings' would 
be cleaner from a maintenance perspective if I can put it in a FT_STRING types 
header_field_info object.  I could expose the unit_name_string_get functions in 
proto.h and convert the ASCII strings to local integer or double types as its 
dissected, but I'd still need to maintain a separate table of header fields -> 
unit_name_string objects in my dissector.

>To me there isn't an argument here to have support for "true" strings and the 
>proto_tree_add_string_format or >proto_tree_add_string_format_value seems more 
>appropriate.

I agree that in general for FT_STRING, one should use 
proto_tree_add_string_format and friends.  I just have a use case where there's 
just enough repetition that making the dissector "ugly" for several dozen 
fields when I can patch Wireshark to make it look cleaner (and more 
maintainable to others) is an argument I'm having with myself.

I'm not intending to push this as a feature to be integrated into the Wireshark 
main, just how to modify the source enough to see if I can make it work for 
this use case.  I already have a modified Wireshark repo for some minor 
extensions already (BASE_SUPPRESS_BITFIELD to turn off those bitfield displays 
for certain bitfields, and I have a "word" size equivalent of the 
bytestring_to_str and a tvb_bytes_to_str_punct for 1553 traffic over ethernet).

I'm just hunting and pecking for something that makes the dissector a bit 
easier to maintain.

Best regards,
John Dill
___
Sent via:Wireshark-dev mailing list <wireshark-dev@wireshark.org>
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

[Wireshark-dev] unit_name_string for FT_STRING field types?

[John Dill]

I have a dissector for a protocol sending packets containing ASCII strings of a 
delimited format over a TCP stream.



/AREA/NAME/FILLED/GREEN/1/2000/4000//



Sometimes the values are floating point, like



/ENV/-/-/1.0/90.0/100.0/-/-/-/5000.0//



I'm dissecting the format ok, but I can't use unit_name_string for these 
FT_STRING defined header fields.



I see (in 2.4.1) that unit_name_string is disabled for FT_STRING 
(?tmp_fld_check_assert is not allowing hfinfo->strings), so I've been using 
proto_tree_add_string_format..., but wondering if there's potential to allow 
FT_STRING to use unit_name_string.



One could classify the string contents as an integer or floating point value to 
pass to one of these functions:



unit_name_string_get_value

unit_name_string_get_value64

unit_name_string_get_double



If the string is not a valid number, or out of range, I'm not sure what the 
proper error behavior should be.  Could be to ignore the 'strings' value, throw 
an assert, or malformed packet.  It's possible that a value is missing '-' but 
I wouldn't want it to mark the packet as bogus because of it.



Mostly, it'd be easier putting the units in the header field definition instead 
of having a separate table of header field -> unit_name_string for these 
FT_STRING types and doing the checking/formatting myself.



Does this idea seem compatible with proto.c?



Thanks,

John Dill


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

[Wireshark-dev] learning VoIP with Wireshark

[John Dill]

Hi,



I've been assigned to be the guy to support this new VoIP system we're getting, 
and I know that Wireshark has some VoIP analysis features.  I have ok enough 
background in networking, but VoIP is completely new to me.



If there's anyone with background in VoIP has any pointers on good reference 
books on the subject to recommend, and where to look at any VoIP traffic 
captures, that would be wonderful.  Apologies if this should be on 
wireshark-users.  Traffic seemed a bit light in the archives, and I figured 
there's a chance that there's a VoIP expert who also does Wireshark 
development.  I believe we're getting Cisco stuff, but I'm not at management 
level, so I don't really know what's coming down the pike yet.



Thanks for any suggestions,

John Dill


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

Re: [Wireshark-dev] proto.h extension (unit strings)

[John Dill]

>Message: 1
>Date: Sun, 11 Dec 2016 22:17:11 -0500
>From: Michael Mann <mman...@netscape.net>
>To: wireshark-dev@wireshark.org
>Subject: Re: [Wireshark-dev] proto.h extension (unit strings)
>Message-ID: <158f108bd63-2eb5-5...@webstg-m08.mail.aol.com>
>Content-Type: text/plain; charset="utf-8"
>
>
>I thought this was a good idea, just took a while to get around to it:
>https://code.wireshark.org/review/19211

Hi Michael,

First off, thanks for spending time on a feature that at least I for one would 
thoroughly abuse ;-).  One initial comment that I can think of is whether 
"BASE" is an appropriate term for specifying a unit string, since a unit string 
is typically independent of the base used to represent the number.  I typically 
think of BASE when using BASE_DEC or BASE_HEX, etc.  In the patch I maintain, I 
ended up renaming it to OPTION_UNIT_STRING because there was confusion with the 
field_display_e enumeration in header field definitions.  Might be something to 
consider.

You could consider using a value_string for multiple representations could be 
useful for {"second", "seconds", "s"}.  That way you can associate a 
standardized name for each component.  I don't handle multiple unit string 
versions, but this is the route I would try first if I was going to try to 
implement it.

static const value_string header_field_units[] =
{
  { UNIT_SINGULAR, "foot" },
  { UNIT_PLURAL, "feet" },
  { UNIT_ABBREVIATION, "ft" },
  { 0, NULL }
};

The only difficulty is communicating when to use the abbreviation vs full name 
for a given header field or on a broad scale.  I'm not sure about what other 
people's needs would be, but I think a global (or possibly but less likely a 
dissector) specific preference seems feasible in my opinion.

I'm not a fan of manually adding " " to some unit strings and leaving it out 
for the abbreviation to the definition, i.e. I wouldn't want to have to do this:

static const value_string header_field_units[] =
{
  { UNIT_SINGULAR, " foot" },
  { UNIT_PLURAL, " feet" },
  { UNIT_ABBREVIATION, "ft" },
  { 0, NULL }
};

To that end I think the strings should not be specified with spaces at all.  
It's pretty obvious to put a space for whole words, less so for abbreviations.  
Could do a survey of a few text books with units to see what the majority style 
is for English.  Of course all hats are off for foreign translations.  If you 
choose to make the standard rendering use abbreviations without leading spaces 
in the dissection, then one can simply insert a space into the abbreviation 
string to get the effect they want.  Maybe not the idyllic solution, but 
certainly feasible.  Alternatively, it may be better to include a couple of 
global unit string checkbox preferences to include the leading string or not.  
I'm not familiar with enough foreign languages to know how best to address it.

I don't know whether I'd recommend maintaining a list of unit string structures 
in Wireshark.  I mean, it would certainly be nice for common SI units, but I 
don't know about Imperial units, and then do you maintain these same unit 
strings in different languages as well?  Seems like it'd be difficult to 
maintain.  Unfortunately, I don't have any ideas on how to address it, but I 
don't think it too much to ask for people to create their own value_string if 
they really want units for a header field.

On a related note (and the reason I'm pushing using a value_string), using a 
value_string may be the best way to add optional parameters in the future as 
well, where I could foresee wanting to do this (at least for the stuff that I 
do).

static const value_string header_field_options[] =
{
  { UNIT_SINGULAR, " foot" },
  { UNIT_PLURAL, " feet" },
  { UNIT_ABBREVIATION, "ft" },
  { SCALE_FACTOR, "0.125" },
  { 0, NULL }
};

If there's future design space to include a scale factor, this may be one 
method to incorporate it without messing with the header_field_info structure 
too badly.  Then, you could add "| OPTION_SCALE_FACTOR" if you needed to 
convert units (I do radians to degrees, and semicircles to lat/long, and lots 
of data that are in scaled integer form all the time, and it's pretty messy).  
Unfortunately, I've not made much headway into applying a scale factor 
usefully.  I can kind of get the display working, but I've no clue how to 
handle the filtering, e.g. if I convert the display to degrees, but the raw 
data is in radians, I can't figure out how to change the filtering mechanism 
that would allow me to filter a header field in degrees.

Just some ideas to ponder.

Best regards,
John Dill

P.S.  A couple of times my emails didn't show up on the wireshark-dev list, so 
I cc'd you as well.  I think it's a plain-text/html problem with my email 
client.

Re: [Wireshark-dev] dissecting TCP packets with multiple PDUs

[John Dill]

>Message: 1
>Date: Fri, 5 Aug 2016 14:47:59 +0100
>From: Graham Bloice <graham.blo...@trihedral.com>
>To: Developer support list for Wireshark <wireshark-dev@wireshark.org>
>Subject: Re: [Wireshark-dev] dissecting TCP packets with multiple PDUs
>
>>On 5 August 2016 at 14:08, John Dill <john.d...@greenfieldeng.com> wrote:
>>
>> I have a TCP protocol that sends multiple PDUs.  So far, my dissector
>> seems to handle the cases where one PDU is split across multiple frames,
>> and when multiple PDUs are dissected in one frame.  Unfortunately, I'm
>> having issues where the TCP dissection stops if I have multiple PDUs that
>> are split inside a frame, e.g.
>>
>>
>>
>> packet 37104 TCP segment (536)
>>
>> packet 37167 TCP segment (498) - creates reassembled TCP size of (1034)
>> which is correct
>>
>> However, packet 37167 has the start of another PDU containing 38 bytes.  I
>> can't seem to get the dissector to recognize the start of it.
>>
>> ?I printed out the captured length, but it always seems to be 1034.  I'm
>> not sure how to recognize that the current frame has leftover bytes to
>> start a new dissection.
>>
>> Is there an example plugin that someone can suggest that I can investigate
>> to see how this scenario is handled?
>>
>> Thanks,
>>
>> John D.
>
>
>Is your dissector returning the number of bytes it dissected?

Yes, I am returning tvb_length(tvb), and the length matches the expected size 
of the Reassembled TCP packet.  It appears everything makes sense from that 
perspective.

Upon closer inspection, I found that one of the frames in a sequence of PDUs 
appears to have been dropped, so the PDU length read in the earlier frame 
didn't match the data.  I believe that caused the TCP dissector to not parse 
properly.

I'm looking at another capture, and it appears to have the same issue where one 
of the last frames of a sequence of PDUs is not captured.  I thought I had a 
problem with my dissector code, but now it looks more like a protocol software 
bug.

On a different note...

One problem I have is that I'm creating multiple subtrees for a protocol when 
two PDUs are found in the same frame.  What's the best way to avoid this?

\code
gint
dissect_mk32_tcp_pdu(tvbuff_t *tvb, packet_info *pinfo, proto_tree *tree, void 
*data)
{
  proto_tree *mk32_tree = NULL;
  proto_item *ti; /* ti := tree item */
  gint   offset = 0;

  /*
   * This is a high level dissector targeting a re-assembled TCP
   * packet containing MK32 messages.  The main responsibilities
   * of the dissector is to control the meta data displayed in the
   * "Packet List" pane, and to display the packet contents in the
   * "Packet Details" pane.  Typically, the dissection details of
   * higher level protocol messages (MK32) and their contents are
   * handled in message specific sub-dissectors.
   */

  /* Change the Protocol column to MK32 in addition to TCP. */
  col_set_str(pinfo->cinfo, COL_PROTOCOL, "TCP/MK32");

  /* Change the Info column to indicate what? */

  /* Process the remaining data only if actively viewed in the
 "Packet Details" pane (when 'tree != NULL'). */
  if (tree)
  {
ti = proto_tree_add_item(tree, proto_mk32, tvb, offset, -1, ENC_BIG_ENDIAN);
mk32_tree = proto_item_add_subtree(ti, ett_mk32);

mk32_dissect_messages(tvb, pinfo, offset, mk32_tree);
  }
  return tvb_length(tvb);
}
\endcode

If the frame has multiple PDUs, I create multiple mk32_tree subtrees instead of 
just one.  Is there any recommended heuristic or method I should use to 
determine whether my PDU is in the same frame as another so that I don't make 
duplicate protocol subtrees, e.g. "if (tree && 
)"

I thought about static variables, or maybe using the 'data' member.  Any 
suggestions?

Thanks,
John D.
___
Sent via:Wireshark-dev mailing list <wireshark-dev@wireshark.org>
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

[Wireshark-dev] Trying to submit a patch

[John Dill]

I have finally got the time to port my changes to proto.h/proto.c over to the 
master-1.12 version of wireshark and I'm getting stuck trying to submit a patch 
for review.

I was not able to clone using the ssh method to download the latest git repo, 
but I was able to clone using the https link.  ​I believe that the port 29418 
is blocked by the IT firewall.  After checking out the 1.12 branch and making 
my changes, I'm trying to submit a patch and can't seem to get it to go.

Is it possible to submit a patch using something like the following

git push https://user.n...@code.wireshark.org/wireshark 
HEAD:refs/for/master-1.12/feature-request-display-options

Or does submitting a patch require ssh?  I didn't see an equivalent for the 
https version in the developer's guide.

Thanks,
John D.
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] proto.h extension

[John Dill]

Message: 1
Date: Fri, 8 May 2015 12:09:14 -0700
From: Guy Harris g...@alum.mit.edu
To: Developer support list for Wireshark wireshark-dev@wireshark.org
Subject: Re: [Wireshark-dev] proto.h extension
Message-ID: 4b338f97-11b8-41a6-9d7a-7a79f8c5d...@alum.mit.edu
Content-Type: text/plain; charset=iso-8859-1


On May 8, 2015, at 7:06 AM, John Dill john.d...@greenfieldeng.com wrote:

 Message: 3
 Date: Thu, 7 May 2015 11:29:22 -0700
 From: Guy Harris g...@alum.mit.edu
 To: Developer support list for Wireshark wireshark-dev@wireshark.org
 Subject: Re: [Wireshark-dev] proto.h extension
 Message-ID: cf2e7490-f023-49c2-8383-6c1a1394b...@alum.mit.edu
 Content-Type: text/plain; charset=iso-8859-1
 
 On May 7, 2015, at 8:13 AM, John Dill john.d...@greenfieldeng.com wrote:
 
 I have a couple of extensions that I created for the Wireshark baseline
 that we're using (1.10.x).  The diffs to proto.h and proto.c show the code
 changes to add a couple of features that I've found useful, unit strings
 and hiding the bits for bitmask header fields.
 
 http://codepad.org/KTGdEL1t 
 
 You need more than
 
 /* Following constants have to be ORed with a base_display_e when 
 dissector
  * want to control aspects of the display string for a 
 header_field_info */
 
 as a comment there - you need comments explaining what each of those flags 
 actually *does*.
 
 Guy,
 
 Sorry it wasn't clear.  Starting from this snippet...
 
 /*
 * BASE_UNIT_STRING - Append a unit string to the numeric value

That one's reasonable; I've thought of a similar option.

 *
 * When active, Wireshark will append a unit string declared as a
 * simple 'char *' for the 'strings' to the numeric value.

You might want to, instead, have it be a structure with a pair of strings, so 
that
if the field has the value 1, you can print the singular rather than the 
plural, e.g.:

struct unit_names {
   char *singular; /* name to use for 1 unit */
   char *plural;   /* name to use for  1 or  1 units */
};


struct unit_names feet {
   foot,
   feet
};

An interesting idea, did not consider that issue on unit strings.  On my side
at least, supporting proper English terminology would be nice but not that
important.

{
 hf_MFD_State_Data_Slew_Elevation_Ch1,
 {
   Slew_Elevation_Ch1,
   ndo.MFD_State_Data.Slew_Elevation_Ch1,
   FT_FLOAT,
   BASE_NONE | BASE_UNIT_STRING,
   feet,
   0x0,
   NULL,
   HFILL
 }
},

(For floating-point numbers, 1 unit means *exactly* 1 unit, i.e. an
exact floating-point comparison with 1x2^0.)

We could either

   1) require that both be non-null

or

   2) assume that, if the plural is null, you can pluralize using
the standard rules of English.

Does anybody have a preference there?

No preference either way.

As the last word of the last item in the list above indicates, that
limits the output to English; however, the same applies to, for example

{ hf_ip_hdr_len,  
  { Header Length, ip.hdr_len, FT_UINT8, BASE_DEC,
NULL, 0x0F, NULL, HFILL }},

and I don't expect to see the full names of every single field in Wireshark:

Yes, and even in the avionics data, there are many fields without unit strings.
There were just enough of them to make it annoying enough to produce the
desire to support them in header fields.

   $ ./tshark -G fields | wc -l
 151035

to be translated to any other language any time soon, and it also applies to

static const value_string ipopt_timestamp_flag_vals[] = {
{IPOPT_TS_TSONLY,Time stamps only  },
{IPOPT_TS_TSANDADDR, Time stamp and address},
{IPOPT_TS_PRESPEC,   Time stamps for prespecified addresses},
{0,  NULL}};

and translating all value_string tables would also be difficult.

So should we think about localization of the packet summary and detail fields 
(which would, I suspect, be a huge project), and possibly leave the unit 
strings open for localization, or not?

 /*
 * BASE_NO_BITMASK_DISPLAY - Hide the bitfield display of a data
 *   element.
 *
 * In Wireshark, any time the 'bitmask' argument is non-zero, a
 * bitfield display showing the location of 1's and 0's is
 * display is shown.  In certain situations, the display of
 * bitmask fields next to non-bitmask fields is quite jarring
 * because the display of these bitfields do not align the
 * data elements in an easy to scan column.
 *
 * 1010  Data Element 1
 *  0101 Data Element 2
 * Data Element 3

Presumably that would be used by people who don't care enough about the 
individual
bits of the octet(s) to be willing to sacrifice that for having the elements 
line up.

That might depend on the protocol, with protocols doing more bit-packing being 
more
likely to have a mix of octet-aligned and non-octet-aligned fields.  Presumably
avionics has some low-bit-rate links and needs to do more bit-packing; I think 
some
telephony protocols have the same

Re: [Wireshark-dev] proto.h extension

[John Dill]

Message: 3
Date: Thu, 7 May 2015 11:29:22 -0700
From: Guy Harris g...@alum.mit.edu
To: Developer support list for Wireshark wireshark-dev@wireshark.org
Subject: Re: [Wireshark-dev] proto.h extension
Message-ID: cf2e7490-f023-49c2-8383-6c1a1394b...@alum.mit.edu
Content-Type: text/plain; charset=iso-8859-1

On May 7, 2015, at 8:13 AM, John Dill john.d...@greenfieldeng.com wrote:

 I have a couple of extensions that I created for the Wireshark baseline
that we're using (1.10.x).  The diffs to proto.h and proto.c show the code
changes to add a couple of features that I've found useful, unit strings
and hiding the bits for bitmask header fields.
 
 http://codepad.org/KTGdEL1t 

You need more than

   /* Following constants have to be ORed with a base_display_e when 
 dissector
* want to control aspects of the display string for a 
 header_field_info */

as a comment there - you need comments explaining what each of those flags 
actually *does*.

Guy,

Sorry it wasn't clear.  Starting from this snippet...

/*
 * BASE_UNIT_STRING - Append a unit string to the numeric value
 *
 * When active, Wireshark will append a unit string declared as a
 * simple 'char *' for the 'strings' to the numeric value.
 */

This will take a string in a header field with the following definition

{
  hf_MFD_State_Data_Slew_Elevation_Ch1,
  {
Slew_Elevation_Ch1,
ndo.MFD_State_Data.Slew_Elevation_Ch1,
FT_FLOAT,
BASE_NONE | BASE_UNIT_STRING,
feet,
0x0,
NULL,
HFILL
  }
},

and display a header field value with that text appended such as

Slew_Elevation_Ch1: 580 feet


Without it, I would have to construct a cumbersome sequence of
commands to add the item with proto_tree_add_item, use
proto_registrar_get_nth to access the header field, do the
conversion manually and finally use a proto_item_set_text to
manually add the unit string text in the display code.  This
further disassociates the units of a header field further away
from its definition.  With this in place, I can put the units
of the header field in the header_field_info struct (where it
belongs) and have a simple proto_tree_add_item and it just
works.

/*
 * BASE_NO_BITMASK_DISPLAY - Hide the bitfield display of a data
 *   element.
 *
 * In Wireshark, any time the 'bitmask' argument is non-zero, a
 * bitfield display showing the location of 1's and 0's is
 * display is shown.  In certain situations, the display of
 * bitmask fields next to non-bitmask fields is quite jarring
 * because the display of these bitfields do not align the
 * data elements in an easy to scan column.
 *
 * 1010  Data Element 1
 *  0101 Data Element 2
 * Data Element 3
 *
 * If the 'bitmask' field is non-zero, one can append a
 * BASE_NO_BITMASK_DISPLAY bit to the 'display' parameter and
 * hide these bitfields.
 */

Normally, if you have a non-zero bitmask, you get a nice display
of a bitmask like the following:

0...      = Parity: 0
.00.      = SSM: Normal Operation (0)
...0  00..    = Spare: 0

etc...

The problem is that in a lot of avionics data, the message data
is packed in a combination of bit fields and octet sized fields.
Without any method to disable the bitfield display, you get a
stuttered display of the data so that it looks like this.

00..  BitField 1: 0
..0.  BitField 2: In-Air (0)
...0  BitField 3: 0
Field 1: 0 feet
00..    BitField 4: 0
..00    BitField 5: 0
  0...  BitField 6: 0
  .00.  BitField 7: 0
  ...0  BitField 8: 0
Field 2: 20 degrees
Field 3: 45 degrees
0...  BitField 9: 0
.0..  BitField 10: 0
..0.  BitField 11: 0
...0  BitField 12: 0
  BitField 13: 0
Field 4: 30 knots
...etc...

and so on in a message with several dozen to hundreds of data
elements.  The result is a very jagged display of that message's
data that looks ugly.  Some bit-fields are 8-bits wide, others
are 16-bits wide.

What BASE_NO_BITMASK_DISPLAY does is that when a bitmask field
is non-zero, it simply turns off the bitmask display for that
text string for the header field so that you get the following:

BitField 1: 0
BitField 2: In-Air (0)
BitField 3: 0
Field 1: 0 feet
BitField 4: 0
BitField 5: 0
BitField 6: 0
BitField 7: 0
BitField 8: 0
Field 2: 20 degrees
Field 3: 45 degrees
BitField 9: 0
BitField 10: 0
BitField 11: 0
BitField 12: 0
BitField 13: 0
Field 4: 30 knots

This flag avoids the ugly hack of having to access the header field
with proto_registrar_get_nth and basically having to format it myself.

Hopefully that better explains the motivation behind it.  If you
still have questions, let me know.  I have it implemented for 1.10.x
since that's what my development environment allows.  I'm mostly
curious whether this type of feature would be desired in the main
development branch.  I'm not asking anyone to do the work of porting
it as I'd do it when

Re: [Wireshark-dev] proto.h extension

[John Dill]

Message: 2
Date: Thu, 7 May 2015 17:58:46 + (UTC)
From: Christopher Maynard christopher.mayn...@igt.com
To: wireshark-dev@wireshark.org
Subject: Re: [Wireshark-dev] proto.h extension
Message-ID: loom.20150507t193823...@post.gmane.org
Content-Type: text/plain; charset=us-ascii

John Dill John.Dill@... writes:

 On a unrelated note, is there some way to begin a capture in wireshark (or
one of its tools) when a packet
 matches a filter expression?  For example, I have a specific packet that
triggers some process on the
 system, and I want to capture for the next 2 minutes and then stop.

This is not directly possible, no.  However, you can script something
together to make this work by utilizing 2 instances of dumpcap, for example.
 The first instance would wait for the capture event of interest, then
terminate, which would allow the second instance to be started up with the
capture settings you desire (e.g., capturing for 2 minutes, etc.).

If you're running on Windows, I wrote a dumpcap.bat batch file to help with
this, which I originally announced on 31 May 2014 here:
https://www.wireshark.org/lists/wireshark-users/201405/msg00030.html.  It
supports 4 modes of operation (including triggered captures), supports
e-mail notification of the event with the help of mailsend, and has hooks
for user-defined actions.  The latest published version of the batch file is
currently available under the Scripts section of
https://wiki.wireshark.org/Tools.  It is mostly self-documented, but you can
read more about it from the link above or from some questions on
ask.wireshark.org where I thought the batch file might possibly come in
handy for other folks:

1)
https://ask.wireshark.org/questions/39456/is-there-a-way-to-stop-capture-
upon-http-error-404
2) https://ask.wireshark.org/questions/40888/custom-stop-recording-trigger
3) https://ask.wireshark.org/questions/26434/sound-alert

- Chris
P.S. Keep in mind that trigger mode might not be good enough though, as
capturing won't start until AFTER the event occurs.  If you want to be sure
you capture from the event onwards, you might want to run the batch file in
Dumpcap+Event Mode and use a ring buffer to do continuous capturing until
the event occurs and then just set the Event kills dumpcap? option to Y
along with Delay before kill/action to 120 seconds in your case.

Thank you, I will take a look and give it a try.

Best regards,
John D.
winmail.dat___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

[Wireshark-dev] proto.h extension

[John Dill]

I have a couple of extensions that I created for the Wireshark baseline that 
we're using (1.10.x).  The diffs to proto.h and proto.c show the code changes 
to add a couple of features that I've found useful, unit strings and hiding the 
bits for bitmask header fields.

http://codepad.org/KTGdEL1t 

I intended to try to integrate them into the latest development, but I keep 
kicking it out since it's low priority on my schedule at the moment (it's been 
a few months and I still haven't gotten around to it).  I figured that if 
anyone is curious enough to look at it, maybe there'd be discussion whether 
either feature has value making it into the main line of development.

The differences between 1.10 and master seemed significant enough that I 
haven't tried to make a patch for that yet.

Just looking for feedback either way.

On a unrelated note, is there some way to begin a capture in wireshark (or one 
of its tools) when a packet matches a filter expression?  For example, I have a 
specific packet that triggers some process on the system, and I want to capture 
for the next 2 minutes and then stop.

Thanks,
John D.
winmail.dat___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] What Wireshark base version to use for customization

[John Dill]

Message: 2
Date: Wed, 10 Dec 2014 15:13:08 +
From: Anders Broman anders.bro...@ericsson.com
To: Developer support list for Wireshark wireshark-dev@wireshark.org
Subject: Re: [Wireshark-dev] What Wireshark base version to use for
   customization
Message-ID:
   43c5658ba3fb7b48a6f38eed0b6253f11aa7c...@esessmb105.ericsson.se
Content-Type: text/plain; charset=utf-8

Hi,
Note that under GPL you are obliged to supply the source code of your 
modifications if you distribute binaries to your customers.
I would use the development version to get the bleeding edge stuff or the 
latest stable if stability is more of an issue.

Regards
Anders

So what restrictions are there when you have a Wireshark plugin that contains 
proprietary information (which can be of the do not export variety) from the 
govt or customer and they do *not* want that information released to the 
public, since Wireshark can be used as a tool to visualize and analyze these 
private kinds of protocols?  If some of that implementation leaks into the 
Wireshark application (like hiding all of the unnecessary protocol cruft to 
make it simpler for user to use), what are the implications?

Best Regards,
John D.
winmail.dat___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] What Wireshark base version to use for customization

[John Dill]

Message: 3
Date: Wed, 10 Dec 2014 11:08:25 -0700
From: Stephen Fisher sfis...@sdf.org
To: Developer support list for Wireshark wireshark-dev@wireshark.org
Subject: Re: [Wireshark-dev] What Wireshark base version to use for
   customization
Message-ID: 20141210180825.ga29...@sdf.org
Content-Type: text/plain; charset=us-ascii

On Wed, Dec 10, 2014 at 12:51:23PM -0500, John Dill wrote:

 So what restrictions are there when you have a Wireshark plugin that 
 contains proprietary information (which can be of the do not export 
 variety) from the govt or customer and they do *not* want that 
 information released to the public, since Wireshark can be used as a 
 tool to visualize and analyze these private kinds of protocols?  If 
 some of that implementation leaks into the Wireshark application (like 
 hiding all of the unnecessary protocol cruft to make it simpler for 
 user to use), what are the implications?

Is the proprietary information short, such as encryption keys?  A 
preference can be used for things like that and then only if the 
user's preferences file is shared will it get out.  If that's a 
high-risk, you could even have the dissector/plug-in do something 
non-stndard like reading a file for the information (but we probably 
wouldn't want that kind of dissector in the base source).

The entire packet stream generated is a proprietary system on top of
TCP and UDP that consists of avionics data, all of which is considered
proprietary.  There are several hundred different packet messages that
contain one to several hundred data elements.

I was curious how the license Wireshark uses applies to this scenario,
since I've created a DLL to process data that is also distributed to a
govt entity, but I'm using an open source project with a GPL license
to translate this data, but the source code that translates the content
they want to keep private.

Regardless, there's no way I would be allowed to submit this plugin to
the public Wireshark repository (not without serious legal/employment
consequences), so maybe its a moot point to discuss.

Best regards,
John D.

winmail.dat___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] calculating PDU size of TCP message

[John Dill]

Message: 3
Date: Mon, 21 Jul 2014 13:52:40 -0700
From: Guy Harris g...@alum.mit.edu
To: Developer support list for Wireshark wireshark-dev@wireshark.org
Subject: Re: [Wireshark-dev] calculating PDU size of TCP message
Message-ID: 937c9f55-5330-4553-85a3-51543aeed...@alum.mit.edu
Content-Type: text/plain; charset=iso-8859-1
 
 
On Jul 21, 2014, at 1:46 PM, John Dill john.d...@greenfieldeng.com wrote:
 
 I have a TCP message (that I reverse engineered) that contains blocks of the 
 following type:
 
  -
 |  Data Type  | 4 bytes
  -
 | Payload Len | 4 bytes
  -
 |  Checksum   | 4 bytes
  -
 |Data | = Payload Len
  -
(repeats)
 
Since I did not know about the underlying structure, I used tcp_dissect_pdus
with a TCP header length of 12 bytes to be able to read a single block.
 
 tcp_dissect_pdus(tvb, pinfo, tree, desegment_tcp_messages,
  TCP_PAYLOAD_HDR_LENGTH,
  get_tcp_pdu_len,
  dissect_tcp_pdu);
 
I have discovered that in general, this application layer message can have
multiple blocks

What do you mean by this application layer message?

I use application layer in reference to the OSI model as a protocol that
sits on top of a transport protocol layer.  An application layer message
refers to a PDU that was desegmented from one or more TCP packets.  Maybe
PDU is the term I should use here.

If a block is

 -
|  Data Type  | 4 bytes
 -
| Payload Len | 4 bytes
 -
|  Checksum   | 4 bytes
 -
|Data | = Payload Len
 -

That is correct.  Each of these blocks could probably be referred to
as a PDU as well.

then presumably there's some *other* header that indicates which blocks
are part of a given application layer message, or a convention that an
application layer message consists of a sequence of blocks all of the
same data type (so that a change in the data type is an indication that
one application layer message ended and another began), or something
such as that.

Unfortunately, there is no other header that identifies which blocks
are part of a given application layer message.  It is just a sequence
of blocks.  There are control messages sent from the client to the
server, and data messages, both periodic and on-demand, from the
server to the client and vice versa.  Here are the scenarios that I
see in the data.

1.  A single TCP packet payload contains 1 block (for control messages
or medium to smaller data messages).

2.  Multiple TCP packets are desegmented to contain 1 block (for large
data messages, up to a few KB).

3.  A single TCP packet payload contains 2 or more blocks (for multiple
control messages and smaller data messages).

Without knowing that, it will be impossible to do

Frame
Ethernet II
Internet Protocol Version 4
Transmission Control Protocol
Application Protocol
  Block 1
  Block 2
  Block ...
  Block N

because Wireshark won't be able to determine where one application layer
message begins and another ends.

I see.  I originally thought I had a mistake in the dissector since it's
the first time I've encountered multiple PDUs in a single TCP packet.  I
had expected them to all be in the same Application Protocol since that
is what I've always seen before.  Now it's clear what is going on.

Thanks again,
John Dill
winmail.dat___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

[Wireshark-dev] calculating PDU size of TCP message

[John Dill]

I have a TCP message (that I reverse engineered) that contains blocks of the 
following type:

 -
|  Data Type  | 4 bytes
 -
| Payload Len | 4 bytes
 -
|  Checksum   | 4 bytes
 -
|Data | = Payload Len
 -
   (repeats)

Since I did not know about the underlying structure, I used tcp_dissect_pdus 
with a TCP header length of 12 bytes to be able to read a single block.

tcp_dissect_pdus(tvb, pinfo, tree, desegment_tcp_messages,
 TCP_PAYLOAD_HDR_LENGTH,
 get_tcp_pdu_len,
 dissect_tcp_pdu);

I have discovered that in general, this application layer message can have 
multiple blocks, and I have something that looks like the following:

Frame
Ethernet II
Internet Protocol Version 4
Transmission Control Protocol
Application Protocol
Application Protocol
Application Protocol
...

It's ok, but ideally, I would like to place all of these blocks into a single 
root layer like the following:

Frame
Ethernet II
Internet Protocol Version 4
Transmission Control Protocol
Application Protocol
  Block 1
  Block 2
  Block ...
  Block N

It does not appear that I can use the normal PDU dissection to arrange that 
because I do not have an overall message size in a fixed header, I have to read 
each block individually and sum the payload lengths.  From the README.developer 
guide, it looks like I need to do something like in section 2.7.2, but I'm 
having a hard time adapting its example to my scenario.

Can someone point me to a dissector that already implements something similar 
to what I need, or give a simple loop on how to get the dissector to do what I 
want?

Thanks,
John Dill
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

[Wireshark-dev] controlling the display of the leading bit string when bitmask != 0

[John Dill]

Is there a mechanism to control whether I want the bit string
displayed when the bitmask field is non-zero?  Granted, in most
circumstances, it looks good for data elements that consist of
consecutive bits, but in others it just looks jarring.

For example, I have a character attribute that has three data
elements, where two of the data elements are stored in a nibble,
followed by one that is in a byte.

  Field 1 - Char 1 (4 bit)
  Field 2 - Char 1 (4 bit)
Field 3 - Char 1   (8 bit)
  Field 1 - Char 2
  Field 2 - Char 2
Field 3 - Char 2
etc. for 24 characters

I need to display an array of this data, and it would be nice
to just remove the leading bit string altogether.  I can see
something in 'proto_tree_set_representation_value' (1.10.6) that
triggers off of 'bitmask != 0', but I don't see anything that
would hide that string using the normal api.

I hacked something crudely together to do it manually.

\code snippet
  header_field_info *hf;
  guint32 value;
  guint32 tmpval;

  ...

  /* Emit the code to display a data element without the leading
 bitmask display. */
#define EMIT_HF_NO_BITMASK(hf_index, tvb_offset) \
  hf = proto_registrar_get_nth(hf_index);\
  value = tvb_get_guint8(tvb, (tvb_offset)); \
  tmpval = (value  hf-bitmask)  hf-bitshift;\
  if (hf-strings) { \
proto_tree_add_uint_format(tree, hf_index, tvb, (tvb_offset), 1, tmpval, \
  %s: %s (%u), \
  hf-name, val_to_str_const(tmpval, cVALS(hf-strings), Unknown), 
tmpval); \
  }  \
  else { \
proto_tree_add_uint_format(tree, hf_index, tvb, (tvb_offset), 1, tmpval, \
  %s: %u,  \
  hf-name, tmpval); \
  }
\endif

I'm tempted to add another bit next to BASE_RANGE_STRING
and BASE_EXT_STRING to flip the bit string display off in
'proto_tree_set_representation_value' so that I can just use
'proto_tree_add_item' and be done with it.

Or perhaps I missed something completely obvious.  Any
suggestions?

Thanks,
John Dill
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Plugin Dissector vs Builtin Dissector

[John Dill]

Message: 4
Date: Wed, 23 Apr 2014 13:19:43 -0400
From: Kevin Cox kevin...@kevincox.ca
To: wireshark-dev@wireshark.org
Subject: [Wireshark-dev] Plugin Dissector vs Builtin Dissector
Message-ID: 5357f62f.5080...@kevincox.ca
Content-Type: text/plain; charset=iso-8859-1

Hello,

Forgive me if this has been asked before but I can't find any resources
about the advantages/disadvantages of plugin dissectors and the ideal
cases for each.

So far I have gathered that plugin dissectors are easiest to write
initially[0] while builtin dissectors load slightly faster.

[0] https://www.wireshark.org/docs/wsdg_html_chunked/ChDissectAdd.html

I have read the README.{developer,dissector,plugin} and a number of
others but can't find a resource to help me decide which to write.

For the curious I will be working on a dissector for the Ceph[1]
protocol as a gsoc project this summer and am trying to make the
decision whether a builtin or plugin dissector would be preferred.

[1] https://ceph.com/

Cheers,
Kevin

One factor to consider is whether the contents of the packet is
considered proprietary.  In that sense, developing and releasing
the protocol dissector as a plugin allows to one to control the
code distribution without the need to maintain a fork of Wireshark.

For development purposes, either is fine, but Wireshark appears
to prefer to release dissectors as built-in when feasible.

Best regards,
John Dill
winmail.dat___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

[Wireshark-dev] preventing malformed packet errors with dissector when desegment is turned off

[John Dill]

I have a dissector for an application layer protocol that is on top
of a TCP port.

\code snippet
guint
get_xyz_pdu_len(packet_info *pinfo, tvbuff_t *tvb, int offset)
{
  guint32 plen;

  /* Get the length of the TCP XYZ payload. */
  plen = tvb_get_ntohl(tvb, offset);

  /* The TCP XYZ payload length value does not include itself so
 add that in. */
  return plen + 4;
}

void
dissect_xyz_tcp(tvbuff_t *tvb, packet_info *pinfo, proto_tree *tree)
{
  tcp_dissect_pdus(tvb, pinfo, tree,
   desegment_xyz_messages, TCP_XYZ_PAYLOAD_HDR_LENGTH,
   get_xyz_pdu_len, dissect_xyz_tcp_pdu);
}

static void
dissect_xyz_tcp_pdu(tvbuff_t *tvb, packet_info *pinfo, proto_tree *tree)
{
  ...
}

void
proto_reg_handoff_xyz(void)
{
  xyz_tcp_handle = create_dissector_handle(dissect_xyz_tcp, proto_xyz);
  dissector_add_uint(tcp.port, WKS_TCP_PORT, xyz_tcp_handle);

  heur_dissector_add(udp, dissect_xyz_udp_heur, proto_xyz);
}
\endcode

When the 'desegment_xyz_messages' is true, the protocol dissector
appears to work fine, and I do not get any malformed packets in
my desegmented TCP messages.  However, when I set desegment to false,
I get '[Malformed Packet]' next to any TCP segment messages and my
dissector is attempting to run on each segment which creates these
errors.

So my question is, what is the correct behavior to implement?  Should
I not have a desegment option?

I could decide not to run my dissector when its false and just leave
all of the packets in the conversation as TCP.

\code
void
dissect_xyz_tcp(tvbuff_t *tvb, packet_info *pinfo, proto_tree *tree)
{
  if (desegment_xyz_messages) {
tcp_dissect_pdus(tvb, pinfo, tree,
 desegment_xyz_messages, TCP_XYZ_PAYLOAD_HDR_LENGTH,
 get_xyz_pdu_len, dissect_xyz_tcp_pdu);
  }
}
\endcode

In this scenario, if desegment is on, I get the protocol messages; if
it's off, it looks like unadorned TCP messages.

I'm just wondering what kind of expectations there are for TCP based
application layer protocol dissectors.

Best regards,
John Dill
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] adding units

[John Dill]

Message: 5
Date: Wed, 16 Apr 2014 08:59:46 +
From: Anders Broman anders.bro...@ericsson.com
To: Developer support list for Wireshark wireshark-dev@wireshark.org
Subject: Re: [Wireshark-dev] adding units
Message-ID:
   43c5658ba3fb7b48a6f38eed0b6253f11a969...@esessmb105.ericsson.se
Content-Type: text/plain; charset=us-ascii

I'm tinkering with the 1.10.6 source code

You should be doing it on trunk if you are planning to commit to
gerrit as this is new functionality.

My group is just now starting to convert to Subversion!, so I maintain
a separate repository with a baseline from the latest release of 1.10.6
for development of the dissector plugin.  Well, it's a step up from
Visual SourceSafe.

The reason is that management for this project desired a stable API and
codebase to develop the dissector.

and I'm wondering if there's
any opinions about the position and placement of units when using the
different 'display' enumerations.


:

 case BASE_DEC_HEX:

:

} case BASE_HEX_DEC:
eturn format;

Both these format should probably be treated as BASE_HEX, I can't think
of a case where something expressed in units would need a HEX
representation.

I would think the prime usage for BASE_HEX, BASE_DEC_HEX and BASE_HEX_DEC
is when a standard document expresses IEs or Messages in HEX to ease
comparison with the standard document.

I thought about it and tend to agree with your assessment.  I ended up
not populating any unit strings when HEX is in the display type.  It made
the implementation a bit simpler too.

I have something that seems to work for the use cases that I have header
fields for, but it's based on 1.10.6 instead of trunk.  I checked out
the latest version out of git, and it appears that the API has changed
enough that I'd have to adapt where the changes are made, so is it
worth posting/submitting the proto.c file based on 1.10.6 (to pastebin
perhaps)?

I'd eventually get around to adapting it for the latest wireshark, but
it's kind of out of my scope of work at this time, so I don't know
when exactly that I'd get to it.  And trying to add a scale factor may
change things since I need to merge that in and it'll probably end up
in the 'strings' location.

Thanks,
John Dill
winmail.dat___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

[Wireshark-dev] TCP dissector design

[John Dill]

I have a closed network system where there are several TCP conversations
that transmit the same kind of data, but use different application layer
messages structures.  It seems to be based on the age of the code,
where TCP conversations from older code use a different application
message structure (with different headers) than newer ones.

They would like to be able to see all the data fields under the same
protocol, whether the message came from a UDP packet or TCP packet.
However, I'm a bit confused as to how to structure the dissector to
be able to handle this properly.

For the UDP, I have a top level dissector that uses an heuristic to
receive all UDP packets and discover which of these UDP messages are
the protocol's application messages.  I represent the protocol with
the acronym as XYZ.

\code snippet

static void xyz_dissect_app_msg_fmt1(tvbuff_t *tvb, packet_info *pinfo, gint 
offset, proto_tree *tree);
static void xyz_dissect_app_msg_fmt2(tvbuff_t *tvb, packet_info *pinfo, gint 
offset, proto_tree *tree);

/* Forward declare the XYZ message sub-dissectors to handle each Message ID. */
static void dissect_xyz_message1(tvbuff_t *tvb, gint offset, proto_tree *tree);
...
static void dissect_xyz_messageN(tvbuff_t *tvb, gint offset, proto_tree *tree);
[There is a switch table in each app_msg_fmt dissector that calls
the appropriate message subdissector based on an id.]

/* Forward declare the hand-off registration. */
void proto_register_xyz(void);
void proto_reg_handoff_xyz(void);

/* This is the main XYZ dissector that gets called for every UDP packet
   because it is registered as a heuristic filter under the UDP protocol. */
static gboolean
dissect_xyz_udp(tvbuff_t *tvb, packet_info *pinfo, proto_tree *tree)
{
  ...

if (tree)
{
  if (msg_fmt == APPLICATION_MSG_FMT1) {
xyz_dissect_app_msg_fmt1(tvb, pinfo, offset, xyz_tree);
  }
  else if (msg_fmt == APPLICATION_MSG_FMT2) {
xyz_dissect_app_msg_fmt2(tvb, pinfo, offset, xyz_tree);
  }
}

  ...
}

static gboolean
dissect_xyz_heur(tvbuff_t *tvb, packet_info *pinfo, proto_tree *tree, void 
*data)
{
  return dissect_xyz_udp(tvb, pinfo, tree);
}

void proto_register_xyz(void)
{
  static hf_register_info hf[] = ...
  static gint *ett[] = ...

  /* proto_register_protocol(name, short_name, abbreviation) */
  proto_xyz = proto_register_protocol(XYZ Protocol,
  XYZ,
  xyz);

  /* The macro 'array_length' calculates the number of elements of a
 fixed-size array at the compile phase. */
  proto_register_field_array(proto_xyz, hf, array_length(hf));
  proto_register_subtree_array(ett, array_length(ett));

  /* Register configuration options for the XYZ protocol dissector. */
  {
module_t *xyz_module;
xyz_module = prefs_register_protocol(proto_xyz, proto_reg_handoff_xyz);

...
  }

  register_dissector(xyz, dissect_xyz_udp, proto_xyz);
}

void
proto_reg_handoff_xyz(void)
{
  heur_dissector_add(udp, dissect_xyz_heur, proto_xyz);
}
\endcode

The TCP dissectors can be split up into three families (as far as I
know), where port family A uses the older application message
structure and port family B uses the new application message
structure, and one port C uses its own separate custom application
message format.

Ideally, they would like to see all the messages under one protocol
family 'XYZ', regardless of whether it came from a TCP or UDP packet.
All the TCP conversations require fragments to be assembled.  Can
someone offer some advice on how to structure the dissector registration
so that I can handle the TCP messages in this scenario.  Is there a
dissector already developed that kind of matches this scenario that
I can glean some ideas from?

Thanks,
John Dill
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

[Wireshark-dev] adding units

[John Dill]

I'm tinkering with the 1.10.6 source code and I'm wondering if there's
any opinions about the position and placement of units when using the
different 'display' enumerations.

Here are my thoughts based on one particular use case.
(my comments are in [])

\code snippet
static const char *
hfinfo_uint_value_format(const header_field_info *hfinfo)
{
  const char *format = NULL;

  /* Pick the proper format string */
  if (hfinfo-type == FT_FRAMENUM) {
/*
 * Frame numbers are always displayed in decimal.
 */
format = %u; [no reason to apply a units field to FT_FRAMENUM imo]
  } else {
switch (hfinfo-display) {
  case BASE_DEC:
format = %u; [would become %u %s, should be a no-brainer]
break;
  case BASE_DEC_HEX:
switch (hfinfo-type) {
  case FT_UINT8:
format = %u (0x%02x);
[could become %u %s (0x%02x) or %u (0x%02x) %s, prefer first 
version]
break;
  case FT_UINT16:
format = %u (0x%04x); [prefer %u %s (0x%04x)]
break;
  case FT_UINT24:
format = %u (0x%06x); [prefer %u %s (0x%06x)]
break;
  case FT_UINT32:
format = %u (0x%08x); [prefer %u %s (0x%08x)]
break;
  default:
DISSECTOR_ASSERT_NOT_REACHED();
;
}
break;
  case BASE_OCT:
format = %#o; [my preference is not to include units for octal 
display]
break;
  case BASE_HEX:
switch (hfinfo-type) {
  case FT_UINT8:
[my preference is to not include units for hexadecimal display, 
since
 the format tends to be used to display raw data]
format = 0x%02x;
break;
  case FT_UINT16:
format = 0x%04x;
break;
  case FT_UINT24:
format = 0x%06x;
break;
  case FT_UINT32:
format = 0x%08x;
break;
  default:
DISSECTOR_ASSERT_NOT_REACHED();
;
}
break;
 case BASE_HEX_DEC:
switch (hfinfo-type) {
  case FT_UINT8:
format = 0x%02x (%u);
[my preference in this instance is to attach units to the decimal
 part of the display, so you would have 0x%02x (%u %s)]
break;
  case FT_UINT16:
format = 0x%04x (%u); [prefer 0x%04x (%u %s)]
break;
  case FT_UINT24:
format = 0x%06x (%u); [prefer 0x%06x (%u %s)]
break;
  case FT_UINT32:
format = 0x%08x (%u); [prefer 0x%08x (%u %s)]
break;
  default:
DISSECTOR_ASSERT_NOT_REACHED();
;
}
break;
  default:
DISSECTOR_ASSERT_NOT_REACHED();
;
}
  }
  return format;
}
\endcode

Obviously this would require some kind of change in 'proto_custom_set'
and 'fill_label_bitfield' where this type of function is used, since the
order of the printf modifiers change based on the 'display' enumeration
value.

Currently, I'm using the next available bit above BASE_EXT_STRING to
distinguish the conditions as BASE_UNIT_STRING.

The FT_FLOAT and FT_DOUBLE types should be as simple as adding the unit
string after the value in 'proto_custom_set' and 'proto_item_fill_label'.

It appears that some error condition checking happens in 'tmp_fld_check_assert'.
If I detect a bad combination of a FT_TYPE and BASE_UNIT_STRING, should I
try to report that as an error somehow, or ignore it?

Any comments on the placement of unit strings in the format, or other
considerations I should look into.

Thanks,
John Dill
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] How to print out string encoded data that contains nul characters?

[John Dill]

Message: 1
Date: Wed, 9 Apr 2014 14:24:53 -0700
From: Guy Harris g...@alum.mit.edu
To: Developer support list for Wireshark wireshark-dev@wireshark.org
Subject: Re: [Wireshark-dev] How to print out string encoded data that
   contains nul characters?
Message-ID: 570e5517-8137-466f-aeb1-c32cc47c1...@alum.mit.edu
Content-Type: text/plain; charset=iso-8859-1


On Apr 9, 2014, at 2:06 PM, John Dill john.d...@greenfieldeng.com wrote:

I have several character data fields that happen to contain sections of
non-ascii binary data including nul characters.  I'd like to get a string
display that shows all of the characters according to the length of the
field, i.e.
 
 20 20 20 20 20 20 01 00 01 00 48 31 20 20 20 20
 
 produces
 
   \001\000\001\000H1
 
 In proto.c, I see that all of the format_text calls use strlen(bytes) as the 
 length.
 
 case FT_STRING:
 case FT_STRINGZ:
 case FT_UINT_STRING:
 bytes = (guint8 *)fvalue_get(fi-value);
 label_fill(label_str, hfinfo, format_text(bytes, strlen(bytes)));
 
What is the recommended way of creating a text string that uses the octal
encoding '\xxx' for non-ASCII data including nul characters that uses the
'length' field of 'proto_tree_add_item'?

The right short-term way would be to use proto_tree_add_string_format_value()
to add the field, and format the string's value yourself, using format_text()
with a byte count rather than strlen().

Cool, thanks!

The right long-term way is to modify Wireshark so that this works.  The way we
handle strings should probably be changed so that we:

store the raw string octets as a counted array, along with the string encoding;

convert the octets from the encoding to UTF-8 *with invalid octets and 
sequences
shown as escapes* when displaying the strings;

convert the octets from the encoding to UTF-8 with invalid octets and sequences
shown as Unicode REPLACEMENT CHARACTERS when making the string available for
processing by other software (e.g., -T fields, etc.) (or somehow saying this
isn't a valid string in this encoding);

somehow arrange that strings with invalid octets or sequences are *always* 
unequal
to any character string in packet-matching expressions (display/read filters,
color filters, etc.), and perhaps allow strings to be compared against octet
sequences (e.g. foobar.name = 20:20:20:20:20:20:01:00:01:00:48:31:20:20:20:20
matches the raw octets of the string), and use that with Prepare As Filter 
etc..

Sounds pretty reasonable to me.  For now I'll have to use the short method since
this dissector is still hanging over my head (and I haven't even started the TCP
side yet).

Alternatively, if they're *not* really character strings, display them as a set
of subfields, with the text part shown as strings and the binary data shown as
whatever it is, e.g.

Frobozz text 1: {blanks}
Frobozz count 1: 1
Frobozz count 2: 1
Frobozz text 2: H1{and more blanks}

or whatever it is.

I had considered that, but I've found that the field is mapped to an array of
16 byte characters but for whatever reason, the array is used differently
depending on the radio its addressed to.  Sometimes the 16 bytes of data is a
valid string, and other times it looks like pair of 6 character strings with
binary data of either garbage or has some unknown meaning (at least to me).

The string itself is in a structure that is grouped as an array so preset 1
out of 10 could be 16 character string in one message and two pair of strings
in another.  I would need to analyze the other fields in the message to be
able to make that distinction and I didn't want to go to that level of effort
(since there are over 20 different preset types where each type could
potentially have its own string format).  Just displaying the string encoding
showing nul bytes is simpler.

Best regards,
John Dill
winmail.dat___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Header field with scaling factor/units?

[John Dill]

Message: 3
Date: Wed, 9 Apr 2014 16:16:40 -0700
From: Guy Harris g...@alum.mit.edu
To: Developer support list for Wireshark wireshark-dev@wireshark.org
Subject: Re: [Wireshark-dev] Header field with scaling factor/units?
Message-ID: 4d624ab4-5fcd-47a2-8850-39cc4e6b4...@alum.mit.edu
Content-Type: text/plain; charset=iso-8859-1


On Apr 9, 2014, at 11:01 AM, John Dill john.d...@greenfieldeng.com wrote
(in a font that gets rendered as rather small characters in my mail reader -
 you might want to use larger type to help out those of us with aging eyes):

I have a common use case (hundreds to low thousands of data elements) where
I need to take some data, encoded in an integer FT_UINT[8|16|32], sometimes
has a bitmask applied, and needs to be multiplied by a scaling factor that
may be an integer or floating point value, with an optional units string.
I didn't see a use case in README.developer that directly handles this 
scenario.

Unfortunately, while both scaling and appending units would be useful for a
number of fields, we don't have mechanisms to support them.

Since at the moment it appears that I need to overwrite the item's text
string to accomplish what I want, I was considering hijacking the 'strings'
member to store the scaling factor and units strings.  Then I could test
for the existence of a scaling factor/units string in the hf-strings member.
I'll probably have to package it into a VALS and use try_val_to_str to
access the units string to remain compatible with 'proto_tree_add_item'
before I rewrite the text representation.The scale factor code be
encoded as a string where I'd have to convert it on the fly using some form
of strto[d|l|ul].  Of course this could be just added inline with the
dissector code, but it would be nice to have a place in the hf_register_info
declaration that documents this information.

I would think it would be possible to extend the FT_ types with a constant,
that informs the api that the scaling factor and units are encoded in
'hf-strings' as [{ 0, 0.25 } { 1, pounds }] with a new interface
function or two to implement it.

Currently, the header_field_info structure has a field named display.
Originally, it was used only for numerical values, to control the base in
which to display the number; it's now used for other field types to control
how they're displayed as well.  In addition, for numerical fields, there
are some flags that can be set to indicate how to interpret the ext field...

...which is the strings field.

I might be inclined to, for numerical fields, divide the display field
into a 4-bit field used for the base and another field indicating how the
strings field is to be interpreted (currently, that's what we have, but
they're implemented as bit flags, which means that there are mixtures of
flags that might not make sense).

We could add an additional type, in which the strings field encodes a
scaling factor and units; perhaps integral and floating-point scaling
factors could have different types.  (I would include the scaling factor
as a number, not a string.)

I would also rename strings, while we're at it - I think display might
have been called base in the old days.

How difficult would it be to allow a filter expression to be able to
search on a header field whose condition assumes that the scaling factor
has been applied, i.e., the data is an integer and has a scaling factor
of .25 and you want to filter its value using a floating point value
(probably quite difficult I'm guessing)?

We'd probably want to support both filtering on the raw and displayed value
of a field.  We can already do that with enumerated fields - if you have
a field with a value_string table that maps 2 to Hello, then you can do

proto.field == 2

or

proto.field == Hello

We might want to add syntax so that, for a field with a scale factor of 0.5,
we might have

wlan.rate = raw(22)

or

wlan.rate = 11

I think raw() is a fine option.  Another idea is to surround the value with a
delimiter character that's not used otherwise to signal that the value should
be compared against the raw data.  If '~' isn't used for instance, one could\
use ~22~.  I don't have a particular preference at this point in time.

(no, that was not a randomly-chosen field example :-)).  Other suggestions
for the syntax are welcome.

I spent some time thinking about this, and I believe that the scaling factor
and units could probably be implemented independently (as in one after the
other).  The units string is probably the easier of the two, so here are my
thoughts so far.  Hopefully not all of it is chaff.

Of all the FT_ types defined, this is the list that I think makes sense to
allow an optional unit string.

FT_INT[8|16|24|32|64]
FT_UINT[8|16|24|32|64]
FT_FLOAT
FT_DOUBLE

You could add FT_ABSOLUTE_TIME and FT_RELATIVE_TIME to turn on a units
display, but the only units that would make sense would be 'seconds' or
a derived abbreviation 's', 'sec', etc.

I do

[Wireshark-dev] Header field with scaling factor/units?

[John Dill]

I have a common use case (hundreds to low thousands of data elements) where I 
need to take some data, encoded in an integer FT_UINT[8|16|32], sometimes has a 
bitmask applied, and needs to be multiplied by a scaling factor that may be an 
integer or floating point value, with an optional units string.  I didn't see a 
use case in README.developer that directly handles this scenario.

I'm thinking about doing something like the following.

\code idea
proto_item *pi;
header_field_info *hf;

/* hf_index is the registered hf identifier */

pi = proto_tree_add_item(tree, hf_index, tvb, offset, length, ENC_BIG_ENDIAN);
hf = proto_registrar_get_nth(hf_index);
value = tvb_get_ntohX(tvb, offset);
tmpval = (value  hf-bitmask)  hf-bitshift;
dblval = tmpval * scaling_factor;
if (units_str) {
  proto_item_set_text(pi, %s: %f %s, hf-name, dblval, units_str);
} else {
  proto_item_set_text(pi, %s: %f, hf-name, dblval);
}
\endcode

I can wrap this kind of code in one or more function(s), but I'm wondering if 
there is a recommended Wireshark standard solution.

Since at the moment it appears that I need to overwrite the item's text string 
to accomplish what I want, I was considering hijacking the 'strings' member to 
store the scaling factor and units strings.  Then I could test for the 
existence of a scaling factor/units string in the hf-strings member.  I'll 
probably have to package it into a VALS and use try_val_to_str to access the 
units string to remain compatible with 'proto_tree_add_item' before I rewrite 
the text representation.The scale factor code be encoded as a string where 
I'd have to convert it on the fly using some form of strto[d|l|ul].  Of course 
this could be just added inline with the dissector code, but it would be nice 
to have a place in the hf_register_info declaration that documents this 
information.

I would think it would be possible to extend the FT_ types with a constant, 
that informs the api that the scaling factor and units are encoded in 
'hf-strings' as [{ 0, 0.25 } { 1, pounds }] with a new interface function 
or two to implement it.

Any thoughts on applying the proto_item_add_xxx interface to handle this use 
case?

How difficult would it be to allow a filter expression to be able to search on 
a header field whose condition assumes that the scaling factor has been 
applied, i.e., the data is an integer and has a scaling factor of .25 and you 
want to filter its value using a floating point value (probably quite difficult 
I'm guessing)?

Thanks for any comments,
John Dill
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

[Wireshark-dev] How to print out string encoded data that contains nul characters?

[John Dill]

I have several character data fields that happen to contain sections of 
non-ascii binary data including nul characters.  I'd like to get a string 
display that shows all of the characters according to the length of the field, 
i.e.

20 20 20 20 20 20 01 00 01 00 48 31 20 20 20 20 

produces

  \001\000\001\000H1

In proto.c, I see that all of the format_text calls use strlen(bytes) as the 
length.

case FT_STRING:
case FT_STRINGZ:
case FT_UINT_STRING:
bytes = (guint8 *)fvalue_get(fi-value);
label_fill(label_str, hfinfo, format_text(bytes, strlen(bytes)));

What is the recommended way of creating a text string that uses the octal 
encoding '\xxx' for non-ASCII data including nul characters that uses the 
'length' field of 'proto_tree_add_item'?  I'm currently using FT_STRING, but 
obviously the string label ends at the first nul character.  I do not want 
FT_BYTES because the characters themselves are the important data in the field.

Thanks,
John Dill
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Header field with scaling factor/units?

[John Dill]

Message: 5
Date: Wed, 9 Apr 2014 20:17:51 +0200
From: Pascal Quantin pascal.quan...@gmail.com
To: Developer support list for Wireshark wireshark-dev@wireshark.org
Subject: Re: [Wireshark-dev] Header field with scaling factor/units?
Message-ID:
   cagka-82kzagng1doy3emteyvdrvscbcijwbparzpcjccuqw...@mail.gmail.com
Content-Type: text/plain; charset=iso-8859-1

[snip]

Hi John,

This is the kind of use case where I personally use BASE_CUSTOM (see
explained in doc/README.dissector for details).

Pascal,

I did a quick grep of BASE_CUSTOM and it appears that the amount of use is not 
very large in the current 'dissectors' folder.  If there were a small number of 
fields, that would probably be my choice as well.

The problem is that the scheme in my opinion doesn't scale well.  As the number 
of BASE_CUSTOM elements grows, the amount of maintenance to keep each and every 
field's separate display routine in sync becomes problematic (particularly for 
internal test and source code review).  Each function has custom code to read 
the integer from the buffer, apply some bitmask, apply a scale factor, and 
display the string with any attached units.  That means that the components 
that go into maintaining a header field need to look at its entry in the 
hf_register_info array, the subdissector function that processes the 
application-layer message, and now a separate display function for each header 
field, where there can be dozens of these scaling factor fields per message.

I see enough similarity that a structured method of encoding this mechanism 
should be feasible.  In my project, I've created an XML database of each data 
element/header field by message.  I've structured it in such a way that my 
group can translate an XML tag (based on the nomenclature used in the 
documentation) into a header_field entry for Wireshark for many of the basic 
field types.  If I can inject the architecture needed to handle integers with 
scaling factors into Wireshark using a method through the header_field, I 
believe that I can reduce the complexity of code generation of the protocol 
dissector (at the cost of increasing the complexity to adapt the Wireshark 
application for this use case).

I have no intention of trying to push any change of this magnitude on to 
mainline Wireshark source tree, but it's a common enough use case that it's 
worth it for me to try to investigate possible methods to develop it and 
possibly integrate it into the Wireshark protocol dissection api.

I would actually use BASE_CUSTOM for those fields that need to be assembled 
from separate words where each component has it's own bitmask.  For example, 
radio frequencies are often encoded as digits, but each of the digits may use 
1-4 bits, and there may be implicit offsets and different scaling factors for 
each component in the data in the calculation itself, like adding an implicit 
100 MHz to the frequency (as there is no 100 MHz digit to begin with).

Best regards,
John Dill

Regards,
Pascal.

winmail.dat___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] overriding dissector for port 8080

[John Dill]

Message: 4
Date: Thu, 03 Apr 2014 16:14:53 -0400
From: Jeff Morriss jeff.morriss...@gmail.com
To: Developer support list for Wireshark wireshark-dev@wireshark.org
Subject: Re: [Wireshark-dev] overriding dissector for port 8080
Message-ID: 533dc13d.8010...@gmail.com
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

On 04/03/14 10:26, John Dill wrote:

 I have network traffic that uses TCP port 8080 for sending non-http data
 (on a private network with its own custom application layer on top of
 TCP an UDP).  Is there a recommendation for how to override or remove
 this dissector?  I still have port 80 for http traffic.

 I can remove port 8080 from the default http dissector TCP port options,
 and strip 'http-alt' out of services (to be replaced with a different
 well-known service name).  Is there anything else?

You don't have to change the services file unless you don't want to see 
port 8080 translated into http-alt in Wireshark.

Yeah, the avionics network architecture defines its own Well Known Services
for several TCP and UDP ports, so I'd have to eventually create a custom
'services' file to document all the ports.

Removing port 8080 from the HTTP dissector's preference is probably the 
best way.  If you have a custom dissector for your protocol, registering 
it for port 8080 *might* override the HTTP dissector but it's not 
guaranteed (last I checked).  As Alexis mentioned Decode-As would 
override it.

Unfortunately, I do not have the TCP dissector component working yet (the
message structure has to be somewhat reverse engineered), so I'll have to
try that out when I get it working.

 I also noticed a disabled_protos.[ch], so maybe there is a feature to
 disable other protocols.  Is there a feature that could be used to hide
 protocols I don't need in the Filter Expression (to reduce the list to
 simplify the interface to users)?

No, I don't think there's a way to simplify what's in the Filter 
Expression dialog short of removing dissectors from Wireshark (probably 
more effort than it's worth).

The only reason would be to simplify the interface for test engineers who
like to streamline their process (it would remove the need to constantly
type the protocol abbreviation).  It would happen at the end of the
development cycle if at all.

Thank you (and to Alexis) for your feedback.
John Dill

winmail.dat___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] overriding dissector for port 8080

[John Dill]

Message: 2
Date: Fri, 4 Apr 2014 10:19:52 -0400
From: Hadriel Kaplan hadriel.kap...@oracle.com
To: Developer support list for Wireshark wireshark-dev@wireshark.org
Subject: Re: [Wireshark-dev] overriding dissector for port 8080
Message-ID: d1433e77-410e-44ed-9cb6-2cd341618...@oracle.com
Content-Type: text/plain; charset=windows-1252

On Apr 4, 2014, at 9:56 AM, John Dill john.d...@greenfieldeng.com wrote:

 I also noticed a disabled_protos.[ch], so maybe there is a feature to
 disable other protocols.  Is there a feature that could be used to hide
 protocols I don't need in the Filter Expression (to reduce the list to
 simplify the interface to users)?

 No, I don't think there's a way to simplify what's in the Filter
 Expression dialog short of removing dissectors from Wireshark (probably
 more effort than it's worth).

 The only reason would be to simplify the interface for test engineers who
 like to streamline their process (it would remove the need to constantly
 type the protocol abbreviation).  It would happen at the end of the
 development cycle if at all.

Can?t you just create some filter macros [1] to do that for you?

[1] 
http://www.wireshark.org/docs/wsug_html_chunked/ChDisplayFilterMacrosSection.html

That would work well for filter expressions that different test engineers
would commonly use.  However, there are hundreds of messages each ranging
from one to several hundred data elements that engineers would have to
browse to build their own expressions to begin with, and it really depends
on the types of tests they are doing, or troubleshooting new problems.
The Filter Expression dialog is the best place in Wireshark to locate the
data elements they are looking for, so it was mentioned as a nice to have.

Since often times the test engineers (or really anyone) do not have
intimate knowledge of all the message traffic and memory of its exact
contents (unless you can memorize several thousand pages of reference
documents), much of the browsing happens in the Filter Expression dialog.

Best regards,
John Dill
winmail.dat___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] overriding dissector for port 8080

[John Dill]

Message: 2
Date: Fri, 4 Apr 2014 10:59:18 -0400
From: Hadriel Kaplan hadriel.kap...@oracle.com
To: Developer support list for Wireshark wireshark-dev@wireshark.org
Subject: Re: [Wireshark-dev] overriding dissector for port 8080
Message-ID: 225ee544-6929-4484-a8c2-2260be860...@oracle.com
Content-Type: text/plain; charset=windows-1252

 On Apr 4, 2014, at 10:43 AM, John Dill john.d...@greenfieldeng.com wrote:

 The Filter Expression dialog is the best place in Wireshark to locate the
 data elements they are looking for, so it was mentioned as a nice to have?.

Oh well if it?s just the dialog, why not just disable the other protocols?
Go to menu Analyze-Enabled Protocols, and disable all and then select the
ones you want enabled.  Only the enabled ones show up in the Filter
Expression dialog, I believe.

That'll work!  Thanks :-)
winmail.dat___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

[Wireshark-dev] overriding dissector for port 8080

[John Dill]

I have network traffic that uses TCP port 8080 for sending non-http data (on a 
private network with its own custom application layer on top of TCP an UDP).  
Is there a recommendation for how to override or remove this dissector?  I 
still have port 80 for http traffic.

I can remove port 8080 from the default http dissector TCP port options, and 
strip 'http-alt' out of services (to be replaced with a different well-known 
service name).  Is there anything else?

I also noticed a disabled_protos.[ch], so maybe there is a feature to disable 
other protocols.  Is there a feature that could be used to hide protocols I 
don't need in the Filter Expression (to reduce the list to simplify the 
interface to users)?

Thanks,
John Dill
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] displaying header field without filtering

[John Dill]

Message: 1
Date: Fri, 21 Feb 2014 11:42:33 -0800
From: Guy Harris g...@alum.mit.edu
To: Developer support list for Wireshark wireshark-dev@wireshark.org
Subject: Re: [Wireshark-dev] displaying header field without filtering
Message-ID: aa970ebd-3c3b-4f05-8996-31ce6319f...@alum.mit.edu
Content-Type: text/plain; charset=iso-8859-1


On Feb 21, 2014, at 8:15 AM, John Dill john.d...@greenfieldeng.com wrote:

 From the topic discussion, I got the impression that not
 putting hf_register_info entries for Spare or Reserved fields
 was considered bad practice.

Some might consider it bad practice; I don't.

The only advantage to having it be a named field would be to be able
to filter for a specific value for the field, or to check whether it's
non-zero.

I'm not sure there's any point in filtering for specific values.

There might be some use for checking for non-zero values *if* the
spare bits are supposed to be zero; that's why I suggested
proto_tree_add_mbz(), if, for a given collection of spare bits,
those bits Must Be Zero.

What *is* bad practice is using proto_tree_add_text() for an actual
data value, as it can't be used to filter the display, can't be used
in find packet, can't be used to control the color of the packet,
can't be used as a custom column, can't be dumped with -T fields, etc..

I think we should add replacements for all the use cases of
proto_tree_add_text() except for this is an actual data value, but
I don't want to add a named field for it - it shouldn't be up to
the dissector author to decide what fields the user should, and
shouldn't, be able to refer to by name.

proto_tree_add_spare() and proto_tree_add_mbz() replaces the these
are spare bits and we want to have a protocol tree item for it use
case of proto_tree_add_text().

Sounds reasonable to me.

Best regards,
John Dill
winmail.dat___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] displaying header field without filtering

[John Dill]

Message: 5
Date: Thu, 20 Feb 2014 12:33:04 -0800
From: Guy Harris g...@alum.mit.edu
To: Developer support list for Wireshark wireshark-dev@wireshark.org
Subject: Re: [Wireshark-dev] displaying header field without filtering
Message-ID: d47d871e-c44b-4644-9af9-9009055dc...@alum.mit.edu
Content-Type: text/plain; charset=iso-8859-1


On Feb 20, 2014, at 8:12 AM, John Dill john.d...@greenfieldeng.com wrote:

 On 19 Feb 2014, Guy Harris g...@alum.mit.edu wrote:
 
 If it's deemed too-inconvenient to require that all spare
 fields/padding/etc. be given some named field or fields, perhaps
 we should have a
 
 proto_tree_add_spare(tree, tvb, offset, len);
 
 API, perhaps with a global preference item to indicate whether those
 fields should be displayed in the protocol tree or not; if displayed,
 they'll be shown as the raw hex data.
 
 An additional API might be
 
 proto_tree_add_mbz(tree, tvb, offset, len);
 
 which is similar, but doesn't display the value unless it's non-zero,
 *and* adds an expert info item if it's non-zero.
 
 Those functions sound very reasonable for controlling the display of
 spare bytes, but I'm also greedy enough to want some way to kick these
 Spare and Reserved header_field_info structures out of the Filter
 Expression dialog.

In what fashion would those functions not achieve that goal?

Before giving my answer, let me explain in more detail what my
thought process is.  It's a bit long, so I apologize I couldn't
make it shorter.  I'm also using 1.10.3 (it's annoying to get
new versions of software installed on my workstation), so if
there is an important behavioral change downstream, I probably
missed it.

Based on my coding tests, here is what I've observed in these given
scenarios.  Let me start with the original setup.  'proto' is a
placeholder for the moment.

\code snippet
/* msg: Status */
{
  hf_Status_LRU,
  {
LRU,
proto.Status.LRU,
FT_UINT8,
BASE_DEC,
VALS(proto_Status_LRU_enum_vals),
0x0,
Line Replaceable Unit,
HFILL
  }
},
{
  hf_Status_Spare,
  {
Spare,
proto.Status.Spare,
FT_UINT8,
BASE_HEX,
NULL,
0x0,
NULL,
HFILL
  }
},
{
  hf_Status_Status,
  {
Status,
proto.Status.Status,
FT_UINT16,
BASE_DEC,
VALS(proto_Status_Status_enum_vals),
0x0,
LRU Status,
HFILL
  }
}

...

void
dissect_msg_Status(tvbuff_t *tvb, gint offset, proto_tree *tree)
{
  proto_tree_add_item(tree, hf_Status_LRU, tvb, offset, 1, ENC_BIG_ENDIAN);
  proto_tree_add_item(tree, hf_Status_Spare, tvb, offset + 1, 1, 
ENC_BIG_ENDIAN);
  proto_tree_add_item(tree, hf_Status_Status, tvb, offset + 2, 2, 
ENC_BIG_ENDIAN);
}
\endcode

The observed behavior is the following:

In the Packet Details pane, I see populated in a subtree

LRU: Hf_9087D (117)
Spare: 0x00
Status: Failed (0)

In the Filter Expression dialog, I see entries for

proto.Status.LRU
proto.Status.Spare
proto.Status.Status

The desired requirement is to provide an option to display or not
display 'Spare: 0x00' in the Packet Details based on a preference, but
to not populate 'proto.Status.Spare' in the Filter Expression dialog.

In my effort to satisfy this requirement, I attempted the following
implementation.

\code snippet
/* msg: Status */
{
  hf_Status_LRU,
  {
LRU,
proto.Status.LRU,
FT_UINT8,
BASE_DEC,
VALS(proto_Status_LRU_enum_vals),
0x0,
Line Replaceable Unit,
HFILL
  }
},
{
  hf_Status_Status,
  {
Status,
proto.Status.Status,
FT_UINT16,
BASE_DEC,
VALS(proto_Status_Status_enum_vals),
0x0,
LRU Status,
HFILL
  }
}

...

void
dissect_msg_Status(tvbuff_t *tvb, gint offset, proto_tree *tree)
{
  proto_tree_add_item(tree, hf_Status_LRU, tvb, offset, 1, ENC_BIG_ENDIAN);
  proto_tree_add_text(tree, tvb, offset + 1, 1, Spare: 0x%02x, 
tvb_get_guint8(tvb, offset + 1) );
  proto_tree_add_item(tree, hf_Status_Status, tvb, offset + 2, 2, 
ENC_BIG_ENDIAN);
}
\endcode

This accomplishes the behavior that I want, with the caveat that
I'm using an older (perhaps obsolete?) interface, in that it still
populates the Packet Details pane with:

LRU: Hf_9087D (117)
Spare: 0x00
Status: Failed (0)

but only has the following elements in the Filter Expression dialog

proto.Status.LRU
proto.Status.Status

Now, if I use the following configuration:

\code snippet
/* msg: Status */
{
  hf_Status_LRU,
  {
LRU,
proto.Status.LRU,
FT_UINT8,
BASE_DEC,
VALS(proto_Status_LRU_enum_vals),
0x0,
Line Replaceable Unit,
HFILL
  }
},
{
  hf_Status_Spare,
  {
Spare,
proto.Status.Spare

Re: [Wireshark-dev] displaying header field without filtering

[John Dill]

Message: 1
Date: Fri, 21 Feb 2014 17:22:59 +0100
From: Alexis La Goutte alexis.lagou...@gmail.com
To: Developer support list for Wireshark wireshark-dev@wireshark.org
Subject: Re: [Wireshark-dev] displaying header field without filtering
Message-ID:
   CAHzrgZ=fgn0-zckrs5_rnm_d17dlaj5_tskdtorkircmmz7...@mail.gmail.com
Content-Type: text/plain; charset=iso-8859-1

Hi,

Why don't use FT_BYTES type ?

The FT_ type used to render the Spare bytes is not the root cause
of my issue.  There are probably several methods to render Spare
bytes in the Packet Details pane using FT_BYTES or FT_UINT*.

The key point is that populating a Spare data element in hf_register_info
using a header_field_info struct forces (to the best of my
knowledge) that field to appear in the Filter Expression dialog.
For my set of requirements, they want to see the Spare bytes in the
Packet Details pane for validation, but do not want to see them in
the Filter Expression dialog, as they are not data of interest to
engineers and there are a ton of unused or Spare data elements.

I can use proto_tree_add_text to do what I need manually, but it's
not as centralized and it seems in general not recommended for new
plugin development.

Best regards,
John Dill

[snip]
winmail.dat___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] displaying header field without filtering

[John Dill]

Message: 2
Date: Wed, 19 Feb 2014 19:03:57 -0500
From: Evan Huus eapa...@gmail.com
To: Developer support list for Wireshark wireshark-dev@wireshark.org
Subject: Re: [Wireshark-dev] displaying header field without filtering
Message-ID:
   CAOYNdEKR4BVCBfmFG8a2=98U1CCXyCzT5j=z10pdrea4csb...@mail.gmail.com
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Feb 19, 2014 at 5:57 PM, John Dill john.d...@greenfieldeng.com wrote:
Message: 6
 Date: Wed, 19 Feb 2014 17:24:11 -0500
 From: Evan Huus eapa...@gmail.com
 To: Developer support list for Wireshark wireshark-dev@wireshark.org
 Subject: Re: [Wireshark-dev] displaying header field without filtering
 capability
 Message-ID:
 
 CAOYNdEKkYZmjZUZ28tjJdgKnO+_qvEu2YYMOCXmAPZhHbBKO=a...@mail.gmail.com
 Content-Type: text/plain; charset=ISO-8859-1

 You could use proto_tree_add_text but that is strongly recommended
 against. Why do you want to explicitly disallow filtering?

 Because there are several dozen messages (in the first subset I'm
 working on, there are several hundred messages total) with any
 number of arbitrary placed Spare bytes to make some data elements
 in these messages aligned at multiples of 4, and these Spare
 entries would clog up a decent amount of space in the filter
 expression dialog.

You can reuse a single spare field for all of these bytes, and they
would only cause a single entry in the filter expression dialog. I
suspect this is the best answer.

This could be feasible.  Unfortunately, the naming convention for these
spare bytes are mixed since these message groups were developed across
several teams and there was no cross-team standardization.  What this
means is that there are several naming conventions for Spare bytes.

Spare, Spare1, Spare2, ...
Filler_1, Filler_2, ...
Not_Used, Not_Used2, ...
Pad, Pad2, Pad3, ...
Pad_1, Pad_2, Pad_3, ...

Some of these fields are 1 or 2 bytes in length, which means that in
message 'A', Spare is 1 byte, but in message 'B' Spare is 2 bytes.

On top of this, there are also reserved fields which are applicable
for some M out of N platforms depending on installed avionics, so
having the ability to disable the filtering of these data elements
for different configurations would be very useful.  At the moment
I'm working on one platform, but this could eventually extend to
several platforms with potentially multiple configurations as they
get upgrades over time.  As such, I currently use something like
protocol.message.data_element for the 'abbrev' member of
'struct header_field_info'.  Eventually, these header_field_info
structures will be code generated.

To give a little more perspective, my audience for using the Wireshark
tool are not network protocol experts.  They are not even familiar with
the data that is in these messages.  They are test engineers that want
to load a capture file, browse through what data is available (I'm
using the Filter Expression dialog as that location), and then search
or filter based on that data displayed in human readable text (for
enums/booleans) or integer/floating point data converted to engineering
units.

Seeing all the Spare elements in the packets is important for the
validation part of the project.  When the dissector plugin has been
deployed, the test engineers want the option to not see Spare or
Reserved data elements to reduce noise and the potential for
confusion if one happens to pick a Reserved data element.

[snip]

 proto_tree_add_text(tree, tvb, offset + 1, 1, Spare: 0x%02x, 
 tvb_get_guint8(tvb, offset + 1));

 Can you explain in more detail why this is strongly recommended against?

It was at one point (long ago before wireshark had filtering) the
default API, so it is in a lot of old code. People often use it by
mistake when they *want* filterable items. It's also not quite as
abstract, since the data must be fetched separately, and the offset
must be specified twice.

Thanks for the history.

Message: 3
Date: Wed, 19 Feb 2014 16:45:25 -0800
From: Guy Harris g...@alum.mit.edu
To: Developer support list for Wireshark wireshark-dev@wireshark.org
Subject: Re: [Wireshark-dev] displaying header field without filtering
Message-ID: df61d62c-1157-4cb2-ba03-8121c4dea...@alum.mit.edu
Content-Type: text/plain; charset=us-ascii

On Feb 19, 2014, at 4:03 PM, Evan Huus eapa...@gmail.com wrote:

 It was at one point (long ago before wireshark had filtering) the
 default API, so it is in a lot of old code. People often use it by
 mistake when they *want* filterable items. It's also not quite as
 abstract, since the data must be fetched separately, and the offset
 must be specified twice.

 If it's deemed too-inconvenient to require that all spare
 fields/padding/etc. be given some named field or fields, perhaps
 we should have a

   proto_tree_add_spare(tree, tvb, offset, len);

 API, perhaps with a global preference item to indicate whether those
 fields should be displayed in the protocol tree or not; if displayed,
 they'll be shown

[Wireshark-dev] displaying header field without filtering capability

[John Dill]

I'm trying to add a header field for spare bytes in a custom dissector.

Currently, I'm creating a header field for a 'Spare' data element in a 'Status' 
message, as shown in the example below:

\code snippet
{
  hf_Spare,
  {
Spare,
msg.Status.Spare,
FT_UINT8,
BASE_HEX,
NULL,
0x0,
Spare,
HFILL
  }
},
\endcode

Later I have a function that processes the 'Status' message components.

void dissect_message_Status(tvbuff_t* tvb, gint offset, proto_tree *tree)
{
  proto_tree_add_item(tree, hf_Field1, tvb, offset, 1, ENC_BIG_ENDIAN);
  proto_tree_add_item(tree, hf_Spare,  tvb, offset + 1, 1, ENC_BIG_ENDIAN);
  proto_tree_add_item(tree, hf_Field2, tvb, offset + 2, 2, ENC_BIG_ENDIAN);
}

Visually it works great in the Packet Details pane.  The issue is that I don't 
want to allow any filtering based on the 'Spare' data field when the user is 
editing a Filter Expression.

What is the recommended method to handle this scenario?  Do I need to remove 
the hf_Spare structure from the hf_register_info array and use something like 
proto_tree_add_text?  I also see something about PROTO_ITEM_SET_HIDDEN, but it 
doesn't look like it applies.

Thanks,
John Dill
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] displaying header field without filtering

[John Dill]

Message: 6
 Date: Wed, 19 Feb 2014 17:24:11 -0500
 From: Evan Huus eapa...@gmail.com
 To: Developer support list for Wireshark wireshark-dev@wireshark.org
 Subject: Re: [Wireshark-dev] displaying header field without filtering
 capability
 Message-ID:
 
 CAOYNdEKkYZmjZUZ28tjJdgKnO+_qvEu2YYMOCXmAPZhHbBKO=a...@mail.gmail.com
 Content-Type: text/plain; charset=ISO-8859-1

 You could use proto_tree_add_text but that is strongly recommended
 against. Why do you want to explicitly disallow filtering?

Because there are several dozen messages (in the first subset I'm working on, 
there are several hundred messages total) with any number of arbitrary placed 
Spare bytes to make some data elements in these messages aligned at multiples 
of 4, and these Spare entries would clog up a decent amount of space in the 
filter expression dialog.

 If the
 field is reserved and not important you could just not add any item at
 all, and skip that byte entirely...

As part of the validation process for this development effort, they want to see 
a verbatim rendering of all the data elements and padding bytes in the Packet 
Details referenced against an external standards document.  Eventually I'll 
include a preference in the plugin to visualize these Spare bytes or not.

I was able to do something like the following that seems to do what I want.

proto_tree_add_text(tree, tvb, offset + 1, 1, Spare: 0x%02x, 
tvb_get_guint8(tvb, offset + 1));

Can you explain in more detail why this is strongly recommended against?

Best regards,
John Dill

 On Wed, Feb 19, 2014 at 4:17 PM, John Dill john.d...@greenfieldeng.com 
 wrote:
 
  I'm trying to add a header field for spare bytes in a custom dissector.
 
  Currently, I'm creating a header field for a 'Spare' data element in a
  'Status' message, as shown in the example below:
 
  \code snippet
  {
hf_Spare,
{
  Spare,
  msg.Status.Spare,
  FT_UINT8,
  BASE_HEX,
  NULL,
  0x0,
  Spare,
  HFILL
}
  },
  \endcode
 
  Later I have a function that processes the 'Status' message components.
 
  void dissect_message_Status(tvbuff_t* tvb, gint offset, proto_tree *tree)
  {
proto_tree_add_item(tree, hf_Field1, tvb, offset, 1, ENC_BIG_ENDIAN);
proto_tree_add_item(tree, hf_Spare,  tvb, offset + 1, 1, ENC_BIG_ENDIAN);
proto_tree_add_item(tree, hf_Field2, tvb, offset + 2, 2, ENC_BIG_ENDIAN);
  }
 
  Visually it works great in the Packet Details pane.  The issue is that I
  don't want to allow any filtering based on the 'Spare' data field when the
  user is editing a Filter Expression.
 
  What is the recommended method to handle this scenario?  Do I need to remove
  the hf_Spare structure from the hf_register_info array and use something
  like proto_tree_add_text?  I also see something about PROTO_ITEM_SET_HIDDEN,
  but it doesn't look like it applies.
 
  Thanks,
  John Dill
winmail.dat___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

[Wireshark-dev] Adding install target to Makefile.nmake for plugins

[John Dill]

I added an install target for my protocol dissector plugin nmake file.  
Simplifies the tedious step of copying it to the Wireshark/plugins folder 
during development and test.  Here's the snippets that I added.

---
INSTALL_ROOT=$(PROGRAMFILES)\Wireshark\plugins
WIRESHARK_VER=1.10.3
!IF EXIST($(INSTALL_ROOT)\$(WIRESHARK_VER))
INSTALL_DIR=$(INSTALL_ROOT)\$(WIRESHARK_VER)
!ENDIF

...

!IF EXIST($(INSTALL_ROOT))
!  IF EXIST($(INSTALL_DIR))
install:
@echo Copying $(PLUGIN_NAME).dll to $(INSTALL_DIR)
xcopy /dy $(PLUGIN_NAME).dll $(INSTALL_DIR)
!  ELSE
install:
@echo Copying $(PLUGIN_NAME).dll to $(INSTALL_ROOT)\$(WIRESHARK_VER)
@echo ERROR: Wireshark version not found!  Check WIRESHARK_VER in 
Makefile.nmake
!  ENDIF
!ELSE
install:
@echo ERROR: Wireshark not installed!
!ENDIF
---

There is probably a smarter way to detect the version folder, but I didn't 
bother to go down that path.

Best regards,
John Dill
winmail.dat___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Adding install target to Makefile.nmake

[John Dill]

Message: 4
 Date: Wed, 13 Nov 2013 13:44:15 -0500
 From: John Dill john.d...@greenfieldeng.com
 To: wireshark-dev@wireshark.org
 Subject: Re: [Wireshark-dev] Adding install target to Makefile.nmake
 Message-ID:
 
 CD873D5C230AC04B9F3C4934376CEDDC2AA26B@green-5.greenfieldengineering.local

 Content-Type: text/plain; charset=iso-8859-1

 Message: 3
  Date: Wed, 13 Nov 2013 16:12:09 +
  From: Graham Bloice graham.blo...@trihedral.com
  To: Developer support list for Wireshark wireshark-dev@wireshark.org
  Subject: Re: [Wireshark-dev] Adding install target to Makefile.nmake
  for plugins
  Message-ID:
  CALcKHKottGppUR_v5U5JqA_d2d7ovooPr1Co_Ba0=ub3res...@mail.gmail.com
  Content-Type: text/plain; charset=iso-8859-1
 
  On 13 November 2013 16:01, John Dill john.d...@greenfieldeng.com wrote:
 
  
   I added an install target for my protocol dissector plugin nmake file.
Simplifies the tedious step of copying it to the Wireshark/plugins folder
   during development and test.  Here's the snippets that I added.
  
  
  
  The nmake build already copies all needed files to a directory so that the
  build artifacts can be run for testing.  The directory is set in
  config.nmake as INSTALL_DIR.  Is there a reason why that directory isn't
  suitable for your tests, it's always sufficed for mine?

 Probably because I didn't come across README.plugins yet... :-O

I made an update to my Makefile.nmake that adds install targets that should 
hopefully not clash with the Wireshark build system that seems to do most of 
what I need without integrating my plugin into the permanent group of plugins.

Someone may find it useful if they are in a similar situation.

---
!IF EXIST(..\..\$(INSTALL_DIR))
INSTALL_PLUGIN_DIR=$(INSTALL_DIR)\plugins\$(VERSION)
!ENDIF

INSTALL_APP_ROOT=$(PROGRAM_FILES)\$(PROGRAM_NAME)
WIRESHARK_APP_VER=1.10.3
!IF EXIST($(INSTALL_APP_ROOT)\plugins\$(WIRESHARK_APP_VER))
INSTALL_APP_DIR=$(INSTALL_APP_ROOT)\plugins\$(WIRESHARK_APP_VER)
!ENDIF

...

!IF EXIST(..\..\$(INSTALL_PLUGIN_DIR))
install:
@echo Copying $(PLUGIN_NAME).dll to $(INSTALL_PLUGIN_DIR)
xcopy /dy $(PLUGIN_NAME).dll ..\..\$(INSTALL_PLUGIN_DIR)
!ELSE
install:
@echo Copying $(PLUGIN_NAME).dll to $(INSTALL_DIR)\plugins\$(VERSION)
@echo ERROR: Wireshark plugin directory not found!  Try building 
Wireshark first.
!ENDIF

!IF EXIST($(INSTALL_APP_ROOT))
!  IF EXIST($(INSTALL_APP_DIR))
install-app:
@echo Copying $(PLUGIN_NAME).dll to $(INSTALL_APP_DIR)
xcopy /dy $(PLUGIN_NAME).dll $(INSTALL_APP_DIR)
!  ELSE
install-app:
@echo Copying $(PLUGIN_NAME).dll to 
$(INSTALL_APP_ROOT)\plugins\$(WIRESHARK_APP_VER)
@echo ERROR: Wireshark version $(WIRESHARK_APP_VER) not found!  Check 
WIRESHARK_APP_VER in Makefile.nmake
!  ENDIF
!ELSE
install-app:
@echo ERROR: Wireshark not installed!
!ENDIF
---

'nmake -f Makefile.nmake install' should copy the plugin dll to the appropriate 
plugins subdirectory in the Wireshark source tree (i.e. 
wireshark-gtk2\plugins\1.10.x).

'nmake -f Makefile.nmake install-app' should copy the plugin dll to the plugins 
folder of an Windows installed release of Wireshark.

Then, when it comes to the point that the plugin is ready for distribution, I 
can follow the procedure set in section 3.1 of README.plugins.

Best regards,
John D.
winmail.dat___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Wireshark development setup Help

[John Dill]

Message: 6
Date: Fri, 8 Nov 2013 23:14:28 +0530
From: Sreejith M M sreejith...@gmail.com
To: wireshark-dev@wireshark.org
Subject: [Wireshark-dev] Wireshark development setup Help
Message-ID:
caedt3utxa4gqx9x5hnbfmvhrvm42-m_c_67-kf6jzcmujme...@mail.gmail.com
Content-Type: text/plain; charset=iso-8859-1

I am trying to make a new dissector for wireshark. As part of this, I am
following wireshark doc to setup tools and source code .

I have a 32 bit windows 7
I followed below steps as shown in the
http://www.wireshark.org/docs/wsdg_html_chunked/ChSetupWin32.html page



   1.

   C compiler: 
 Downloadhttp://www.microsoft.com/visualstudio/eng/downloads#d-2010-expressand
install Microsoft Visual C++ 2010 Express Edition. (This is a very
   large download.)
   2.

   C compiler service pack:
Downloadhttp://www.microsoft.com/en-us/download/details.aspx?id=23691and
install Microsoft Visual Studio 2010 Service Pack 1. (This is a very
   large download.)
   3. Install Cygwin
   4. Install python
   5. Install TortoiseSVN
   6. edit config.nmake

After this I am not able to find

*C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\SetEnv.Cmd*

*or*


vcvarsall.bat or vcvars32.bat


One thing is that , I am not having v7.1 ,rather v7.0A. But I am suprised
that this folder doesnt have any of the above 3 files.


Please help to proceed

I ran into the same problem, where I realized that I needed the Windows SDK to 
do the actual build in Windows 7 32-bit.

The problem was that my development install was broken where I could not 
properly install the Windows SDK (step 2) if I already installed the C compiler 
service pack (step 4).  I would uninstall whatever you have done in section 
2.2.1, and reinstall *all* those components in order from steps 1 through 4.  
Unfortunately, I had to re-image my Windows installation before I could get the 
Wireshark build process to work because the uninstall broke the registry to the 
point that I couldn't get Windows SDK to re-install properly.  Starting over, I 
could get the Wireshark installation to work if I ran each step without 
skipping steps 2 or 4, this time installing the Windows SDK even though I was 
on a 32-bit Windows 7 computer.

I would consider removing the if you want to build 64-bit binaries for Windows 
7 text simply because it can give people the impression that you don't need to 
install it if you have Windows 7 32-bit.  If someone has successfully built 
Wireshark for Windows 7 32-bit skipping steps 2 and 4 of section 2.2.1, then I 
must have a misunderstanding somewhere.

Hope it helps!
John D.
winmail.dat___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] adding IRIG time and time of day

[John Dill]

Message: 1
Date: Wed, 6 Nov 2013 13:12:04 -0800
From: Guy Harris g...@alum.mit.edu
To: Developer support list for Wireshark wireshark-dev@wireshark.org
Subject: Re: [Wireshark-dev] adding IRIG time and time of day
Message-ID: a4378249-6d30-404f-8123-2fe8b845c...@alum.mit.edu
Content-Type: text/plain; charset=iso-8859-1


On Nov 5, 2013, at 3:22 PM, John Dill john.d...@greenfieldeng.com wrote:

 They provided a set of sample driver programs that used the board's internal 
 clock to timestamp packets, starting from 0. There was no sample (back 
 then, there may be now) that demonstrated how to use the IRIG time signal 
 from the board to synchronize the packet stream, or to populate the packet 
 time with an Unix epoch timestamp (their API did at least document how to 
 query the board for an IRIG time in seconds).

So they didn't provide code to even time stamp packets with IRIG-derived time 
stamps, much less with Unix-epoch time stamps?

Correct.

 Condor Engineering (bought by GE) also provided a modified version of 
 Ethereal (or Wireshark) that attempts to handle some of the extensions 
 that AFDX provided in a different graphical representation. It was difficult 
 to understand and impractical to use for our needs.

Could you get the source code to their modifications? (If not, they've 
violated the GPL, and lawyers can be sent after them to force them to provide 
the source code.) That might be interesting.

They provide three headers: cpcap.h, CnicStructures.h, and version.h, and a 
library that you link against.  The version that I have have a copyright 
license from Condor Engineering.  From the look of the header file, most of the 
interface does not mimic pcap per se except for the pcap_compile related stuff. 
 The source code never came with the distribution, and I never bothered to ask 
for it, so it's unclear how much is a wrapper around pcap and what's not.

 The other data streams (ARINC-429 and MIL-STD-1553 were timestamped using 
 IRIG-B without the year, and their BusTools applications that provided 
 graphical introspection of the data did not support Unix Epoch time format 
 as an option. I decided to synchronize the packet stream to the IRIG-B so 
 that all three bus modalities were synchronized to that same format. At 
 that time, I was not very familiar with the pcap-ng standard and made that 
 decision based on my group's local needs.

OK, so it sounds as if you had to (as per the first paragraph above) write 
your own code to combine the board's internal clock value and the IRIG time 
value somehow to generate a fractions of a second since the beginning of the 
current year time stamp for packets. Combining that with the current year 
would have been preferable, but what's done is done.

That's correct.

 I'm not sure if there's a good way to resolve the issue. Changing the 
 MIL-STD-1553 and ARINC-429 timestamps to Unix Epoch would break their 
 compatibility with the GE tools, and we'd have to adapt our other software 
 tools to handle mixed time formats. There's several years worth of data that 
 may or may not be politcally difficult to justify retroactively applying 
 the Unix epoch just to make the capture files standard compliant.

So, *IF* you know what year a capture was started, you could convert the time 
stamps in libwireshark, and present seconds-and-nanoseconds-since-the-Epoch 
time stamps to Wireshark/TShark/etc., as those programs expect.

I can find the year based on either the last modification timestamp of in the 
file's properties, or using the date substring in the packet dump filename as 
well.  The packet dump files all have an automatically generated filename with 
a standard naming convention.  I suppose it's possible to analyze the filename 
format on Open and branch into a special case that resolves the time difference 
(in a patch I'd maintain).

If you know what year a given capture was started, one option might be to:

add a special API to libwireshark to specify a starting year for an open 
capture file (zero would mean this file has valid time stamps, no conversion 
is necessary);

have the pcap-ng reader use that information to convert 
fractions-of-a-second-since-the-beginning-of-the-year to 
seconds-and-nanoseconds-since-the-Epoch (doing this means keeping a table of 
frame offsets in the file and time offsets, so that random access works, and 
watching for a wrap-around in the time stamps and treating that as a switch 
to a new year, unless you don't need to support captures that start on or 
before December 31 and end on or after January 1 of the next year);

use the current trunk version of Wireshark, which has an option to display 
time stamps as /DOY HH:MM:SS, or apply the change for that:

http://anonsvn.wireshark.org/viewvc?revision=53114view=revision 
https://www.greenfieldeng.com/exchweb/bin/redir.asp?URL=http://anonsvn.wireshark.org/viewvc?revision=53114%26view=revision
 

to your version (not all of the changes are necessary

Re: [Wireshark-dev] adding IRIG time and time of day

[John Dill]

Message: 1
Date: Mon, 4 Nov 2013 18:42:57 -0800
From: Guy Harris g...@alum.mit.edu
To: Developer support list for Wireshark wireshark-dev@wireshark.org
Subject: Re: [Wireshark-dev] adding IRIG time and time of day
Message-ID: 887bd778-62a3-48c6-8f7e-3358b064d...@alum.mit.edu
Content-Type: text/plain; charset=iso-8859-1


On Nov 1, 2013, at 1:39 PM, John Dill john.d...@greenfieldeng.com wrote:

 The timestamp is populated with a time of day starting with day 1 as Jan 1 
 12:00:00am and wraps around at either day 365 or 366 which corresponds to 
 Dec 31, 11:59:59pm. One slight issue is that the IRIG time does not 
 capture the year,

According to IRIG Standard 200-04 IRIG SERIAL TIME CODE FORMATS:

https://wsmrc2vger.wsmr.army.mil/rcc/manuals/200-04/TT-45.pdf 
https://www.greenfieldeng.com/exchweb/bin/redir.asp?URL=https://wsmrc2vger.wsmr.army.mil/rcc/manuals/200-04/TT-45.pdf
 

IRIG Standard 200-98 was last updated in May 1998 and defined the 
characteristics of the serial time codes A, B, D, E, G, and H This 2004 
edition of the Standard incorporates year information for codes A, B, E, and 
G. Codes D and H remain unchanged.

So which IRIG time stamp are we talking about, and are we talking about the 
1998 edition, in which there's apparently no year information, or the 2004 
edition, in which there is year information?
 
The IRIG Time Code Generator used is from ITS (GPS/IRIG B Time Code 
Generator/Reader, Model 6115G), and it outputs an IRIG-B time code signal which 
does not have the year embedded in it, so it's pre-2004 standard.

 so some method will be needed to specify whether the date the leap year. I 
 could use a heuristic like the date from the file, or use Ctrl + Alt + 8 
 to cycle between leap year and non-leap year displays.
 
 The data is not collected from Wireshark directly, but from an external 
 board that uses a modified pcap driver (cpcap) that I use to stream 
 collected packets to file.

So are we talking about a board such as

http://defense.ge-ip.com/products/cnic-a2pu4/p3437 
https://www.greenfieldeng.com/exchweb/bin/redir.asp?URL=http://defense.ge-ip.com/products/cnic-a2pu4/p3437
 

for which that page says An IRIG-B receiver/generator is included for 
synchronization to external IRIG-B time sources and for synchronizing 
multiple CNIC-A boards.

We have a CNIC-A2P3 board installed in a Compact PCI chassis.
 
http://defense.ge-ip.com/products/cnic-a2p3/p1046
 
I built the instrumentation package when it was still Condor Engineering around 
the 2007-08 timeframe.
 
Best regards,
John D.
 
winmail.dat___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] adding IRIG time and time of day

[John Dill]

Message: 2
Date: Tue, 5 Nov 2013 09:19:15 -0800
From: Guy Harris g...@alum.mit.edu
To: Developer support list for Wireshark wireshark-dev@wireshark.org
Subject: Re: [Wireshark-dev] adding IRIG time and time of day
Message-ID: c698fbe1-0808-4dfc-b85a-f5dd597f6...@alum.mit.edu
Content-Type: text/plain; charset=iso-8859-1

 We have a CNIC-A2P3 board installed in a Compact PCI chassis.

Unfortunately, GE won't let me get either the hardware manuals for their ARINC 
664 devices or the cpcap manual.

I'm guessing, perhaps incorrectly, from the pcap in cpcap, that it 
provides a libpcap-compatible API.

The folks at GE *could* have, somewhere in the path between the hardware and 
the caller of cpcap:

gotten the current year number;

calculated the number of seconds between January 1, 1970, 00:00:00 UTC and 
January 1, {current year}, 00:00:00 UTC (except for leap seconds - don't ask, 
that's why I say seconds-since-the-Epoch rather than seconds since the 
Epoch);

added that to the fractions of seconds since the beginning of the year value 
from the IRIG-synchronized counter;

when the IRIG time stamp overflows into the next year, increment the year 
number and recalculate the number of seconds since... value;

and provide *that* value as the packet time stamp (which they *especially* 
should have done if cpcap has what they intend to be a libpcap-compatible 
API!).

*Did* they do so, or do they just provide a fractions of seconds since the 
beginning of the year value?

From an excerpt from their manual describing the API
The Cpcap API is a relatively high level set of functions, much like libpcap, 
with a user-friendly abstraction of the traffic source.

---

They provided a set of sample driver programs that used the board's internal 
clock to timestamp packets, starting from 0.  There was no sample (back then, 
there may be now) that demonstrated how to use the IRIG time signal from the 
board to synchronize the packet stream, or to populate the packet time with an 
Unix epoch timestamp (their API did at least document how to query the board 
for an IRIG time in seconds).

Condor Engineering (bought by GE) also provided a modified version of Ethereal 
(or Wireshark) that attempts to handle some of the extensions that AFDX 
provided in a different graphical representation.  It was difficult to 
understand and impractical to use for our needs.

The other data streams (ARINC-429 and MIL-STD-1553 were timestamped using 
IRIG-B without the year, and their BusTools applications that provided 
graphical introspection of the data did not support Unix Epoch time format as 
an option.  I decided to synchronize the packet stream to the IRIG-B so that 
all three bus modalities were synchronized to that same format.  At that time, 
I was not very familiar with the pcap-ng standard and made that decision based 
on my group's local needs.

I'm not sure if there's a good way to resolve the issue.  Changing the 
MIL-STD-1553 and ARINC-429 timestamps to Unix Epoch would break their 
compatibility with the GE tools, and we'd have to adapt our other software 
tools to handle mixed time formats.  There's several years worth of data that 
may or may not be politcally difficult to justify retroactively applying the 
Unix epoch just to make the capture files standard compliant.

It is what it is.

Best regards,

John D.

winmail.dat___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] adding IRIG time and time of day

[John Dill]

Message: 4
Date: Sat, 2 Nov 2013 19:50:58 -0700
From: Guy Harris g...@alum.mit.edu
To: Developer support list for Wireshark wireshark-dev@wireshark.org
Subject: Re: [Wireshark-dev] adding IRIG time and time of day
Message-ID: 710f03e1-ad4b-400c-9e8c-6b66cfc78...@alum.mit.edu
Content-Type: text/plain; charset=iso-8859-1


On Nov 2, 2013, at 4:36 PM, John Dill john.d...@greenfieldeng.com wrote:

 On Nov 1, 2013 at 2:18:04 PM, Guy Harris g...@alum.mit.edu wrote:

 What is the file format? Where does it store the IRIG time stamps?

 The file is NTAR (another name for pcap-ng?).

Actually, it's the name for a library that reads pcap-ng files; the official 
name for the file format is pcap-ng.

 The software stores the 64-bit IRIG timestamp in the Timestamp 
 (High)/Timestamp (Low) field of a Packet Block.

To quote the pcap-NG specification:

o Timestamp (High) and Timestamp (Low): high and low 32-bits of a 64-bit 
quantity representing the timestamp. The timestamp is a single 64-bit 
unsigned integer representing the number of units since 1/1/1970. The way to 
interpret this field is specified by the 'if_tsresol' option (see Figure 9) 
of the Interface Description block referenced by this packet. Please note 
that differently from the libpcap file format, timestamps are not saved as 
two 32-bit values accounting for the seconds and microseconds since 1/1/1970. 
They are saved as a single 64-bit quantity saved as two 32-bit words.

and therefore...

 It's injected into the packet stream from a 10-nanosecond resolution clock 
 on the capture board that is synchronized to an external IRIG-B timecode. 
 It's used to synchronize the time of the packet stream with ARINC 429 and 
 MIL-STD-1553 data streams, which are also IRIG-B time coded.

 IRIG-B is a time format that is simply a count of seconds since Jan 1 at 
 midnight UTC, not from 1970.

 +---+
 0 | Block Type = 0x0006 |
 +---+
 4 | Block Total Length |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 8 | Interface ID |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 12 | Timestamp (High) |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IRIG-B 
 Timestamp
 16 | Timestamp (Low) |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

...that's not a valid pcap-ng file.

Well, from what I've gathered on my side, it appeared that the very old AFDX 
capture files had a timestamp starting from 0 in nanoseconds, and was later 
converted to use an IRIG time to sync the same timestamp against other IRIG 
source data streams.  It also appears that the block type was not the 
'Enhanced' type with ID 6, but the Obsolete Packet Block with ID 2.  It appears 
that the hardware board and the driver never created standard legal pcap-ng 
files.

Either get a new block type value for blocks containing an IRIG-B time stamp, 
or put a fractions-of-seconds-since-the-Epoch time stamp into the packets, 
get a new option value for IRIG-B time stamps, and put those into the 
Enhanced Packet Block as an option.

I suppose that it is possible to retroactively put Unix Epoch timestamps into 
the packet stream, but the intent seems to be deliberate to keep multiple data 
streams in sync with a common timestamp (there are other external tools that 
dump the contents of the packet data payload beneath the UDP protocol layer 
with data from the other message streams, which expects a common timestamp in 
IRIG).

 Isn't the time column displayed based on the contents of Timestamp 
 (High)/Timestamp (Low)?

The time column is displayed based on the time stamp supplied by the Wiretap 
library (the library in the wiretap subdirectory).

Wiretap returns, and Wireshark and TShark expect, this time stamp to be a time 
stamp that is in the form of seconds since January 1, 1970, 00:00:00 GMT, and 
nanoseconds since that second.

The pcap-ng file reading code turns Timestamp (High) and Timestamp (Low) into 
such a value, just as the pcap code turns its time stamp (seconds since 
January 1, 1970, 00:00:00 UTC, and either microseconds or nanoseconds since 
that second, into that format, and so on.

 I figure that adding another display option should be feasible to handle 
 this special case.

No, that's not feasible, given the way Wireshark works.

To handle a time stamp that rolls over on day boundaries, the Wiretap API 
would have to be changed. There are some files that have time stamps like 
that (some of the text formats dumped out by some devices only give times, 
not dates), so that might be a useful change, but it's not a simple change.

The UI would, for files such as that, probably not offer any options to 
display the date, *and* dissectors would probably be changed to, if no 
date-and-time was available, either not do things such as calculating response 
times, or display them only if the response

Re: [Wireshark-dev] adding IRIG time and time of day

[John Dill]

Date: Fri, 1 Nov 2013 14:18:04 -0700
From: Guy Harris g...@alum.mit.edu
To: Developer support list for Wireshark wireshark-dev@wireshark.org
Subject: Re: [Wireshark-dev] adding IRIG time and time of day
Message-ID: 7d6992b1-a55a-45a6-948d-117dc8c29...@alum.mit.edu
Content-Type: text/plain; charset=iso-8859-1


On Nov 1, 2013, at 1:39 PM, John Dill john.d...@greenfieldeng.com wrote:

 I just finished installing the latest version of wireshark 1.10.2 and was 
 able to build it successfully for Windows 7 using the recommended procedure 
 in the developer's guide.
 
 One of the things that I'd like to tweak is to add an IRIG time of day to 
 the list of Time Display Formats.

Note that View - Time Display Format controls the way packet time stamps are 
displayed, so the only formats that make sense are formats where you can take 
a count of seconds and nanoseconds since January 1, 1970, 00:00:00 UTC and 
convert it to that format.  Nothing else is implementable.

If, however, the file contains IRIG time stamps *in addition to* the packet 
time stamp read by Wireshark, it might be possible to have an IRIG time stamp 
column, separate from the Time column.
 
 The issue is that my packet stream is synchronized to an IRIG time code 
 generator and would like to display the date in the following format.
 
 (day) hh:mm:ss.n
 
 The timestamp is populated with a time of day starting with day 1 as Jan 1 
 12:00:00am and wraps around at either day 365 or 366 which corresponds to 
 Dec 31, 11:59:59pm.  One slight issue is that the IRIG time does not 
 capture the year, so some method will be needed to specify whether the date 
 the leap year. I could use a heuristic like the date from the file, or use 
 Ctrl + Alt + 8 to cycle between leap year and non-leap year displays.
 
 The data is not collected from Wireshark directly, but from an external 
 board that uses a modified pcap driver (cpcap) that I use to stream 
 collected packets to file.

What is the file format?  Where does it store the IRIG time stamps?

The file is NTAR (another name for pcap-ng?).  The software stores the 64-bit 
IRIG timestamp in the Timestamp (High)/Timestamp (Low) field of a Packet Block. 
 It's injected into the packet stream from a 10-nanosecond resolution clock on 
the capture board that is synchronized to an external IRIG-B timecode.  It's 
used to synchronize the time of the packet stream with ARINC 429 and 
MIL-STD-1553 data streams, which are also IRIG-B time coded.

IRIG-B is a time format that is simply a count of seconds since Jan 1 at 
midnight UTC, not from 1970.

   +---+
 0 |Block Type = 0x0006|
   +---+
 4 |  Block Total Length   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 8 | Interface ID  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
12 |Timestamp (High)   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IRIG-B 
Timestamp
16 |Timestamp (Low)|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
20 | Captured Len  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
24 |  Packet Len   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
28 /   /
   /  Packet Data  /
   /  /* variable length, aligned to 32 bits *//
   /   /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /   /
   /  Options (variable)   /
   /   /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Block Total Length   |
   +---+

Isn't the time column displayed based on the contents of Timestamp 
(High)/Timestamp (Low)?  I figure that adding another display option should be 
feasible to handle this special case.  Everything looks fine when I use the UTC 
time without the date, but with a date it's wrong as it displays a date in 1970.

Best regards,
John D.
winmail.dat___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman

[Wireshark-dev] adding IRIG time and time of day

[John Dill]

I just finished installing the latest version of wireshark 1.10.2 and was able 
to build it successfully for Windows 7 using the recommended procedure in the 
developer's guide.
 
One of the things that I'd like to tweak is to add an IRIG time of day to the 
list of Time Display Formats.
 
View - Time Display Format - IRIG Time of Day (Ctrl + Alt + 8)
 
The issue is that my packet stream is synchronized to an IRIG time code 
generator and would like to display the date in the following format.
 
(day) hh:mm:ss.n
 
The timestamp is populated with a time of day starting with day 1 as Jan 1 
12:00:00am and wraps around at either day 365 or 366 which corresponds to Dec 
31, 11:59:59pm.  One slight issue is that the IRIG time does not capture the 
year, so some method will be needed to specify whether the date the leap year. 
I could use a heuristic like the date from the file, or use Ctrl + Alt + 8 to 
cycle between leap year and non-leap year displays.
 
The data is not collected from Wireshark directly, but from an external board 
that uses a modified pcap driver (cpcap) that I use to stream collected packets 
to file.
 
The Wireshark developer's guide recommended that I start here, so if there's 
any tips to start with, that would be great.
 
---
 
What I'm eventually after is the ability to specify an IRIG timestamp range to 
load a time slice from packet stream, as the traffic files I work with are in 
the 5-20 GB range and make it impossible to use Wireshark to inspect them 
except for a small fraction at the beginning (unless there is a method I'm not 
familiar with, as I'm not an expert at using Wireshark).  I could write an 
external tool to parse the packet block structure to create a copy of the file 
by removing any packet blocks outside the time range, but having it 
incorporated into Wireshark would make it more convenient to use.
 
I'm pretty familiar with C, somewhat familiar with the ntar file format, but 
completely new to the Wireshark development environment, so any pointers will 
be appreciated.
 
Thanks for any feedback.
 
Best regards,
John D.
 
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe