It ends up dragging in libwireshark headers, which programs not linking
with libwireshark shouldn't do. In particular, including
<epan/address.h> causes some functions that refer to libwireshark
functions to be defined if the compiler doesn't handle "static inline"
the way GCC does, and you end up requiring libwireshark even though you
shouldn't require it.
Move plurality() to wsutil/str_util.h, so that non-libwireshark code can
get it without include epan/packet.h. Fix includes as necessary.
Change-Id: Ie4819719da4c2b349f61445112aa419e99b977d3
Reviewed-on: https://code.wireshark.org/review/11545
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Change-Id: I8cfd1c223c70c7e03728af8b2f7cbf9354d7ad86
Ping-Bug: 3949
Reviewed-on: https://code.wireshark.org/review/10865
Petri-Dish: Michael Mann <mmann78@netscape.net>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Roland Knall <rknall@gmail.com>
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Bug: 9877
Change-Id: I84fbfb0ae2dcfc98b005b0f4243d07bd929bb195
Reviewed-on: https://code.wireshark.org/review/10773
Petri-Dish: Michael Mann <mmann78@netscape.net>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Michael Mann <mmann78@netscape.net>
Add a CF_FUNC macro to match VALS, TFS, etc. This should help us to avoid
the following warning:
warning: ISO C forbids initialization between function pointer and 'void *' [-Wpedantic]
We could start adding DIAG_OFF+DIAG_ON everywhere but this seems to be
more consistent with the other macros in proto.h. Update each instance
of BASE_CUSTOM to use CF_FUNC.
Adjust a dummy variable name generated by asn2wrs.py that was triggering
an invalid error in checkhf.pl.
Fix an encoding arguement in packet-elasticsearch.c found by
fix-encoding-args.pl.
Change-Id: Id0e75076c2d71736639d486f47b87bab84e07d22
Reviewed-on: https://code.wireshark.org/review/7150
Reviewed-by: Gerald Combs <gerald@wireshark.org>
Provide a way for Lua-based dissectors to invoke tcp_dissect_pdus()
to make TCP-based dissection easier.
Bug: 9851
Change-Id: I91630ebf1f1fc1964118b6750cc34238e18a8ad3
Reviewed-on: https://code.wireshark.org/review/6778
Reviewed-by: Alexis La Goutte <alexis.lagoutte@gmail.com>
Reviewed-by: Hadriel Kaplan <hadrielk@yahoo.com>
Tested-by: Hadriel Kaplan <hadrielk@yahoo.com>
Change-Id: I79c613cbdd8dc939dd4c29ebc477fb6eefd5bfc4
Reviewed-on: https://code.wireshark.org/review/6371
Petri-Dish: Michael Mann <mmann78@netscape.net>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Michael Mann <mmann78@netscape.net>
Also change bytestring_to_str to match bytes_to_ep_str_punct functionality (limiting byte string size)
Change-Id: Idb958c7f0c203d103629469302b81fa922714f7e
Reviewed-on: https://code.wireshark.org/review/6369
Reviewed-by: Michael Mann <mmann78@netscape.net>
Change-Id: Id57a9f2df6a4011078b0bef359b2cd5503f6f7ce
Reviewed-on: https://code.wireshark.org/review/6171
Reviewed-by: Michael Mann <mmann78@netscape.net>
Change-Id: I1d258923a7a63539ec8456d3e306bca5016a1e4b
Reviewed-on: https://code.wireshark.org/review/6060
Petri-Dish: Michael Mann <mmann78@netscape.net>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Pascal Quantin <pascal.quantin@gmail.com>
Reviewed-by: Michael Mann <mmann78@netscape.net>
Specifically:
- Set packet.h to be the first wireshark #include after
config.h and "system" #includes.
packet.h added as an #include in some cases when missing.
- Remove some #includes included (directly/indirectly) in
packet.h. E.g., glib.h.
(Done only for those files including packet.h).
- As needed, move "system" #includes to be after config.h and
before wireshark #includes.
- Rework various #include file specifications for consistency.
- Misc.
Change-Id: Ifaa1a14b50b69fbad38ea4838a49dfe595c54c95
Reviewed-on: https://code.wireshark.org/review/5923
Petri-Dish: Alexis La Goutte <alexis.lagoutte@gmail.com>
Reviewed-by: Bill Meier <wmeier@newsguy.com>
Note: Use of most of these filter names could have caused a Wireshark crash.
Change-Id: I393402a25dd26d174baff77f4706f6d5f43a94ae
Reviewed-on: https://code.wireshark.org/review/5610
Reviewed-by: Bill Meier <wmeier@newsguy.com>
Change-Id: Iadd80aab291e5de714891a9f3c79edeca19e9b93
Reviewed-on: https://code.wireshark.org/review/5458
Reviewed-by: Michael Mann <mmann78@netscape.net>
Petri-Dish: Michael Mann <mmann78@netscape.net>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Evan Huus <eapache@gmail.com>
For:
- FT_BYTES: Always use just ENC_NA
- integral/floating (other than FT_[U]INT8): Do ENC_NA --> ENC_BIG_ENDIAN
Also:
- FT_UINT... --> FT_UINT8 in a few cases (to match proto_tree_add_item...)
- Change one case of incorrect '||' to '|'
Change-Id: I427e0e61618ff8faf55691c8a695930f67d455b0
Reviewed-on: https://code.wireshark.org/review/4184
Reviewed-by: Bill Meier <wmeier@newsguy.com>
Extract RFC3315 about hop-count :
20.1.2. Relaying a Message from a Relay Agent
If the message received by the relay agent is a Relay-forward message
and the hop-count in the message is greater than or equal to
HOP_COUNT_LIMIT, the relay agent discards the received message.
The relay agent copies the source address from the IP datagram in
which the message was received from the client into the peer-address
field in the Relay-forward message and sets the hop-count field to
the value of the hop-count field in the received message incremented
by 1.
Bug:10449
Change-Id: Ifb94e7c54c0a26714fc543862d4358d3e60c2676
Reviewed-on: https://code.wireshark.org/review/4017
Reviewed-by: Michael Mann <mmann78@netscape.net>
Petri-Dish: Michael Mann <mmann78@netscape.net>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Evan Huus <eapache@gmail.com>
Extract RFC3315 about relay message and hop-count :
20.1.1. Relaying a Message from a Client
If the relay agent received the message to be relayed from a client,
the relay agent places a global or site-scoped address with a prefix
assigned to the link on which the client should be assigned an
address in the link-address field. This address will be used by the
server to determine the link from which the client should be assigned
an address and other configuration information. The hop-count in the
Relay-forward message is set to 0.
20.3. Construction of Relay-reply Messages
A server uses a Relay-reply message to return a response to a client
if the original message from the client was relayed to the server in
a Relay-forward message or to send a Reconfigure message to a client
if the server does not have an address it can use to send the message
directly to the client.
A response to the client MUST be relayed through the same relay
agents as the original client message. The server causes this to
happen by creating a Relay-reply message that includes a Relay
Message option containing the message for the next relay agent in the
return path to the client. The contained Relay-reply message
contains another Relay Message option to be sent to the next relay
agent, and so on. The server must record the contents of the
peer-address fields in the received message so it can construct the
appropriate Relay-reply message carrying the response from the
server.
For example, if client C sent a message that was relayed by relay
agent A to relay agent B and then to the server, the server would
send the following Relay-Reply message to relay agent B:
msg-type: RELAY-REPLY
hop-count: 1
link-address: 0
peer-address: A
Relay Message option, containing:
msg-type: RELAY-REPLY
hop-count: 0
link-address: address from link to which C is attached
peer-address: C
Relay Message option: <response from server>
Change-Id: I774cc22c9c090af1a5d3732115c7cd3478343288
Bug:10437
Reviewed-on: https://code.wireshark.org/review/3936
Petri-Dish: Evan Huus <eapache@gmail.com>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Evan Huus <eapache@gmail.com>
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
Guy Harris