Re: Gemalto (was Gemplus) GemPC Key SmartCard Reader not working in debian stretch
Wolfgang Pichler <[email protected]> Mon, 22 May 2017 11:26:15 +0200
| Newsgroups | gmane.comp.lib.muscle |
|---|---|
| Message-ID | <[email protected]> |
--===============2152048721164078186== Content-Type: multipart/alternative; boundary="Apple-Mail=_9E5856F3-687D-48DD-A95F-E99BAB878E7F" --Apple-Mail=_9E5856F3-687D-48DD-A95F-E99BAB878E7F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, 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 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 ;-). So 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 = which worked announced on more speed entry than the other stick. The = rest ist identically. Here is the original thread for reference: = http://lists.alioth.debian.org/pipermail/pcsclite-muscle/Week-of-Mon-20170= 220/000823.html = <http://lists.alioth.debian.org/pipermail/pcsclite-muscle/Week-of-Mon-2017= 0220/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 br, Wolfgang > Am 22.05.2017 um 11:05 schrieb Ludovic Rousseau = <[email protected]>: >=20 > 2017-05-22 10:16 GMT+02:00 Wolfgang Pichler <[email protected] = <mailto:[email protected]>>: > Hi, >=20 > Hello, > =20 > 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 >=20 > Very interesting. >=20 > 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. >=20 > Same question with a non-bogus device if you have one. >=20 > How have you found the work around? > Have you used a USB hardware spy or something similar? >=20 > 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. > =20 > Attached a workaround for this problem - which does work for me. >=20 > But as stated - this is a workaround - not a real bug fix. >=20 > 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. >=20 > Bye >=20 > --=20 > Dr. Ludovic Rousseau > _______________________________________________ > Pcsclite-muscle mailing list > [email protected] > = http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pcsclite-muscle --Apple-Mail=_9E5856F3-687D-48DD-A95F-E99BAB878E7F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 <html><head><meta http-equiv=3D"Content-Type" content=3D"text/html = charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; = -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" = class=3D"">Hi,<div class=3D""><br class=3D""></div><div class=3D"">i = will try to collect this data.</div><div class=3D""><br = class=3D""></div><div class=3D"">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.</div><div class=3D""><br class=3D""></div><div class=3D"">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 = ;-). So 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.</div><div class=3D""><br class=3D""></div><div = class=3D"">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><div class=3D""><br class=3D""></div><div = class=3D"">Here is the original thread for reference:</div><div = class=3D""><a = href=3D"http://lists.alioth.debian.org/pipermail/pcsclite-muscle/Week-of-M= on-20170220/000823.html" = class=3D"">http://lists.alioth.debian.org/pipermail/pcsclite-muscle/Week-o= f-Mon-20170220/000823.html</a></div><div class=3D""><br = class=3D""></div><div class=3D"">I forgot to answer - sorry.</div><div = class=3D""><br class=3D""></div><div class=3D"">The plattform is not a 2 = byte int plattform.</div><div class=3D""><br class=3D""></div><div = class=3D"">The bug must be somewhere, where it does calculate the read = size=E2=80=A6</div><div class=3D""><br class=3D""></div><div = class=3D"">br,</div><div class=3D"">Wolfgang</div><div class=3D""><br = class=3D""></div><div class=3D""><div><blockquote type=3D"cite" = class=3D""><div class=3D"">Am 22.05.2017 um 11:05 schrieb Ludovic = Rousseau <<a href=3D"mailto:[email protected]" = class=3D"">[email protected]</a>>:</div><br = class=3D"Apple-interchange-newline"><div class=3D""><div dir=3D"ltr" = class=3D""><div class=3D"gmail_extra"><div = class=3D"gmail_quote">2017-05-22 10:16 GMT+02:00 Wolfgang Pichler <span = dir=3D"ltr" class=3D""><<a href=3D"mailto:[email protected]" = target=3D"_blank" class=3D"">[email protected]</a>></span>:<br = class=3D""><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" class=3D"">Hi,</div></blockquote><div = class=3D""><br class=3D""></div><div class=3D"">Hello,<br = class=3D""> <br class=3D""></div><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" = class=3D""><div class=3D""></div><div class=3D"">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 class=3D""><br = class=3D""></div><div class=3D"">Very interesting.<br class=3D""><br = class=3D""></div><div class=3D"">Can you send me the output of the = GNU/Linux command "lsusb -v" for your bogus device?<br class=3D"">And = also the lines logged by the Linux kernel when you connect the = device.<br class=3D""><br class=3D"">Same question with a non-bogus = device if you have one.<br class=3D""></div><div class=3D""><br = class=3D"">How have you found the work around?<br class=3D""></div><div = class=3D"">Have you used a USB hardware spy or something similar?<br = class=3D""><br class=3D""></div><div class=3D"">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 = class=3D""></div><div class=3D""> <br class=3D""></div><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" = class=3D""><div class=3D"">Attached a workaround for this problem - = which does work for me.</div><div class=3D""><br class=3D""></div><div = class=3D"">But as stated - this is a workaround - not a real bug = fix.</div></div></blockquote><div class=3D""><br class=3D""></div><div = class=3D"">The workaround has a bad size effect that reader responses of = more than 4096 bytes would have problems.<br class=3D""></div><div = class=3D"">Before I apply any workaround I need to understand why your = change makes the reader work.<br clear=3D"all" class=3D""></div></div><br = class=3D""></div><div class=3D"gmail_extra">Bye<br class=3D""><br = class=3D""></div><div class=3D"gmail_extra">-- <br class=3D""><div = class=3D"m_-287520824702272625gmail_signature" = data-smartmail=3D"gmail_signature"> Dr. Ludovic Rousseau</div> </div></div> _______________________________________________<br = class=3D"">Pcsclite-muscle mailing list<br class=3D""><a = href=3D"mailto:[email protected]" = class=3D"">[email protected]</a><br = class=3D"">http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pcsclit= e-muscle</div></blockquote></div><br class=3D""></div></body></html>= --Apple-Mail=_9E5856F3-687D-48DD-A95F-E99BAB878E7F-- --===============2152048721164078186== 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 --===============2152048721164078186==--