TCP scanner doesn't work, missing 32bit signed+unsinged option and more

[guy22israel]

Hello,

I just found OpenModScan yesterday and it looks very nice :) Thank you.

I used to work with the original ModScan utility years ago but since then I found newer, better and free tools with the same functionality.

The nice thing with OpenModScan is that it has two tools in one: client and scanner functionality - both Serial and TCP.

There are few issues I found:

1. TCP scanner: I didn't yet tried the Serial scanner but with the TCP scanner I did two tests: yesterday at home and today at work. For the test at home I used a Modbus slave emulator (pyModSlave). While testing, OpenModScan didn't show any IDs even though the OpenModScan client itself was able to connect and show data for the specific ID that was configured.

The test I did today was at a real project where I use many Modbus gateways, When I tried testing one of the gateway's IP, the scanner show no results (the range of IPs was for only one IP). I tried a wider range of IPs e.g 10.0.20.10-10.0.20.15 and still nothing. Only after I changed the range to something wider, the scanner did show some results but with non existing IDs.

For example: the Modbus gateway hosts IDs 10-11 but the scanner returned many other IDs even above 100.

There is another free scanner for Modbus (Modbus RTU Scan). It works very well but it only supports the serial protocol. Both GUIs look very similar....

2. There is no 32 bit Signed/Unsigned register with swap option (like there is for Float register)

3. Changing Device ID in client WHILE connected: if you put the correct Device ID before connecting to the TCP device, communication work fine. If you change ID while connected to the device, you get the "no responses from...". This is Ok. But if I change the ID back to the correct ID, communication is not restored. I must disconnect and reconnect.

4. Show traffic: it will be nice to change the original ModScan traffic view so it will show Rx/Tx line by line: Tx, Rx, Tx, Rx). It will be easier to understand debug. I also saw in the past functionality such as phrasing each Rx/Tx packet so the software can tell you exactly how the packet is built: Rx or Tx, ID, type of register (coild, input, holding etc..), range of registers and the data/values (like in QModMaster).

Thank you, Omer.

[sanny32]

Hello @guy22israel. Thank you for being interested in my program OpenModScan. I have to ask a few questions about the issue you wrote.

1. TCP Scanner. Can you say more information about your network and what settings did you use in Modbus TCP Scanner? The modbus slave emulator (pyModSlave) runs a modbus emulation at 127.0.0.1 ip address. Did you setup ip address range in Modbus TCP Scanner from 127.x.x.x range?
2. Do you need 32 bit Signed/Unsigned register values? I can add it in future releases. If you need this feature, please create a new issue for this feature.
3. I suppose that this is a bug in pyModSlave. Beacause using OpenModScan with other simulators i don`t see the behavior you describe. But with original Modscan i see the same program behavior as my OpenModScan.
4. OpenModScan repeats the functionality of the original Modscan. If you need this feature, please create a new issue with detailed description (preferably with screenshots) to implement this functionality.

[guy22israel]

Hello,

Thank you for the fast response.

In response to your questions:

1. TCP Scanner. Can you say more information about your network and what settings did you use in Modbus TCP Scanner? The modbus slave emulator (pyModSlave) runs a modbus emulation at 127.0.0.1 ip address. Did you setup ip address range in Modbus TCP Scanner from 127.x.x.x range?

@guy22israel: indeed, i put 127.0.0.1 in both "from" and "to", mask 255.255.255.0, port 502, IDs 1-254. No results. On the other hand, the client itself can read data from the device (I set it to ID 123). After few more tests and combinations: 127.0.0.1-127.0.0.1, 502, ID 123 = Doesn't work 127.0.0.1-127.0.0.2, 502, ID 123 = Doesn't work 127.0.0.1-127.0.0.3, 502, ID 123 = It works 127.0.0.1-127.0.0.3, 502, ID 120-123 = Doesn't work 127.0.0.1-127.0.0.3, 502, ID 123-130 = It works 127.0.0.1-127.0.0.2, 502, ID 123-130 = Doesn't work

The test I did on-site with actual Modbus gateways but I got a lot of non-existing IDs. I'll test again at the office tomorrow and update later.

2. Do you need 32 bit Signed/Unsigned register values? I can add it in future releases. If you need this feature, please create a new issue for this feature.

@guy22israel: 32 bit registers are also very common in this field so I think it is important to have this, otherwise the tool might not be usable in all scenarios. i'll open a new ticket.

3. I suppose that this is a bug in pyModSlave. Beacause using OpenModScan with other simulators i don`t see the behavior you describe. But with original Modscan i see the same program behavior as my OpenModScan.

@guy22israel: I am not a software developer but maybe it is possible to enhance the comm. mechanism for compatibility purpose (as the manual disconnect/connect "fixes" this issue), so when changing the ID in the client, it will close and reopen the TCP socket connection or maybe disconnect/reconnect on the background to the new device ID. As long as the ID is not changed, connection stays opened.

