| Bug ID |
9138
|
| Summary |
Malformed NORM packet
|
| Classification |
Unclassified
|
| Product |
Wireshark
|
| Version |
1.8.6
|
| Hardware |
x86
|
| OS |
SuSE
|
| Status |
UNCONFIRMED
|
| Severity |
Major
|
| Priority |
Low
|
| Component |
Dissection engine (libwireshark)
|
| Assignee |
[email protected]
|
| Reporter |
[email protected]
|
Build Information:
NORM treats UDP packet as NORM packet
--
In reference to :
http://ask.wireshark.org/questions/24577/malformed-norm-packets
When using the NORM protocol dissector I receive a malformed packet error on
every CMD CC packet. The packets seems to start out fine, but when it gets to
the Congestion Control subtree, Wireshark seems to go into an infinite loop and
prints out hundreds of Congestion Control subrees completely filled with
zeroes. Each CMD CC packet I receive ends up being around 2074 bytes in
length, which compared to the NORM sample capture on your website that says the
CMD CC packet length was 78 bytes, is way too big.
Cmaynard answered by saying this :
"Section 4.2.3.4 of RFC 3940 states, "The list length can be inferred from the
length of the NORM_CMD(CC) message."
It looks like Wireshark is assuming that all remaining bytes in the packet are
part of the "cc_node_list", rather than stopping dissection according to the
hdr_len field in the NORM Common Message Header.
To quote:
The 8-bit "hdr_len" field indicates the number of 32-bit words that
comprise the given message's header portion. This is used to
facilitate header extensions that may be applied. The presence of
header extensions are implied when the "hdr_len" value is greater
than the base value for the given message "type".
Please file a bug and attach a sample capture file for testing. It need only be
a single packet."
Unfortunately I cannot submit a sample capture. So any fixes that you suggest I
will have to apply myself.
Thanks!
You are receiving this mail because:
- You are watching all bug changes.