I'm doing some EMV testing, and hoping someone can shed some light on what I'm seeing. I'm running the Mastercard M-TIP tests that apply to our solution, and I'm seeing some unexpected results. When running the M-TIP 50 tests (1, 2, 3) with the M-TIP 50 test card, I'm getting errors on the 2nd GENERATE_AC command. Our solution is technically defined as offline with online capability, but we're currently testing in an entirely offline environment.
I've spent a good amount of time reading the EMV books and scouring Google, but I still don't understand why it's returning 6985. The best guess I can come up with at this point is it has something to do with CDA (which should also be happening during this process?)
I've included the 1st and 2nd GEN_AC requests and responses to show what's happening. If someone could provide insight into what's happening or what's going wrong, I would greatly appreciate it.
1st Generate AC (ARQC)
Request : 80 AE 90 00 2F 00 00 00 00 20 00 00 00 00 00 00 00 00 80 00 80 00 08 26 17 01 03 00 B0 32 0F C0 22 00 00 00 00 00 00 00 00 00 00 44 03 02 16 11 12 60 00 80
Class :80
Ins :AE
P1 :90
P2 :00
Lc :2F
Data :00 00 00 00 20 00 00 00 00 00 00 00 00 80 00 80 00 08 26 17 01 03 00 B0 32 0F C0 22 00 00 00 00 00 00 00 00 00 00 44 03 02 16 11 12 60 00 80
Tag 9F 02: Transaction Amount : 00 00 00 00 20 00
Amount value: 20.00
Tag 9F 03: Cashback Amount : 00 00 00 00 00 00
Amount value: 0.00
Tag 95 : Terminal Verification Results (TVR) : 00 80 00 80 00
Byte 1 bit 8 = 0 Offline data authentication was performed
bit 7 = 0 SDA passed or not performed
bit 6 = 0 No ICC data missing
bit 5 = 0 Card does not appear on terminal exception file
bit 4 = 0 DDA passed or not performed
bit 3 = 0 CDA passed or not performed
bit 2 = 0 SDA not selected
bit 1 = 0 RFU
Byte 2 bit 8 = 1 ICC and terminal have different application versions
bit 7 = 0 No Expired application
bit 6 = 0 Application effective
bit 5 = 0 Requested service allowed for card product
bit 4 = 0 No New card
bit 3 = 0 RFU
bit 2 = 0 RFU
bit 1 = 0 RFU
Byte 3 bit 8 = 0 Cardholder verification was successful or not performed
bit 7 = 0 Recognised CVM
bit 6 = 0 PIN Try Limit not exceeded
bit 5 = 0 No PIN entry required (PIN pad may or may not be present or may or may not be working)
bit 4 = 0 No PIN entry required (PIN pad may or may not be present)
bit 3 = 0 No Online PIN entered
bit 2 = 0 RFU
bit 1 = 0 RFU
Byte 4 bit 8 = 1 Transaction exceeds floor limit
bit 7 = 0 Lower consecutive offline limit not exceeded
bit 6 = 0 Upper consecutive offline limit not exceeded
bit 5 = 0 Transaction not selected randomly for online processing
bit 4 = 0 Merchant did not force transaction online
bit 3 = 0 RFU
bit 2 = 0 RFU
bit 1 = 0 RFU
Byte 5 bit 8 = 0 No Default TDOL used
bit 7 = 0 Issuer authentication passed or not performed
bit 6 = 0 Script processing passed before final GENERATE AC or no script received
bit 5 = 0 Script processing passed after final GENERATE AC or no script received
bit 4 = 0 RFU
bit 3 = 0 RFU
bit 2 = 0 RFU
bit 1 = 0 RFU
Tag 5F 2A: Transaction Currency Code : 08 26
Code (num) = 08 26
Code (an) = GBP
Currency = Pound Sterling
Tag 9A : Transaction Date : 17 01 03
Year : 2017
Month: January
Day : 03
Tag 9C : Transaction Type : 00
Purchase (of goods or services)
Tag 9F 37: Unpredictable Number : B0 32 0F C0
Tag 9F 35: Terminal Type : 22
Terminal Type: 22
Attended
Merchant
Offline with online capability
Tag 9F 45: Data Authentication Code : 00 00
Tag 9F 4C: ICC Dynamic Number : 00 00 00 00 00 00 00 00
Tag 9F 34: Cardholder Verification Method (CVM) Results : 44 03 02
Byte 1 bit 8 = 0 (default value)
bit 7 = 1 (Apply succeeding CVM field if this CVM is unsuccessful)
bit 6-1= 000100 (Enciphered PIN verification performed by ICC)
Byte 2 = '03' (If terminal supports the CVM type)
Byte 3 = '02' (Successful)
Tag 9F 21: Transaction Time : 16 11 12
Time = 16:11:12
Hours (HH) = 16
Minutes (MM) = 11
Seconds (SS) = 12
Tag 9F 40: Additional Terminal Capabilities : 60 00 80
Byte 1 bit 8 = 0 Cash NOT supported
bit 7 = 1 Goods supported
bit 6 = 1 Services supported
bit 5 = 0 CashBack NOT supported
bit 4 = 0 Inquiry NOT supported
bit 3 = 0 Transfer NOT supported
bit 2 = 0 Payment NOT supported
bit 1 = 0 Administrative NOT supported
Byte 2 bit 8 = 0 CashBack Deposit NOT supported
bit 7 = 0 RFU
bit 6 = 0 RFU
bit 5 = 0 RFU
bit 4 = 0 RFU
bit 3 = 0 RFU
bit 2 = 0 RFU
bit 1 = 0 RFU
Byte 3 bit 8 = 1 Numeric keys supported
bit 7 = 0 Alphabetic and special characters keys NOT supported
bit 6 = 0 Command keys NOT supported
bit 5 = 0 Function keys NOT supported
bit 4 = 0 RFU
bit 3 = 0 RFU
bit 2 = 0 RFU
bit 1 = 0 RFU
Byte 4 bit 8 = 0 Print, attendant NOT supported
bit 7 = 0 Print, cardholder NOT supported
bit 6 = 0 Display, attendant NOT supported
bit 5 = 0 Display, cardholder NOT supported
bit 4 = 0 RFU
bit 3 = 0 RFU
bit 2 = 0 Code table 10 NOT supported
bit 1 = 0 Code table 9 NOT supported
Byte 5 bit 8 = 0 Code table 8 NOT supported
bit 7 = 0 Code table 7 NOT supported
bit 6 = 0 Code table 6 NOT supported
bit 5 = 0 Code table 5 NOT supported
bit 4 = 0 Code table 4 NOT supported
bit 3 = 0 Code table 3 NOT supported
bit 2 = 0 Code table 2 NOT supported
bit 1 = 0 Code table 1 NOT supported
masterKeyAC: 9E 15 20 43 13 F7 31 8A CB 79 B9 0B D9 86 AD 29
uniqueKeyAC: 80 32 AD CE E0 B9 40 BA FB E3 5B 5B 15 9E 8F EA
MCHIP SKD Session Key Derivation
ATC: 00 08
UN: B0 32 0F C0
Cryptogram Version No.: 10
ICC Master Key AC: 9E 15 20 43 13 F7 31 8A CB 79 B9 0B D9 86 AD 29
Derived Card Unique Key: 80 32 AD CE E0 B9 40 BA FB E3 5B 5B 15 9E 8F EA
Derived Session Key: A1 00 11 56 78 15 15 85 2B 53 76 A9 18 14 AA F2
AC calculation: 00 00 00 00 20 00 00 00 00 00 00 00 00 80 00 80 00 08 26 17 01 03 00 B0 32 0F C0 79 00 00 08 A7 40 0F 04 00 00 80
Amount Authorised : 00 00 00 00 20 00
Amount Other : 00 00 00 00 00 00
Terminal Verification Results : 00 80 00 80 00
Transaction Currency Code : 08 26
Transaction Date : 17 01 03
Transaction Type : 00
Unpredictable Number : B0 32 0F C0
Application Interchange Profile : 79 00
Application Transaction Counter : 00 08
Card Verification Results : A7 40 0F 04 00 00
AC Session Key : A1 00 11 56 78 15 15 85 2B 53 76 A9 18 14 AA F2
CDA Signature Generation
Input data: E0 B8 C8 03 72 22 60 00 80 30 00 00 00 00 00 20 00 00 00 00 00 00 00 00 80 00 80 00 08 26 17 01 03 00 B0 32 0F C0 22 00 00 00 00 00 00 00 00 00 00 44 03 02 16 11 12 60 00 80 9F 27 01 80 9F 36 02 00 08 9F 10 12 02 10 A7 40 0F 04 00 00 00 00 00 00 00 00 00 00 00 FF
ICC dynamic number: 98 43 55 5A 0A C1 C2 4A
ICC private key: 1A C2 53 A6 2F FC 28 F2 CA 67 EE 9B 2C BE 16 C2 38 FB E3 C8 8B 28 4A 81 18 44 4B 6A BD 6F 68 FD F4 70 23 62 20 D1 4A 1A 11 6F E4 A8 5C 33 FE 1E 35 CD 9A 3F 48 44 13 64 A3 E9 50 58 ED 26 35 82 D3 6E FA 8E A4 EF EE A2 42 21 C5 4C 02 FB 5D C3 AE 17 97 8B D6 CE 6B 68 A2 4B 3B 13 C8 61 3A 2E 1E 0A 53 1B A1 71 AF 7E 1E FF 44 4B FF 72 50 03 89 F6 64 2F 0F 62 E4 9A 43 0C 6D F7 0C 07 EE 0D
ICC public modulus: A0 8D F5 E5 1F E8 F5 B0 BE 6F 97 A3 0C 74 88 8D 55 E7 56 B3 42 F1 BF 06 91 99 C4 80 70 9C 75 F3 BA A0 D4 4C C4 E7 BC 9C 68 9F 5B F2 29 37 F4 B5 42 D1 9D 7B B1 98 74 5B D7 77 E2 15 8E E5 41 12 8A 15 8E 73 6A 88 4B 82 C5 21 61 6E F0 6F 8D 26 7C 07 B1 EF 79 8A B5 77 AA A3 C6 DD 89 37 C9 B2 34 4C EC AD 5A B8 D5 29 BC AC A7 F9 EC EA DE 85 99 0F 1E 04 FE AE 9F A0 33 DF 69 12 68 F9 F2 D5
Terminal unpredictable number: B0 32 0F C0
Signature: 89 A6 C6 A0 AD 68 43 14 03 EE 4E 92 4B A8 CE B0 ED D9 F2 23 9A AB C9 90 D6 67 FD D5 B4 FF FC 98 99 AB 66 A7 10 0D 5B EB EE 36 7C 36 79 2D A2 A2 92 11 A2 0C 00 71 86 4B BE 20 BA 44 57 73 E5 0C 2D FB 17 AA DE 5C 85 8B 19 66 B8 F3 40 E0 00 EB BF 10 8B 1C AE 91 BD D0 DC 0C D3 D5 40 85 42 72 B0 E2 2F 30 D5 B5 EA 61 29 C9 9F 4F 39 F3 EE BC 66 06 F7 60 11 4D D6 DB 57 CF 57 F6 C1 EF 8C 35
Signed Dynamic Authentication Data
Evaluated: 6A 05 01 26 08 98 43 55 5A 0A C1 C2 4A 80 EC 19 0A DB E4 1C 90 B0 AA 00 A2 EC B5 50 A9 54 A9 92 00 1E CA 05 21 B1 DD 13 98 ED BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB 8E 73 0F 77 06 61 76 D4 6A 68 EF 7A 9C 45 23 0C 9A 62 43 C6 BC
RecoveredDataHeader '6A'h
DynamicApplicationData_for_signature '05 01 26 08 98 43 55 5A 0A C1 C2 4A 80 EC 19 0A DB E4 1C 90 B0 AA 00 A2 EC B5 50 A9 54 A9 92 00 1E CA 05 21 B1 DD 13 98 ED BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB'h structure
SignedDataFormat '05'h
HashAlgorithmIndicator '01'h
ICCDynamicDataLength 38
ICCDynamicData '08 98 43 55 5A 0A C1 C2 4A 80 EC 19 0A DB E4 1C 90 B0 AA 00 A2 EC B5 50 A9 54 A9 92 00 1E CA 05 21 B1 DD 13 98 ED'h
PadPattern 'BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB'h
HashResult '8E 73 0F 77 06 61 76 D4 6A 68 EF 7A 9C 45 23 0C 9A 62 43 C6'h
RecoveredDataTrailer 'BC'h
Expected: 6A 05 01 .. .. .. .. BC
RecoveredDataHeader '6A'h
DynamicApplicationData_for_signature 05 01 .. .. .. structure
SignedDataFormat '05'h
HashAlgorithmIndicator '01'h
ICCDynamicDataLength Length(ICCDynamicData)
ICCDynamicData .. concatenation
QS{0-}
''h
PadPattern .. concatenation
QS {..}
''h
HashResult .. concatenation
QS{1-}
''h
RecoveredDataTrailer 'BC'h
Previous Transaction History
Response: 61 A5
SW1 SW2: 61 A5 (SW_OK Response bytes available(Le))
Get Response
Request : 00 C0 00 00 A5
Class :00
Ins :C0
P1 :00
P2 :00
Le :A5
Response: C0 77 81 A2 9F 27 01 80 9F 36 02 00 08 9F 4B 81 80 89 A6 C6 A0 AD 68 43 14 03 EE 4E 92 4B A8 CE B0 ED D9 F2 23 9A AB C9 90 D6 67 FD D5 B4 FF FC 98 99 AB 66 A7 10 0D 5B EB EE 36 7C 36 79 2D A2 A2 92 11 A2 0C 00 71 86 4B BE 20 BA 44 57 73 E5 0C 2D FB 17 AA DE 5C 85 8B 19 66 B8 F3 40 E0 00 EB BF 10 8B 1C AE 91 BD D0 DC 0C D3 D5 40 85 42 72 B0 E2 2F 30 D5 B5 EA 61 29 C9 9F 4F 39 F3 EE BC 66 06 F7 60 11 4D D6 DB 57 CF 57 F6 C1 EF 8C 35 9F 10 12 02 10 A7 40 0F 04 00 00 00 00 00 00 00 00 00 00 00 FF 90 00
Ack Byte : C0
Data : 77 81 A2 9F 27 01 80 9F 36 02 00 08 9F 4B 81 80 89 A6 C6 A0 AD 68 43 14 03 EE 4E 92 4B A8 CE B0 ED D9 F2 23 9A AB C9 90 D6 67 FD D5 B4 FF FC 98 99 AB 66 A7 10 0D 5B EB EE 36 7C 36 79 2D A2 A2 92 11 A2 0C 00 71 86 4B BE 20 BA 44 57 73 E5 0C 2D FB 17 AA DE 5C 85 8B 19 66 B8 F3 40 E0 00 EB BF 10 8B 1C AE 91 BD D0 DC 0C D3 D5 40 85 42 72 B0 E2 2F 30 D5 B5 EA 61 29 C9 9F 4F 39 F3 EE BC 66 06 F7 60 11 4D D6 DB 57 CF 57 F6 C1 EF 8C 35 9F 10 12 02 10 A7 40 0F 04 00 00 00 00 00 00 00 00 00 00 00 FF
Tag 77 : Response Message Template Format 2
Tag 9F 27: Cryptogram Information Data (CID) : 80
Byte 1 bit 8-7 = 10 ARQC
bit 6-5 = 00 Payment System specific cryptogram
bit 4 = 0 No advice required
bit 3-1 = 000 No information given
Tag 9F 36: Application Transaction Counter (ATC) : 00 08
Decimal value = 8
Tag 9F 4B: Signed Dynamic Application Data : 89 A6 C6 A0 AD 68 43 14 03 EE 4E 92 4B A8 CE B0 ED D9 F2 23 9A AB C9 90 D6 67 FD D5 B4 FF FC 98 99 AB 66 A7 10 0D 5B EB EE 36 7C 36 79 2D A2 A2 92 11 A2 0C 00 71 86 4B BE 20 BA 44 57 73 E5 0C 2D FB 17 AA DE 5C 85 8B 19 66 B8 F3 40 E0 00 EB BF 10 8B 1C AE 91 BD D0 DC 0C D3 D5 40 85 42 72 B0 E2 2F 30 D5 B5 EA 61 29 C9 9F 4F 39 F3 EE BC 66 06 F7 60 11 4D D6 DB 57 CF 57 F6 C1 EF 8C 35
Tag 9F 10: Issuer Application Data [M/Chip 4] : 02 10 A7 40 0F 04 00 00 00 00 00 00 00 00 00 00 00 FF
Key Derivation Index = 02
Cryptogram Version Number = 10
Card Verification Results (CVR) = A7 40 0F 04 00 00
Byte 1 bit 8-7 = 10 AC Returned in Second Generate AC: Not requested
bit 6-5 = 10 AC Returned in First Generate AC: ARQC
bit 4 = 0 RFU
bit 3 = 1 Offline PIN Verification Performed
bit 2 = 1 Offline Encrypted PIN Verification Performed
bit 1 = 1 Offline PIN Verification Successful
Byte 2 bit 8 = 0 DDA not returned
bit 7 = 1 M/Chip Select 4: Combined DDA/AC Generation Returned in First Generate AC, M/Chip Lite 4: Value not allowed
bit 6 = 0 Combined DDA/AC Generation Not Returned in Second Generate AC
bit 5 = 0 Issuer Authentication not performed
bit 4 = 0 CIAC-Default not skipped on CAT3 or not required
bit 3 = 0 RFU
bit 2 = 0 RFU
bit 1 = 0 RFU
Byte 3 bit 8-5 = 0000 Right nibble of Script Counter : '0'
bit 4-1 = 1111 Right nibble of PIN Try Counter: 'F'
Byte 4 bit 8 = 0 RFU
bit 7 = 0 Unable To Go Online Not Indicated
bit 6 = 0 Offline PIN Verification Performed
bit 5 = 0 No Failure OF Offline PIN Verification
bit 4 = 0 PTL Not Exceeded
bit 3 = 1 International Transaction
bit 2 = 0 International Transaction
bit 1 = 0 Terminal Does Not Erroneously Consider Offline PIN OK
Byte 5 bit 8 = 0 Lower Consecutive Offline Limit Not Exceeded
bit 7 = 0 Upper Consecutive Offline Limit Not Exceeded
bit 6 = 0 Lower Cumulative Offline Limit Not Exceeded
bit 5 = 0 Upper Cumulative Offline Limit Not Exceeded
bit 4 = 0 Go Online On Next Transaction Was Not Set (in this transaction or in a previous one)
bit 3 = 0 No Issuer Authentication Failed (in this transaction or in a previous one)
bit 2 = 0 No Script Received (in a previous transaction)
bit 1 = 0 No Script Failed (in a previous transaction)
Byte 6 bit 8 = 0 RFU
bit 7 = 0 RFU
bit 6 = 0 RFU
bit 5 = 0 RFU
bit 4 = 0 RFU
bit 3 = 0 RFU
bit 2 = 0 No Match found in Additional Check Table
bit 1 = 0 Match Found in Additional Check Table
DAC = 00 00
Counters = 00 00 00 00 00 00 00 FF
SW1 SW2 : 90 00 (SW_OK)
2nd Generate AC (TC)
Request : 80 AE 50 00 23 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 59 33 00 80 00 80 00 B0 32 0F C0 98 43 55 5A 0A C1 C2 4A
Class :80
Ins :AE
P1 :50
P2 :00
Lc :23
Data :00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 59 33 00 80 00 80 00 B0 32 0F C0 98 43 55 5A 0A C1 C2 4A
Tag 91 : Issuer Authentication Data [M/Chip] : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Tag 8A : Authorization Response Code : 59 33
Response Code = 59 33
Meaning = Unable to go online, Requesting for offline approval
Tag 95 : Terminal Verification Results (TVR) : 00 80 00 80 00
Byte 1 bit 8 = 0 Offline data authentication was performed
bit 7 = 0 SDA passed or not performed
bit 6 = 0 No ICC data missing
bit 5 = 0 Card does not appear on terminal exception file
bit 4 = 0 DDA passed or not performed
bit 3 = 0 CDA passed or not performed
bit 2 = 0 SDA not selected
bit 1 = 0 RFU
Byte 2 bit 8 = 1 ICC and terminal have different application versions
bit 7 = 0 No Expired application
bit 6 = 0 Application effective
bit 5 = 0 Requested service allowed for card product
bit 4 = 0 No New card
bit 3 = 0 RFU
bit 2 = 0 RFU
bit 1 = 0 RFU
Byte 3 bit 8 = 0 Cardholder verification was successful or not performed
bit 7 = 0 Recognised CVM
bit 6 = 0 PIN Try Limit not exceeded
bit 5 = 0 No PIN entry required (PIN pad may or may not be present or may or may not be working)
bit 4 = 0 No PIN entry required (PIN pad may or may not be present)
bit 3 = 0 No Online PIN entered
bit 2 = 0 RFU
bit 1 = 0 RFU
Byte 4 bit 8 = 1 Transaction exceeds floor limit
bit 7 = 0 Lower consecutive offline limit not exceeded
bit 6 = 0 Upper consecutive offline limit not exceeded
bit 5 = 0 Transaction not selected randomly for online processing
bit 4 = 0 Merchant did not force transaction online
bit 3 = 0 RFU
bit 2 = 0 RFU
bit 1 = 0 RFU
Byte 5 bit 8 = 0 No Default TDOL used
bit 7 = 0 Issuer authentication passed or not performed
bit 6 = 0 Script processing passed before final GENERATE AC or no script received
bit 5 = 0 Script processing passed after final GENERATE AC or no script received
bit 4 = 0 RFU
bit 3 = 0 RFU
bit 2 = 0 RFU
bit 1 = 0 RFU
Tag 9F 37: Unpredictable Number : B0 32 0F C0
Tag 9F 4C: ICC Dynamic Number : 98 43 55 5A 0A C1 C2 4A
Previous Transaction History
Response: 69 85
SW1 SW2: 69 85 (SW_Error Accesscondition not satisfied)
Test Completed
It seems like you did a lot of "Offline approval" without clear counters.
There are several possible reasons in your case for 6985:
1) AC Session Key Counter Limit Exceeded
Because response code in Second Generate AC is "Unable to go online, Requesting for offline approval" card goes Offline, therefore CTR accumulates and is not reset (it reset only then Online in Generate AC 2).
Try to personalize increased limits or do full Online.
2) Overflow during the amount conversion, if transaction International
(transaction currency != CRM currency Code).
Required full Online
3) Overflow during add the cumulative amount, if transaction Domestic (transaction currency == CRM currency Code).
Required full Onlinе
also, check why "Country code" is absent in Cdol1
I got some help from my test tool's support system. Their response helped explain this scenario:
Response 1:
"The transaction amount in your test cases M-TIP 50 test1, test2, and test 3 are all above the floor limit, so the transactions are supposed to go online. However, due to your test environment is offline, the transactions can not be processed online. I can see the issuer authentication data in the 2nd generate AC are all 0s (They are not returned by the issuer, but the default value set by the terminal). The card validate the authentication data to see if the data is returned by the issuer. In your case, the validation is failed and the card returns "69 85"."
Response 2:
"The MTIP50 test cases are a little special. The issuer authentication data for MTIP50 test cases is 16 bytes which is different than the normal value (10 bytes). Thus BTT has extra checks on the issuer authentication data of MTIP50. Since the issuer authentication data are all zeros in your case, the simulated card thinks they are not valid."
Resolution:
Turns out this was an issue with the testing tool I was using. They recently released a new version of their software and this no longer happens.
Related
I have a custom SOM (based on iMX6) board being developed that will run Ubuntu, and has several I2C devices attached to one of the iMX6 I2C "adapters". Given the hardware is not yet available, I'd like to write software to access and control said I2C devices, preferably by emulating them on my Ubuntu laptop; I'm thinking such as setup might also be useful for software testing.
I've been playing with i2cdetect to see what is on my laptop, and I found a few particularly intriguing things; consider these commands and the responses:
$ sudo i2cdetect -l
i2c-3 i2c i915 gmbus dpd I2C adapter
i2c-1 i2c i915 gmbus dpc I2C adapter
i2c-6 i2c DPDDC-C I2C adapter
i2c-4 i2c DPDDC-A I2C adapter
i2c-2 i2c i915 gmbus dpb I2C adapter
i2c-0 i2c Synopsys DesignWare I2C adapter I2C adapter
i2c-5 i2c DPDDC-B I2C adapter
$ sudo i2cdetect -y -r 4
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
10: 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f
20: 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f
30: 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f
40: 40 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e 4f
50: 50 51 52 53 54 55 56 57 58 59 5a 5b 5c 5d 5e 5f
60: 60 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f
70: 70 71 72 73 74 75 76 77
I understand this to mean that, for each cell in that table that has a number, a device with that number as its address is present on the bus; for example, the first number, 0x03, means there is a device with I2C address 0x03. It seems rather unlikely that the i2c-4 adapter really has 117 devices attached to it! (FWIW most of the other adapters have no devices, with only two showing a small number of devices on each bus; these appear to be "real" I2C buses.) But back to i2c-4 - is that some sort of simulated (or emulated) adapter with simulated devices on it? I decided to see what I could i2cdump data from one of the suspect devices, and found something like this:
$ sudo i2cdump -y 4 0x3 b
0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
00: 00 00 02 02 04 04 06 06 08 08 0a 0a 0c 0c 0e 0e ..??????????????
10: 10 10 12 12 14 14 16 16 18 18 1a 1a 1c 1c 1e 1e ????????????????
20: 20 20 22 22 24 24 26 26 28 28 2a 2a 2c 2c 2e 2e ""$$&&((**,,..
30: 30 30 32 32 34 34 36 36 38 38 3a 3a 3c 3c 3e 3e 0022446688::<<>>
40: 40 40 42 42 44 44 46 46 48 48 4a 4a 4c 4c 4e 4e ##BBDDFFHHJJLLNN
50: 50 50 52 52 54 54 56 56 58 58 5a 5a 5c 5c 5e 5e PPRRTTVVXXZZ\\^^
60: 60 60 62 62 64 64 66 66 68 68 6a 6a 6c 6c 6e 6e ``bbddffhhjjllnn
70: 70 70 72 72 74 74 76 76 78 78 7a 7a 7c 7c 7e 7e pprrttvvxxzz||~~
80: 80 80 82 82 84 84 86 86 88 88 8a 8a 8c 8c 8e 8e ????????????????
90: 90 90 92 92 94 94 96 96 98 98 9a 9a 9c 9c 9e 9e ????????????????
a0: a0 a0 a2 a2 a4 a4 a6 a6 a8 a8 aa aa ac ac ae ae ????????????????
b0: b0 b0 b2 b2 b4 b4 b6 b6 b8 b8 ba ba bc bc be be ????????????????
c0: c0 c0 c2 c2 c4 c4 c6 c6 c8 c8 ca ca cc cc ce ce ????????????????
d0: d0 d0 d2 d2 d4 d4 d6 d6 d8 d8 da da dc dc de de ????????????????
e0: e0 e0 e2 e2 e4 e4 e6 e6 e8 e8 ea ea ec ec ee ee ????????????????
f0: f0 f0 f2 f2 f4 f4 f6 f6 f8 f8 fa fa fc fc fe fe ????????????????
This worked for device addresses 0x03 through 0x07; above that, the hex data was replaced with XX! Anyway, I'm guessing this table shows 256 bytes of data on the "device".
I tried to read/write/read a byte, but it doesn't work:
$ sudo i2cget -y 4 0x3 0xff
0xfe
$ sudo i2cset -y 4 0x3 0xff 0x27
$ sudo i2cget -y 4 0x3 0xff
0xfe
With all that as background, here are my questions:
Is i2c-4 really an simulated I2C adapter, and what is its purpose?
Am I using i2cget and i2cset correctly, and if not, where am I going wrong? (Of course, this assumes i2c-4 address 0x3 works as I expected)
If not, is there a way to emulate an I2C device (and probably, adapter) so that I can write software that is able to read/write to it?
Of course, question 3 is the main focus here...
Thanks!
Answering this in case someone else has the same/similar question.
The secret is to use i2c-stub, which I had heard of but didn't get a clear understanding of what it is. Here is all I was looking for:
# Set up fake device
$ sudo modprobe i2c-dev
$ sudo modprobe i2c-stub chip_addr=0x03
$ i2cdetect -l
...
i2c-7 unknown SMBus stub driver N/A <<--- Here it is!
# Read data
$ sudo i2cdump -y -r 0-7 7 0x03 b
0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
00: 00 00 00 00 00 00 00 00 .?......
# Write data
$ sudo i2cset -y 7 0x03 0x01 0x27
# Read data again
$ sudo i2cdump -y -r 0-7 7 0x03 b
0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
00: 00 27 00 00 00 00 00 00 .?......
I am using FIO tool on linux to run some IO's. I am interested to look at data contents that are generated as part of the FIO command.
My command:
sudo fio --name=randwrite --ioengine=libaio --iodepth=1 --rw=write --bs=4k --direct=0 --size=512M --numjobs=1 --runtime=240 --group_reporting --filename=venkata --buffer_compress_percentage=50 --output=fioad
I am interested to see how the data is generated with 50% compress buffer option. Is there any way to look / output the FIO IO input data?
Is there any way to look / output the FIO IO input data?
Just examine the file the I/O is being done on (venkata) with a tool like hexdump? The one thing I'd caution is because your I/O file is 512 megabytes big you will almost certainly want to use the -n flag of hexdump or pipe the output to less to prevent your terminal overflowing... Here's a safe reduced example job to make analysis quicker/easier:
$ fio --name=bufcontents --filename=/tmp/fio.tmp --size=4k --bs=4k --buffer_compress_percentage=50
bufcontents: (g=0): rw=read, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=psync, iodepth=1
[...]
Run status group 0 (all jobs):
READ: bw=4000KiB/s (4096kB/s), 4000KiB/s-4000KiB/s (4096kB/s-4096kB/s), io=4096B (4096B), run=1-1msec
$ hexdump -C /tmp/fio.tmp
00000000 35 e0 28 cc 38 a0 99 16 06 9c 6a a9 f2 cd e9 0a |5.(.8.....j.....|
00000010 80 53 2a 07 09 e5 0d 15 70 4a 25 f7 0b 39 9d 18 |.S*.....pJ%..9..|
00000020 4e a9 ac d9 8e ab 9d 13 29 95 8e 86 9b 48 4e 12 |N.......)....HN.|
00000030 a5 52 3d 26 cc 05 db 1b 54 2a 75 db 9a 4d d8 1d |.R=&....T*u..M..|
00000040 4a a5 44 c6 f8 9b 39 00 a9 94 23 c6 5c d0 90 0c |J.D...9...#.\...|
00000050 95 f2 6f ce f9 b6 c2 13 52 7e 83 40 a7 6f ce 07 |..o.....R~.#.o..|
00000060 ca 6f e7 28 b3 2d e4 10 f9 ed 37 ad 42 f1 48 0f |.o.(.-....7.B.H.|
00000070 bf 7d aa 5e 8c c7 d6 00 b7 cf f5 4c 9c a9 cd 08 |.}.^.......L....|
00000080 f6 39 c3 a1 b8 8e 8c 18 3e 67 3d 77 f5 40 ef 0b |.9......>g=w.#..|
00000090 e7 ac 48 fb 7f 2c 35 1c 9c 95 f5 a8 eb a7 d7 19 |..H..,5.........|
000000a0 b3 b2 50 aa 82 20 89 0f 56 96 f0 fb e7 ce d4 03 |..P.. ..V.......|
000000b0 ca 12 53 b4 e4 9b e0 17 59 62 25 0d 53 b9 0f 0e |..S.....Yb%.S...|
000000c0 4b 2c 78 b0 97 70 47 13 89 85 e9 df d6 15 6a 09 |K,x..pG.......j.|
000000d0 b1 b0 38 19 c6 d2 c0 0e 16 96 ce 6a bc 0d 0c 15 |..8........j....|
000000e0 c2 d2 4e 42 50 4c dd 08 58 da e8 9e 62 88 c1 15 |..NBPL..X...b...|
000000f0 4b 1b b1 e6 97 e1 ee 00 69 a3 30 6f da e8 9e 17 |K.......i.0o....|
00000100 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000200 a8 71 09 48 d3 ad 5f c5 35 2e 2d b0 b5 51 5a 13 |.q.H.._.5.-..QZ.|
[...]
(100 in hex is 256 in decimal, 200 in hex is 512 in decimal etc)
Alternatively, since you asked this on Stack Overflow (which is for programming questions), fio is open source and the fio source is available on GitHub, we can read the source there (note that you didn't say WHICH version of fio you are using so I shall assume the very latest at the tile of writing which is fio-3.21):
https://github.com/axboe/fio/blob/fio-3.21/io_u.c#L2166 (fill_io_buffer() in io_u.c): when compress_percentage is non-zero, fio will try to repeatedly call fill_random_buf_percentage() until it has created a block sized buffer worth of data. In the example job you set a block size of 4k (so the min and max block sizes will both be 4k) and compress_chunk will be 512 (its default). Therefore fill_random_buf_percentage() will be called 8 times and each time with its segment and len parameters being 512.
https://github.com/axboe/fio/blob/fio-3.21/lib/rand.c#L137 (__fill_random_buf_percentage() in rand.c): This works out the percentage of the segment it is filling that needs to be random data and the rest is set to either zeros (the default) or the buffer_pattern (if set). With your example the first 256 bytes will be random data and the next 256 will be zeros.
This is the code for a SUB-side handler of a ZeroMQ PUB / SUB socket:
sock.on('message', function(topic, message) {
console.log("--Topic--");
console.log(topic);
console.log(topic.toString('utf8'));
console.log("--Message--");
console.log(message);
console.log(message.toString('utf8'));
console.log("");
});
Probably missing something here, but I am having a hard time working out why my buffer conversion is returning junk:
--Topic--
<Buffer 70 72 65 73 65 6e 63 65>
presence
--Message--
<Buffer 08 a0 43 10 f9 dd d3 cb 05 18 00 20 18 2a 06 00 0c 29 f2 d5 b4 aa 1f 30 10 00 1a 14 13 00 b3 75 48 ec 55 a7 92 a2 bd ee 9d 4b b6 25 a0 77 a5 d3 22 0c ... >
�C���� *
)�մ�0�uH�U������K�%�w��"
Aruba AP 215*
��۟
The first item (topic) decodes without issue, but the message doesn't seem to.
For example: How would one decode the following ethernet frame?
00 26 b9 e8 7e f1 00 12 f2 21 da 00 08 00 45 00 05 dc e3 cd 20 10 35 06 25 eb 0a 0a 0a 02 c0 a8 01 03 c3 9e 0f 40 00 00 10 00 00 00 14 00 70 10 00 5c 59 99 00 00 02 04 05 b4 01 03 03 06 00 00 01 98 64 34 e8 90 84 98 20 12 18 19 04 85 80 00
I know that the first 6 bytes are the MAC destination address : 00 26 b9 e8 7e f1 The next 6 bytes are the source MAC address : 00 12 f2 21 da 00 The next 2 bytes show the ethernet type : 08 00 The next 4 bytes are : 45 00... Ipv4... "5" the number of bytes in the header.. and "00" means there are no differentiated services.
What I don't know is what anything after that is or how to read it.
Anyone help?
Rearranging a bit your packet, we have:
00 26 b9 e8 7e f1 00 12 f2 21 da 00 08 00 45 00
05 dc e3 cd 20 10 35 06 25 eb 0a 0a 0a 02 c0 a8
01 03 c3 9e 0f 40 00 00 10 00 00 00 14 00 70 10
00 5c 59 99 00 00 02 04 05 b4 01 03 03 06 00 00
01 98 64 34 e8 90 84 98 20 12 18 19 04 85 80 00
If you know that the first 6 octets form the destination mac address, that means that it is an Ethernet layer 2 packet.
According to IEEE 802.3, $3.1.1:
First 6 octets are the destination mac address (00 26 b9 e8 7e f1)
Next 6 octets are the source mac address (00 12 f2 21 da 00)
Next 4 octets are, optionally the 802.1Q tag (present, 08 00 45 00)
Next 2 octets are either:
Maximum payload size - aka MTU (if <= 1500, which is the case, 05 dc is 1500)
Ethernet 2 frame (if >= 1536)
Next is the payload ranging from 46 octets (if the 802.1Q tag is absent) or 42 octets (if the 802.1Q tag is present) to up to 1500 octets (starts at e3 cd 20 10 ..., ends either at 20 12 18 19 or at 03 06 00 00, depends on the 7th item)
Last 4 octets form the CRC32 code (either 01 98 64 34 or 04 85 80 00, depending on the 7th item)
There is also 12 octets used for padding (random - not so random - bytes), that may or may not be inserted in this packet. (if inserted, the padding is e8 90 84 98 20 12 18 19 04 85 80 00)
I got some ADTS AAC raw data from somewhere(actually it is extracted from a demuxed file) and in theory it should be corrected encoded. it looks like this:
Frame1:
21 19 94 ED A1 09 45 58 09
40 02 CA AA 85 D4 E5 C5 58 A9 73 00 0C 75 1C 5D
A7 4E 52 40 90 38 71 9C 65 D5 C4 22 0B 28 7D EF
F8 42 33 15 03 BA 6C DE B1 74 B4 A1 4E 0A 21 05
15 34 6B FD D9 E7 8F BF FF 79 5C D3 7D 90 79 F6
65 57 08 3A F7 C5 14 85 5E D7 C3 7D 2A 85 E1 7A
86 BA 3A AC 13 0D AE D1 1B 65 69 B6 71 92 E5 8A
BC CB 5C 7A 6F D7 F2 2B 38 C9 0E 2A 40 2F 8E 90
9B 1F A2 3A 9C 39 A8 35 CE 69 14 CD 64 54 70 00
50 07 CE 37 83 6E F0 01 18 AA A8 49 B2 8B 8F A1
37 17 1C 06 00 00 00 06 00 72
Frames2:
21 19 95 14 C2 0A A9 61 19 8B CB 9B 56 AE A7
0A A0 34 DA EA D9 34 28 0C F8 DC 0C 30 97 12 A7
DD 3F F5 FE 7B 65 52 61 6D 7F DA BE D3 EB 30 CA
A6 94 54 8E D4 0A 32 E1 EA FD AD 02 82 B5 1E 40
4C 04 3A BE 56 21 5D 7D 5D B3 31 2A 5D AF 4E FF
A6 48 B9 42 E3 87 DE 5C 59 4B B9 BB C3 2C AD 50
6B 35 C8 24 6C 06 82 86 B2 26 17 E2 C6 DD 9A 43
53 91 D3 68 8D 67 8E 7D 0A 28 EB 7D F1 BB FC 56
5E 13 25 F9 77 E6 27 BF DA 4E 09 38 86 20 0A 00
F9 C6 F0 1D DE 00 21 05 4F 28 C0 A0 5F 0E 18 00
03 00 0E
.....
And for each following frames there is a quite strange similiar header as:
21 19 xx xx
For examples:
21 19 94 E1 ..
21 19 95 03 ..
....
So do you know what does this header mean?
This is how ADTS AAC looks like, for example for stereo:
adts_header()
channel_pair_element()
adts_header()
channel_pair_element()
adts_header()
channel_pair_element()
adts_header()
channel_pair_element()
etc...
This seems like it's not ADTS header at all. ADTS header is typicaly not used in some other container, like mp4, but is used for standalone AAC files only. ADTS header starts with 12 bit syncword 1111 1111 1111. So all ones, and this is not the case in your example.
In case muxer stripped out any header there was, you might have raw AAC which should start with single_channel_element() in case of mono or channel_pair_element() in case of stereo.
single_channel_element() starts with 3 bits 000
cannel_pair_element() starts with 3 bits 001
Your sample starts with 0010 0001 0001 1001 so it might be channel_pair_element().
You probably have stereo but without any header, like so:
channel_pair_element()
channel_pair_element()
channel_pair_element()
channel_pair_element()
etc.
You should ask the muxer to tell you the number of channels, sampling rate, etc, and you are ready to continue decoding. Muxer should grab this info from mp4 or whichever container your AAC was originaly in.
It most likely a mpeg4 latm format. if you run mediainfo tool to check, it will output as below:
$mediainfo a.aac
General
Complete name : a.aac
Format : LATM
File size : 821 KiB
Overall bit rate mode : Variable
Audio
Format : AAC
Format/Info : Advanced Audio Codec
Format profile : HE-AACv2 / HE-AAC / LC
Bit rate mode : Variable
Channel(s) : 2 channels / 1 channel / 1 channel
Channel positions : Front: L R / Front: C / Front: C
Sampling rate : 48.0 KHz / 48.0 KHz / 24.0 KHz
Compression mode : Lossy
Such format usually generated after ADTS header removed or from DTV channel. DTV data transfer use LATM format to save bandwidth, so no ADTS header there but use some codec config buffer to initialize decoder.