Hello
In Austria we got a new Smartmeter from the Manufacturer KAIFA (ShenZen?).
Can you include this Manufacturer in DLMSDirector in the future?
The Data I receive via Wired-M-Bus contain 2 Telegrams (starting 68FA /6872 .. ending ..16)
The 1. Telegram contains a Header with a lot of infos (length, Sys-T, SC, IC...), the 2. Telegram has just a short Header for (6872726853FF110167) but ist still added in your Data an therefor ends earlier as expected!
I also have a Kaifa smart meter in Austria and I was able to read the telegrams from the M-Bus master with an ESP32:
Example #1:
68 FA FA 68 53 FF 00 01 67 DB 08 4B 46 4D 10 20 00 78 40 82 01 55 21 00 00 C4 4A F7 17 5C 82 73 80 52 3E 91 C7 27 09 EB DC DD 0F 6B 3B EB FC 6A 97 48 0A 69 69 EC 15 B9 C6 1F 6E 06 60 07 3C 28 F1 97 73 13 7A B7 73 01 6D 7E ED 02 03 99 A5 61 AF 88 5C 01 13 DA 47 DA 75 37 B7 CB 90 68 FA 1C 25 61 82 CA 65 CE 8D 59 6C 6E 78 72 CA 57 AF FF 08 68 36 ED 5B 91 E7 BA 44 4B AD 40 95 9F 6A 44 5C 1D 0C D1 54 CF 75 9C 21 04 56 D4 99 F8 69 47 27 CC D1 DD 09 A7 CD F1 1F 79 09 64 B1 1F 14 DD D3 C7
Example #2:
68 FA FA 68 53 FF 00 01 67 DB 08 4B 46 4D 10 20 00 78 40 82 01 55 21 00 00 C4 4B 12 53 53 EE 56 FE 26 94 81 FB 63 05 AB F1 A6 D9 FB CD 94 5F 6B 58 FF BD 4A 81 69 4C 78 C1 C3 B3 70 CF AD F8 4A 4C 29 F0 C6 BC ED 01 0B 39 EA 5E 00 A0 20 FB FD F9 E6 00 12 72 90 B8 2B 9E 64 C4 F1 A4 F2 F0 8E 45 C8 AC B4 2B 34 76 76 2F EB 2F 4C B2 94 23 49 F0 B8 12 98 DE 13 60 95 B7 4B C2 6E 40 08 7A 15 73 4C BF F5 D8 37 98 81 CA AA B6 5E 56 CF 97 48 9C 66 1C C1 5B BC B5 9C 21 05 46 05 66 91 7E AB D5 98
They look very similar to what was posted by KFM_chris, altough I think there is only a single telegram in there.
Ideally I would be able to decode these directly on the ESP but I'm also fine with sending it somewhere else for decoding.
I tried decoding them with the GXDLMSDirector but there is no WiredMBus interface type in the application for me, I assume I need a newer version?
My provider gave me the key and these details about the encryption:
Protocol:
Version:DLMS / COSEM, IDIS CII
Security Standard:
Security Suite:Security Suite 1
Security Profil: Security profile B (OMS Standard)
Encryption: AES128-CBC
Key: Global Unicast Encryption Key
Authentication: CMAC (8 Byte trunc)(MAC-Mode AT=5)
Not sure if they really meant CBC since Security Suite 1 only mentions GCM but who knows. Using the DLMS Green Book excerpt I was able to find some fields but it's hard to decrypt the data without knowing exactly where to find the IV. It's easy to find the invocation counter but everything before that is just gibberish without the protocol details.
Start GXDLMSDirector and select "Tools" and "DLMS Translator". If you paste Chris's frame you can see the result. If you paste your frame you don't see anything. The reason is that there are bytes missing. In Chris's frame there are 394 bytes and in in your example frame there are only 162 bytes. You need to read more bytes to get the correct frame.
If you set the correct block cipher key in Ciphering tab, you can see the decrypted result.
Adding my key in block cipher key in the ciphering tab like you said still leads the same result, so that's progress but I assume the message still can't be decrypted?
Each Telegram starts with 68 FA FA 68 (Telegram1) and 68 72 72 68 (Telegram2) and ends with CRCbyte and 0x16.
The first 27 Bytes are the Header for the whole Msg.
SysTitle:12-19
IC:24-27
IV:SysT+IC (12 Bytes)
CipherText: 28-254(Telegram1=227Bytes) + 10-118(Telegram2=109Bytes) ->336
Maybe it helps.
Yes, one go. The Header of 2. Telegram is just 9 Bytes long and has no more Infos.
The Ciphertext to Decrypt is 336 Bytes! with GCM.
There is no Tag needed. (Green Book Ed9 Excerpt Page 79) because SC=0x21 (Byte 23).
The Message sent by KFM is 376 Bytes long and consists 2(!) Telegrams.
The 2. Telegram starts at Pos 257 with 68 72 72 68.. and is 120 Bytes long.
Without the Header (9Bytes) + CRC + Stop (0x16) the CipherText of the 2. Telegram is 109 Bytes long and must be concatenated with the ChipherText of the 1. Telegram, which ist 227 Bytes long.
In GXDLMSDirector these 2 parts of the CipherText (336 Bytes) are not combined correctly.
The whole Message will be sent together with 376 Bytes.
The first Telegram always starts with 68 FA.. and a long Header (27 Bytes).
CI-Byte (pos 7) is 00 in the 1. Telegram and 11 in the 2.
Bytes 21+22 (01 55 = 341) minus 5 (maybe length of SC (23) and IC (24-27) or length of C-Field(5-9) tells you the length of the whole Ciphertext = 336.
Bytes 10 + 11 (DB + 08 = 227) give the length of the Ciphertext of Telegram1.
I just dont know what Byte 20 (= 0x82) is used for.
This is now fixed. I didn't notest that there are two telegrams (frames) and because the message is ciphered I didn't notest anything strange. Parser is fixed and it can handle multiple telegrams.
I have just seen the new version of GXDLMSDirector.
There is still a mistake in the amount of the Ciphertext. Your version has 341 Bytes, but there should be only 336 Bytes. You included the SC-Byte and the IC, which is 4 Bytes long.
The Header of the first Telegram is 27 Bytes! The Ciphertext of the 1. Telegram is 227 Bytes, the Ciphertext of 2. Telegram is 109, so together it must be 336.
thanks for the information about the 2 telegrams, this was the missing information I needed to decrypt it.
I have a KAIFA MA309 from the Austrian Energy Company EVN and finally got my key.
I can confirm that the cyphertext of this Meter does not include the frame-counter.
For these 2 Frames the init_vector = "4b464d6550997b02 + 00001439"
and the cypertext is:
frame = "b9750c72d83273f48f686d1e0eab7428d01fca56ebc2f3d0035716abba09458104c75dd85ff54608a8904df77bfea544929ce20076ce175a4277fd72e9abb9f8ee8b745f7bc797533b09255ae680c7d6c6a84c830ae34b514bbfaf278ca9f5d290079586fad63c76d3791884502e9b23c1249f94666d55bdf164674cc9e77da450ce6eb0b1b47f034a87120343c9953db1303d1169875ee6f2d44ac7c684177a5e515f37f885b4915c6d3af1ac954d4453ddedc625ae63fbfab39eecd8875be5861a7694771856a9516a2ffabe2939288eaa3a7e780df9dc6f288daf03997c5ca63f46d3551e48fcbabec8fbdfde58194c3b90"
Could you give me some advice how I could decode and check the cyphertext of these two telegrams with the gurux python library (check the Checksum & lengths fields etc..)
So far I have observed that the meter sends these two telegrams as a single Byte-String every 5 seconds .
Please, create a new topic if you have a new question. Create a new topic and I'll answer there. It's hard to remember what was the original question if there are multiple questions in the same topic.
But, you are wrong. There is a frame counter for each PDU and it's increased every time when the new message is sent.
Hello
Hello
I found the missing link, now it works fine in my program.
BR, Christian
Hi Christian,
Hi Christian,
I'm sorry for the slow reply. We are a little bit busy with the new version of Gurux.DLMS,AMI at the moment.
You should be able to show received data in GXDLMSDirector if you change the interface type to WiredMBus.
Let me know if you have any problems.
BR,
Mikko
Hey there,
Hey there,
I also have a Kaifa smart meter in Austria and I was able to read the telegrams from the M-Bus master with an ESP32:
Example #1:
68 FA FA 68 53 FF 00 01 67 DB 08 4B 46 4D 10 20 00 78 40 82 01 55 21 00 00 C4 4A F7 17 5C 82 73 80 52 3E 91 C7 27 09 EB DC DD 0F 6B 3B EB FC 6A 97 48 0A 69 69 EC 15 B9 C6 1F 6E 06 60 07 3C 28 F1 97 73 13 7A B7 73 01 6D 7E ED 02 03 99 A5 61 AF 88 5C 01 13 DA 47 DA 75 37 B7 CB 90 68 FA 1C 25 61 82 CA 65 CE 8D 59 6C 6E 78 72 CA 57 AF FF 08 68 36 ED 5B 91 E7 BA 44 4B AD 40 95 9F 6A 44 5C 1D 0C D1 54 CF 75 9C 21 04 56 D4 99 F8 69 47 27 CC D1 DD 09 A7 CD F1 1F 79 09 64 B1 1F 14 DD D3 C7
Example #2:
68 FA FA 68 53 FF 00 01 67 DB 08 4B 46 4D 10 20 00 78 40 82 01 55 21 00 00 C4 4B 12 53 53 EE 56 FE 26 94 81 FB 63 05 AB F1 A6 D9 FB CD 94 5F 6B 58 FF BD 4A 81 69 4C 78 C1 C3 B3 70 CF AD F8 4A 4C 29 F0 C6 BC ED 01 0B 39 EA 5E 00 A0 20 FB FD F9 E6 00 12 72 90 B8 2B 9E 64 C4 F1 A4 F2 F0 8E 45 C8 AC B4 2B 34 76 76 2F EB 2F 4C B2 94 23 49 F0 B8 12 98 DE 13 60 95 B7 4B C2 6E 40 08 7A 15 73 4C BF F5 D8 37 98 81 CA AA B6 5E 56 CF 97 48 9C 66 1C C1 5B BC B5 9C 21 05 46 05 66 91 7E AB D5 98
They look very similar to what was posted by KFM_chris, altough I think there is only a single telegram in there.
Ideally I would be able to decode these directly on the ESP but I'm also fine with sending it somewhere else for decoding.
I tried decoding them with the GXDLMSDirector but there is no WiredMBus interface type in the application for me, I assume I need a newer version?
My provider gave me the key and these details about the encryption:
Protocol:
Version:DLMS / COSEM, IDIS CII
Security Standard:
Security Suite:Security Suite 1
Security Profil: Security profile B (OMS Standard)
Encryption: AES128-CBC
Key: Global Unicast Encryption Key
Authentication: CMAC (8 Byte trunc)(MAC-Mode AT=5)
Not sure if they really meant CBC since Security Suite 1 only mentions GCM but who knows. Using the DLMS Green Book excerpt I was able to find some fields but it's hard to decrypt the data without knowing exactly where to find the IV. It's easy to find the invocation counter but everything before that is just gibberish without the protocol details.
Any pointers?
Best regards
Dominik
Hi Dominik,
Hi Dominik,
Start GXDLMSDirector and select "Tools" and "DLMS Translator". If you paste Chris's frame you can see the result. If you paste your frame you don't see anything. The reason is that there are bytes missing. In Chris's frame there are 394 bytes and in in your example frame there are only 162 bytes. You need to read more bytes to get the correct frame.
If you set the correct block cipher key in Ciphering tab, you can see the decrypted result.
BR,
Mikko
Hey Mikko,
Hey Mikko,
thanks, you were right. I attached my Logic Analyzer and got more bytes than the ESP read, I now read 376 bytes:
68 FA FA 68 53 FF 00 01 67 DB 08 4B 46 4D 10 20 00 78 40 82 01 55 21 00 00 E5 54 7F E6 80 4B EE FE 35 29 9E 6E BD 48 A8 BF A9 A5 A0 D1 D8 00 E1 69 D7 3A 06 F0 E9 7C F3 ED 24 B2 1E 94 9F 7E 76 DD 22 55 FF 2D 7D 05 52 48 F5 68 98 76 86 3E 1F C0 B0 D4 F0 F3 75 1E A2 19 87 79 97 89 94 FA A1 B6 3A 30 19 86 38 E2 44 ED 65 44 49 8D 7C 7F 8B 4F 2F 61 83 E0 86 CD A4 A8 3D 45 85 DD C4 E4 F9 3F E4 B9 95 DE B5 88 27 23 99 68 EB BC B8 83 37 09 14 6C 4E E3 14 7E 40 18 DC 9E 42 39 55 CE BF 2D BF 73 EF 4F 61 90 EE D1 9F FC 53 A6 67 F8 13 85 22 AE 44 0C 57 B6 C4 E5 FD 43 4B DF F2 F6 E9 33 5E 12 20 63 07 97 9F FC 35 DE EB 9A 3A 6E 05 5E 1E EF D1 B7 DC 55 6A D6 97 AF 4D 06 F5 B0 14 85 71 23 EA 88 A3 8C D2 88 08 4D 6D 0C 87 0F 5A 7E 42 8A 31 14 9D E4 BD C0 EC BF AA A0 94 88 16 68 72 72 68 53 FF 11 01 67 75 D9 10 4A 5C 1E 37 43 71 08 B3 E0 F5 DF DE 22 6D BF 09 73 F8 22 04 5F 15 3E 53 83 D4 8D 87 6B 81 CF 12 73 CD 59 EC 0E F4 80 20 A1 88 B5 05 F3 D8 78 EF 28 43 D7 B1 84 1F 95 DF 8B 2F 42 01 4C 25 D7 13 97 E3 A6 B6 05 53 2E 91 EC CA 11 BB D3 FD A2 4A 77 D0 54 7B DF B4 70 A3 51 46 0A FB 96 00 2E DB 59 C0 1D 25 FB D5 9A 15 EE 42 14 16
This parses correctly now with the DLMS Translator:
<WiredMBus len="178" >
<TargetAddress Value="67" />
<SourceAddress Value="1" />
<!-- Command: SndUd -->
<!-- A-Field: 255 -->
<!-- CI-Field: 0 -->
<!-- Primary station: 103 -->
<!-- Secondary station: 1 -->
<PDU>
<GeneralGloCiphering>
<SystemTitle Value="4B464D1020007840" />
<CipheredService Value="210000E5547FE6804BEEFE35299E6EBD48A8BFA9A5A0D1D800E169D73A06F0E97CF3ED24B21E949F7E76DD2255FF2D7D055248F5689876863E1FC0B0D4F0F3751EA2198779978994FAA1B63A30198638E244ED6544498D7C7F8B4F2F6183E086CDA4A83D4585DDC4E4F93FE4B995DEB58827239968EBBCB8833709146C4EE3147E4018DC9E423955CEBF2DBF73EF4F6190EED19FFC53A667F8138522AE440C57B6C4E5FD434BDFF2F6E9335E12206307979FFC35DEEB9A3A6E055E1EEFD1B7DC556AD697AF4D06F5B014857123EA88A38CD288084D6D0C870F5A7E428A31149DE4BDC0ECBFAAA09488166872726853FF11016775D9104A5C1E37437108B3E0F5DFDE226DBF0973F822045F153E5383D48D876B81CF1273CD59EC0EF48020A188B505F3D878EF2843D7B1841F95DF8B2F42014C25D71397E3A6B605532E91ECCA11BBD3FDA24A77D0547BDFB470A351460AFB96002E" />
</GeneralGloCiphering>
</PDU>
</WirelessMBus>
Adding my key in block cipher key in the ciphering tab like you said still leads the same result, so that's progress but I assume the message still can't be decrypted?
Best regards
Dominik
Hi Dominik,
Hi Dominik,
Each Telegram starts with 68 FA FA 68 (Telegram1) and 68 72 72 68 (Telegram2) and ends with CRCbyte and 0x16.
The first 27 Bytes are the Header for the whole Msg.
SysTitle:12-19
IC:24-27
IV:SysT+IC (12 Bytes)
CipherText: 28-254(Telegram1=227Bytes) + 10-118(Telegram2=109Bytes) ->336
Maybe it helps.
Hey Christian,
Hey Christian,
yes, that helps a lot.
Do I need to decrypt telegram 1 and 2 in one go without getting the IV from the second telegram header for the second ciphertext?
Since the IV is 12 bytes in size I assume the encryption used really is AES128-GCM and the specifications from my provider are wrong?
For GCM I still need the tag for decryption, any idea where that is?
From the info you gave me I computed these bytes for the data I posted above:
Key: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 (from my provider, 16 bytes)
IV: 4B 46 4D 10 20 00 78 40 00 00 E5 54
Tag: ?
Ciphertext: 7F E6 80 4B EE FE 35 29 9E 6E BD 48 A8 BF A9 A5 A0 D1 D8 00 E1 69 D7 3A 06 F0 E9 7C F3 ED 24 B2 1E 94 9F 7E 76 DD 22 55 FF 2D 7D 05 52 48 F5 68 98 76 86 3E 1F C0 B0 D4 F0 F3 75 1E A2 19 87 79 97 89 94 FA A1 B6 3A 30 19 86 38 E2 44 ED 65 44 49 8D 7C 7F 8B 4F 2F 61 83 E0 86 CD A4 A8 3D 45 85 DD C4 E4 F9 3F E4 B9 95 DE B5 88 27 23 99 68 EB BC B8 83 37 09 14 6C 4E E3 14 7E 40 18 DC 9E 42 39 55 CE BF 2D BF 73 EF 4F 61 90 EE D1 9F FC 53 A6 67 F8 13 85 22 AE 44 0C 57 B6 C4 E5 FD 43 4B DF F2 F6 E9 33 5E 12 20 63 07 97 9F FC 35 DE EB 9A 3A 6E 05 5E 1E EF D1 B7 DC 55 6A D6 97 AF 4D 06 F5 B0 14 85 71 23 EA 88 A3 8C D2 88 08 4D 6D 0C 87 0F 5A 7E 42 8A 31 14 9D E4 BD C0 EC BF AA A0 94 75 D9 10 4A 5C 1E 37 43 71 08 B3 E0 F5 DF DE 22 6D BF 09 73 F8 22 04 5F 15 3E 53 83 D4 8D 87 6B 81 CF 12 73 CD 59 EC 0E F4 80 20 A1 88 B5 05 F3 D8 78 EF 28 43 D7 B1 84 1F 95 DF 8B 2F 42 01 4C 25 D7 13 97 E3 A6 B6 05 53 2E 91 EC CA 11 BB D3 FD A2 4A 77 D0 54 7B DF B4 70 A3 51 46 0A FB 96 00 2E DB 59 C0 1D 25 FB D5 9A 15 EE 42
Best regards
Dominik
Hi Dominik,
Hi Dominik,
Yes, one go. The Header of 2. Telegram is just 9 Bytes long and has no more Infos.
The Ciphertext to Decrypt is 336 Bytes! with GCM.
There is no Tag needed. (Green Book Ed9 Excerpt Page 79) because SC=0x21 (Byte 23).
Hi Christian and Dominik,
Hi Christian and Dominik,
Can you post an example from Telegram2? I want to see what it looks like.
BR,
Mikko
Hi Mikko
Hi Mikko
The Message sent by KFM is 376 Bytes long and consists 2(!) Telegrams.
The 2. Telegram starts at Pos 257 with 68 72 72 68.. and is 120 Bytes long.
Without the Header (9Bytes) + CRC + Stop (0x16) the CipherText of the 2. Telegram is 109 Bytes long and must be concatenated with the ChipherText of the 1. Telegram, which ist 227 Bytes long.
In GXDLMSDirector these 2 parts of the CipherText (336 Bytes) are not combined correctly.
Hi Christian,
Hi Christian,
Thank you for this information. I believe that this is now solved. This is tested with some other meters and I'll let you know.
BR,
Mikko
Hi Mikko,
Hi Mikko,
The whole Message will be sent together with 376 Bytes.
The first Telegram always starts with 68 FA.. and a long Header (27 Bytes).
CI-Byte (pos 7) is 00 in the 1. Telegram and 11 in the 2.
Bytes 21+22 (01 55 = 341) minus 5 (maybe length of SC (23) and IC (24-27) or length of C-Field(5-9) tells you the length of the whole Ciphertext = 336.
Bytes 10 + 11 (DB + 08 = 227) give the length of the Ciphertext of Telegram1.
I just dont know what Byte 20 (= 0x82) is used for.
Hey Christian,
Hey Christian,
thanks for the response. My previous library was not able to do GCM decryption without a tag.
Switching the library to one that supports CTR mode I'm now able to decrypt my data and see my OBIS codes.
Now i just need to decode the OBIS codes and implement it on the ESP and I'm good to go.
Thanks a lot you 2, would probably never have figured out that there's 2 telegrams hidden in there without this thread.
Best regards
Dominik
Hi Christian and Dominik,
Hi Christian and Dominik,
This is now fixed. I didn't notest that there are two telegrams (frames) and because the message is ciphered I didn't notest anything strange. Parser is fixed and it can handle multiple telegrams.
The new version is released this week.
BR,
Mikko
Hi Mikko
Hi Mikko
I have just seen the new version of GXDLMSDirector.
There is still a mistake in the amount of the Ciphertext. Your version has 341 Bytes, but there should be only 336 Bytes. You included the SC-Byte and the IC, which is 4 Bytes long.
The Header of the first Telegram is 27 Bytes! The Ciphertext of the 1. Telegram is 227 Bytes, the Ciphertext of 2. Telegram is 109, so together it must be 336.
Hi Christian,
Hi Christian,
DLMS standard defines that SC-byte and IC are included in the Telegram. It works with all other meters.
BR,
Mikko
Hallo domi2410
Hallo domi2410
"Switching the library to one that supports CTR mode I'm now able to decrypt my data and see my OBIS codes."
welche library hast du da verwendet? wie hast du es geschafft zu den OBIS Codes zu kommen?
mbedtls/gcm.h
mbedtls/gcm.h
I made my entire ESPHome component available here:
https://github.com/DomiStyle/esphome-dlms-meter
congratulation, very cool
congratulation, very cool
Hi,
Hi,
thanks for the information about the 2 telegrams, this was the missing information I needed to decrypt it.
I have a KAIFA MA309 from the Austrian Energy Company EVN and finally got my key.
It sends out two telegrams like this:
68fafa6853ff000167db084b464d6550997b0281f82000001439b9750c72d83273f48f686d1e0eab7428d01fca56ebc2f3d0035716abba09458104c75dd85ff54608a8904df77bfea544929ce20076ce175a4277fd72e9abb9f8ee8b745f7bc797533b09255ae680c7d6c6a84c830ae34b514bbfaf278ca9f5d290079586fad63c76d3791884502e9b23c1249f94666d55bdf164674cc9e77da450ce6eb0b1b47f034a87120343c9953db1303d1169875ee6f2d44ac7c684177a5e515f37f885b4915c6d3af1ac954d4453ddedc625ae63fbfab39eecd8875be5861a7694771856a9516a2ffabe2939288eaa3a7e780df9dc6f288daf03997c5ca63f46d3a916
6814146853ff110167551e48fcbabec8fbdfde58194c3b900216
I can confirm that the cyphertext of this Meter does not include the frame-counter.
For these 2 Frames the init_vector = "4b464d6550997b02 + 00001439"
and the cypertext is:
frame = "b9750c72d83273f48f686d1e0eab7428d01fca56ebc2f3d0035716abba09458104c75dd85ff54608a8904df77bfea544929ce20076ce175a4277fd72e9abb9f8ee8b745f7bc797533b09255ae680c7d6c6a84c830ae34b514bbfaf278ca9f5d290079586fad63c76d3791884502e9b23c1249f94666d55bdf164674cc9e77da450ce6eb0b1b47f034a87120343c9953db1303d1169875ee6f2d44ac7c684177a5e515f37f885b4915c6d3af1ac954d4453ddedc625ae63fbfab39eecd8875be5861a7694771856a9516a2ffabe2939288eaa3a7e780df9dc6f288daf03997c5ca63f46d3551e48fcbabec8fbdfde58194c3b90"
Decryption worked with
frame = unhexlify(frame)
encryption_key = unhexlify(evn_schluessel)
init_vector = unhexlify(systemTitel + frameCounter)
cipher = AES.new(encryption_key, AES.MODE_GCM, nonce=init_vector)
apdu = cipher.decrypt(frame).hex()
Could you give me some advice how I could decode and check the cyphertext of these two telegrams with the gurux python library (check the Checksum & lengths fields etc..)
So far I have observed that the meter sends these two telegrams as a single Byte-String every 5 seconds .
Thanks & best regards
Joli
Hi Joli,
Hi Joli,
Please, create a new topic if you have a new question. Create a new topic and I'll answer there. It's hard to remember what was the original question if there are multiple questions in the same topic.
But, you are wrong. There is a frame counter for each PDU and it's increased every time when the new message is sent.
BR,
Mikko