I have captured the protocol analyzer logs from RS485 serial connection between RTU device and the equipment which is to be monitored. I am newbee to this. I have read through Modbus and RS485. Found that every frame will have Slave address, Function code, DATA and CRS with start and end of the frame of 305 charcaters. I am trying to decode the protocol analyzer logs but unable to get theu clue. Please help me on this.
These are the logs which I need to understand
=============================================================
Record = 1 05.23.15 13:29:29.000000000
RTS:OFF DTR:OFF CTS:OFF DSR:OFF CD:ON
Record = 2 (DTE) 05.23.15 13:29:29.127439596 00 NUL
Record = 3 (DTE) 05.23.15 13:29:29.127986496 37 7
Record = 4 (DTE) 05.23.15 13:29:29.128741696 17 ETB
Record = 5 (DTE) 05.23.15 13:29:29.129184396 ED ...
Record = 6 (DTE) 05.23.15 13:29:29.129757296 F2 ...
Record = 7 (DTE) 05.23.15 13:29:29.130486496 FD ...
Record = 8 (DTE) 05.23.15 13:29:29.131007296 D5 ...
Record = 9 (DCE) 05.23.15 13:29:29.559109485 91 ...
Record = 10 (DCE) 05.23.15 13:29:29.559630385 10 DLE
Record = 11 (DCE) 05.23.15 13:29:29.560151185 2F /
Record = 12 (DCE) 05.23.15 13:29:29.560678485 B0 ...
Record = 13 (DCE) 05.23.15 13:29:29.561199385 00 NUL
Record = 14 (DCE) 05.23.15 13:29:29.561720185 01 SOH
Record = 15 (DCE) 05.23.15 13:29:29.562247485 02 STX
Record = 16 (DCE) 05.23.15 13:29:29.562768385 00 NUL
Record = 17 (DCE) 05.23.15 13:29:29.563289185 01 SOH
Record = 18 (DCE) 05.23.15 13:29:29.563816485 0F SI
Record = 19 (DCE) 05.23.15 13:29:29.564337385 64 d
Record = 20 (DTE) 05.23.15 13:29:29.707291982 00 NUL
Record = 21 (DTE) 05.23.15 13:29:29.707838882 37 7
Record = 22 (DTE) 05.23.15 13:29:29.708594082 17 ETB
Record = 23 (DTE) 05.23.15 13:29:29.709036682 ED ...
Record = 24 (DTE) 05.23.15 13:29:29.709609682 F2 ...
Record = 25 (DTE) 05.23.15 13:29:29.710338782 FD ...
Record = 26 (DTE) 05.23.15 13:29:29.710859682 D5 ...
Record = 27 (DCE) 05.23.15 13:29:30.142926671 91 ...
Record = 28 (DCE) 05.23.15 13:29:30.143447471 10 DLE
Record = 29 (DCE) 05.23.15 13:29:30.143974871 2F /
Record = 30 (DCE) 05.23.15 13:29:30.144495671 B0 ...
Record = 31 (DCE) 05.23.15 13:29:30.145016471 00 NUL
Record = 32 (DCE) 05.23.15 13:29:30.145543871 01 SOH
Record = 33 (DCE) 05.23.15 13:29:30.146064671 02 STX
Record = 34 (DCE) 05.23.15 13:29:30.146585471 00 NUL
Record = 35 (DCE) 05.23.15 13:29:30.147112871 01 SOH
Record = 36 (DCE) 05.23.15 13:29:30.147633671 0F SI
Record = 37 (DCE) 05.23.15 13:29:30.148154470 64 d
Record = 38 (DTE) 05.23.15 13:29:30.287254967 00 NUL
Record = 39 (DTE) 05.23.15 13:29:30.287801867 37 7
=============================================================
Looking at the time stamps, this seems to be one message:
91 10 2F B0 00 01 02 00 01 0F 64. It actually appears twice in your log.
The interpretation should be:
91 Slave address (145 dec)
10 Function code (16 dec) = Write registers
2F Start address (Most significant byte)
B0 Start address (Least significant byte)
00 Number of registers (Most significant byte)
01 Number of registers (Least significant byte)
02 Byte count (2 bytes will follow)
00 Data (Most significant byte)
01 Data (Least significant byte)
0F CRC (checksum)
64 CRC (checksum)
It is a message from the master (computer) to a slave (instrument). Basically it says: Write one register on instrument with slave address 145. The register address is 2FB0 (hex), and the data value is 0001 (hex).
I have written about how to interpret Modbus RTU messages in the documentation of my Python Minimalmodbus module:
https://minimalmodbus.readthedocs.org/en/master/modbusdetails.html
https://minimalmodbus.readthedocs.org/en/master/debugmode.html
What information register 2FB0 (hex) holds is described in the documentation of your instrument.
Related
From a file that I'm trying to decode, I have the following data and his corresponding timestamps:
05/21/2022 12:30:00.000 PM
62 d9 d0 58 31 44 89 c4 00 00 00 00
8/24/2022 12:15:00.000 PM
62 fd 6f 58 31 83 27 42 00 00 00 00
First 4 bytes are close to the unix timestamp representation but just close
I think byte 31 is a separator but not sure
Please help! :)
If you take some of the bytes and multiply by 2, you can recreate the Unix timestamp.
For example,
05/21/2022 12:30:00 PM => 31 44 89 c4 => 826575300 x 2 => 1653150600 => 2022-05-21 16:30:00
8/24/2022 12:15:00 PM => 31 83 27 42 => 830678850 x 2 => 1661357700 => 2022-08-24 16:15:00
Note: data seems to be shifted 4 hours (Chile = GMT-4)
Did you tried the INT96 format?
that's an 12 byte representation
I am using a REINER SCT cyberJack RFID standard card reader and an estonian ID card.
pcsc_scan correctly identifies the card:
$ pcsc_scan
PC/SC device scanner
V 1.5.2 (c) 2001-2017, Ludovic Rousseau <ludovic.rousseau#free.fr>
Using reader plug'n play mechanism
Scanning present readers...
0: REINER SCT cyberJack RFID standard (9084002233) 00 00
Wed Mar 13 14:02:39 2019
Reader 0: REINER SCT cyberJack RFID standard (9084002233) 00 00
Card state: Card inserted,
ATR: 3B DB 96 00 80 B1 FE 45 1F 83 00 12 23 3F 53 65 49 44 0F 90 00 F1
ATR: 3B DB 96 00 80 B1 FE 45 1F 83 00 12 23 3F 53 65 49 44 0F 90 00 F1
+ TS = 3B --> Direct Convention
+ T0 = DB, Y(1): 1101, K: 11 (historical bytes)
TA(1) = 96 --> Fi=512, Di=32, 16 cycles/ETU
250000 bits/s at 4 MHz, fMax for Fi = 5 MHz => 312500 bits/s
TC(1) = 00 --> Extra guard time: 0
TD(1) = 80 --> Y(i+1) = 1000, Protocol T = 0
-----
TD(2) = B1 --> Y(i+1) = 1011, Protocol T = 1
-----
TA(3) = FE --> IFSC: 254
TB(3) = 45 --> Block Waiting Integer: 4 - Character Waiting Integer: 5
TD(3) = 1F --> Y(i+1) = 0001, Protocol T = 15 - Global interface bytes following
-----
TA(4) = 83 --> Clock stop: state H - Class accepted by the card: (3G) A 5V B 3V
+ Historical bytes: 00 12 23 3F 53 65 49 44 0F 90 00
Category indicator byte: 00 (compact TLV data object)
Tag: 1, len: 2 (country code, ISO 3166-1)
Country code: 23 3F
Tag: 5, len: 3 (card issuer's data)
Card issuer data: 65 49 44
Mandatory status indicator (3 last bytes)
LCS (life card cycle): 0F (unknown)
SW: 9000 (Normal processing.)
+ TCK = F1 (correct checksum)
Possibly identified card (using /home/mag/.cache/smartcard_list.txt):
3B DB 96 00 80 B1 FE 45 1F 83 00 12 23 3F 53 65 49 44 0F 90 00 F1
Estonia ID-card (eID)
https://id.ee
however pkcs11-tool does not see the card:
$ pkcs11-tool --module /usr/lib/x86_64-linux-gnu/opensc-pkcs11.so -L
Available slots:
Slot 0 (0x0): REINER SCT cyberJack RFID standard (9084002233) 00 00
(empty)
What can be the cause of the problem? What do I miss?
Apparently the toolchain of the estonian card is not compatible with pkcs-11. However the chrome-token-signing package contains the needed code at least for authentication to their service both for chromium and firefox, and the qdigidoc4 package contains a tool to create and check signed/encrypted documents.
Their repo is here:
deb https://installer.id.ee/media/ubuntu/ bionic main
Another issue I have encountered that my cert is said to be invalid. That was because the certificate won't get enabled right away when you receive your ID.
I'm trying to send Eddystone UID packets with my hcitool but I cannot find it via my BLE scanner(I can find another Eddystone UID beacons around with my BLE scanner and also I can find my Eddystone URLthat has been sent with my hcitool). my command: sudo hcitool -i hci0 cmd 0x08 0x0008 1e 02 01 06 03 03 aa fe 15 16 aa fe 00 e7 43 f2 ac d1 4a 82 8e a1 2c 30 11 11 11 11 11 11 could you let me know if I'm wrong about it?
you forgot the final RFU bytes at the end of the UID so the command should be
sudo hcitool -i hci0 cmd 0x08 0x0008 1f 02 01 06 03 03 aa fe 17 16 aa fe 00 e7 43 f2 ac d1 4a 82 8e a1 2c 30 11 11 11 11 11 11 00 00
I can read UDP packet using
void my_callback(u_char *useless, const struct pcap_pkthdr* pkthdr, const u_char* packet)
I have hexa output of my packet:
08 00 27 E5 B5 3B 52 54 00 12 35 02 08 00 45 00 00 4C 7C E7 00 00 40 11 3C 28 5B BD 59 C6 0A 00 02 0F 00 7B 00 7B 00 38 B7 9D 24 02 03 E8 00 00 04 A8 00 00 07 51 83 BC 03 DC DC C5 CC 47 F1 F1 69 C3 DC C5 CF 37 D2 5F A7 F5 DC C5 CF 38 3C 2D C2 CF DC C5 CF 38 3C 32 0B 9A
I know, that it is NTP packet.
How can I extrath data? Cut ethernet frames, etc..
Thank you for your help.
I am using pcap c++.
If you read pcap you get raw packet from the network device. Several options may be there:
Packet is read from ethernet device
Packet is read from vlan device
Packet is read from some other device
What kind of device is used during pcap defines what protocol header is first in your packet. To know it you can look at link layer type field of global pcap header.
Once you defined first protocol header you need to open protocol specification and find:
Size of header (in your case it looks like regular ethenet header - 14 bytes 08 00 27 E5 B5 3B 52 54 00 12 35 02 08 00)
How to find encapsulated packet type (in your case last 08 00 means IP)
Once you found IP header (45 00 00 4C 7C E7 00 00 40 11 ...) you can determine IP header length:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| IHL |Type of Service| Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |Flags| Fragment Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to Live | Protocol | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Address |
Here you need:
IHL defines sizeof IP header. This is lower 4 bits of first byte of IP header. In your case it is 0x5. This means 5 words or 20 bytes.
Protocol defines what data is encapsulated in IP header. In your case 0x11 (IPPROTO_UDP)
After that you can get UDP header (8 bytes) check ports if you need it and parse NTP header in according to NTP specification.
In your example total shift of the NTP header will be 14+20+8 bytes.
I've been working on Midi file for some time and I stuck on some kind of status byte of thing. According to the standard Midi file format there is no such a things. So, Can someone tell what is this 3 bytes information "00 a040". I know that "00" is the byte stands for delta time and 0xa0 should be status byte, If only I understood it correctly. Last 3 bytes located at line 18 is the only part I don't understand so far. After those 3 bytes, then comes the text meta event bytes lead by "00 ff01".
Midi File Line 18th to 19th:
ff 51 03 09 cc 90 00 c0 00 00 b0 07 64 00 0a 40
00 ff 01 20 62 64 63 61 34 32 36 64 31 30 34 61
The SMF specification says:
Running status is used: status bytes of MIDI channel messages may be omitted if the preceding event is a MIDI channel message with the same status.
So these bytes can be decoded as follows:
ff 51 03 09 cc 90: meta event: set tempo, 9CC90h = 642192 µs per quarter note
00: delta time
c0 00: set program 0 (piano) on channel 0
00: delta time
b0 07 64: set controller 7 (volumn) to value 100
00: delta time
0a 40: running status (repeat B0h); set controller 10 (expression) to value 64
00: delta time
ff 01 20 ...: meta event: text: "bdca426d104a..."