Created attachment 13160
IPv6 packet with RPL routing header
Build Information:
Version 1.12.1 (v1.12.1-0-g01b65bf3 from master-1.12)
Copyright 1998-2014 Gerald Combs <gerald@wireshark.org> and contributors.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Compiled (64-bit) with GTK+ 2.24.23, with Cairo 1.10.2, with Pango 1.34.0, with
GLib 2.38.0, with WinPcap (4_1_3), with libz 1.2.5, with SMI 0.4.8, with c-ares
1.9.1, with Lua 5.2, without Python, with GnuTLS 3.1.22, with Gcrypt 1.6.0,
without Kerberos, with GeoIP, with PortAudio V19-devel (built Sep 16 2014), with
AirPcap.
Running on 64-bit Windows 7 Service Pack 1, build 7601, with WinPcap version
4.1.3 (packet.dll version 4.1.0.2980), based on libpcap version 1.0 branch
1_0_rel0b (20091008), GnuTLS 3.1.22, Gcrypt 1.6.0, without AirPcap.
Intel(R) Core(TM) i5-3550 CPU @ 3.30GHz, with 16345MB of physical
memory.
Built using Microsoft Visual C++ 10.0 build 40219
Wireshark is Open Source Software released under the GNU General Public License.
Discovered while working on Pcap.Net (http://pcapdot.net).In the attached pcap file there's a single IPv6 packet with multiple extension headers.The third extension header is RPL routing header with two addresses.The number compressed octets the routing header has is 6 for the internal addresses and 13 for the final address.However, the two addresses it contains are both interpreted as if they have the same number of compressed octets (6) in the Address field.The Full Address field seems correct though, with 13 octets compressed.
What comment are you referring to?
I couldn't find something that looks suspicious in the code, but I don't know that code and I don't know how to debug it.
(In reply to boaz.brickner from comment #2) > Hi Alexis, > > What comment are you referring to? > I couldn't find something that looks suspicious in the code, but I don't > know that code and I don't know how to debug it. On packet-ipv6.c start line 815, there is comment like : /* We use cmprI for internal (e.g.: not last) address for how many bytes to elide, so actual bytes present = 16-CmprI /* We use cmprE for last address for how many bytes to elide, so actual bytes present = 16-CmprE */And the question is what the good display for this packet...
As far as I understand:* Since CmprI is 6, it means that we should parse 16-6=10 bytes as the suffix of the first address.* Since CmprE is 13, it means that we should parse 16-13=3 bytes as the suffix of the second (last) address.In practice, Wireshark tries to parse 10 bytes for both addresses, which causes it to read beyond the Routing Header data.The comment seems correct, but I'm not sure the implementation matches it.