Linux / modbus

 endianness tests with differents agents (correct value is 478)

Hi asitnikov ,

Is there any way we could reproduce the issue locally? Assuming we are starting from fresh installation of Zabbix?

Additionally, could you increase logging level to 4 or 5 and capture the results from both agents so that we will be able to compare if there is any difference in querying the results.

Thanks

Is there any way we could reproduce the issue locally? Assuming we are starting from fresh installation of Zabbix?

You must have Satec BFM136 device ;(

Additionally, could you increase logging level to 4 or 5 and capture the results from both agents so that we will be able to compare if there is any difference in querying the results.

for agent I can't raise it, there will be a huge number of records. for agent2 it already 5

agent2 log

2024/10/25 12:57:15.787315 received passive check request: '{"request":"passive checks","data":[{{{}

{}}}]}' from '127.0.0.1'*
*2024/10/25 12:57:15.787627 received passive check request: '{"request":"passive checks","data":[{{{}

{}}}]}' from '127.0.0.1'*
2024/10/25 12:57:15.787905 [1] processing update request (1 requests)
2024/10/25 12:57:15.788026 [1] adding new request for key: 'modbus.get[tcp://10.6.4.51:502,1,4,13958,3,uint32,mle,0]'
2024/10/25 12:57:15.788091 [1] created direct exporter task for plugin 'Modbus' itemid:0 key 'modbus.get[tcp://10.6.4.51:502,1,4,13958,3,uint32,mle,0]'
2024/10/25 12:57:15.788173 [1] processing update request (1 requests)
2024/10/25 12:57:15.788204 [1] adding new request for key: 'modbus.get[tcp://10.6.4.51:502,1,4,13958,3,uint32,mbe,0]'
2024/10/25 12:57:15.788227 [1] created direct exporter task for plugin 'Modbus' itemid:0 key 'modbus.get[tcp://10.6.4.51:502,1,4,13958,3,uint32,mbe,0]'
2024/10/25 12:57:15.788291 executing direct exporter task for key 'modbus.get[tcp://10.6.4.51:502,1,4,13958,3,uint32,mbe,0]'
2024/10/25 12:57:15.788334 executing direct exporter task for key 'modbus.get[tcp://10.6.4.51:502,1,4,13958,3,uint32,mle,0]'
2024/10/25 12:57:15.832943 executed direct exporter task for key 'modbus.get[[tcp://10.6.4.51:502 1 4 13958 3 uint32 mbe 0]]'
*2024/10/25 12:57:15.833091 sending passive check response: '{"version":"7.0.5","variant":2,"data":[{{{}

{}}}]}' to '127.0.0.1'*
2024/10/25 12:57:16.003396 [101] processing update request (0 requests)
2024/10/25 12:57:16.003421 [101] skipping empty update for unregistered client
2024/10/25 12:57:16.029007 executed direct exporter task for key 'modbus.get[[tcp://10.6.4.51:502 1 4 13958 3 uint32 mle 0]]'
{}{*}2024/10/25 12:57:16.029156 sending passive check response: '{"version":"7.0.5","variant":2,"data":[{{{}

{}}}]}' to '127.0.0{*}.1'

Hi, thank you for the logs.

The difference in modbus.get results between Zabbix Agent and Agent2 suggests that you may be using two different item keys with distinct byte order configurations. For example:

• Agent2: modbus.get[tcp://10.6.4.51:502,1,4,13958,3,uint32,{*}mle{*},0] (Mixed Little Endian) returns for example [474,0,0].
• Agent: modbus.get[tcp://10.6.4.51:502,1,4,13958,3,uint32,{*}mbe{*},0] (Mixed Big Endian) returns respectively [3657498624,0,0].

The difference in byte order (mle vs. mbe) causes the discrepancy in values.

Suggested Fix:

Verify and align the item keys to use the same byte order setting (e.g., mle or mbe) across both agents to ensure consistent results.

I'm not sure you understood the essence of the problem

in my opinion, the same request through different agents should give the same result.

please study the screenshots I provided again carefully

More info (tcp dump attached)

root@zabbix:/home/sitnikov# systemctl stop zabbix-server

root@zabbix:/home/sitnikov#tcpdump -i ens160 -nn -w 10.6.4.51_502.pcap host 10.6.4.51 and port 502

root@zabbix:/home/sitnikov# zabbix_get -s 127.0.0.1 -p 10050 -k 'modbus.get[tcp://10.6.4.51:502,1,4,13958,1,uint32,mbe,0]'
3875602432

root@zabbix:/home/sitnikov# zabbix_get -s 127.0.0.1 -p 20050 -k 'modbus.get[tcp://10.6.4.51:502,1,4,13958,1,uint32,mbe,0]'
474

root@zabbix:/home/sitnikov# zabbix_get -s 127.0.0.1 -p 10050 -k 'modbus.get[tcp://10.6.4.51:502,1,4,13958,1,uint32,mle,0]'
460

root@zabbix:/home/sitnikov# zabbix_get -s 127.0.0.1 -p 20050 -k 'modbus.get[tcp://10.6.4.51:502,1,4,13958,1,uint32,mle,0]'
3456172032

In raw the device return two words - 0x01e7 0x0000 (for example, this is electrical current may vary slightly over time between requests)

Correct value is ~487 (0x000001e7) 

I now see that we have another problem with decoding this data  (not in this ticket scope)

From device manual:

2.7.2 32-bit Long Integer Format
32-bit long integer data is transmitted in two adjacent 16-bit Modbus registers as unsigned
(UINT32) or signed (INT32) whole numbers. The first register contains the low-order word
(lower 16 bits) and the second register contains the high order word (higher 16 bits). The loworder
word always starts at an even Modbus address.

The value range for unsigned data is 0 to 4,294,967,295; for signed data the range is - 2,147,483,648 to 2,147,483,647.

If your Modbus driver does not support a 32-bit long integer format, you can read the two 16-
bit registers separately, and then convert them into a 32-bit value as follows (using C notation):

32-bit value = (signed short)high_order_register × 65536L + (unsigned short)low_order_register
 

but the main question remains the same: why agent and agent 2 decode the same data with the same parameters differently

10.6.4.51_502.pcap

^{P.S. agent 1 port: 10050, agent2 port 20050}

Hi, could you please also attach the item config specified for agent 1 ( port 10050).

Thanks

yesterday's message contain all the information

Sure, got it. Seems like a bug. Thank you for reporting that. I confirm and pass it to the respective team.

Looks like the correct parsing should be MBE as the data type is uint16, and seems like an issue with agent 1.

Available in versions:

• 6.0.39rc1 37e5f9f6c3b, 8fe13d75299
• 7.0.10rc1 4738ea74850, 33904377162, b9effe16ac8
• 7.2.4rc1 dbc9e472312, 0d538c4e284, e9a1930fda7
• 7.4.0alpha1 (master) 6e86647480c, 7b79ea92983, df2cad17864