Change-Id: I2ea1892b5963cc5578cbdd2b03029ca8424f2267
Reviewed-on: https://code.wireshark.org/review/2640
Tested-by: Michael Mann <mmann78@netscape.net>
Reviewed-by: Michael Mann <mmann78@netscape.net>
The Interface-ID SHOULD be considered an opaque value, with policies
based on exact match only; that is, the Interface-ID SHOULD NOT be
internally parsed by the server.
This reverts the "Cable Lab specific" functionality added in SVN rev 32928, git rev a541950ca8.
bug:9877
Change-Id: Id4a8cbd01ab3cd6d5a0a44aa2066ea395190f51a
Reviewed-on: https://code.wireshark.org/review/1579
Reviewed-by: Evan Huus <eapache@gmail.com>
Reviewed-by: Alexis La Goutte <alexis.lagoutte@gmail.com>
Details:
- Use dhcpv6_domain() to handle dissection of certain FQDN fields:
+ OPTION_AFTR_NAME: Don't use get_dns_name(); It allows "compression"
which is not valid forthis field.
+ OPTION_CCCV6_IETF_PROV_SRV: Replace use of swap_field_length_with_char();
Fix bug which caused invalid "expert" message.
+ OPTION_CCCV6_KRB_REALM: Remove validation; replace use of swap_field_length_with_char().
- Allow filtering for each different FQDN field (rather than using a generic "dhcpv6.domain"
for the various FQDN fields).
- Fix some bugs in the display of the dissection for NTP_SERVER_OPTION;
- Add some "XXX ToDo" comments.
- Add some comments as the to specific RFC for certain options;
- Note that RFC 4075 is now "deprecated";
- CL-SP-CANN-DHCP-Reg: version I10 is the latest as Feb 2014.
Change-Id: I82edafb8293b71037b84629406ce609f9a835f04
Reviewed-on: https://code.wireshark.org/review/257
Reviewed-by: Bill Meier <wmeier@newsguy.com>
Tested-by: Bill Meier <wmeier@newsguy.com>
obvious that the returned string is ephemeral, and opens up the original names
in the API for versions that take a wmem pool (and thus can work in any scope).
svn path=/trunk/; revision=54249
Now that "bytes consumed" can be determined, should tcp_dissect_pdus() take advantage of that?
Should tcp_dissect_pdus return length (bytes consumed)? There are many dissectors that just call tcp_dissect_pdus() then return tvb_length(tvb). Seems like that could all be rolled into one.
svn path=/trunk/; revision=53198
1. Case sensitivity differences between hf_ field name and formatted string.
2. Unnecessary whitespace between hf_ field name and colon in formatted string
There are cases where the hf_ field name doesn't quite match the proto_tree_add_uint_format, but it's close enough that one of them should be "right", I'm just not sure which is, I just know the string in proto_tree_add_uint_format is the one displayed.
svn path=/trunk/; revision=52098
The script didn't catch as many as I would have liked, but it's a start.
The most common (ab)use of proto_tree_add_uint_format was for appending strings to CRC/checksum values to note good or bad CRC/checksum.
svn path=/trunk/; revision=52045
Also (for a few files):
- create/use some extended value strings;
- remove unneeded #include files;
- remove unneeded variable initialization;
- re-order fcns slightly so prefs_reg_handoff...() at end, etc
svn path=/trunk/; revision=44438
Specifically: Replace FALSE|0 and TRUE|1 by ENC_BIG_ENDIAN|ENC_LITTLE_ENDIAN as
the encoding parameter for proto_tree_add_item() calls which directly reference
an item in hf[] which has a type of:
FT_BOOLEAN
FT_IPv4
FT_EUI64
FT_GUID
FT_UINT_STRING
Also: For type FT_ITv6 use ENC_NA. (This was missed in SVN #39260)
svn path=/trunk/; revision=39328
Specifically: Replace FALSE|0 and TRUE|1 by ENC_BIG_ENDIAN|ENC_LITTLE_ENDIAN as
the encoding parameter for proto_tree_add_item() calls which directly reference
an item in hf[] which has a type of:
FT_UINT8
FT_UINT16
FT_UINT24
FT_UINT32
FT_UINT64
FT_INT8
FT_INT16
FT_INT24
FT_INT32
FT_INT64
FT_FLOAT
FT_DOUBLE
svn path=/trunk/; revision=39288
FT_NONE
FT_BYTES
FT_IPV6
FT_IPXNET
FT_OID
Note: Encoding field set to ENC_NA only if the field was previously TRUE|FALSE|ENC_LITTLE_ENDIAN|ENC_BIG_ENDIAN
svn path=/trunk/; revision=39260