This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

Malformed NORM packets

0

When I do a capture using the NORM protocol I receive an error message saying that my CMD CC packets are malformed. I believe I’ve narrowed the problem down to the Congestion Control subtree. When it reaches the Congestion Control part, Wireshark creates hundreds of Congestion Control subtrees filled completely with zeroes, creating a bigger packet than Wireshark is expecting. Here is the section of the code that dissects NORM cmd(cc) packets:

static guint dissect_norm_cmd_cc(struct _norm *norm, proto_tree *tree,
 tvbuff_t *tvb, guint offset, packet_info *pinfo _U_)
{
  proto_tree_add_item(tree, hf.reserved, tvb, offset, 1, ENC_NA); offset ++;
  proto_tree_add_item(tree, hf.cc_sequence, tvb, offset, 2, ENC_BIG_ENDIAN); offset += 2;

proto_tree_add_item(tree, hf.cc_sts, tvb, offset, 4, ENC_BIG_ENDIAN); offset += 4; proto_tree_add_item(tree, hf.cc_stus, tvb, offset, 4, ENC_BIG_ENDIAN); offset += 4; if (offset < hdrlen2bytes(norm->hlen)) { struct _fec_ptr f; memset(&f, 0, sizeof f); f.fec = &norm->fec; f.hf = &hf.fec; f.ett = &ett.fec; f.prefs = &preferences.fec; offset = dissect_norm_hdrext(norm, &f, tree, tvb, offset, pinfo); } while (tvb_reported_length_remaining(tvb, offset) > 0) { proto_item *ti, *tif; proto_tree *cc_tree, *flag_tree; double grtt; ti = proto_tree_add_text(tree, tvb, offset, 8, "Congestion Control"); cc_tree = proto_item_add_subtree(ti, ett.congestioncontrol); proto_tree_add_item(cc_tree, hf.cc_node_id, tvb, offset, 4, ENC_BIG_ENDIAN); offset += 4; tif = proto_tree_add_item(cc_tree, hf.cc_flags, tvb, offset, 1, ENC_BIG_ENDIAN); flag_tree = proto_item_add_subtree(tif, ett.flags); proto_tree_add_item(flag_tree, hf.cc_flags_clr, tvb, offset, 1, ENC_BIG_ENDIAN); proto_tree_add_item(flag_tree, hf.cc_flags_plr, tvb, offset, 1, ENC_BIG_ENDIAN); proto_tree_add_item(flag_tree, hf.cc_flags_rtt, tvb, offset, 1, ENC_BIG_ENDIAN); proto_tree_add_item(flag_tree, hf.cc_flags_start, tvb, offset, 1, ENC_BIG_ENDIAN); proto_tree_add_item(flag_tree, hf.cc_flags_leave, tvb, offset, 1, ENC_BIG_ENDIAN); offset += 1; grtt = UnquantizeRtt(tvb_get_guint8(tvb, offset)); proto_tree_add_double(cc_tree, hf.cc_rtt, tvb, offset, 1, grtt); offset += 1; grtt = UnquantizeSendRate(tvb_get_ntohs(tvb, offset)); proto_tree_add_double(cc_tree, hf.cc_rate, tvb, offset, 2, grtt); offset += 2; } return offset; }

The problem seems to be occurring in the “while” loop since Wireshark seems to recognize everything before that point. Sorry I cannot post a screenshot of the capture itself. I am using Wireshark-1.8.6 and the full code is located under /epan/dissectors/packet-rmt-norm.c.

I am fairly new to Wireshark so any advice on how to make Wireshark recognize this packet and fill it with useful information (activate the flags, register the node ID, etc.) would be much appreciated.

asked 11 Sep '13, 08:15

Torbett's gravatar image

Torbett
11334
accept rate: 0%

edited 11 Sep '13, 08:32

grahamb's gravatar image

grahamb ♦
19.8k330206


One Answer:

0

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.

answered 11 Sep '13, 11:39

cmaynard's gravatar image

cmaynard ♦♦
9.4k1038142
accept rate: 20%

Unfortunately I'm not allowed to upload a sample capture. Do you have any suggestions about anything I can tweak in the source code on my end and fix the bug myself?

(12 Sep '13, 05:02) Torbett

I'd suggest filing a bug report first, that way if someone decides to look into it and provide a patch, that person can post it to the bug report for you to apply and test.

If the patch turns out to be faulty in your testing, then you can either provide feedback or modify the patch yourself and post an updated patch to the bug report. After review, the patch can then be committed to the archive and scheduled to be backported, if applicable.

Filing a bug will track the problem much better than this Q&A site will. (But you may reference this question in the bug report.)

(12 Sep '13, 08:48) cmaynard ♦♦

By changing while (tvb_reported_length_remaining(tvb, offset) > 0 to while (offset < hdrlen2bytes(hlen)), the Malformed Packet error no longer appears in my capture. However, the packet size is still huge. I'm expecting a packet size of 78 bytes and Im still getting a 2074 byte packet for CMD CC. Now instead of those all being Congestion Control Subtrees filled with zeros, 2004 of those bytes now are listed as "Payload" but they are still completely filled with zeros. Is there any way to fix this? I believe this is due to the way that tvb_reported_length_remaining(tvb, offset) collects its information but I could be wrong. Once again I'm sorry I can't post a sample capture.

(23 Sep '13, 05:30) Torbett

Right, that was the change I made to resolve bug 9138.

Wireshark displays any remaining data as "payload", so the frame size is apparently too big. That's likely a bug in the sending application.

(23 Sep '13, 07:51) cmaynard ♦♦