Wireshark-dev: Re: [Wireshark-dev] [Wireshark-commits] rev 39384: /trunk/epan/dissectors/ /trun
Date Index · Thread Index · Other Months · All Mailing Lists
Date Prev · Date Next · Thread Prev · Thread Next
From: Bill Meier <wmeier@xxxxxxxxxxx>
Date: Wed, 12 Oct 2011 14:20:29 -0400
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);