Electricity meters, controlled valves and gate valves, flow meters, vibration sensors, telemechanics devices.
Everything that can generate data or be controlled remotely and has an RS-232, RS-485 and RS-422 interface - works through these converters.
The general meaning of their use is usually as follows: forward the RS-232, RS-485 and RS-422 interfaces through an existing local network, connect a device or device having one of the serial interfaces to a PC (server, SCADA) via Ethernet, connect to the device having a serial interface via the Internet for remote control, etc.
Prices for these converters are not very high, younger models can be borrowed for $ 100-200. But considering that hundreds or even thousands can be installed on any automated production of such devices, a pretty tidbit is emerging for domestic “import substitutes”.
I'll try to help them today.
What do we do?
Firstly, we will understand the theory of how it is arranged inside.
Secondly, we isolate the minimum functionality to start working in Real Com Mode (that is, in fact, to forward the virtual COM port to the device via Ethernet).
Thirdly, for the sake of interest, we will analyze the protocol for searching and configuring the device through the NPort Administration Suite utility. We will get a full understanding of how to create a pin-to-pin analogue of a piece of iron that can be stuck in place of the existing MOXA Nport, while receiving full support from the native software and driver.
And finally - let's try to calculate how many Indians wrote the MOXA firmware code.
Part 1. Introductory
So, we have a test subject on our table (there were actually several of them, so don’t be surprised if you see different model identifiers and different MAC addresses in the article)
It has an Ethernet port and two RS-422 / RS-485 ports - this is physically.
And in the program plan - on the device are open:
UDP port 4800 - it is responsible for catching device search packets and sends data about the device itself to the configuration utility.
TCP port 4900 - it receives device configuration commands. The device’s time, name, IP address, operating mode, speed and port settings, and other basic parameters can be configured through this port, which can be configured through the NPort Administration Suite utility’s main interface:
TCP port 80 - is responsible for the operation of the WEB interface
TCP ports 966, 967, (and 968, 969 for 4 port devices) are transmission control ports. They run commands to open / close the corresponding COM port, set the port speed, push data, monitor the transmit / receive buffer fullness, etc. Port 966 is responsible for the operation of the first port, respectively.
TCP ports (default) 950, 951, (and 952, 953 for 4 port devices) are ports for direct data transfer. That is, what should directly appear on the RS-232/485/422 port of the device is transmitted to the data port. Only data flow control in this port goes to 966, 967, 968, 969 ports, respectively.
I hope the general picture of understanding the operation of the device in my head has developed. Let's move on to the next part:
Part 2. Emulate MOXA
Surely it has already become clear to many that in order to pretend to be MOXA Nport in the minimum configuration, it is necessary to raise a TCP server on its own hardware on 2 ports: 966 for transmission control and 950 for direct data transmission. Naturally, you will have to correctly answer and process driver requests on port 966, but as shown by wireshark analysis, there are not so many requests and they are the simplest.
In order not to overload the text of the article with calculations describing the requests and answers, I prepared and posted separately in the form of a pdf file a description of all parsed requests, answers and transmitted parameters.
Download: Description of the protocol parsing MOXA.pdf
That is, this set of knowledge allows you to implement a device that can be paired with a native driver and transmit data as MOXA. Half of the work has been completed, but there is one point - how to change the configuration? It would be great to use the native NPort Administration Suite utility for these purposes.
Part 3. Search and find
The first two parts described what needs to be done, but there was not a word about how to obtain data for the implementation of the protocols.
In this part, we dig a little deeper and see how the analysis of the exchange itself was carried out.
We know that UDP port 4800 is open on the device, let's connect the device, run NPort Administration Suite, Wireshark and see what happens when searching for devices with the native utility.
We look at the sent packets:
We see that the NPort Administration Suite sends a Broadcast to the address 255.255.255.255 that is, it hopes that the packet will fly across the network.
The payload package contains data:
01 00 00 08 00 00 00 00, : 01 00 – 00 08 – Big Endian. 00 00 00 00 –
This request is sent several times, apparently in the hope that at least one of them will achieve the goal.
All MOXs respond to this request.
Specifically, our replied:
81 00 00 18 00 00 00 00 12 03 00 80 32 03 00 90 e8 26 4a ab c0 a8 7f fe 81 00 – 00 18 – (24) 00 00 00 00 – 12 03 00 80 32 03 – MOXA Nport device, NPort 5232. MOXA Nport device. NPort Administrator. 00 90 e8 26 4a ab – MAC MOXA Nport device c0 a8 7f fe – IP MOXA Nport device ( 192.168.127.254 )
It seems that everything is elementary simple, confuses only the value 12 03 00 80 32 03, which is responsible for the interpretation of a specific model of the device.
But, since this value is checked against some reference reference, it means it must be stored somewhere.
Having studied the software directory a bit, we find that in NPort Administrator Suite v1.22 these values ​​are stored in the file C: \ Program Files \ NPortAdminSuite \ bin \ dsci.dll
After sitting with Wireshark and the device for several days, we get a complete exchange log and an understanding of what function codes that get in response. For convenience, everything found is described in the same pdf file, the link to which is indicated in the article earlier.
For a complete understanding of the picture - I’ll just remind you that UDP 4800 is receiving primary information about the device, all parameters that require configuration and installation are configured through requests for TCP port 4900.
Having correctly processed all incoming requests for 4800 and 4900 ports, we can fully pretend to be a device, so even native software will not notice the catch.
Part 4. Counting Indians *
During the analysis of the protocol, I had a feeling that different pieces of the exchange protocol were written by different people, the meaning of the functions and their interpretation are too different.
For example:
UDP port 4800 function codes begin with:
01 00 .. .. 81 00 .. .. 10 00 .. .. 90 00 .. .. 16 00 .. .. 96 00 .. .. 29 00 .. .. a9 00 .. ..
TCP port 4900 function codes begin with:
00 01 .. .. 00 01 .. .. 02 01 .. .. 02 01 .. ..
etc
TCP ports 966, 967, 968, 969 function codes begin with:
10 .. .. 10 4f 4b 11 .. .. 11 4f 4b
etc
That is, a single byte identifier of the function is used, and not a double byte as before.
Then, by the way, a funny moment came out. On ports 966, 967, 968, 969, the response to setting parameters always consists of 3 bytes.
The first is the function number, and the remaining 2 is 4f 4b or is there a look in the ASCII table - “O” “K”
Well OK with him, go ahead.
The second feature seen is a hash of Big and Little Endian within the same response.
Answer example:
9a 00 00 24 00 00 00 00 01 52 00 80 9a 52 00 90 e8 3b 89 9c 75 00 04 00 01 00 0f 00 09 00 17 00 36 00 00 00 9a 00 – 00 24 – (36) 00 00 00 00 – 01 52 00 80 9a 52 – MOXA Nport device 00 90 e8 3b 89 9c - MAC MOXA Nport device 75 00 - : 1900 + (1900 + 117 = 2017) 04 00 - : 1 - 01 00 – 0f 00 – (15) 09 00 – (9) 17 00 – (23) 36 00 – (36) 00 00 –
The packet size is encoded in one way, and all numerical values ​​(year, month, day ...) in another. From this we can conclude that the processing of the user part starting from 75 00 04 00 ....... was written by another programmer.
To summarize: At least 3 different people wrote the exchange protocol, 1 wrote the processing of the user part of the data, and at least 1 wrote the WEB interface handler. According to my calculations, about 5 programmers worked on the project.
How much did you count?
* In this case, the term “Hindu” means an employee who fulfills his duties for food and mortgages, is able to code from here and before lunch, without particularly delving into the global plans of the employer company.
PS This article was written on materials that were in development in 2017, so many of the data contain dating precisely this year. The protocols were analyzed within the framework of a working draft, but since the mind won out over marketing and the matter did not go beyond the stage of a single working prototype. I will publish all the developments on this project in the public domain, as I believe that this information will be useful to the developer community.
PPS Original article as always on my personal blog