| Bug ID |
9594
|
| Summary |
DHCPv4 Suboptions not dissected if first suboption is not number 1
|
| Classification |
Unclassified
|
| Product |
Wireshark
|
| Version |
1.10.4
|
| Hardware |
x86-64
|
| OS |
Windows 7
|
| Status |
UNCONFIRMED
|
| Severity |
Normal
|
| Priority |
Low
|
| Component |
Dissection engine (libwireshark)
|
| Assignee |
[email protected]
|
| Reporter |
[email protected]
|
Created attachment 12378 [details]
Supporting Documentation
Build Information:
Version 1.10.4 (SVN Rev 54184 from /trunk-1.10)
Copyright 1998-2013 Gerald Combs <[email protected]> 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.14, with Cairo 1.10.2, with Pango 1.30.1, with
GLib 2.34.1, with WinPcap (4_1_3), with libz 1.2.5, without POSIX capabilities,
without libnl, with SMI 0.4.8, with c-ares 1.9.1, with Lua 5.1, without Python,
with GnuTLS 2.12.18, with Gcrypt 1.4.6, without Kerberos, with GeoIP, with
PortAudio V19-devel (built Dec 17 2013), 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 2.12.18, Gcrypt 1.4.6, without AirPcap.
Intel(R) Core(TM) i7-2720QM CPU @ 2.20GHz, with 20437MB of physical
memory.
Built using Microsoft Visual C++ 10.0 build 40219
Wireshark is Open Source Software released under the GNU General Public
License.
Check the man page and http://www.wireshark.org for more information.
--
When dissecting DHCPv4 Option 125 - Vendor-Identifying Vendor options as
defined in RFC3925 section 4 Wireshark does not properly dissect and display
the sub-options in all cases.
In my specific example examples that begin with sub-option 01 are parsed
correctly. Those that begin with sub-option 04 are not.
RFC 3925 DHCP Option 125 format
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| enterprise-number1 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data-len1 | |
+-+-+-+-+-+-+-+-+ option-data1 |
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ----
| enterprise-number2 | ^
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| data-len2 | | optional
+-+-+-+-+-+-+-+-+ option-data2 | |
/ / |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
~ ... ~ V
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ----
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| subopt-code | subopt-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ sub-option-data /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
7d 24 00 00 0d e9 1f 01 06 30 30 31 34 30 34 02 }$.......001404.
0c 4d 39 31 32 34 37 53 41 30 33 33 35 03 07 56 .M91247SA0335..V
41 50 32 35 30 30 AP2500
Option Number 7d 125
Length 24 36
Enterprise 00000de9 3561 - The Broadband Forum
data-len 1f 31
Sub-option 1
- suboption 01
- length 06
- data 303031343034
Sub-option 2
- suboptioon 02
- length 0c
- data 4d 39 31 32 34 37 53 41 30 33 33 35
Sub-option 3
- suboption 03
- length 07
- data 56 41 50 32 35 30 30
0000 7d 27 00 00 11 3d 22 04 06 30 30 30 34 45 44 05 }'...="..0004ED.
0010 0c 30 30 30 34 65 64 66 35 35 64 39 39 06 0a 42 .0004edf55d99..B
0020 45 43 20 38 39 32 30 4e 45 EC 8920NE
Option Number 7d 125
Length 27 39
Enterprise 0000 113d 4413 - Broadcom Corporation
data-len 22 34
Sub-option 4
- suboption 01
- length 06
- data 30 30 30 34 45 44
Sub-option 5
- suboptioon 05
- length 0c 12
- data 30 30 30 34 65 64 66 35 35 64 39 39
Sub-option 6
- suboption 06
- length 0a 10
- data 42 45 43 20 38 39 32 30 4e 45
In the attached packet capture the DHCPDISCOVER and DHCPREQUEST requests from
the client where the Option 125 sub-options begin at 1 are dissected and
displayed correctly. The DHCP responses where the option 125 sub-option begins
at sub-option 4 are not.
Note that it is appropriate in this case for the DHCP server to begin at
sub-option 4. See Broadband Forum TR-069 Table 102 in Section F.2.5 for a
definition of the appropriate information for each device to include.
RFC 3925 Section 4 does not define an required order of sub-options, or
starting number. It only indicates that the sub-options are not defined by
IANA, but rather by the Enterprise in question.
Based on my efforts to manually dissect the packets, they appear to be properly
formatted in both cases per the RFC and Broadband Forum requirements.
I wonder if Wireshark isn't expecting the sub-options to begin with 01 and
fails to dissect the suboptions when they do not.
Issue also noted in various previous 1.10.x versions of Wireshark. Unknown if
it existed in earlier versions as we did not have hardware that conformed with
this RFC until recently.
Attached:
Broadband Forum TR-069 Amendment 4 as referenced.
Packet capture showing a properly dissected pair of requests and an improperly
dissected pair of responses (as dissected manually above)
Screenshots of the display differences within the Wireshark UI (have not
verified CLI output)
You are receiving this mail because:
- You are watching all bug changes.
