forked from public/pysim
f1609424de
The current behavior we implement in the method __send_apdu_T0 is incomplete. Some details discussed in ETSI TS 102 221, section 7.3.1.1.4, clause 4 seem to be not fully implemented. We may also end up sending a GET RESPONSE in other APDU cases than case 4 (the only case that uses the GET RESPONSE command). Related: OS#6970 Change-Id: I26f0566af0cdd61dcc97f5f502479dc76adc37cc
34 lines
1.4 KiB
Plaintext
34 lines
1.4 KiB
Plaintext
set debug true
|
|
set echo true
|
|
set apdu_trace true
|
|
set apdu_strict true
|
|
|
|
# Case #1: (open channel #1)
|
|
# No command data field, No response data field present
|
|
apdu 00700001 --expect-sw 9000 --expect-response-regex '^$'
|
|
|
|
# Case #1: (verify pin)
|
|
# This command returns the number of remaining authentication attempts in the
|
|
# form of a status that has the form 63cX, where X is the number of remaining
|
|
# attempts. Such a status word can be easily confused with the response to a
|
|
# case #4 APDU. This test checks if the transport layer correctly distinguishes
|
|
# the between APDU case #1 and APDU case #4.
|
|
apdu 0020000A --expect-sw 63c? --expect-response-regex '^$'
|
|
|
|
# Case #2: (status)
|
|
# No command data field, Response data field present
|
|
apdu 80F2000000 --expect-sw 9000 --expect-response-regex '^[a-fA-F0-9]+$'
|
|
|
|
# Case #2: (verify pin)
|
|
# (see also above). This test checks if the transport layer is also able to
|
|
# distinguish correctly between APDU case #2 (with zero length response) and
|
|
# APDU case #4.
|
|
apdu 0020000A00 --expect-sw 63c? --expect-response-regex '^$'
|
|
|
|
# Case #3: (terminal capability)
|
|
# Command data field present, No response data field
|
|
apdu 80AA000005a903830180 --expect-sw 9000 --expect-response-regex '^$'
|
|
|
|
# Case #4: (select MF)
|
|
# Command data field present, Response data field present
|
|
apdu 00a40004023f0000 --expect-sw 9000 --expect-response-regex '^[a-fA-F0-9]+$' |