4. OpenModScan repeats the functionality of the original Modscan. If you need this feature, please create a new issue with detailed description (preferably with screenshots) to implement this functionality. @guy22israel: Ok.

Thank you, Omer.

[guy22israel]

Hello,

I did some tests today at the office with a Modbus gateway and one Modbus/RTU device (ID 3).

Scanning the gateway's IP (10.0.50.100) with no results while the client can read data:

Extended the IP range (10.0.50.100-101). No result:

Added another IP to the range (10.0.50.100-102). Now The scanner will return IDs 1-10 even though only ID 3 is online: I guess that it shows IDs 1-10 because of the gateway's ID mapping: each ID requested from the TCP side is mapped/forwarded to a COM port. In other words, all requests are forwarded back and forth from the TCP side to the Serial side and vice versa. In my case, I configured IDs 1-10 to forward to COM1. For some reason the scanner "thinks" that all IDs are online. Maybe it interprets the replies in a different way that "tells" him that those IDs are online.

In the ZIP file there are some captures I took with WireShark. I noticed that if I disable Exceptions in the gateway, meaning all Exceptions are ignored, the scanner will not find any ID.

Also, I could also see the problem when I change the ID in the client while connected. when changing the ID back to the online device (ID 3), the client will not refresh the data. Even after few disconnect/connect it wasn't able to read anything. At some point data was shown. I never saw this behavior with other tools I used.

The files: OMS_WireShark_With exception_Without_Exception_2_Tests..pcapng: I tested twice with and without exceptions enabled. OMS_WireShark_With exception_Testing_IDs_1_3.pcapng: exceptions enabled, changing IDs between 1-3. OMS_WireShark_With exception_Testing_Different_IDs.pcapng: exceptions enabled, different IDs.

Thank you, Omer.

WireShark_Captures.zip

[sanny32]

Hello, Omer Thank you for detail description of the problem. I`ve found some problems in modbus tcp scanner algorithm. It will be fixed at next release.

[sanny32]

Problems with modbus tcp scanner was fixed at version 1.5.0. @guy22israel you can test it to give me feedback.

[guy22israel]

Hello @sanny32 ,

Thank you very much for the fast response and update.

I did some tests here (at home) with the regular enviroment: pyModSlave, ID 123.

The TCP scanner is indeed improved. The added functions seem to assist with finding the device I am simulating, yet there is still an issue. These willl not work:

But these are working:

Something with the ID range will not work correctly even though the slave's bus monitor shows the same replies for ID 123, so no matter if I scan e.g IDs 120-125 or 123-125, bus monitor shows the same reply for ID 123, meaning it is there.

It looks like scanning a range of IPs is ok, at least with the test I do here with only one IP. I'll have to do a deeper test on-site where I have many Modbus gateways. As I know what is connected to each gateway, it will be easier to investigate further more and see if the results are ok.

You will see that I changed the Modbus ports for my tests. For some reason the slave stopped responding/didn't allow to connect at some point, even when testing with other Modbus client, so it might be a slave issue.

So, for now it is the ID range issue for the scanner. I'll do some more tests when on-site with some real Modbus gateway. I'll update with the results.

Thank you, Omer.

[sanny32]

Hello, @guy22israel The pyModSlave program has a bug when modbus master send packets with different device id.

I recommend not to use this program to test modbus tcp scanner.

[guy22israel]

Ok. So when i'll be on-site I run some tests and report.

Thank you, Omer.

[guy22israel]

Hello,

I did more tests with the newest version 1.5.1-1 while on site.

In the picture below you can see all Modbus ID's connected to our Modbus gateway. All ID's are online and I can read them with both our system as well as OpenModScan client:

Yet, the TCP scanner will not return those ID's when I try to scan.

Attached are two WireShark logs: holding reg. scan and modbus ID slave scan. None return the ID's seen above.

For the holding register scan, in some scenarios when I changed the ID's range from 1-60 to e.g. 10-60, I can see that the scanner does return the actual ID's but they show on the same line one after another. Only one line appear in the scanner. It is a bit fast but I can see that it will return the actual ID's that are connected to the gateway (I can see it skips those that doesn't exist as there are gaps. e.g: 1-5, 11-16 etc.)

The modbus ID slave scan didn't return anything. Maybe the remote devices do not support this function.

To sum: the basic client works, the address scan works. I believe the RTU scanner also works. (I didn't yet had the opportunity to run tests. I'll test it in the next project I have very soon). The TCP scanner doesn't work...

Thank you, Omer.

wireshark_tcp_scan_holding_reg.zip wireshark_tcp_scan_report_slave_id.zip

[sanny32]

Hello @guy22israel Can you show me result (screenshot) of modbus tcp scan? And mark, what addresses are correct and incorrect.

[guy22israel]

Hello,

Maybe i'll make a short video showing what I am doing and what is seen while scanning, it will be easier to understand.

I'll try this next time and report back.

Omer.

[sanny32]

Try to use version 1.5.2 if possible.

[guy22israel]

Will do. Thanks.

Omer.