chrisdutz closed pull request #12: fix a few typos URL: https://github.com/apache/incubator-plc4x/pull/12
This is a PR merged from a forked repository. As GitHub hides the original diff on merge, it is displayed below for the sake of provenance: As this is a foreign pull request (from a fork), the diff is supplied below (as it won't show otherwise due to GitHub magic): diff --git a/src/site/asciidoc/protocols/delta-v/reverse-engineering.adoc b/src/site/asciidoc/protocols/delta-v/reverse-engineering.adoc index 47ac51058..53211fa8c 100644 --- a/src/site/asciidoc/protocols/delta-v/reverse-engineering.adoc +++ b/src/site/asciidoc/protocols/delta-v/reverse-engineering.adoc @@ -28,7 +28,7 @@ We kindly were provided with access to a DeltaV system used for training. Therefore we were able to change a few things without fearing to break anything important. -This system consisted of tree DeltaV controllers, two Operator-System instances +This system consisted of three DeltaV controllers, two Operator-System instances So in general there were three types of systems involved: 1. DeltaV Controller @@ -156,6 +156,7 @@ During this we managed to reverse engineer the connection on the wrapper-protoco ==== Connecting When an OS is booted, the following communication could be observed: + 1. The OS sends a wrapper-protocol type `0x0003` to the controller. 2. The controller responds with a `0x0004` message back to the controller. 3. After receiving the `0x0004` message, the OS sends a type `0x0002` message with a wrapped type `0x0501` @@ -163,7 +164,7 @@ When an OS is booted, the following communication could be observed: 5. The controller sends a very similar packet as the `0x0501` packet back to the OS 6. The OS acknowledges this packet back to the controller -From looking at the packet in WireSharks byte and ASCII view, we could see ASCII characters that seem to relate to test strings. +From looking at the packet in WireShark's byte and ASCII view, we could see ASCII characters that seem to relate to test strings. A quick consultation of the guy in charge of these systems made us realize that these strings refer to parts of the controllers software. Digging even deeper made us realize that the 4 byte values relate to unix timestamps - at least we could decode the byte values to absolutely sensible dates. So it seems that In these packets each participant compares it's software state in order to know all are using compatible versions. @@ -198,9 +199,9 @@ So we started with the value 0 and incremented that in steps of 1 till 20 and th And we could see that there were certain parts of the packet that seem to change when changing values, most of the packet remaining constant. When changing a value back to the original value, the packets payload was identical in this part. -As the packets didn't all have the same content and some times blocksp were added and left away in regular intervals, lead us to the impression, that these packets too consist of a fixed packet header followed by blocks. +As the packets didn't all have the same content and some times blocks were added and left away in regular intervals, lead us to the impression, that these packets too consist of a fixed packet header followed by blocks. In our case the changing blocks all had two indicator bytes `0x0b08` with the 4 bytes after that changing according to the input. -Some times a block of bytes was added before this block, then the entire content was just pushed back. +Sometimes a block of bytes was added before this block, then the entire content was just pushed back. The last of such blocks would always be a sequence of 9 bytes: `0x01000000000000000000`, so we assume this is sort of the `terminating block` of such a packet. @@ -228,7 +229,7 @@ However when using what we learnt on the old captures we did, it turned out that So it seems that `0x08` indicates the type of an `signed 32 bit IEE 754 floating point value`. Eventually the `0x0b` part referred to some sort subscription-id. -As we seem to be doing a subscription based communication, the OS has to tell the controller what information he is interested in. +As we seem to be doing a subscription based communication, the OS has to tell the controller what information it is interested in. Right now we are assuming that in one of the other `0x04` packets a subscription is initiated and assigned with some sort of id and this id is used to identify which value is actually changed. diff --git a/src/site/site.xml b/src/site/site.xml index 472490e01..e2339a800 100644 --- a/src/site/site.xml +++ b/src/site/site.xml @@ -112,7 +112,7 @@ <menu name="Protocols"> <item name="Features" href="protocols/features.html"/> <item name="ADS" href="protocols/ads/index.html"/> - <item name="DelataV" href="protocols/delta-v/index.html"/> + <item name="DeltaV" href="protocols/delta-v/index.html"/> <item name="EtherNet/IP" href="protocols/ethernet-ip/index.html"/> <item name="Modbus" href="protocols/modbus/index.html"/> <item name="OPC-UA" href="protocols/opc-ua/index.html"/> ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services