Cardem under Manjaro/Arch: Some Troubleshooting

[Harald Welte]

Hi Katherina and list,

I think I've now fixed master, so 'cardem' versions from
e33c2907bcc113fca8e189bc69c36383615523e9
(current master) upwards should work at least for basic use cases.  At
least they do on those phones I've tested so far (which is not a lot
yet, admittedly).

I've also updated our CI to actually build 'simtrace-cardem-dfu' images
and publish those at  https://ftp.osmocom.org/binaries/simtrace2/
which now has the build like
https://ftp.osmocom.org/binaries/simtrace2/firmware/all/simtrace-cardem-dfu-0.7.0.106-79650.bin

I'm currently looking at a potential problem regarding to PTS,  where
the log output of simtrace2-cardem-pcsc looks like this:


... everything looks great but then a block like his happens:

SIMtrace <- 01 01 00 00 00 00 10 00 06 00 00 00 02 00 94 04
SIMtrace IRQ 01 04 00 00 00 00 15 00 13 00 00 00 00 00 01 01 0a 80 25 00 00
SIMtrace IRQ STATUS: flags=0x13, fi=1, di=1, wi=10 wtime=9600
SIMtrace IRQ 01 04 00 00 00 00 15 00 03 00 00 00 00 00 01 01 0a 80 25 00 00
SIMtrace IRQ STATUS: flags=0x3, fi=1, di=1, wi=10 wtime=9600
-> 01 07 00 00 00 00 15 00 04 ff 10 11 fe 00 00 ff 10 11 fe 00 00
=> PTS req: ff 10 11 fe 00 00
-> 01 06 00 00 00 00 13 00 01 00 00 00 05 00 00 a4 00 04 02
=> DATA: flags=1, 00 a4 00 04 02 : <= osmo_st2_cardem_request_pb_and_rx(a4, 2)
SIMtrace <- 01 01 00 00 00 00 0f 00 08 00 00 00 01 00 a4
-> 01 06 00 00 00 00 10 00 02 00 00 00 02 00 3f 00
=> DATA: flags=2, 3f 00 : SW=0x6e00, len_rx=0
<= osmo_st2_cardem_request_sw_tx(6e 00)
SIMtrace <- 01 01 00 00 00 00 10 00 06 00 00 00 02 00 6e 00
-> 01 06 00 00 00 00 13 00 01 00 00 00 05 00 00 a4 00 04 02
=> DATA: flags=1, 00 a4 00 04 02 : <= osmo_st2_cardem_request_pb_and_rx(a4, 2)
SIMtrace <- 01 01 00 00 00 00 0f 00 08 00 00 00 01 00 a4
-> 01 06 00 00 00 00 10 00 02 00 00 00 02 00 3f 00
=> DATA: flags=2, 3f 00 : SW=0x6e00, len_rx=0
<= osmo_st2_cardem_request_sw_tx(6e 00)
SIMtrace <- 01 01 00 00 00 00 10 00 06 00 00 00 02 00 6e 00

where we see a PTS is happening, and afterwards a seemingly innocent
APDU like "00 a4 00 04 02 3f 00" (SELECT MF) results in
SW  6e00: Checking errors - Class not supported

-- 
- Harald Welte <laforge at osmocom.org>            http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)