On Sunday 19 March 2006 20:32, Chaskiel Grundman wrote:
> > I noticed that too. I tried sending 0x65 pts[2] (which happens to be
> > 0x18), but all that did was put opensc into some weird loop:
> >
> > recv: 00 82 00 82
> > send: 00 c0 00 c0
> > recv: 00 82 00 82
> > send: 00 c0 00 c0
> > recv: 00
I noticed that too. I tried sending 0x65 pts[2] (which happens to be 0x18),
but all that did was put opensc into some weird loop:
recv: 00 82 00 82
send: 00 c0 00 c0
recv: 00 82 00 82
send: 00 c0 00 c0
recv: 00 e0 00 e0
This is sane (but unfortunate) T=1 control stuff. The first is
T1_R_BLOCK |
On Sunday 19 March 2006 15:39, Chaskiel Grundman wrote:
> > First, I should mention that with your patch, now the 0x65 control
> > request happens before the T=1 negotiation. The original ifd-eutron.c
> > and safesign both do it afterwards. My device doesn't seem to mind
> > though.
> >
> > Howev
Getting closer...
It seem like a step backwards to me though...
First, I should mention that with your patch, now the 0x65 control request
happens before the T=1 negotiation. The original ifd-eutron.c and safesign
both do it afterwards. My device doesn't seem to mind though.
However, the 0x65
Hi Chaskiel,
thanks for the patch, commited.
> It's unlikely that I'm going to work on this anytime soon, but I thought
> I'd let people know about the issue...
ok, thanks for letting me know.
Regards, Andreas
___
opensc-devel mailing list
opensc-deve
Hi,
we want openct to work fine with hotplug: when some usb reader or
crypto token is inserted, it should work right away. in the past this worked
fine using the linux kernel hotplug support and the hotplug shell utilities.
distributions are moving away from the old /sbin/hotplug interface,
with
