CentOS 7

And item configuration:

Are you sure that the trailing space is not a part of response from the SNMP OID ?

What is the "conversion" you are talking about?

In the images provided it seems that everything is working as expected. The values discovered by the Wireless Clients discovery rule contain trailing spaces because that's a part of SNMP response. This is why trailing spaces also appear in generated item names and keys.

Please note, that as of Zabbix 4.2 it is possible to define transformation rules to apply to the result of discovery.

Andrejs, there is something. Did you spot that colons : are replaced by spaces in the value?
This should be clarified.

<averza> Actually the SNMP library returns Hex numbers separated by space and with the space in the end. The colons are inserted by the utility you use. There is no substitution on Zabbix side.

Closing this task with the following resolution:

1. A trailing space in the end of Hex-Strings is by design and therefore not a bug.
2. The last value without a trailing space (as seen on the first screenshot) is corrected in the development branch of ZBX-16176 by not trimming spaces from the output. So that user can detect spaces by making text selection.

"Please note, that as of Zabbix 4.2 it is possible to define transformation rules to apply to the result of discovery."

This does not help, because Zabbix 4.2 is not production ready. Non-LTS version can't be used.

<averza> If I understood correctly, the original report was related to mapping history data (different output on Latest data and History screens). As was indicated before, that was a bug since mapping shouldn't get applied for values with trailing spaces. Although that can be solved by user by adding a TRIM function to the Item prototype. Please note that mapping is not taken into account while generating new items based on item prototype. Even if there was no confusion with the trailing spaces, the mapping still wouldn't happen at that stage.

If this trailing space is by design, that just means this is SNMP library bug.

Incorrect processing of array.

Why are you thinking of keeping these trailing spaces?

Trailing spaces in data are common typos added unintentionally.

<averza> This is how SNMP works. You can easily test it yourself by running snmpget for a value of Hex-String type. Redirect the output into a file and note a space in the end of line. Changing this on our side (by forcing early Trim on all Hex-Strings) would break current Zabbix installations, since new items would get generated, and the old ones would stop updating. We are sorry for this situation, but hopefully the proposed solution will be helpful to you.

"Although that can be solved by user by adding a TRIM function to the Item prototype."

Thanks for suggestion, however unfortunately this does not fit into "how it should work solution".

Because I use this MAC Address as an {#SNMPVALUE} in item prototype names to have an unique and readable identifier, which is much better than having {#SNMPINDEX} numeric value there.

<averza> Could I please ask you to open a new ticket describing your case in details, since it's out of scope of this ticket? Currently dynamic item names (through mapping) are not supported in any version of Zabbix, but this functionality will hopefully be implemented in the next versions of Zabbix.