| Bug ID |
9877
|
| Summary |
DHCPv6 packet dissector is making interpretations where not supported by standard
|
| Classification |
Unclassified
|
| Product |
Wireshark
|
| Version |
1.10.6
|
| Hardware |
x86-64
|
| OS |
Windows 7
|
| Status |
UNCONFIRMED
|
| Severity |
Minor
|
| Priority |
Low
|
| Component |
Dissection engine (libwireshark)
|
| Assignee |
[email protected]
|
| Reporter |
[email protected]
|
Created attachment 12629 [details]
Packet w/ an interface ID which does not represent a MAC address
Build Information:
Version 1.10.6 (v1.10.6 from master-1.10)
--
Wireshark is inappropriately attempting to decode Option 18 in the packet as
potentially a string followed by a MAC address. I cannot find a standard
anywhere which supports this interpretation. RFC 3315, section 22.18 strongly
suggests that such interpretation is inappropriate:
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 misleads anybody who happens to be looking at a packet that the content
means something that it does not. Attached is a packet with an Option 18
supplied, but it does not contain a Link Address anywhere in it.
This particular packet happens to be decoded as:
Value: 303955004e6f744d41434164647265737300
Interface-ID: 09U
Link Address: 4e:6f:74:4d:41:43
You are receiving this mail because:
- You are watching all bug changes.
