Introduced with v2.3.0rc0-112-gdcb7b71, nxt is only a guint8* which
fails on 32-bit glib before 2.31.2.
Change-Id: Ide1816a971fa213f5669a7fa71bc111d5b1cc921
Reviewed-on: https://code.wireshark.org/review/17418
Petri-Dish: Peter Wu <peter@lekensteyn.nl>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Peter Wu <peter@lekensteyn.nl>
Change-Id: Ibc43b1976d5827e8c40252a5200852fbcd00b70c
Reviewed-on: https://code.wireshark.org/review/16763
Petri-Dish: João Valverde <j@v6e.pt>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Michael Mann <mmann78@netscape.net>
Reviewed-by: João Valverde <j@v6e.pt>
We may want to add expert infos for IPv6 extension headers over IPv4 (TODO).
Any side-effects that don't make sense (e.g: IPv6 Routing over IPv4) are
ignored.
The IPv6 Next Header decode as is replaced by IP Proto decode as. It
didn't fit a conceptual model well and it also was not working very well
in practice (for multiple extension headers).
We now support decoding any IP Protocol number as an extension header.
Bug: 12673
Change-Id: Icbde019aba8990cc556ef2bd832f64cba76c24b6
Reviewed-on: https://code.wireshark.org/review/16681
Petri-Dish: João Valverde <j@v6e.pt>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: João Valverde <j@v6e.pt>
Both display as zero in the UI. We shouldn't have null values for
decode as, but we do for IPv6, and the user (also the developer) can't
tell them apart from an IPv6 Hop-by-hop Option extension header.
NULL values are represented as IP Protocol 255 (Reserved) in the UI,
intead of IP Protocol 0 (Hop-By-Hop extension header).
Change-Id: I840db99df212a3bee03027b91fdec9c01886004d
Reviewed-on: https://code.wireshark.org/review/16746
Petri-Dish: João Valverde <j@v6e.pt>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: João Valverde <j@v6e.pt>
Also remove code dependency on ip6_hdr pointer. It is used solely for the
"ipv6" tap now.
Change-Id: I07150bfae8bf94bf3c585f20c27b60db78688a7b
Reviewed-on: https://code.wireshark.org/review/16655
Petri-Dish: João Valverde <j@v6e.pt>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: João Valverde <j@v6e.pt>
To perform IPv6 defragmentation we need to compute the IPv6 fragment header
payload length by subtracting the length of intermediate extension headers
from the IPv6 payload length.
Add a new frag_plen field to ipv6_pinfo_t to do that instead of (ab)using
struct ws_ip.
Note: The RFC 2460 rules for fragment header order are stricter than the code
suggests but that shouldn't be a problem here.
Change-Id: I76f3cb3a1a29d96b080d3d53c0f493f9d0b2786c
Reviewed-on: https://code.wireshark.org/review/16637
Petri-Dish: João Valverde <j@v6e.pt>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: João Valverde <j@v6e.pt>
That way, we don't rely on the ws_ip pointer being non-null.
Based on changes from Ib73410fd8575ad6c836311bbda87a0580e5640ac.
Change-Id: If8c437572c725481ac4148c8095a1a479b4fb0f8
Reviewed-on: https://code.wireshark.org/review/16617
Reviewed-by: Guy Harris <guy@alum.mit.edu>
That way, we don't rely on the ws_ip pointer being non-null.
Based on changes from Ib73410fd8575ad6c836311bbda87a0580e5640ac.
Bug: 12645
Change-Id: I8c74ba57637b6a125593c4711d7c21b9693c2c85
Reviewed-on: https://code.wireshark.org/review/16616
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Change field ip_v_hl to version.
Change-Id: Ic7ce8d6d083f6413284a7b9ba91a2387b11b29fb
Reviewed-on: https://code.wireshark.org/review/16555
Petri-Dish: João Valverde <j@v6e.pt>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: João Valverde <j@v6e.pt>
This is an attempt to standardize display/handling of checksum fields for all dissectors.
The main target is for dissectors that do validation, but dissectors that just report the
checksum were also included just to make them easier to find in the future.
Bug: 10620
Bug: 12058
Ping-Bug: 8859
Change-Id: Ia8abd86e42eaf8ed50de6b173409e914b17993bf
Reviewed-on: https://code.wireshark.org/review/16380
Petri-Dish: Michael Mann <mmann78@netscape.net>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Jeff Morriss <jeff.morriss.ws@gmail.com>
Reviewed-by: Michael Mann <mmann78@netscape.net>
As requested by Alexis.
Change-Id: I33e91aa0234e7c07869d69b5da6d0df8f94254ba
Reviewed-on: https://code.wireshark.org/review/16559
Reviewed-by: Alexis La Goutte <alexis.lagoutte@gmail.com>
It was passing the wrong offset for an FT_UINT_STRING type.
Change-Id: I739eb5bbf86768f6bf953662d407270cc8e27f2b
Reviewed-on: https://code.wireshark.org/review/16547
Petri-Dish: João Valverde <j@v6e.pt>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: João Valverde <j@v6e.pt>
In accordance with the IANA registry. This option was never used.
Change-Id: I2fc16579b084a0d537f16b9104b025d97a0afd8d
Reviewed-on: https://code.wireshark.org/review/16552
Reviewed-by: João Valverde <j@v6e.pt>
It's not being used and makes some things more difficult so kill it.
It's not possible in general to distinguish an unknown extension header from
an unknown IP protocol and the concept is fuzzy anyway (for example ESP is
officially an extension header but meh) so don't bother trying for now.
Change-Id: I3bdfcc2b76b47e8c1588e91838225b14808e43a7
Reviewed-on: https://code.wireshark.org/review/16529
Petri-Dish: João Valverde <j@v6e.pt>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: João Valverde <j@v6e.pt>
Don't require 40 bytes upfront, do it by field.
Miscellaneous cleanups.
Change-Id: Ib40b43eb3cf9aa52aa490cdabc6de26b0e977483
Reviewed-on: https://code.wireshark.org/review/16522
Reviewed-by: João Valverde <j@v6e.pt>
struct ws_ip is IP version agnostic. "ip_p" is too terse and less
appropriate.
Change-Id: I06b8740ab420e20781bf7b9efcf5dce19ad22ab2
Reviewed-on: https://code.wireshark.org/review/16519
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: João Valverde <j@v6e.pt>
The field macros are a particularly obnoxious form of namespace pollution.
Change-Id: I9010a767625fd1c4b4a48c9d75481c577915fce6
Reviewed-on: https://code.wireshark.org/review/16520
Petri-Dish: João Valverde <j@v6e.pt>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: João Valverde <j@v6e.pt>
Peter Wu