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.
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.
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?
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).
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
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).
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.
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
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.
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
