Re: Gemalto (was Gemplus) GemPC Key SmartCard Reader not working in debian stretch

--===============0052806641335662139==
Content-Type: multipart/alternative; boundary="94eb2c002330e94ac80550192d4e"

--94eb2c002330e94ac80550192d4e
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

2017-05-22 10:16 GMT+02:00 Wolfgang Pichler <[email protected]>:

> Hi,
>

Hello,


> i did had the same bug - it seems that some Gemalto Sticks (not all) have
> a problem in the firmware intitalize procedure. Because of this problem y=
ou
> get a too big usb read bytes request - which will then fail=E2=80=A6
>

Very interesting.

Can you send me the output of the GNU/Linux command "lsusb -v" for your
bogus device?
And also the lines logged by the Linux kernel when you connect the device.

Same question with a non-bogus device if you have one.

How have you found the work around?
Have you used a USB hardware spy or something similar?

I am surprised to see that changing the _reception_ buffer length has an
effect. The USB device should not know this buffer size. But I am not a USB
expert.


> Attached a workaround for this problem - which does work for me.
>
> But as stated - this is a workaround - not a real bug fix.
>

The workaround has a bad size effect that reader responses of more than
4096 bytes would have problems.
Before I apply any workaround I need to understand why your change makes
the reader work.

Bye

--=20
 Dr. Ludovic Rousseau

--94eb2c002330e94ac80550192d4e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">2017=
-05-22 10:16 GMT+02:00 Wolfgang Pichler <span dir=3D"ltr">&lt;<a href=3D"ma=
ilto:[email protected]" target=3D"_blank">[email protected]</a>&gt;</sp=
an>:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border=
-left:1px #ccc solid;padding-left:1ex"><div style=3D"word-wrap:break-word">=
Hi,</div></blockquote><div><br></div><div>Hello,<br>=C2=A0<br></div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div style=3D"word-wrap:break-word"><div></div><div=
>i did had the same bug - it seems that some Gemalto Sticks (not all) have =
a problem in the firmware intitalize procedure. Because of this problem you=
 get a too big usb read bytes request - which will then fail=E2=80=A6</div>=
</div></blockquote><div><br></div><div>Very interesting.<br><br></div><div>=
Can you send me the output of the GNU/Linux command &quot;lsusb -v&quot; fo=
r your bogus device?<br>And also the lines logged by the Linux kernel when =
you connect the device.<br><br>Same question with a non-bogus device if you=
 have one.<br></div><div><br>How have you found the work around?<br></div><=
div>Have you used a USB hardware spy or something similar?<br><br></div><di=
v>I am surprised to see that changing the _reception_ buffer length has an =
effect. The USB device should not know this buffer size. But I am not a USB=
 expert.<br></div><div>=C2=A0<br></div><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div =
style=3D"word-wrap:break-word"><div>Attached a workaround for this problem =
- which does work for me.</div><div><br></div><div>But as stated - this is =
a workaround - not a real bug fix.</div></div></blockquote><div><br></div><=
div>The workaround has a bad size effect that reader responses of more than=
 4096 bytes would have problems.<br></div><div>Before I apply any workaroun=
d I need to understand why your change makes the reader work.<br clear=3D"a=
ll"></div></div><br></div><div class=3D"gmail_extra">Bye<br><br></div><div =
class=3D"gmail_extra">-- <br><div class=3D"m_-287520824702272625gmail_signa=
ture" data-smartmail=3D"gmail_signature">=C2=A0Dr. Ludovic Rousseau</div>
</div></div>

--94eb2c002330e94ac80550192d4e--


--===============0052806641335662139==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Pcsclite-muscle mailing list
[email protected]
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pcsclite-muscle
--===============0052806641335662139==--