When I try to select a root file on this card by sending SELECT 3f00
file, the first response to the APDU returns SW 67 00 'Wrong length'.
Is it a specific problem to the card or to the ccid driver? I don't have
access to other CCID readers at the moment, but the same APDU works with
etoken and
I am looking at
long ifd_time_elapsed( struct ifd_time *then )
{
struct timeval now, delta, then_tv;
then_tv.tv_sec = then->p1;
then_tv.tv_usec = then->p2;
gettimeofday(&now, NULL);
timersub(&now, &then_tv, &delta);
return delta.tv_sec * 1000 + (d
[corrected to the actual source from CVS]
I am looking at
long ifd_time_elapsed(struct timeval *then)
{
struct timeval now, delta;
gettimeofday(&now, NULL);
timersub(&now, then, &delta);
return delta.tv_sec * 1000 + (delta.tv_usec % 1000);
}
what does last line
I tried new ifd-eutron.c with 2048 bit key decryption and ran into an
issue in t1-proto.c.
Please take a look at the following patch. It restores regression
introduced by new Eutron driver for decryption with 2048 bit key.
Without this change the code bellow fails with "receive buffer too
sma
Hello,
I was thinking to implement the cyberJack PIN pad reader support.
Unfortunately, I ran into a problem when I must reset the reader with
usb_reset(device_handle). However, I don't see ifd_device_ops.reset
implemented. Is there a way to cleanly invoke the USB device reset
functionality?
Andreas Jellinghaus wrote:
Andrey Jivsov wrote:
I was thinking to implement the cyberJack PIN pad reader support.
that is a good idea! if I can be of any help please let me know.
I thought about it myself, but never found time for that (and most
likely neither will anytime soon, so please go
Martin Preuss wrote:
Hi,
On Friday 03 November 2006 00:40, Andrey Jivsov wrote:
[...]
I was thinking to implement the cyberJack PIN pad reader support.
[...]
Just curious: Are you implementing support for both types of Cyberjack devices
(0x100 and 0x300, even though they look identical they
Martin Preuss wrote:
Hi,
On Friday 03 November 2006 00:40, Andrey Jivsov wrote:
[...]
I was thinking to implement the cyberJack PIN pad reader support.
Unfortunately, I ran into a problem when I must reset the reader with
usb_reset(device_handle). However, I don't see ifd_device_ops.
Andreas Jellinghaus wrote:
+/* need to limit to 248 */
+if (card->max_send_size > 248)
+card->max_send_size = 248;
+if (card->max_recv_size > 248)
+card->max_recv_size = 248;
+
+
can we put something like this in the generic code for
all cards and drivers? or in the
rmmod cyberjack" after the device is plugged in,
+ or better add "blacklist cyberjack" to modprobe.conf.
+
+ TODO: cleanup improvised T=1 communication with the reader.
+
+ Written by Andrey Jivsov in 2006. [EMAIL PROTECTED
Marcin Cieslak wrote:
> Ludovic Rousseau wrote:
>> On Dec 7, 2007 2:12 AM, Andrey Jivsov <[EMAIL PROTECTED]> wrote:
>>> one year ago I mentioned that I would like to contribute the cyberJack
>>> PINPAD reader driver for OpenCT. I apologize for the delay. Finall
Marcin Cieslak wrote:
> Andrey Jivsov wrote:
>> Looks like cyberjack_activate() fails on the first cyberjack_recv_t1.
>>
>> I would try to increase/decrease the value in ifd_msleep( 100 ) before
>> cyberjack_recv_t1 to see if this makes the difference. I will try t
I am attaching the tested patch to the file ifd-ccid.c to add support
for the reader. The reader's USB IDs that I tested with are 0b97:7762
and 0b97:7772. Without this patch the ifd-ccid.c code will not work with
these readers.
The patch is based on the work done in the pcsc-lite project. The
From:
https://www.opensc-project.org/openct/browser/trunk/src/ifd/ifd-ccid.c
if ((st->flags & FLAG_NO_SETPARAM) == 0 &&
1182((st->flags & FLAG_AUTO_ATRPARSE) == 0 |
1183proto != IFD_PROTOCOL_T0)) {
The condition check looks confusing. Should the '|'
Alon Bar-Lev wrote:
> Thanks for finding it!
> I think best is to revert r942 and ask Kurt Jaeger for a different patch.
> What do you think?
>
> On 2/3/09, Chaskiel Grundman wrote:
>
>> On Thu, 29 Jan 2009, Andrey Jivsov wrote:
>>
>> > I am attaching
Ludovic Rousseau wrote:
> Hello,
>
> 2009/1/29 Andrey Jivsov :
>
>> I am attaching the tested patch to the file ifd-ccid.c to add support for
>> the reader. The reader's USB IDs that I tested with are 0b97:7762 and
>> 0b97:7772. Without this patch the ifd-c
Here is an example ATR for the new RSA SecurID 800:
3b 0f 80 22 15 e1 5a 00 20 00 29 21 02 31 20 02 00
T0 = 0x0f, meaning that there are 15 historical bytes and zero TDX bytes.
However, the check in ifd_atr_parse does the following:
if (len <= 2 + (atr[1] & 0x0f))
return IFD_ERROR_
While trying to fix Broadcom Corp CCID build-in reader (USB ID
0A5C:5801) found Dell Latitude E6400 and others, I discovered that the
device's advertised
second bit (0x2) of the dwFeatures flags of USB CCID descriptor causes
problems for the openct ifd-ccid.c reader driver. The driver cannot
po
18 matches
Mail list logo