Timing Issue using Chipdrive Micro 120 V4.30 (buffered RS232) and Jameica/Hibiscus with recent Ubuntu 18.4 (recent Kernel 4.15, recent glibc?)

[gjaekel]

I'm just "migrating" an old (sigh) Ubuntu 14.4 to 18.4: I'm using an independent root partition, clone home and data directories and re-use some shared application on external shares.

In particular, i'm switching over a 1:1 clone of the Jameica/Hibiscus HBCI banking application on the same hardware. But with the newer Ubuntu, the HBCI is not accessible while all still work if i boot the old Ubuntu.

Using the towitoko tester application, the HBCI card is detected, if I initialize it on "COM2" (i.e. ttyS1). But on 18.04, there is no "answer" even on a menu refresh ('*'). You'll see in the following: this is no problem with user rights or something like this.

I'm using libtowitoko.so.2.0.0 of package (dev-)libtowitoko2-2.0.7 from the Ubuntu repository. But's it's no difference if I use the version 2.0.7 delivered with Hibiscus.

But if I start the towitoko tester via 'strace -f tester', it will surprisedly work! I conclude this is some sort of timing error and strace will slow down things just enough to work.

To prove, I downloaded the source of release 2.0.7 and change l.37 of driver/ifd_towitoko.c:

• #define IFD_TOWITOKO_DELAY 0

• #define IFD_TOWITOKO_DELAY 1

Currently i havn't figured out how to let build the .so, but the build drops a static-linked Version of the tester application (checked with ldd). And with this "DELAY 1"-version, the card send reply after initialisation on Ubuntu 18.04 with the recent Kernel / glibc .

Is it appropriate to change this delay? If you agree, I'll may send a pull request. And please tell me, how to let build the shared lib -- I'm no hard core developer, i'm not trained in this.

I'll continue to re-investigate this using the 2.0.8 trunk because i found that here IFD_TOWITOKO_ATR_TIMEOUT was rised from 200 to 400.

with greetings

Guido

[cprados]

If IFD_TOWITOKO_DELAY is set to a different value of 0 following things happen:

• All bytes (both control and data information) sent to the serial port / card reader are sent 1 by 1, ie: one write system call per byte opposed to 1 single write function call for each paquet of data.

• Before each byte is written to the serial port the driver waits IFD_TOWITOKO_DELAY milliseconds.

That would affect all the operations of the driver with the card reader. As you can see that delay parameter is set to 0 so that capability that is in the code is actually never used. It was probably witten (+- 20 years ago, I don't remember now the details) for debbuging.

So the short answer is I don't think that value should be increased this way in general but maybe for some specific commands and for some specific smartcards who need it.

Regarding compilation, it uses generic libtool, automake, autoconf, etc. procedures. It should not be difficult to find out how it should build a shared library on your system. I don't think it has anything specific for that, It is libtool who cares of setting up the build scripts for the shared library. I see there is a configure script option --enable-shared but it is deffaulted to "yes" so there must be something on your system.

[gjaekel]

Dear Carlos,
happy new year and thank you for fast reply and analysis of the code!

Concerning the shared lib I'll google around. Maybe some dev tool chain tools are missing, because it's a plain vanilla Ubuntu 18.04.

May you give me a hint what I should try to change other than the IFD_TOWITOKO_DELAY parameter? Have you any idea what might have been changed between my old Ubuntu 14 (currently using Kernel 3.13.0-164 and 2.19-0ubuntu6.14) and Ubuntu 18?

Guido

[gjaekel]

I switched to my Gentoo homeserver platform for further development. I bumped the current portage ebuild to your 2.0.8 release here withing a few minutes. Running this ebuild I got a shared lib and a dynamical linked 'tester' binaray out of the box.

Will advance to deploy and test it on Ubuntu now.

[gjaekel]

I switched to my Gentoo homeserver platform for further development. I bumped the current portage ebuild to your 2.0.8 release here withing a few minutes. Running this ebuild I got a shared lib and a dynamical linked 'tester' binaray out of the box.

I worked out a patch and tested it on Ubuntu: I decoupled the usage of IFD_TOWITOKO_DELAY used for write delay from a debug mode, where each byte was send separately. From this, there is just one delay per whole write.

I send a pull request with the changes.