Hello,
I agree with this and am very sorry. When I first started doing this about
2 years ago I was just learning and I actually used a different CT-API spec
to write the interface. If anyone has a correct CT-API skeleton that I can
use - I'll put it on the web site so that anything new can be taken care of.
Also, the SCR 110 driver won't quite work with the Reflex 72. There is a
bit of confusion about model numbers here but I won't go into it. I am
working on the 72 code though and will put it back on the web soon.
Schlumberger asked me to remove it because there were some problems with a
couple of cards.
I didn't write the original driver but I just recently got the source code
and will be looking at it. In the meantime I will send a copy of the old
version of the driver if you have to have it now and if you email me but
please do not ask Schlumberger to help you if you have any problems with it.
Also, right now the pcsc resource manager can either load the readers on
demand or at startup. On demand currently has an event thread which helps
notify of card insertion and removal. Plus it is much quicker since the
reader and card are powered up already and may only need to be reset.
I may load the libraries on startup and then start an event thread on
connection so that the events are only notified if there is a connection to
the reader. This would help stop port hijacking and still allow event
notification and automatic reset of cards when inserted. It would also
help stop memory leaks from loading/unloading the library many times. Try
the following:
main() {
while (1) {
void *v = dlopen("/usr/lib/libm.so");
dlclose( v );
}
Many libraries will leak like a sieve if opened and closed repeatedly so
I'm trying to just open the libraries once.
Please send me any problems/etc with pcsc-lite-0.6.0 to my address:
[EMAIL PROTECTED] if you have any and I'll try to get it fixed.
Best Regards,
Dave
>Hi all
>
>I encountered a severe problem with the current CT-API interface used in
>MUSCLE. The skeleton defines the interface to be
>
>int CT_init(unsigned int Ctn, unsigned int pn)
>int CT_data(unsigned int ctn, unsigned char *dad, unsigned char *sad,
> unsigned int lc, unsigned char *cmd, unsigned int *lr,
> unsigned char *rsp)
>and
>int CT_close(unsigned int Ctn)
>
>whereas the original CT-API specification defines
>
>char CT_init(unsigned short Ctn, unsigned short pn)
>char CT_data(unsigned short ctn, unsigned char *dad, unsigned char *sad,
> unsigned short lc, unsigned char *cmd, unsigned short *lr,
> unsigned char *rsp)
>and
>char CT_close(unsigned int Ctn)
>
>Most of the type conversions are handled automatically by the compiler,
>but the
>problem comes up with the lr parameter in CT_data. Usually the compiler will
>warn about the size conflict if the program declares a variable
>
>unsigned short rlen;
>
>CT_data(......, &rlen,...)
>
>but if it goes undetected it may have severe results, because it overwrites
>data objects on the stack located beside the rlen variable (As happend in my
>case and which cause a fairly long debugging session).
>
>I know that this is an ugly problem, but I would still recommend to change the
>interface declaration to archive cross platform compatibility and avoid
>hard to
>find errors as the one above.
>
>Any comments ?
>
>--
>Andreas Schwier Tel. +49 171 8334920
>CardContact Software & System Consulting
>http://www.cardcontact.de
>***************************************************************
>Linux Smart Card Developers - M.U.S.C.L.E.
>(Movement for the Use of Smart Cards in a Linux Environment)
>http://www.linuxnet.com/smartcard/index.html
>***************************************************************
***************************************************************
Linux Smart Card Developers - M.U.S.C.L.E.
(Movement for the Use of Smart Cards in a Linux Environment)
http://www.linuxnet.com/smartcard/index.html
***************************************************************
