# Encoding OCTET STRING or tails:hex-list for SNMP

**URL:** <https://dmap-community.ductus.global/t/encoding-octet-string-or-tails-hex-list-for-snmp/1506>\
**Category:** General\
**Created:** [August 30, 2017, 11:02pm UTC](https://dmap-community.ductus.global/t/encoding-octet-string-or-tails-hex-list-for-snmp/1506 "2017-08-30T23:02:24Z")\
**Posts on this page:** 10\
**Page:** 1

<div class="post-metadata">

**Author:** ![alpesh](https://avatars.discourse-cdn.com/v4/letter/a/b9e5f3/32.png) [@alpesh](https://dmap-community.ductus.global/u/alpesh)\
**Post date:** [August 30, 2017, 11:02pm UTC](https://dmap-community.ductus.global/t/encoding-octet-string-or-tails-hex-list-for-snmp/1506/1 "2017-08-30T23:02:25Z")

</div>

Using Confd-6.4

I am trying to integrate with SNMP agent and send traps.

The trap requires a variable of type tailf:hex-list. In the mib, it is a OCTET string.

Its supposed to be encoded using the CONFD\_SET\_BINARY() but no matter how I try to set the data, the confd\_notification\_send\_snmp() fails with “snmpa failed to convert value …” error.

Code snippet is

unsigned char err\_val[2];// = “FF:EE”;

vb[0].type = CONFD\_SNMP\_VARIABLE;  
strcpy(vb[0].var.name, “testVar”);  
err\_val[0] = 0xFF;  
err\_val[1] = 0xEE;  
CONFD\_SET\_BINARY(&vb[0].val, err\_val, 2);

* * *

The “snmpa failed to convert value …” is seen in the “devel.log”

Exact error in devel.log is  
 28-Aug-2017::17:15:27.837 alpesh-ds confd[13832]: devel-snmpa internal error: unsupported type conversion: type=‘OCTET STRING’, value={39,\<\<“FE”\>\>}  
 28-Aug-2017::17:15:27.837 alpesh-ds confd[13832]: devel-snmpa failed to convert value for testVar, oid: 1.3.6.1.2.1.22.0, value: {39,\<\<“FE”\>\>}

Relevant snippet from the mib-2-yang file

leaf testVar {  
type testErrorType;  
tailf:snmp-name “testVar”;  
config false;  
}

typedef testErrorType {  
type tailf:hex-list {  
tailf:value-length “2”;  
}  
}

Any suggestions? thanks in advance

---

<div class="post-metadata">

**Author:** ![nabil](https://avatars.discourse-cdn.com/v4/letter/n/e79b87/32.png) [@nabil](https://dmap-community.ductus.global/u/nabil)\
**Post date:** [August 31, 2017, 3:17am UTC](https://dmap-community.ductus.global/t/encoding-octet-string-or-tails-hex-list-for-snmp/1506/2 "2017-08-31T03:17:17Z")

</div>

My guess for this error: 28-Aug-2017::17:15:27.837 alpesh-ds confd[13832]: devel-snmpa internal error: unsupported type conversion: type=‘OCTET STRING’, value={39,\<\<“FE”\>\>

Is that the value is somehow truncated. You pass in a size of 2 but it only reads 1 byte.  
Maybe the data gets corrupted somewhere before you send the trap?

There is documentation in the user guide as well as example code under that makes use of a “tailf:hex-list” type.  
Look at how this the encoding is used in:  
$CONFD\_DIR/examples.conf/linuxcfg/ipmibs/ipmibs.c

Please note that this type is deprecated and it’s better to use the standard type “yang:hex-string”.

C\_BINARY This type is used to represent arbitrary binary data. The YANG built-in type  
binary, the ConfD built-in types tailf:hex-list and tailf:octet-list, and the XML  
Schema primitive type xs:hexBinary all use this type. The value representation  
is the same as for C\_BUF. Binary (C\_BINARY) data received by the application  
from ConfD is always NUL terminated, but since the data may also contain NUL  
bytes, it is generally necessary to use the size given by the representation.

typedef struct confd\_buf {  
unsigned int size;  
unsigned char \*ptr;  
} confd\_buf\_t;

Data is also allocated by the library as for C\_BUF. Example:

confd\_value\_t myval, myval2;  
unsigned char \*bin;  
int len;  
bin = CONFD\_GET\_BINARY\_PTR(&myval);  
len = CONFD\_GET\_BINARY\_SIZE(&myval);  
CONFD\_SET\_BINARY(&myval2, bin, len);

---

<div class="post-metadata">

**Author:** ![alpesh](https://avatars.discourse-cdn.com/v4/letter/a/b9e5f3/32.png) [@alpesh](https://dmap-community.ductus.global/u/alpesh)\
**Post date:** [August 31, 2017, 7:15pm UTC](https://dmap-community.ductus.global/t/encoding-octet-string-or-tails-hex-list-for-snmp/1506/3 "2017-08-31T19:15:06Z")

</div>

Thanks Nabil,

The yang file is auto-generated by confdc so the type “tailf:hex-list” type is added by confdc. Is it really not supported?

Seems like all MIB OCTET STRINGS types are converted to tailf:hex-list

Thanks for the pointer to the ipmibs example. Checked it, looks like it is doing same thing for ipv6InterfaceIdentifier in ipmibs.c. And its yang files have hex-list type too.

Could it be something else? Does it need ‘:’ separators explicitly in the value?

---

<div class="post-metadata">

**Author:** ![per](https://avatars.discourse-cdn.com/v4/letter/p/9f8e36/32.png) [@per](https://dmap-community.ductus.global/u/per)\
**Post date:** [August 31, 2017, 8:05pm UTC](https://dmap-community.ductus.global/t/encoding-octet-string-or-tails-hex-list-for-snmp/1506/4 "2017-08-31T20:05:05Z")

</div>

> [@alpesh](#):
>
> The yang file is auto-generated by confdc so the type “tailf:hex-list” type is added by confdc. Is it really not supported?

No, the deprecation note in the tailf\_yang\_extensions(5) man page is targeted at use in YANG modules that **you** write, not the ones that confdc writes:-) - and furthermore states “There are no plans to remove tailf:hex-list”. The “Table 17.1. SMI mapping to YANG types” in the “17.2.3. Types” section in the UG also shows that OCTET STRING with “binary” syntax is mapped to tailf:hex-list (and vice versa), and there is no mapping for yang:hex-string. Maybe this should all change at some point, but it isn’t the issue here.[quote=“alpesh, post:3, topic:1506”]  
Does it need ‘:’ separators explicitly in the value?  
[/quote]  
No - the “FF:EE” comment that you have in your code is the **string** representation corresponding to a C\_BINARY value of two bytes, 255 and 238 decimal - i.e. exactly as you have it in your code:

```
err_val[0] = 0xFF;
err_val[1] = 0xEE;

```

And I **really** can’t see how this code could possibly result in the `value={39,<<"FE">>}` that you have in the error message. Are you sure that error isn’t actually from another one of your attempts? (I can imagine _some_ ways to get that error.) Please try again with the err\_val setting as above, and make sure (check the date and time) that you capture the error you get from this attempt (if any).

---

<div class="post-metadata">

**Author:** ![alpesh](https://avatars.discourse-cdn.com/v4/letter/a/b9e5f3/32.png) [@alpesh](https://dmap-community.ductus.global/u/alpesh)\
**Post date:** [August 31, 2017, 11:42pm UTC](https://dmap-community.ductus.global/t/encoding-octet-string-or-tails-hex-list-for-snmp/1506/5 "2017-08-31T23:42:33Z")

</div>

Hi Per,  
Thanks for the reply.

The clue for this issue is in  
devel-snmpa internal error: unsupported type conversion: type=‘OCTET STRING’, value={39,\<\<“FE”\>\>}

. Unsupported type conversion. So I changed to using CONFD\_SET\_BUF instead of CONFD\_SET\_BINARY to match what an OCTET STRING would need. And that worked !!

Can receive the trap with the right values.

The ConfD documentation needs an update? What a goose chase ☹

---

<div class="post-metadata">

**Author:** ![per](https://avatars.discourse-cdn.com/v4/letter/p/9f8e36/32.png) [@per](https://dmap-community.ductus.global/u/per)\
**Post date:** [September 1, 2017, 8:31am UTC](https://dmap-community.ductus.global/t/encoding-octet-string-or-tails-hex-list-for-snmp/1506/6 "2017-09-01T08:31:27Z")

</div>

> [@alpesh](#):
>
> The clue for this issue is in devel-snmpa internal error: unsupported type conversion: type=‘OCTET STRING’, value={39,\<\<“FE”\>\>}

Good that it was clue enough for you to try C\_BUF, it certainly wasn’t for me:-) (and I still have a really hard time seeing that the code you showed could give that exact error - I could buy it with `value={39,<<"\377\356">>}` - but never mind).

> [@alpesh](#):
>
> The ConfD documentation needs an update?

The documentation is absolutely correct as far as the `tailf:hex-list` ↔ `C_BINARY` mapping goes, but there is _something_ wrong in the SNMP area. I suspect that the documentation for SMI type mappings is also correct, but that there is a bug in the SNMP agent implementation for some specific case - perhaps specifically the case of sending traps. If you look at the SMI type mapping table I pointed to earlier, you can see that `OCTET STRING` can be mapped to either YANG `string` (`C_BUF`/`C_STR`) or YANG `tailf:hex-list` (`C_BINARY`) depending on `DISPLAY-HINT` etc - it could be that the code that deals with the varbinds in traps only handles the first case.

If you have a support contract, please open a ticket for this issue - if not, let me know and I’ll see what I can do about it.

---

<div class="post-metadata">

**Author:** ![alpesh](https://avatars.discourse-cdn.com/v4/letter/a/b9e5f3/32.png) [@alpesh](https://dmap-community.ductus.global/u/alpesh)\
**Post date:** [September 1, 2017, 9:30pm UTC](https://dmap-community.ductus.global/t/encoding-octet-string-or-tails-hex-list-for-snmp/1506/7 "2017-09-01T21:30:43Z")

</div>

Hi Per,  
Do not have contract yet (still is business negotiations). Pls open an internal ticket if needed.

Don’t know where or why Agent is expecting OCTET STRING because the YANG model says type is tailf:hex-list.

The code snippet and yang model should be enough to reproduce the issue. Yes, using it only for sending traps. The log snippet is also a cut-n-paste from actual devel.log

alpesh

---

<div class="post-metadata">

**Author:** ![per](https://avatars.discourse-cdn.com/v4/letter/p/9f8e36/32.png) [@per](https://dmap-community.ductus.global/u/per)\
**Post date:** [September 2, 2017, 11:30am UTC](https://dmap-community.ductus.global/t/encoding-octet-string-or-tails-hex-list-for-snmp/1506/8 "2017-09-02T11:30:51Z")

</div>

> [@alpesh](#):
>
> Do not have contract yet (still is business negotiations). Pls open an internal ticket if needed.

OK.

> [@alpesh](#):
>
> Don’t know where or why Agent is expecting OCTET STRING because the YANG model says type is tailf:hex-list.

That’s just the mapping between SMI types and YANG types, see the table I pointed you to. There has to be a mapping since the types are different… - and the SNMP agent is supposed to do any conversions required for that mapping.

> [@alpesh](#):
>
> The log snippet is also a cut-n-paste from actual devel.log

Oh yes, I don’t think you made it up:-) - but you wrote “no matter how I try”, so I guess you tried many different things, and I just think that the _specific_ error message that you showed was not the result of the specific code that you showed. If one of your attempts was something like

```
strcpy(&err_val[0], "FF");
strcpy(&err_val[1], "EE")

```

I believe it would result in exactly that error message.

---

<div class="post-metadata">

**Author:** ![alpesh](https://avatars.discourse-cdn.com/v4/letter/a/b9e5f3/32.png) [@alpesh](https://dmap-community.ductus.global/u/alpesh)\
**Post date:** [September 5, 2017, 5:38pm UTC](https://dmap-community.ductus.global/t/encoding-octet-string-or-tails-hex-list-for-snmp/1506/9 "2017-09-05T17:38:14Z")

</div>

Hi Per,  
I had not tried this strcpy() option. Only assignments or strcpy(err\_val, “FF:EE”). But the log was from the assignment try.

alpesh

---

<div class="post-metadata">

**Author:** ![per](https://avatars.discourse-cdn.com/v4/letter/p/9f8e36/32.png) [@per](https://dmap-community.ductus.global/u/per)\
**Post date:** [September 6, 2017, 12:39pm UTC](https://dmap-community.ductus.global/t/encoding-octet-string-or-tails-hex-list-for-snmp/1506/10 "2017-09-06T12:39:30Z")

</div>

OK, I guess I’m missing something, but it doesn’t really matter - the important finding is that C\_BINARY doesn’t work even though it should.