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

--===============4249995604012203583==
Content-Type: multipart/alternative; boundary="94eb2c002330f70a6c055019a22e"

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

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

> Hi,
>

Hello,


>
> i will try to collect this data.
>
> An other thing i forgot to mention here - for me the bug only encountered
> on arm architecture (i have no idea why=E2=80=A6) - the same lib versions=
 on i386 /
> amd64 did worked.
>

I suspect a bug in the USB hardware or USB Linux layer of your arm platform
then.

I just talked to a USB expert and the reader (USB device) has no idea of
the reception buffer size. So the problem should not be in the reader (for
this bug).

I found the problem by adding some debug lines - to see where it does not
> get the correct answer. At this point i recongnised that the lib request =
to
> ready 65535 bytes from the usb stack - which seemed to be too much ;-). S=
o
> i simply used a fixed value - which will be enough for my needs (signing =
a
> 256 bytes hash). But as said - this is just a workaround for me - no bug
> fix.
>
> The only difference i found between the two sticks is - that the one whic=
h
> worked announced on more speed entry than the other stick. The rest ist
> identically.
>

Without your change you have a working reader and a non working one?

Using the same hardware and software platform?


> Here is the original thread for reference:
> http://lists.alioth.debian.org/pipermail/pcsclite-muscle/
> Week-of-Mon-20170220/000823.html
>
> I forgot to answer - sorry.
>
> The plattform is not a 2 byte int plattform.
>

>

> The bug must be somewhere, where it does calculate the read size=E2=80=A6
>

Try to upgrade to a recent Linux kernel.
Are you using Linux?

Bye

--=20
 Dr. Ludovic Rousseau

--94eb2c002330f70a6c055019a22e
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 11:26 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><br></div>=
<div>i will try to collect this data.</div><div><br></div><div>An other thi=
ng i forgot to mention here - for me the bug only encountered on arm archit=
ecture (i have no idea why=E2=80=A6) - the same lib versions on i386 / amd6=
4 did worked.</div></div></blockquote><div><br></div><div>I suspect a bug i=
n the USB hardware or USB Linux layer of your arm platform then.<br> <br></=
div><div>I just talked to a USB expert and the reader (USB device) has no i=
dea of the reception buffer size. So the problem should not be in the reade=
r (for this bug).<br><br></div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style=3D=
"word-wrap:break-word"><div>I found the problem by adding some debug lines =
- to see where it does not get the correct answer. At this point i recongni=
sed that the lib request to ready 65535 bytes from the usb stack - which se=
emed to be too much ;-). So i simply used a fixed value - which will be eno=
ugh for my needs (signing a 256 bytes hash). But as said - this is just a w=
orkaround for me - no bug fix.</div><div><br></div><div>The only difference=
 i found between the two sticks is - that the one which worked announced on=
 more speed entry than the other stick. The rest ist identically.</div></di=
v></blockquote><div><br></div><div>Without your change you have a working r=
eader and a non working one?<br></div><div><br>Using the same hardware and =
software platform?<br>=C2=A0<br></div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div s=
tyle=3D"word-wrap:break-word"><div>Here is the original thread for referenc=
e:</div><div><a href=3D"http://lists.alioth.debian.org/pipermail/pcsclite-m=
uscle/Week-of-Mon-20170220/000823.html" target=3D"_blank">http://lists.alio=
th.debian.<wbr>org/pipermail/pcsclite-muscle/<wbr>Week-of-Mon-20170220/0008=
23.<wbr>html</a></div><div><br></div><div>I forgot to answer - sorry.</div>=
<div><br></div><div>The plattform is not a 2 byte int plattform. <br></div>=
</div></blockquote><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:b=
reak-word"><div>=C2=A0</div></div></blockquote><blockquote class=3D"gmail_q=
uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e=
x"><div style=3D"word-wrap:break-word"><div><br></div><div>The bug must be =
somewhere, where it does calculate the read size=E2=80=A6</div></div></bloc=
kquote><div><br></div><div>Try to upgrade to a recent Linux kernel.<br></di=
v><div>Are you using Linux?<br><br></div><div>Bye<br><br></div></div>-- <br=
><div class=3D"gmail_signature" data-smartmail=3D"gmail_signature">=C2=A0Dr=
. Ludovic Rousseau</div>
</div></div>

--94eb2c002330f70a6c055019a22e--


--===============4249995604012203583==
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
--===============4249995604012203583==--