On Saturday 18 March 2006 18:06, Chaskiel Grundman wrote:
> The attached patch _should_ force the use of T=1 in a clean way. It
> includes (and expands upon) the PTS/ccid patch I sent earlier. (I left the
> ccid-specific parts out though).
>
> If I decide to pick one of these devices up, I might tr
The attached patch _should_ force the use of T=1 in a clean way. It
includes (and expands upon) the PTS/ccid patch I sent earlier. (I left the
ccid-specific parts out though).
If I decide to pick one of these devices up, I might try to fix the T=0
stuff, but the cost seems a bit high for exper
On Sat, 18 Mar 2006, Justin Karneges wrote:
By the way, how do the fields not initialized by ifd_eutron_register() get
initialized?
global uninitialized data is stored in the bss segment, which is
guaranteed to be zeroed when the executable is loaded. I'm pretty sure the
C standard says somet
On Saturday 18 March 2006 08:40, Chaskiel Grundman wrote:
> Try the attached patch. It introduces eutron_set_protocol.
By the way, how do the fields not initialized by ifd_eutron_register() get
initialized?
What tipped me off is that you added this line:
eutron_driver.set_protocol = eutron_set
On Saturday 18 March 2006 16:52, Chaskiel Grundman wrote:
> > send: 00 a4 00 0c 02 3f 00
> > recv: a4
>
> This means that the set_protocol patch is incorrect. the a4 is a proper
> T=0 ack byte. (and my assumptions about what usb T=0 devices do don't
> apply here)
>
> You didn't say what actually ha
The attached patch fixes some broken PTS behavior that resulted from two
misconceptions that I had about PTS:
1) that the PTS response from the card must be an exact reflection of the
request in order to be considered successful. 7816-3 says that the card
may refuse the PTS1 byte by sending a
send: 00 a4 00 0c 02 3f 00
recv: a4
This means that the set_protocol patch is incorrect. the a4 is a proper
T=0 ack byte. (and my assumptions about what usb T=0 devices do don't
apply here)
You didn't say what actually happens when eutron_send only gets/sends 5
bytes. Does the card reply at a
On Saturday 18 March 2006 08:40, Chaskiel Grundman wrote:
> On Fri, 17 Mar 2006, Justin Karneges wrote:
> > send: 00 c1 01 fe 3e
> > recv: 00 e1 01 fe 1e
> > The 0x40 bit is set in here, but of course there are others too. I'd
> > also like to find out what the meaning of the content is as well (0
On Fri, 17 Mar 2006, Justin Karneges wrote:
I'd like to make ifd-eutron do the same thing, although I'm not sure of the
best approach. My "guess" is that SafeSign determines that the first
response is wrong, and then rerequests the ATR, but I don't know how this
wrongness would be detected, esp
Justin Karneges wrote:
...
5) The device claims to support PKCS#15. I thought this was a hardware
protocol standard, and would mean instant OpenSC compatibility, but I
guess I was wrong? (I read now that it's more of a filesystem layout, how
uninteresting...)
yep, pkcs15 describes what is where
Martin Paljak wrote:
Hi,
On 16.03.2006, at 21:24, Andreas Jellinghaus wrote:
0.) things to do before a first beta release:
does anyone have a major issue we should wait for?
please let us know as soon as possible.
It was discussed some time ago, but I'd like to have a common agreement
on the
11 matches
Mail list logo
