[Wireshark-dev] TCP and IP reassembling code
Hi Where can I find the TCP and IP reassembling code in Wireshark, Is that re-usable? -- Best Regards, Aaron Lewis - PGP: 0x13714D33 - http://pgp.mit.edu/ Finger Print: 9F67 391B B770 8FF6 99DC D92D 87F6 2602 1371 4D33 ___ Sent via:Wireshark-dev mailing list 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] TCP and IP reassembling code
On Apr 9, 2014, at 12:09 PM, Aaron Lewis wrote: > Hi > > Where can I find the TCP and IP reassembling code in Wireshark, epan/reassemble.h epan/reassemble.c > Is > that re-usable? Yes, it's used by a bunch of dissectors. (grep for 'reassembly_table_init') -hadriel ___ Sent via:Wireshark-dev mailing list 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] TCP and IP reassembling code
On Apr 9, 2014, at 9:26 AM, Hadriel Kaplan wrote: > On Apr 9, 2014, at 12:09 PM, Aaron Lewis wrote: > >> Hi >> >> Where can I find the TCP and IP reassembling code in Wireshark, > > epan/reassemble.h > epan/reassemble.c ...and the code that calls it in packet-ip.c, packet-ipv6.c, and packet-tcp.c. Note that TCP reassembly is more complicated. Most protocols that involve some form of fragmentation and reassembly define it at the protocol layer, so only the protocol's dissector is involved. TCP, however, has no notion of packets in the service it offers; the service it offers is a byte stream with no packet boundaries in it, so reassembly involves both TCP *and* the protocol running atop it; that protocol specifies the packet boundaries in the byte stream, and its dissector needs to tell the TCP dissector when packets begin and end. >> Is that re-usable? > > Yes, it's used by a bunch of dissectors. (grep for 'reassembly_table_init') I.e., "reusable" from within Wireshark. It wasn't designed to be extracted from Wireshark and used elsewhere, if that's the re-use you have in mind; it might be possible to do so, but it'd be significant work. ___ Sent via:Wireshark-dev mailing list 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] Header field with scaling factor/units?
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
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?
Le 9 avr. 2014 20:02, "John Dill" a écrit :
>
>
> 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
Hi John,
This is the kind of use case where I personally use BASE_CUSTOM (see
explained in doc/README.dissector for details).
Regards,
Pascal.
___
Sent via:Wireshark-dev mailing list
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?
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 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?
On Apr 9, 2014, at 2:06 PM, "John Dill" 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().
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..
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.
___
Sent via:Wireshark-dev mailing list
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?
>Message: 5 >Date: Wed, 9 Apr 2014 20:17:51 +0200 >From: Pascal Quantin >To: Developer support list for Wireshark >Subject: Re: [Wireshark-dev] Header field with scaling factor/units? >Message-ID: > >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. <>___ Sent via:Wireshark-dev mailing list 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?
On Apr 9, 2014, at 11:01 AM, "John Dill" 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 next 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
(no, that was not a randomly-chosen field example :-)). Other suggestions for
the syntax are welcome.
___
Sent via:Wireshark-dev mailing list
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] Possible change to packet-ssl.c?
Should this chunk of code:
if (tree) {
if (type && (payload_length <= record_length - 16 - 3)) {
proto_item_set_text(tree, "%s Record Layer: Heartbeat "
"%s",
val_to_str_const(*conv_version,
ssl_version_short_names, "SSL"),
type);
proto_tree_add_item(tls_heartbeat_tree,
hf_ssl_heartbeat_message_type,
tvb, offset, 1, ENC_BIG_ENDIAN);
offset += 1;
proto_tree_add_uint(tls_heartbeat_tree,
hf_ssl_heartbeat_message_payload_length,
tvb, offset, 2, payload_length);
offset += 2;
proto_tree_add_bytes_format(tls_heartbeat_tree,
hf_ssl_heartbeat_message_payload,
tvb, offset, payload_length,
NULL, "Payload (%u byte%s)",
payload_length,
plurality(payload_length, "", "s"));
offset += payload_length;
proto_tree_add_bytes_format(tls_heartbeat_tree,
hf_ssl_heartbeat_message_padding,
tvb, offset, padding_length,
NULL, "Padding and HMAC (%u byte%s)",
padding_length,
plurality(padding_length, "", "s"));
} else {
proto_item_set_text(tree,
"%s Record Layer: Encrypted Heartbeat",
val_to_str_const(*conv_version,
ssl_version_short_names, "SSL"));
proto_item_set_text(tls_heartbeat_tree,
"Encrypted Heartbeat Message");
}
}
perhaps report an expert info if the payload length is too large? Why is that
treated as a "this is encrypted" indication rather than a "somebody's trying to
extract whatever's in the server's memory after the request payload" indication?
___
Sent via:Wireshark-dev mailing list
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] Possible change to packet-ssl.c?
On Wed, Apr 9, 2014 at 7:49 PM, Guy Harris wrote:
> Should this chunk of code:
>
> if (tree) {
> if (type && (payload_length <= record_length - 16 - 3)) {
> proto_item_set_text(tree, "%s Record Layer: Heartbeat "
> "%s",
> val_to_str_const(*conv_version,
> ssl_version_short_names, "SSL"),
> type);
> proto_tree_add_item(tls_heartbeat_tree,
> hf_ssl_heartbeat_message_type,
> tvb, offset, 1, ENC_BIG_ENDIAN);
> offset += 1;
> proto_tree_add_uint(tls_heartbeat_tree,
> hf_ssl_heartbeat_message_payload_length,
> tvb, offset, 2, payload_length);
> offset += 2;
> proto_tree_add_bytes_format(tls_heartbeat_tree,
> hf_ssl_heartbeat_message_payload,
> tvb, offset, payload_length,
> NULL, "Payload (%u byte%s)",
> payload_length,
> plurality(payload_length, "", "s"));
> offset += payload_length;
> proto_tree_add_bytes_format(tls_heartbeat_tree,
> hf_ssl_heartbeat_message_padding,
> tvb, offset, padding_length,
> NULL, "Padding and HMAC (%u byte%s)",
> padding_length,
> plurality(padding_length, "", "s"));
> } else {
> proto_item_set_text(tree,
> "%s Record Layer: Encrypted Heartbeat",
> val_to_str_const(*conv_version,
> ssl_version_short_names, "SSL"));
> proto_item_set_text(tls_heartbeat_tree,
> "Encrypted Heartbeat Message");
> }
> }
>
> perhaps report an expert info if the payload length is too large? Why is
> that treated as a "this is encrypted" indication rather than a "somebody's
> trying to extract whatever's in the server's memory after the request
> payload" indication?
I have no idea why it treats it as an "encrypted" indication; possibly
some old deprecated spec? Anyways, +1 for heartbleed expert info.
___
Sent via:Wireshark-dev mailing list
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
