I am working with a BLE device that currently sends sequential values when subscribing to a notify characteristic. Each returned value starts with f083 and ends with 0000 with each hex value in between incrementing.
When I connect to the device with LightBlue on iOS (mobile or desktop) I get the expected results. However, if I connect with LightBlue on Android or use gatttool on Ubuntu I get substantial packet loss. You can still see the sequential values in the result, however, there are massive gaps.
It is worth noting that when I connect on Ubuntu or Android I have to manually specify the MTU whereas iOS does this automatically. However, I can confirm that the MTU on iOS matches the value entered on Android on gatttool. Is there some way I can view gatttool logs or some further information?
If it helps, I am using the following for connecting on gatttool:
$ gatttool -b 18:04:ED:39:96:77 -I
[18:04:ED:39:96:77][LE]> connect
Attempting to connect to 18:04:ED:39:96:77
Connection successful
[18:04:ED:39:96:77][LE]> mtu 31
MTU was exchanged successfully: 31
[18:04:ED:39:96:77][LE]> char-write-req 0x00015 0100
Characteristic value was written successfully
Notification handle = 0x0014 value: f0 83 15 15 15 15 15 15 15 15 15 15 15 15 15 15 15 15 15 15 15 15 15 15 15 15 00 00
Notification handle = 0x0014 value: f0 83 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 00 00
Any help here would be hugely appreciated.
iOS Output
17:45:34.854 - Characteristic (FFF4) notified: <f0830707 07070707 07070707 07070707 07070707 07070707 07070000>
17:45:34.855 - Characteristic (FFF4) notified: <f0830808 08080808 08080808 08080808 08080808 08080808 08080000>
17:45:34.882 - Characteristic (FFF4) notified: <f0830909 09090909 09090909 09090909 09090909 09090909 09090000>
17:45:34.914 - Characteristic (FFF4) notified: <f0830a0a 0a0a0a0a 0a0a0a0a 0a0a0a0a 0a0a0a0a 0a0a0a0a 0a0a0000>
17:45:34.943 - Characteristic (FFF4) notified: <f0830b0b 0b0b0b0b 0b0b0b0b 0b0b0b0b 0b0b0b0b 0b0b0b0b 0b0b0000>
17:45:34.944 - Characteristic (FFF4) notified: <f0830c0c 0c0c0c0c 0c0c0c0c 0c0c0c0c 0c0c0c0c 0c0c0c0c 0c0c0000>
17:45:34.974 - Characteristic (FFF4) notified: <f0830d0d 0d0d0d0d 0d0d0d0d 0d0d0d0d 0d0d0d0d 0d0d0d0d 0d0d0000>
17:45:35.002 - Characteristic (FFF4) notified: <f0830e0e 0e0e0e0e 0e0e0e0e 0e0e0e0e 0e0e0e0e 0e0e0e0e 0e0e0000>
17:45:35.032 - Characteristic (FFF4) notified: <f0830f0f 0f0f0f0f 0f0f0f0f 0f0f0f0f 0f0f0f0f 0f0f0f0f 0f0f0000>
17:45:35.064 - Characteristic (FFF4) notified: <f0831010 10101010 10101010 10101010 10101010 10101010 10100000>
17:45:35.094 - Characteristic (FFF4) notified: <f0831111 11111111 11111111 11111111 11111111 11111111 11110000>
17:45:35.095 - Characteristic (FFF4) notified: <f0831212 12121212 12121212 12121212 12121212 12121212 12120000>
17:45:35.124 - Characteristic (FFF4) notified: <f0831313 13131313 13131313 13131313 13131313 13131313 13130000>
17:45:35.153 - Characteristic (FFF4) notified: <f0831414 14141414 14141414 14141414 14141414 14141414 14140000>
17:45:35.184 - Characteristic (FFF4) notified: <f0831515 15151515 15151515 15151515 15151515 15151515 15150000>
17:45:35.214 - Characteristic (FFF4) notified: <f0831616 16161616 16161616 16161616 16161616 16161616 16160000>
17:45:35.244 - Characteristic (FFF4) notified: <f0831717 17171717 17171717 17171717 17171717 17171717 17170000>
17:45:35.244 - Characteristic (FFF4) notified: <f0831818 18181818 18181818 18181818 18181818 18181818 18180000>
Android Output
Tue Apr 27 16:56:51 GMT+10:00 2021: Characteristic 0000fff4-0000-1000-8000-00805f9b34fb changed | value: F0 83 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 00 00
Tue Apr 27 16:56:52 GMT+10:00 2021: Characteristic 0000fff4-0000-1000-8000-00805f9b34fb changed | value: F0 83 1D 1D 1D 1D 1D 1D 1D 1D 1D 1D 1D 1D 1D 1D 1D 1D 1D 1D 1D 1D 1D 1D 1D 1D 00 00
Tue Apr 27 16:56:52 GMT+10:00 2021: Characteristic 0000fff4-0000-1000-8000-00805f9b34fb changed | value: F0 83 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 00 00
Tue Apr 27 16:56:54 GMT+10:00 2021: Characteristic 0000fff4-0000-1000-8000-00805f9b34fb changed | value: F0 83 1F 1F 1F 1F 1F 1F 1F 1F 1F 1F 1F 1F 1F 1F 1F 1F 1F 1F 1F 1F 1F 1F 1F 1F 00 00
Tue Apr 27 16:56:54 GMT+10:00 2021: Characteristic 0000fff4-0000-1000-8000-00805f9b34fb changed | value: F0 83 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 00 00
Tue Apr 27 16:56:59 GMT+10:00 2021: Characteristic 0000fff4-0000-1000-8000-00805f9b34fb changed | value: F0 83 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 00 00
Tue Apr 27 16:57:01 GMT+10:00 2021: Characteristic 0000fff4-0000-1000-8000-00805f9b34fb changed | value: F0 83 03 03 03 03 03 03 03 03 03 03 03 03 03 03 03 03 03 03 03 03 03 03 03 03 00 00
Tue Apr 27 16:57:04 GMT+10:00 2021: Characteristic 0000fff4-0000-1000-8000-00805f9b34fb changed | value: F0 83 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 29 00 00
Tue Apr 27 16:57:06 GMT+10:00 2021: Characteristic 0000fff4-0000-1000-8000-00805f9b34fb changed | value: F0 83 2A 2A 2A 2A 2A 2A 2A 2A 2A 2A 2A 2A 2A 2A 2A 2A 2A 2A 2A 2A 2A 2A 2A 2A 00 00
Tue Apr 27 16:57:08 GMT+10:00 2021: Characteristic 0000fff4-0000-1000-8000-00805f9b34fb changed | value: F0 83 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 00 00
Tue Apr 27 16:57:10 GMT+10:00 2021: Characteristic 0000fff4-0000-1000-8000-00805f9b34fb changed | value: F0 83 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 00 00
Tue Apr 27 16:57:12 GMT+10:00 2021: Characteristic 0000fff4-0000-1000-8000-00805f9b34fb changed | value: F0 83 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 00 00
Tue Apr 27 16:57:13 GMT+10:00 2021: Characteristic 0000fff4-0000-1000-8000-00805f9b34fb changed | value: F0 83 50 50 50 50 50 50 50 50 50 50 50 50 50 50 50 50 50 50 50 50 50 50 50 50 00 00
Gatttool Output
Notification handle = 0x0014 value: f0 83 54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 00 00
Notification handle = 0x0014 value: f0 83 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 00 00
Notification handle = 0x0014 value: f0 83 56 56 56 56 56 56 56 56 56 56 56 56 56 56 56 56 56 56 56 56 56 56 56 56 00 00
Notification handle = 0x0014 value: f0 83 57 57 57 57 57 57 57 57 57 57 57 57 57 57 57 57 57 57 57 57 57 57 57 57 00 00
Notification handle = 0x0014 value: f0 83 58 58 58 58 58 58 58 58 58 58 58 58 58 58 58 58 58 58 58 58 58 58 58 58 00 00
Notification handle = 0x0014 value: f0 83 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 00 00
Notification handle = 0x0014 value: f0 83 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 00 00
Notification handle = 0x0014 value: f0 83 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 00 00
Notification handle = 0x0014 value: f0 83 1b 1b 1b 1b 1b 1b 1b 1b 1b 1b 1b 1b 1b 1b 1b 1b 1b 1b 1b 1b 1b 1b 1b 1b 00 00
Notification handle = 0x0014 value: f0 83 1c 1c 1c 1c 1c 1c 1c 1c 1c 1c 1c 1c 1c 1c 1c 1c 1c 1c 1c 1c 1c 1c 1c 1c 00 00
Notification handle = 0x0014 value: f0 83 3f 3f 3f 3f 3f 3f 3f 3f 3f 3f 3f 3f 3f 3f 3f 3f 3f 3f 3f 3f 3f 3f 3f 3f 00 00
Related
im trying to reverse one app, and wanted to ask, maybe some one can help with fresh idea, or already know what is used here.
So the case, i have client and server, now i have written mitm app, and i can see the packets.
Tha packets order is
s2c: sending rsa key
c2s: sending some always static data, encrypted with rsa
s2c: sending some response, seems like an packet without body (im here)
c2s: sending data, and here is problem, that this packet is not encrypted as packet 2
c2s: sending response
this is packet header
50 50 00 00 40 00 50 00 00 00 00 00 ... rest is body
lets divide it
50 50 - this is always same
00 00 - this is some packet flag, cause always after packet 3, it becomes x04 00
40 00 - this is length 100%
50 00 - packet code i think
00 00 00 00 - i dont know what i this
body - is not readable, but also is not encrypted with rsa
here is example of stream
**s2c packet 1**
2023/01/24 21:32:56 Received: 176
00000000 *50 50 00 00 a4 00 01 00 00 00 00 00* a2 00 2d 2d |PP............--|
00000010 2d 2d 2d 42 45 47 49 4e 20 52 53 41 20 50 55 42 |---BEGIN RSA PUB|
00000020 4c 49 43 20 4b 45 59 2d 2d 2d 2d 2d 0a 4d 45 63 |LIC KEY-----.MEc|
00000030 43 51 51 43 71 49 4e 36 37 76 45 52 47 37 34 49 |CQQCqIN67vERG74I|
00000040 64 77 38 6d 76 6c 66 6d 45 31 38 31 31 56 74 2b |dw8mvlfmE1811Vt+|
00000050 53 76 66 67 73 36 43 68 59 51 78 4e 5a 52 57 74 |Svfgs6ChYQxNZRWt|
00000060 7a 31 6f 62 50 53 69 34 62 75 78 72 41 0a 5a 6d |z1obPSi4buxrA.Zm|
00000070 6d 77 32 4e 69 38 44 59 74 67 6d 77 54 74 48 51 |mw2Ni8DYtgmwTtHQ|
00000080 66 6b 6d 35 65 59 2f 76 63 54 41 67 49 44 43 51 |fkm5eY/vcTAgIDCQ|
00000090 3d 3d 0a 2d 2d 2d 2d 2d 45 4e 44 20 52 53 41 20 |==.-----END RSA |
000000a0 50 55 42 4c 49 43 20 4b 45 59 2d 2d 2d 2d 2d 0a |PUBLIC KEY-----.|
2023/01/24 21:32:56 RSA Key chaged - here i changed key to my
**c2s packet 2**
2023/01/24 21:32:56 Received: 76
00000000 *50 50 00 00 40 00 50 00 00 00 00 00* 97 4a 85 34 |PP..#.P......J.4|
00000010 e6 e0 f8 56 d6 5b 12 a4 4b 3f e2 f3 c7 b4 a1 fc |...V.[..K?......|
00000020 c7 fe b8 88 bc b7 8b 93 89 c2 7f 02 09 7b 52 4a |.............{RJ|
00000030 23 be a4 47 eb b8 02 f5 0a 62 9a 88 15 13 12 de |#..G.....b......|
00000040 a4 94 2c 3a 0a 34 47 bb 13 6f d4 ae |..,:.4G..o..|
2023/01/24 21:32:56 Header: 76
00000000 *50 50 00 00 40 00 50 00 00 00 00 00* |PP..#.P.....|
2023/01/24 21:32:56 Encoded with my key
00000000 *97 4a 85 34 e6 e0 f8 56 d6 5b 12 a4* 4b 3f e2 f3 |.J.4...V.[..K?..|
00000010 c7 b4 a1 fc c7 fe b8 88 bc b7 8b 93 89 c2 7f 02 |................|
00000020 09 7b 52 4a 23 be a4 47 eb b8 02 f5 0a 62 9a 88 |.{RJ#..G.....b..|
00000030 15 13 12 de a4 94 2c 3a 0a 34 47 bb 13 6f d4 ae |......,:.4G..o..|
2023/01/24 21:32:56 Decoded body
00000000 29 00 00 00 23 48 00 00 be 18 00 00 84 67 00 00 |)...#H.......g..|
2023/01/24 21:32:56 Encoded with original key
00000000 0a cb d2 7f f6 a3 8b 57 2c 6b e8 6d ed f0 c1 36 |.......W,k.m...6|
00000010 e4 c8 00 9d ca 55 41 62 ef 4b 72 91 7c fc 7b 1d |.....UAb.Kr.|.{.|
00000020 e4 5c f0 2b ce 86 01 79 ae b8 13 dd 51 a0 30 c5 |.\.+...y....Q.0.|
00000030 6f 77 fa 11 ed 03 7b 2c 77 7c 5b 7e 61 6f 86 9d |ow....{,w|[~ao..|
**s2c packet 3**
2023/01/24 21:32:56 Received: 12
00000000 *50 50 00 00 00 00 02 00 00 00 00 00* |PP..........|
**c2s packet 4**
2023/01/24 21:32:56 Not decoding next packet
2023/01/24 21:32:56 Received: 174
00000000 *50 50 04 00 a2 00 01 30 00 00 00 00* 00 9f 53 ab |PP.....0......S.|
00000010 c8 58 49 ea 4d fa 18 f4 f1 fc 9a 3c 04 ca 11 94 |.XI.M......<....|
00000020 ab ec ba 1d c6 f0 5d e0 1f d6 87 2d de 0c 97 eb |......]....-....|
00000030 29 b7 d1 dc 48 38 f4 63 74 29 e2 ea 9f 81 a8 59 |)...H8.ct).....Y|
00000040 47 75 32 0d 53 0e 55 3e cd 7b 89 d9 c3 22 d5 39 |Gu2.S.U>.{...".9|
00000050 c4 18 a5 c7 e2 eb 3a 9e 72 13 36 c3 52 f5 e6 7d |......:.r.6.R..}|
00000060 9b bf 37 06 e5 e9 4c 74 ac 85 37 85 94 81 37 67 |..7...Lt..7...7g|
00000070 f9 28 60 c7 0a ca 4c 5a 57 20 d6 ce 7c 91 58 6b |.(`...LZW ..|.Xk|
00000080 56 af 96 a8 e4 b5 8c 19 2e 9a 8c fa a6 c2 08 24 |V..............$|
00000090 ab 97 5d be 74 c2 19 d2 bd f1 93 5f a5 65 c5 7c |..].t......_.e.||
000000a0 fa bb 46 07 80 fd b6 79 5c 19 6f 65 54 35 |..F....y\.oeT5|
**s2c packet 5**
2023/01/24 21:32:56 Received: 174
00000000 *50 50 04 00 a2 00 01 40 00 00 00 00* 00 9e e7 03 |PP.....#........|
00000010 1b aa 67 36 1e 6f 34 20 c3 7c a9 85 93 74 b7 53 |..g6.o4 .|...t.S|
00000020 cc 10 68 90 ec 41 54 68 bb 9e 3d 41 c9 3f db 41 |..h..ATh..=A.?.A|
00000030 09 b9 ae 6a 9b f9 5c 0f 47 c6 4b bd 94 08 20 b0 |...j..\.G.K... .|
00000040 2e f2 6e 40 11 b6 14 8b e0 51 89 db 0c e0 c8 5b |..n#.....Q.....[|
00000050 92 1f a3 08 90 05 5c b5 bb bb 50 c0 3e f6 ee e8 |......\...P.>...|
00000060 63 bd 23 74 53 24 8f a3 0b 4e 72 12 a0 0e ac 96 |c.#tS$...Nr.....|
00000070 03 2c e8 31 6a 34 10 84 63 7a e1 32 42 d3 69 17 |.,.1j4..cz.2B.i.|
00000080 73 df a4 89 35 90 0f 92 06 d7 3b 2e 3c 3d 6e 7e |s...5.....;.<=n~|
00000090 db 73 cb f0 96 95 df 84 af 20 b7 7b 7c 64 61 a9 |.s....... .{|da.|
000000a0 b2 0e 9d 1e bc 57 73 5f f0 bc a5 aa b8 36 |.....Ws_.....6|
Maybe some one can identify protocol by packet header, cause i havent seen something similar before.
Thank you
i know that only packet 2 is encrypted, cause i changed rsa key to my key, and decoded data, its not work with other packets.
I am working on a object storage project where I need to understand Reed Solomon error correction algorithm,
I have gone through this Doc as a starter and also some thesis paper.
1. content.sakai.rutgers.edu
2. theseus.fi
but I can't seem to understand the lower part of the identity matrix (red box), where it is coming from. How this calculation is done?
Can anyone please explain this.
The encoding matrix is a 6 x 4 Vandermonde matrix using the evaluation points {0 1 2 3 4 5} modified so that the upper 4 x 4 portion of the matrix is the identity matrix. To create the matrix, a 6 x 4 Vandermonde matrix is generated (where matrix[r][c] = pow(r,c) ), then multiplied with the inverse of the upper 4 x 4 portion of the matrix to produce the encoding matrix. This is the equivalent of "systematic encoding" with Reed Solomon's "original view" as mentioned in the Wikipedia article you linked to above, which is different than Reed Solomon's "BCH view", which links 1. and 2. refer to. The Wikipedia's example systematic encoding matrix is a transposed version of the encoding matrix used in the question.
https://en.wikipedia.org/wiki/Vandermonde_matrix
https://en.wikipedia.org/wiki/Reed%E2%80%93Solomon_error_correction#Systematic_encoding_procedure:_The_message_as_an_initial_sequence_of_values
The code to generate the encoding matrix is near the bottom of this github source file:
https://github.com/Backblaze/JavaReedSolomon/blob/master/src/main/java/com/backblaze/erasure/ReedSolomon.java
Vandermonde inverse upper encoding
matrix part of matrix matrix
01 00 00 00 01 00 00 00
01 01 01 01 01 00 00 00 00 01 00 00
01 02 04 08 x 7b 01 8e f4 = 00 00 01 00
01 03 05 0f 00 7a f4 8e 00 00 00 01
01 04 10 40 7a 7a 7a 7a 1b 1c 12 14
01 05 11 55 1c 1b 14 12
Decoding is performed in two steps. First, any missing rows of data are recovered, then any missing rows of parity are regenerated using the now recovered data.
For 2 missing rows of data, the 2 corresponding rows of the encoding matrix are removed, and the 4 x 4 sub-matrix inverted and used the multiply the 4 non-missing rows of data and parity to recover the 2 missing rows of data. If there is only 1 missing row of data, then a second data row is chosen as if it was missing, in order to generate the inverted matrix. The actual regeneration of data only requires the corresponding rows of the inverted matrix to be used for a matrix multiply.
Once the data is recovered, then any missing parity rows are regenerated from the now recovered data, using the corresponding rows of the encoding matrix.
Based on the data shown, the math is based on finite field GF(2^8) modulo 0x11D. For example, encoding using the last row of the encoding matrix with the last column of the data matrix is (0x1c·0x44)+(0x1b·0x48)+(0x14·0x4c)+(0x12·0x50) = 0x25 (using finite field math).
The question example doesn't make it clear that the 6 x 4 encode matrix can encode a 4 x n matrix, where n is the number of bytes per row. Example where n == 8:
encode data encoded data
01 00 00 00 31 32 33 34 35 36 37 38
00 01 00 00 31 32 33 34 35 36 37 38 41 42 43 44 45 46 47 48
00 00 01 00 x 41 42 43 44 45 46 47 48 = 49 4a 4b 4c 4d 4e 4f 50
00 00 00 01 49 4a 4b 4c 4d 4e 4f 50 51 52 53 54 55 56 57 58
1b 1c 12 14 51 52 53 54 55 56 57 58 e8 eb ea ed ec ef ee dc
1c 1b 14 12 f5 f6 f7 f0 f1 f2 f3 a1
assume rows 0 and 4 are erasures and deleted from the matrices:
00 01 00 00 41 42 43 44 45 46 47 48
00 00 01 00 49 4a 4b 4c 4d 4e 4f 50
00 00 00 01 51 52 53 54 55 56 57 58
1c 1b 14 12 f5 f6 f7 f0 f1 f2 f3 a1
invert encode sub-matrix:
inverse encode identity
46 68 8f a0 00 01 00 00 01 00 00 00
01 00 00 00 x 00 00 01 00 = 00 01 00 00
00 01 00 00 00 00 00 01 00 00 01 00
00 00 01 00 1c 1b 14 12 00 00 00 01
reconstruct data using sub-matrices:
inverse encoded data restored data
46 68 8f a0 41 42 43 44 45 46 47 48 31 32 33 34 35 36 37 38
01 00 00 00 x 49 4a 4b 4c 4d 4e 4f 50 = 41 42 43 44 45 46 47 48
00 01 00 00 51 52 53 54 55 56 57 58 49 4a 4b 4c 4d 4e 4f 50
00 00 01 00 f5 f6 f7 f0 f1 f2 f3 a1 51 52 53 54 55 56 57 58
The actual process only uses the rows of the matrices that correspond
to the erased rows that need to be reconstructed.
First data is reconstructed:
sub-inverse encoded data reconstructed data
41 42 43 44 45 46 47 48
46 68 8f a0 x 49 4a 4b 4c 4d 4e 4f 50 = 31 32 33 34 35 36 37 38
51 52 53 54 55 56 57 58
f5 f6 f7 f0 f1 f2 f3 a1
Once data is reconstructed, reconstruct parity
sub-encode data reconstruted parity
31 32 33 34 35 36 37 38
1b 1c 12 14 x 41 42 43 44 45 46 47 48 = e8 eb ea ed ec ef ee dc
49 4a 4b 4c 4d 4e 4f 50
51 52 53 54 55 56 57 58
One alternate to this approach is to use BCH view Reed Solomon. For an odd number of parities, such as RS(20,17) (3 parities), 2 matrix multiplies and one XOR is needed for encoding, and for a single erasure only XOR is needed. For e>1 erasures, a (e-1) by n matrix multiply is done, followed by an XOR. For an even number of parities, if an XOR is used as part of the encode, then a e by n matrix multiply is needed to correct, or the e x n matrix used for encode, allowing one XOR for the correction.
Another alternative is Raid 6, where "syndromes" are appended to the matrix of data, but do not form a proper code word. One of the syndrome rows, called P, is just XOR, the other row called Q, is successive powers of 2 in GF(2^8). For a 3 parity Raid 6, the third row is called R, is successive powers of 4 in GF(2^8). Unlike standard BCH view, if a Q or R row is lost, it has to be recalculated (as opposed to using XOR to correct it). By using a diagonal pattern, if 1 of n disks fail, then only 1/n of the Q's and R's need to be regenerated when the disk is replaced.
http://alamos.math.arizona.edu/RTG16/ECC/raid6.pdf
Note that this pdf file's alternate method uses the same finite field as the method above, GF(2^8) mod 0x11D, which may make it easier to compare the methods.
There are lots of questions about Desfire EV1 cards here on Stackoverflow.
But if you search for some example data the only place where you will find a few bytes is in Ridrix Blog. But this is quite incomplete.
A lot of people wrote their problems there while developing code for Desfire cards. But mostly when they solved their problem they were too lazy to post the solution. So you find many questions but very few answers with data examples.
Even if you have the Desfire EV1 documentation (I dont have it, I studied easypay code), you will need more than that. A documentation is only theory. But what is the reason that your card returns an Authentication Error or an Integrity Error or an unexpected CMAC?
Is the Session key OK ?
Is CBC working in the correct mode ?
Is the CMAC calculated correctly ?
Is the CRC32 correct ?
Is the IV of the session key correct before / after a function call ?
Without examples you are completely lost.
After spending several weeks with Desfire EV1 development I decided to post some examples for all those who need input data to feed their complex cryprographic functions and compare the output with the expected data. I know that this is EXTREMELY helpfull.
Here you find some Debug output from the most important Desfire EV1 operations.
Currently you cannot find this information in internet.
If I would have had these examples I would have saved a LOT of time developing my code.
Pitfalls for ISO and AES authenticated sessions
In ISO and AES mode EVERY encryption/decryption goes through CBC.
The IV of the session key is reset to zero only ONCE when the key is created after authentication.
The IV of the authentication key is reset only ONCE when authentication starts.
During authentication:
Random B is received from the card with RECEIVE + DECIPHER
Random AB is sent to the card with SEND + ENCIPHER
Random A is received with RECEIVE + DECIPHER
The CMAC is a copy of the IV of the session key.
The CMAC must mostly be calculated for data sent to the card and for data returned from the card.
But all commands that do a CBC encryption (e.g. ChangeKeySettings) differ from that scheme.
Commands that send/receive multiple frames (e.g. GetApplicationIDs) must calculate the CMAC over the data of all frames that have been sent/received (not including the 0xAF status byte).
For TX data the CMAC is calculated over the command byte + all parameter bytes.
For RX data the CMAC is calculated over all response bytes + the last status byte (always 00 = Success) that must be appended at the end!
The authentication is invalidated:
when an error occures (status != 00 and != AF),
when SelectApplication is executed,
after the same key has been changed that was used for authentication,
when another card comes into the RF field (don't forget to reset your variables).
In these cases the session key is no longer valid and so a CMAC must not be calculated.
The CRC32 of the new key is calculated only over the key data itself.
The CRC32 of the cryptogram is calculated over command, key number and the not yet encrypted cryptogram.
The following debug output has been generated by my code running in a Teensy 3.2 with a PN532 board from Adafruit.
For further details see my source code.
The C++ source code has been written for Arduino/Teensy, but it has been designed multiplatform so that it can be compiled on Visual Studio, Linux or other platforms. The ZIP file also contains a Visual Studio project.
In the following examples all keys have key version 0x10.
ISO Authentication with 2K3DES default key #0
*** Authenticate(KeyNo= 0, Key= 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 (DES))
Sending: <1A 00>
Response: <AF B8 90 04 7F 2D C8 D6 8B>
* RndB_enc: B8 90 04 7F 2D C8 D6 8B
* RndB: 74 B8 43 5F CB A0 B6 75
* RndB_rot: B8 43 5F CB A0 B6 75 74
* RndA: 92 31 34 8B 66 35 A8 AF
* RndAB: 92 31 34 8B 66 35 A8 AF B8 43 5F CB A0 B6 75 74
* RndAB_enc: 7C 84 6A 50 7B 9B 6E 68 64 BC 33 72 A3 06 A8 C1
Sending: <AF 7C 84 6A 50 7B 9B 6E 68 64 BC 33 72 A3 06 A8 C1>
Response: <00 B7 96 DD 3F 81 15 45 F3>
* RndA_enc: B7 96 DD 3F 81 15 45 F3
* RndA_dec: 31 34 8B 66 35 A8 AF 92
* RndA_rot: 31 34 8B 66 35 A8 AF 92
* SessKey: 92 30 34 8A 74 B8 42 5E 92 30 34 8A 74 B8 42 5E (DES)
Change 2K3DES default key #0
*** ChangeKey(KeyNo= 0)
* SessKey: B4 28 2E FA 9E B8 2C AE B4 28 2E FA 9E B8 2C AE (DES)
* SessKey IV: 00 00 00 00 00 00 00 00
* New Key: 00 10 20 31 40 50 60 70 80 90 A0 B0 B0 A0 90 80 (2K3DES)
* CRC Crypto: 0x5001FFC5
* Cryptogram: 00 10 20 31 40 50 60 70 80 90 A0 B0 B0 A0 90 80 C5 FF 01 50 00 00 00 00
* CryptogrEnc: 87 99 59 11 8B D7 7C 70 10 7B CD B0 C0 9C C7 DA 82 15 04 AA 1E 36 04 9C
Sending: <C4 00 87 99 59 11 8B D7 7C 70 10 7B CD B0 C0 9C C7 DA 82 15 04 AA 1E 36 04 9C>
Response: <00>
Change 2K3DES default key #1
*** ChangeKey(KeyNo= 1)
* SessKey: 9C 70 56 82 5C 08 9E C8 9C 70 56 82 5C 08 9E C8 (DES)
* SessKey IV: 00 00 00 00 00 00 00 00
* New Key: 00 10 20 31 40 50 60 70 80 90 A0 B0 B0 A0 90 80 (2K3DES)
* Cur Key: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 (DES)
* CRC Crypto: 0xD7A73486
* CRC New Key: 0xC4EF3A3A
* Cryptogram: 00 10 20 31 40 50 60 70 80 90 A0 B0 B0 A0 90 80 86 34 A7 D7 3A 3A EF C4
* CryptogrEnc: 7D 83 D3 4E FB 6C 84 98 48 E2 D6 37 AD A2 D0 87 14 36 1A E6 C4 63 14 52
Sending: <C4 01 7D 83 D3 4E FB 6C 84 98 48 E2 D6 37 AD A2 D0 87 14 36 1A E6 C4 63 14 52>
Response: <00 1D 5C 27 97 10 86 30 8D>
CMAC: 1D 5C 27 97 10 86 30 8D
ISO Authentication with 3K3DES default key #0
*** Authenticate(KeyNo= 0, Key= 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 (3K3DES))
Sending: <1A 00>
Response: <AF 14 65 76 AC 1B 7D B8 CA 24 84 C5 69 7F 80 12 E1>
* RndB_enc: 14 65 76 AC 1B 7D B8 CA 24 84 C5 69 7F 80 12 E1
* RndB: BA 91 37 BB 7A 18 33 E7 39 F0 5E 8F 07 87 D0 C4
* RndB_rot: 91 37 BB 7A 18 33 E7 39 F0 5E 8F 07 87 D0 C4 BA
* RndA: F5 68 6F 3A 39 1C D3 8E BD 10 77 22 81 44 5B F6
* RndAB: F5 68 6F 3A 39 1C D3 8E BD 10 77 22 81 44 5B F6 91 37 BB 7A 18 33 E7 39 F0 5E 8F 07 87 D0 C4 BA
* RndAB_enc: D0 55 BD 5E A0 1E BF C3 02 93 D4 8A 54 A0 51 B4 0A 66 57 7A 38 3C 58 ED 77 5C 51 BC 97 D4 FA BD
Sending: <AF D0 55 BD 5E A0 1E BF C3 02 93 D4 8A 54 A0 51 B4 0A 66 57 7A 38 3C 58 ED 77 5C 51 BC 97 D4 FA BD>
Response: <00 E1 EE 93 F0 12 C8 D6 72 11 D4 33 7C AD 56 6A 40>
* RndA_enc: E1 EE 93 F0 12 C8 D6 72 11 D4 33 7C AD 56 6A 40
* RndA_dec: 68 6F 3A 39 1C D3 8E BD 10 77 22 81 44 5B F6 F5
* RndA_rot: 68 6F 3A 39 1C D3 8E BD 10 77 22 81 44 5B F6 F5
* SessKey: F4 68 6E 3A BA 90 36 BA D2 8E BC 10 32 E6 38 F0 80 44 5A F6 06 86 D0 C4 (3K3DES)
Change 3K3DES default key #0
*** ChangeKey(KeyNo= 0)
* SessKey: F4 68 6E 3A BA 90 36 BA D2 8E BC 10 32 E6 38 F0 80 44 5A F6 06 86 D0 C4 (3K3DES)
* SessKey IV: 00 00 00 00 00 00 00 00
* New Key: 00 10 20 31 40 50 60 70 80 90 A0 B0 B0 A0 90 80 70 60 50 40 30 20 10 00 (3K3DES)
* CRC Crypto: 0xA2003ED6
* Cryptogram: 00 10 20 31 40 50 60 70 80 90 A0 B0 B0 A0 90 80 70 60 50 40 30 20 10 00 D6 3E 00 A2 00 00 00 00
* CryptogrEnc: 7F 88 90 C7 CA B9 A4 22 81 73 A6 41 B6 5F 0F 43 FD 40 4A 01 13 71 A9 90 4A 62 9E 3C 20 B2 FF 63
Sending: <C4 00 7F 88 90 C7 CA B9 A4 22 81 73 A6 41 B6 5F 0F 43 FD 40 4A 01 13 71 A9 90 4A 62 9E 3C 20 B2 FF 63>
Response: <00>
Change 3K3DES default key #1
*** ChangeKey(KeyNo= 1)
* SessKey: 9C 52 0E 3C B4 5A B2 A4 A2 00 C4 DA 72 2C 0E F4 38 FE 8A 48 F8 18 9E 56 (3K3DES)
* SessKey IV: 00 00 00 00 00 00 00 00
* New Key: 00 10 20 31 40 50 60 70 80 90 A0 B0 B0 A0 90 80 70 60 50 40 30 20 10 00 (3K3DES)
* Cur Key: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 (3K3DES)
* CRC Crypto: 0x078BAED8
* CRC New Key: 0x12A6733E
* Cryptogram: 00 10 20 31 40 50 60 70 80 90 A0 B0 B0 A0 90 80 70 60 50 40 30 20 10 00 D8 AE 8B 07 3E 73 A6 12
* CryptogrEnc: 72 18 2F 5B 0C F1 7E A0 86 A5 AE A5 64 ED 98 7A F3 90 CD B3 78 36 4E 2B C2 45 8B 3A E3 23 98 4D
Sending: <C4 01 72 18 2F 5B 0C F1 7E A0 86 A5 AE A5 64 ED 98 7A F3 90 CD B3 78 36 4E 2B C2 45 8B 3A E3 23 98 4D>
Response: <00 D2 E3 BD 0D 09 47 72 ED>
CMAC: D2 E3 BD 0D 09 47 72 ED
AES Authentication with AES default key #0
*** Authenticate(KeyNo= 0, Key= 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 (AES))
Sending: <AA 00>
Response: <AF FF 0A FB 10 B4 3F 3B 34 23 36 57 0F 7A 0E 8B 74>
* RndB_enc: FF 0A FB 10 B4 3F 3B 34 23 36 57 0F 7A 0E 8B 74
* RndB: 1F 45 19 27 E7 C0 FC DE 60 9E E8 02 EF 69 76 04
* RndB_rot: 45 19 27 E7 C0 FC DE 60 9E E8 02 EF 69 76 04 1F
* RndA: 73 AE 5D 30 17 42 21 64 FB 16 25 D8 1F 2A 69 8C
* RndAB: 73 AE 5D 30 17 42 21 64 FB 16 25 D8 1F 2A 69 8C 45 19 27 E7 C0 FC DE 60 9E E8 02 EF 69 76 04 1F
* RndAB_enc: B3 11 34 03 F5 73 95 35 CA 1A 5D 4B D4 38 BE 03 2B 54 28 32 3D 0A 83 4D 11 8F 35 06 C4 2C 5B 01
Sending: <AF B3 11 34 03 F5 73 95 35 CA 1A 5D 4B D4 38 BE 03 2B 54 28 32 3D 0A 83 4D 11 8F 35 06 C4 2C 5B 01>
Response: <00 E2 AE 7D 31 29 48 19 69 E9 A0 C7 CC 89 1E DF 58>
* RndA_enc: E2 AE 7D 31 29 48 19 69 E9 A0 C7 CC 89 1E DF 58
* RndA_dec: AE 5D 30 17 42 21 64 FB 16 25 D8 1F 2A 69 8C 73
* RndA_rot: AE 5D 30 17 42 21 64 FB 16 25 D8 1F 2A 69 8C 73
* SessKey: 73 AE 5D 30 1F 45 19 27 1F 2A 69 8C EF 69 76 04 (AES)
Change AES default key #0
*** ChangeKey(KeyNo= 0)
* SessKey: 73 AE 5D 30 1F 45 19 27 1F 2A 69 8C EF 69 76 04 (AES)
* SessKey IV: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
* New Key: 00 10 20 30 40 50 60 70 80 90 A0 B0 B0 A0 90 80 (AES)
* CRC Crypto: 0x6BE6C6D2
* Cryptogram: 00 10 20 30 40 50 60 70 80 90 A0 B0 B0 A0 90 80 10 D2 C6 E6 6B 00 00 00 00 00 00 00 00 00 00 00
* CryptogrEnc: 97 41 8E 6C C0 1C 4E 6F AD 4D 87 4D 8D 42 5C EA 32 51 36 11 47 2C DA 04 E3 5E FB 77 9A 7D A0 E4
Sending: <C4 00 97 41 8E 6C C0 1C 4E 6F AD 4D 87 4D 8D 42 5C EA 32 51 36 11 47 2C DA 04 E3 5E FB 77 9A 7D A0 E4>
Response: <00>
Change AES default key #1
*** ChangeKey(KeyNo= 1)
* SessKey: 1C D3 8E BD 95 F3 1C 8A B8 7F 0A C9 C4 EB 64 C6 (AES)
* SessKey IV: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
* New Key: 00 10 20 30 40 50 60 70 80 90 A0 B0 B0 A0 90 80 (AES)
* Cur Key: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 (AES)
* CRC Crypto: 0x84B47033
* CRC New Key: 0x1979E3BF
* Cryptogram: 00 10 20 30 40 50 60 70 80 90 A0 B0 B0 A0 90 80 10 33 70 B4 84 BF E3 79 19 00 00 00 00 00 00 00
* CryptogrEnc: 30 23 FA 06 2D 25 0A 04 35 BA E9 45 CA BE 96 5D 62 2A 47 1D 32 5D 1D 42 EA 81 44 41 CB 1A 20 C3
Sending: <C4 01 30 23 FA 06 2D 25 0A 04 35 BA E9 45 CA BE 96 5D 62 2A 47 1D 32 5D 1D 42 EA 81 44 41 CB 1A 20 C3>
Response: <00 9B 68 30 91 50 E0 72 5E>
CMAC: 9B 68 30 91 50 E0 72 5E
CMAC Calculation for AES 128
From: NIST
AES Key: 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c
SubKey1: fb ee d6 18 35 71 33 66 7c 85 e0 8f 72 36 a8 de
SubKey2: f7 dd ac 30 6a e2 66 cc f9 0b c1 1e e4 6d 51 3b
Message: <empty>
CMAC: bb 1d 69 29 e9 59 37 28 7f a3 7d 12 9b 75 67 46
Message: 6b c1 be e2 2e 40 9f 96 e9 3d 7e 11 73 93 17 2a
CMAC: 07 0a 16 b4 6b 4d 41 44 f7 9b dd 9d d0 4a 28 7c
Message: 6b c1 be e2 2e 40 9f 96 e9 3d 7e 11 73 93 17 2a ae 2d 8a 57 1e 03 ac 9c 9e b7 6f ac 45 af 8e 51 30 c8 1c 46 a3 5c e4 11
CMAC: df a6 67 47 de 9a e6 30 30 ca 32 61 14 97 c8 27
If you need more examples (also for CreateApplication, SelectApplication, DeleteApplication, GetApplicationIDs, GetKeyVersion, GetKeySettings, ChangeKeySettings, GetCardVersion, FormatCard, CreateStdDataFile, GetFileIDs, GetFileSettings, WriteFileData, ReadFileData, DeleteFile) download the ZIP file on Codeproject where you find a HTML file with the entire selftest that tests all these commands.
I'm trying to filter duplicated/lost packets from TCP sniffing (using pcap), but I stopped at the understanding of seq/ack. Here are my logs with relative seq/ack:
CLIENT->SERVER/Seq=0;Ack=0/SYN/P.size:0; No data in TCP. Size: 66/66 -> 20 E7 1E 61 15 5B 4E 1D 00 00 00 00 80 02 F7 D3 4D 03 00 00 02 04 05 B4 01 03 03 06 01 01 04 02 | No payload
SERVER->CLIENT/Seq=0;Ack=1/ACK+SYN/P.size:0; No data in TCP. Size: 58/58 -> 1E 61 20 E7 C4 9D 5B 6B 15 5B 4E 1E 60 12 20 00 2D D1 00 00 02 04 05 B4 | No payload
CLIENT->SERVER/Seq=1;Ack=1/ACK/P.size:0; No data in TCP. Size: 54/54 -> 20 E7 1E 61 15 5B 4E 1E C4 9D 5B 6C 50 10 01 6D 64 21 00 00 | No payload
SERVER->CLIENT/Seq=1;Ack=268/ACK/P.size:0; No data in TCP. Size: 54/54 -> 1E 61 20 E7 C4 9D 5B 6C 15 5B 4F 29 50 10 5B 40 09 43 00 00 | No payload
CLIENT->SERVER/Seq=1;Ack=1/ACK+PSH/P.size:267; 20 E7 1E 61 15 5B 4E 1E C4 9D 5B 6C 50 18 01 6D AF 0B 00 00 | 0B 01 00 EA 02 00 00 09 07 54 56 03 09 0B 01 07 02 54 54 56 07 00 02 55 56 00 51 00 53 57 04 07 55 08 54 01 07 01 53 00 56 55 56 01 06 05 04 51 03 08 51 08 51 56 04 54 06 55 08 02 09 51 56 01 53 06 55 04 53 00 56 56 53 01 09 02 09 01 51 54 51 09 55 56 09 03 04 07 05 55 04 06 55 04 06 09 04 51 01 08 08 06 05 52 06 04 01 07 54 03 06 52 55 06 55 55 51 01 02 04 54 03 55 54 01 57 51 55 05 52 05 54 07 51 51 55 07 02 53 53 00 52 05 52 07 01 54 00 03 05 05 08 06 05 05 06 03 00 0D 08 01 07 09 03 51 03 07 53 09 51 06 07 54 0A 50 56 02 52 04 05 55 51 02 53 00 08 54 04 52 56 06 02 09 00 08 03 53 56 01 05 00 55 06 08 56 04 0D 06 07 52 06 07 04 0A 06 01 04 54 04 00 05 02 04 54 00 09 52 53 05 04 01 04 05 05 01 52 51 52 0D 06 51 08 09 54 53 00 0D 01 02 03 54 53 01 05 03 08 56 54 07 02 54 0B 06 DC 4F 61 4F
CLIENT->SERVER/Seq=267;Ack=1/ACK/P.size:0; No data in TCP. Size: 54/54 -> 20 E7 1E 61 15 5B 4F 28 C4 9D 5B 6C 50 10 01 6D 63 17 00 00 | No payload
SERVER->CLIENT/Seq=1;Ack=268/ACK+PSH/P.size:20; 1E 61 20 E7 C4 9D 5B 6C 15 5B 4F 29 50 18 5B 40 3A C6 00 00 | 14 00 00 01 E0 41 9A F0 98 F5 A4 37 01 00 00 00 01 00 00 00
CLIENT->SERVER/Seq=268;Ack=21/ACK/P.size:0; No data in TCP. Size: 54/54 -> 20 E7 1E 61 15 5B 4F 29 C4 9D 5B 80 50 10 01 6D 63 02 00 00 | No payload
SERVER->CLIENT/Seq=21;Ack=305/ACK/P.size:0; No data in TCP. Size: 54/54 -> 1E 61 20 E7 C4 9D 5B 80 15 5B 4F 4E 50 10 5B 40 09 0A 00 00 | No payload
CLIENT->SERVER/Seq=268;Ack=21/ACK+PSH/P.size:37; 20 E7 1E 61 15 5B 4F 29 C4 9D 5B 80 50 18 01 84 6B AF 00 00 | 25 00 32 DF 4C C6 2A 51 18 85 82 AC 27 D8 7A 06 44 DF F7 27 BD FC 59 43 3B E7 19 53 33 37 78 7B 93 81 38 51 CB
CLIENT->SERVER/Seq=304;Ack=21/ACK/P.size:0; No data in TCP. Size: 54/54 -> 20 E7 1E 61 15 5B 4F 4D C4 9D 5B 80 50 10 01 84 62 C7 00 00 | No payload
SERVER->CLIENT/Seq=21;Ack=305/ACK+PSH/P.size:328; 1E 61 20 E7 C4 9D 5B 80 15 5B 4F 4E 50 18 5B 40 AD 89 00 00 | 48 01 F3 B3 29 D9 41 E1 45 1B D3 98 0B 6E CF CC FD 18 F8 B9 23 3B 66 93 37 62 AA E9 7A 43 E2 B9 88 1F FF 77 80 70 E8 1D B9 8E 46 61 F2 F3 52 3E 0F 98 78 3B A1 51 C9 1E BA 8D 45 63 F0 F1 50 F9 F1 67 87 9E 3A C8 50 9D CB 03 34 63 CD C6 B0 FF 7A 4D ED 9F 36 F5 5E 98 43 FC 74 5A 8D 9E 3F 07 BC 10 F3 B2 28 D8 40 81 25 12 DA FD 6E 6F CE A2 93 04 E4 A5 3F CF 57 A2 06 31 F9 DE 4D 4C ED 81 B0 27 C7 86 1C EC 74 81 25 12 DA FD 6E 6F CE A2 93 04 E4 A5 3F CF 57 A2 06 31 F9 DE 4D 4C ED 81 B0 27 C7 86 1C EC 74 81 25 12 DA FD 6E 6F CE A2 93 04 E4 A5 3F CF 57 33 86 71 B9 8A 17 C7 66 1E 21 67 87 7A 95 B4 2C D9 7D 4A 82 A5 36 37 96 8B DB 85 65 24 BE 4E D6 23 87 B0 78 5F CC CD 6C 00 31 A6 46 07 9D 6D F5 00 A4 93 5B 7C EF EE 4F 23 12 85 65 24 BE 4E D6 23 87 B0 78 3F AE AF 0E 5E 6F F8 18 65 FF 0F 97 22 86 B1 79 5E CD CC 6D 01 30 A7 47 F3 76 86 1E EB 4F 78 B0 93 00 01 A0 CC FD 6A 8A C9 53 A3 3B B...
CLIENT->SERVER/Seq=305;Ack=349/ACK/P.size:0; No data in TCP. Size: 54/54 -> 20 E7 1E 61 15 5B 4F 4E C4 9D 5C C8 50 10 01 84 61 7E 00 00 | No payload
CLIENT->SERVER/Seq=305;Ack=349/ACK/P.size:0; No data in TCP. Size: 54/54 -> 20 E7 1E 61 15 5B 4F 4E C4 9D 5C C8 50 10 01 9B 61 67 00 00 | No payload
CLIENT->SERVER/Seq=304;Ack=349/ACK/P.size:0; No data in TCP. Size: 54/54 -> 20 E7 1E 61 15 5B 4F 4D C4 9D 5C C8 50 10 01 B2 61 51 00 00 | No payload
SERVER->CLIENT/Seq=349;Ack=305/ACK+PSH/P.size:7; 1E 61 20 E7 C4 9D 5C C8 15 5B 4F 4E 50 18 5B 40 05 3F 00 00 | 07 00 67 24 BE 4E D6
On the line 5
SERVER->CLIENT/Seq=1;Ack=268/ACK/P.size:0; No data in TCP. Size: 54/54 -> 1E 61 20 E7 C4 9D 5B 6C 15 5B 4F 29 50 10 5B 40 09 43 00 00 | No payload
server sends ACK with 268, while client sends those 267-length size data only on the next line. Why order is broken here??
As I understand, fisrt client should send seq1/ack1/L=267, and then server should resp with seq1/Ack268.
Or does it mean, that I have to implement whole logic for packet exchange in TCP protocol (including selective ACKs?)
Message from syslogd#saskappcu at Mar 18 13:24:54 ...
kernel:BUG: soft lockup - CPU#30 stuck for 61s! [events/30:161]
Message from syslogd#saskappcu at Mar 18 13:24:54 ...
kernel:Process events/30 (pid: 161, ti=f4ea4000 task=f4e5faa0 task.ti=f4ea4000)
Message from syslogd#saskappcu at Mar 18 13:24:54 ...
kernel:Stack:
Message from syslogd#saskappcu at Mar 18 13:24:54 ...
kernel:Call Trace:
Message from syslogd#saskappcu at Mar 18 13:24:54 ...
kernel:Code: 00 89 51 04 89 0a 89 43 20 89 43 24 8b 43 08 39 d8 74 23 83 40 7c 01 31 c9 8b 7b 0c 8b 15 58 09 ac c0 8b 02 39 c2 75 09 eb 31 90 <8b> 00 39 d0 74 2a 3b 78 0c 75 f5 89 d8 ba 00 00 04 00 e8 b9 a0
Message from syslogd#saskappcu at Mar 18 13:24:58 ...
kernel:BUG: soft lockup - CPU#8 stuck for 61s! [buildop:2223]
Message from syslogd#saskappcu at Mar 18 13:24:58 ...
kernel:Process buildop (pid: 2223, ti=e9724000 task=f3ba0aa0 task.ti=e9724000)
Message from syslogd#saskappcu at Mar 18 13:24:58 ...
kernel:Stack:
Message from syslogd#saskappcu at Mar 18 13:24:58 ...
kernel:Call Trace:
Message from syslogd#saskappcu at Mar 18 13:24:58 ...
kernel:Code: 26 00 89 c8 f0 81 28 00 00 00 01 74 05 e8 2c fe ff ff c3 8d b4 26 00 00 00 00 66 ba 00 01 f0 66 0f c1 10 38 f2 74 0e f3 90 8a 10 <eb> f6 66 83 38 00 75 f4 eb e5 c3 8d 74 26 00 f0 81 28 00 00 00
A softlockup is defined as a bug that causes the kernel to loop in
kernel mode for more than 20 seconds without giving other tasks a chance to run.
The log
kernel:BUG: soft lockup - CPU#30 stuck for 61s! [events/30:161]
is generated by the following line in kernel/kernel/watchdog.c
pr_emerg("BUG: soft lockup - CPU#%d stuck for %us! [%s:%d]\n",
smp_processor_id(),
duration,
current->comm,
task_pid_nr(current));
It means that
The CPU core 30 in the system,
has been busy executing kernel code for the past 61 seconds.
The current thread on the system being events/30,
whose process-id is 161.
For more details, checkout kernel/Documentation/lockup-watchdogs.txt.