On 10/12/2011 1:42 PM, Guy Harris wrote:
(Paging LTE experts here....)
On Oct 12, 2011, at 8:02 AM, wmeier@xxxxxxxxxxxxx wrote:
http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=rev&revision=39384
User: wmeier
Date: 2011/10/12 08:02 AM
Log:
Fix a benign bug: Use correct proto_tree_add_item() encoding arg.
At least as I read RFC 3095:
UOR-2-TS
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 1 0 | TS |
+===+===+===+===+===+===+===+===+
|T=1| M | SN |
+---+---+---+---+---+---+---+---+
| X | CRC |
+---+---+---+---+---+---+---+---+
neither the old code nor the new code are correct - the "M" bit is
in the octet after the TS field.
I don't see anything obvious in 3GPP TS 36.323 itself that says the
format is different; does something in a later RFC specify something
different?
Yep: I read the RFC the same way; There's an 'offset++' after the fetch
of ts so I think the code is Ok.
guint8 ts = tvb_get_guint8(tvb, offset) & 0x1f;
proto_tree_add_uint(tree, hf_pdcp_lte_rohc_ts, tvb, offset, 1, ts);
offset++;
/* Large CID */
if (p_pdcp_info->large_cid_present) {
offset = dissect_large_cid(tree, tvb, offset);
}
/* m */
proto_tree_add_item(tree, hf_pdcp_lte_rohc_m, tvb, offset, 1,
ENC_BIG_ENDIAN);