Vendor TLV is inconsistent with format specified in draft RFC

[mikewadsten]

I have been trying to implement a CSMP server. Naturally, the first step in doing so is code that can parse TLVs from the CoAP payload. Everything is working okay there, except when the sample application creates Vendor Defined TLVs.

Per the draft spec, the Vendor Defined TLV:

• follows the same format as a Standard TLV (that is, it consists of Type | Length | Value)
• Type is 127
• Value contains one or more SubTLVs of the format SubType | Length | Value
• SubType 1 is reserved to indicate Vendor Private Enterprise Number

Therefore, I would expect a Vendor Defined TLV to look like:

7F        # Type: 127
__        # Length (of all following content)
01        # SubType 1
__        # Length of encoded Vendor PEN
____      # Vendor PEN
...       # Other SubTLVs

However, src/csmptlv/csmptlv.c does not follow that format. Instead, it writes the Vendor Defined TLV as Type | Vendor PEN | SubType | Length | Value.

csmp-agent-lib/src/csmptlv/csmptlv.c

Lines 37 to 51 in 9ef5400

	if (tlvid.vendor != 0) {
	rv = ProtobufVarint_encodeUINT32(p_cur,len - used,CSMP_TYPE_VENDOR);
	p_cur += rv; used += rv;
	if ((rv == 0) || (used > len)) {
	DPRINTF("csmptlv_write error: (rv == 0) || (used=%d > len=%ld)\n", used, len);
	return 0;
	}
	rv = ProtobufVarint_encodeUINT32(p_cur,len - used,tlvid.vendor);
	p_cur += rv; used += rv;
	if ((rv == 0) || (used > len)) {
	DPRINTF("csmptlv_write error: (rv == 0) || (used=%d > len=%ld)\n", used, len);
	return 0;
	}
	}

7F        # Type: 127
____      # Vendor PEN
...       # One SubTLV (SubType | Length | Value)

This inconsistency breaks the assumption that the CoAP payload is merely the concatenation of Type | Length | Value TLVs.

Is csmp-agent-lib out of compliance with the open specification? Or does the open specification not reflect how the Vendor Defined TLV actually looks?

[paduffy]

Hello Mike. A couple points.

• Vendor TLV is not yet settled. Neither the code nor the draft spec. I'd advise to steer clear of VTLV for a bit.
• It would be interesting context to learn more of how you intend to use VTLV. That might also help to push it up the priority list.
  Thank you.

[mikewadsten]

Hi @paduffy,

The issue here isn't about the content of the Vendor TLV or lack of definition thereof. It's the fact that the csmp-agent-lib code, when asked to output a Vendor TLV, does not output something that's actually a TLV (Type - Length - Value). The output is (Type - Vendor ID - SubType - Length - Value).

If instead it was (127 - Length (of entire payload) - (SubType 1 - Length - Vendor ID) - (SubType - Length - Value)), then parsing the TLV would be trivial, and my code wouldn't need to special case TLV 127 at all.

As a result, I literally cannot "steer clear" of VTLV (if using csmp-agent-lib as a device), because it forces me to special-case TLV ID 127 at the point of splitting the CoAP payload into TLVs. Does that help clarify things?

Maybe some pseudocode would help:

while data is not empty:
    tlv_type = data.read_varint()
    tlv_length = data.read_varint()
    payload = data.read(tlv_length)
    yield tlv_type, payload

With the current csmp-agent-lib code, we instead have to write:

while data is not empty:
    tlv_type = data.read_varint()
    if tlv_type == 127:
        # Vendor Defined TLV breaks top-level TLV parsing.
        # Get Vendor ID and SubType, then resume normal parsing.
        vendor_id = data.read_varint()
        subtype = data.read_varint()
    tlv_length = data.read_varint()
    payload = data.read(tlv_length)
    yield tlv_type, payload

[paduffy]

Do what you must to work-around this for now. As I said previously, VTLV is not settled sauce.