Re: [opensc-devel] Misleading information about capabilities of readers
2011/1/27 Aventra : > Hi, > > Thanks for the tips for building the correct package. > I managed to build it with the timeout fix, but it does not seem to help. > Attached is the new log. Still the same problem :-( According to your new log file the problem does not occur with the APDU "00 B0 00 F0 10" but just before. The reader does not respond to a PC_to_RDR_GetSlotStatus command. Very strange. Can you send me a MyEID card so I can reproduce the problem myself? Thanks -- Dr. Ludovic Rousseau ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Misleading information about capabilities of readers
Hi, Thanks for the tips for building the correct package. I managed to build it with the timeout fix, but it does not seem to help. Attached is the new log. Kind regards, Toni > -Original Message- > From: Ludovic Rousseau [mailto:ludovic.rouss...@gmail.com] > Sent: 22. tammikuuta 2011 12:52 > To: Aventra > Cc: OpenSC Development > Subject: Re: [opensc-devel] Misleading information about capabilities of > readers > > 2011/1/21 Aventra : > > Hello Ludovic, > > > > Well I have been looking into this and have some issues with compiling the > > code. > > The CCID driver version from trunk requires pcsc-lite version 1.6.5, which I > > don't have, so I need to compile that too. > > > > We usually use only the versions that are distributed with ubuntu, which > > means that they are quite old. > > Have not compiled the pcsc-lite or CCID before. > > > > I'm having trouble finding the information on how to compile it. For the > > CCID driver I found it, but not for pcsc-lite. > > apt-get source libccid > sudo apt-get build-dep libccid > sudo apt-get install devscripts > dpkg-source -x ccid_1.3.11-1.dsc > dpkg-buildpackage > > I am using Debian. But that should also work on Ubuntu. > Because of Ubuntu changes in pcsc-lite you should build Ubuntu > packages and not rebuild directly from the .tar.bz2 archives. > > Bye > > -- > Dr. Ludovic Rousseau pcscd-fix.log Description: Binary data ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Misleading information about capabilities of readers
2011/1/21 Aventra : > Hello Ludovic, > > Well I have been looking into this and have some issues with compiling the > code. > The CCID driver version from trunk requires pcsc-lite version 1.6.5, which I > don't have, so I need to compile that too. > > We usually use only the versions that are distributed with ubuntu, which > means that they are quite old. > Have not compiled the pcsc-lite or CCID before. > > I'm having trouble finding the information on how to compile it. For the > CCID driver I found it, but not for pcsc-lite. apt-get source libccid sudo apt-get build-dep libccid sudo apt-get install devscripts dpkg-source -x ccid_1.3.11-1.dsc dpkg-buildpackage I am using Debian. But that should also work on Ubuntu. Because of Ubuntu changes in pcsc-lite you should build Ubuntu packages and not rebuild directly from the .tar.bz2 archives. Bye -- Dr. Ludovic Rousseau ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Misleading information about capabilities of readers
2011/1/21 Aventra : > Hello Ludovic, > > Well I have been looking into this and have some issues with compiling the > code. > The CCID driver version from trunk requires pcsc-lite version 1.6.5, which I > don't have, so I need to compile that too. Why don't you patch the version of the driver you already use? > We usually use only the versions that are distributed with ubuntu, which > means that they are quite old. > Have not compiled the pcsc-lite or CCID before. Read http://ludovicrousseau.blogspot.com/2010/10/pcsc-lite-upgrade-and-ubuntu-special.html bye -- Dr. Ludovic Rousseau ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Misleading information about capabilities of readers
Hello Ludovic, Well I have been looking into this and have some issues with compiling the code. The CCID driver version from trunk requires pcsc-lite version 1.6.5, which I don't have, so I need to compile that too. We usually use only the versions that are distributed with ubuntu, which means that they are quite old. Have not compiled the pcsc-lite or CCID before. I'm having trouble finding the information on how to compile it. For the CCID driver I found it, but not for pcsc-lite. Kind regards, Toni > -Original Message- > From: Ludovic Rousseau [mailto:ludovic.rouss...@gmail.com] > Sent: 20. tammikuuta 2011 21:56 > To: Aventra > Cc: opensc-devel > Subject: Re: [opensc-devel] Misleading information about capabilities of > readers > > Hello "Aventra", > > I did not get any reply to my mail. > Does the patch works for you? > > Thanks > > 2011/1/13 Ludovic Rousseau : > > 2011/1/13 Aventra : > >> Hi, > >> > >> Sorry, a typo when doing logging... > >> Attached is a new log. > > > > Found the bug (I think). > > > > The CCID driver calculate a timeout accordings to the card ATR. In > > your case the timeout is 1428 ms rounded to 2 seconds. > > Log says: > > 0007 ifdhandler.c:791:IFDHSetProtocolParameters() Timeout: 2 seconds > > > > The same timeout is used by the reader and by the CCID driver. I think > > the CCID driver (libusb in fact) triggers its timeout just before the > > reader does. So the driver do not get the reader error message. > > > > Patch to try: > > in src/ifdhandler.c edit the function T1_card_timeout() (at the end of the > file) > > and replace > > return timeout; > > by > > return timeout+1; > > > > Then regenerate a log again. > > > > Thanks > > -- > Dr. Ludovic Rousseau ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Misleading information about capabilities of readers
Hello "Aventra", I did not get any reply to my mail. Does the patch works for you? Thanks 2011/1/13 Ludovic Rousseau : > 2011/1/13 Aventra : >> Hi, >> >> Sorry, a typo when doing logging... >> Attached is a new log. > > Found the bug (I think). > > The CCID driver calculate a timeout accordings to the card ATR. In > your case the timeout is 1428 ms rounded to 2 seconds. > Log says: > 0007 ifdhandler.c:791:IFDHSetProtocolParameters() Timeout: 2 seconds > > The same timeout is used by the reader and by the CCID driver. I think > the CCID driver (libusb in fact) triggers its timeout just before the > reader does. So the driver do not get the reader error message. > > Patch to try: > in src/ifdhandler.c edit the function T1_card_timeout() (at the end of the > file) > and replace > return timeout; > by > return timeout+1; > > Then regenerate a log again. > > Thanks -- Dr. Ludovic Rousseau ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Misleading information about capabilities of readers
Le jeudi 13 janvier 2011 à 18:52 +0100, Andre Zepezauer a écrit : > It would be easier to call it 'certified'. And of cause, certification > may be a service that is not for free. I second that. Certification is loud and clear. -- Jean-Michel Pouré - Gooze - http://www.gooze.eu ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Misleading information about capabilities of readers
Le jeudi 13 janvier 2011 à 18:47 +0100, Ludovic Rousseau a écrit : > But I can't support a reader I do not have. So they are listed (by > default) in the "Should work but untested by me" list. You have the R-301 v2. I shipped it to you and I have an email telling us that you received it. It is listed as Feitian Technologies FT SCR310. So why is it in "Should work but untested by me". -- Jean-Michel Pouré - Gooze - http://www.gooze.eu ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Misleading information about capabilities of readers
On Thu, 2011-01-13 at 18:39 +0100, Jean-Michel Pouré - GOOZE wrote: > Le jeudi 13 janvier 2011 à 18:08 +0100, Peter Stuge a écrit : > > > * Unsupported. > > > * Supported (and not should work). > > > * Supported and reviewed (and not Supported). > > > > The good names depend on what "support" means in this context. I > > don't know that. Do you? Maybe Ludovic can help clarify? > > A word should always be used in the common sense. > > In free software, supported means that a hardware/software can run, > until anyone can fill a bug report or indicate that it is not supported. > And then people propose patches. This is the common sense of > "supported". > > Take the example of smartcards in OpenSC. A lot of them are declared > "supported", but presently only 3 or 4 work very well and are not end of > life. > > Again: > * Supported and reviewed by libccid author: > Means that the hardware is supported and carefully reviewed. This is an > indication of quality, but also that the vendor paid money. It would be easier to call it 'certified'. And of cause, certification may be a service that is not for free. > * Supported > This is the usual meaning. Here is the R-301-v2. > * Unsupported > The reader did not fully pass the benchmark. There should be an > indication of impact on OpenSC. If a reader is reported to work with > OpenSC, users should know. > ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Misleading information about capabilities of readers
Le 13 janvier 2011 18:39, Jean-Michel Pouré - GOOZE a écrit : > Le jeudi 13 janvier 2011 à 18:08 +0100, Peter Stuge a écrit : >> > * Unsupported. >> > * Supported (and not should work). >> > * Supported and reviewed (and not Supported). >> >> The good names depend on what "support" means in this context. I >> don't know that. Do you? Maybe Ludovic can help clarify? > > A word should always be used in the common sense. > > In free software, supported means that a hardware/software can run, > until anyone can fill a bug report or indicate that it is not supported. > And then people propose patches. This is the common sense of > "supported". Free free to support any reader you want to support. But I can't support a reader I do not have. So they are listed (by default) in the "Should work but untested by me" list. > Again: > * Supported and reviewed by libccid author: > Means that the hardware is supported and carefully reviewed. This is an > indication of quality, but also that the vendor paid money. > * Supported > This is the usual meaning. Here is the R-301-v2. > * Unsupported > The reader did not fully pass the benchmark. There should be an > indication of impact on OpenSC. If a reader is reported to work with > OpenSC, users should know. The readers listed on my 4 lists are not used only with OpenSC. So a reader may be listed in the "Unsupported or partly supported CCID readers" but work great with OpenSC. Also note that readers listed in "Supported CCID readers/ICCD tokens", "Should work but untested by me" and "Unsupported or partly supported CCID readers" are all usable with my CCID driver. Only readers in the "Disabled CCID readers" are not working at all and are not recognized by my CCID driver. Bye -- Dr. Ludovic Rousseau ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Misleading information about capabilities of readers
Le jeudi 13 janvier 2011 à 18:08 +0100, Peter Stuge a écrit : > > * Unsupported. > > * Supported (and not should work). > > * Supported and reviewed (and not Supported). > > The good names depend on what "support" means in this context. I > don't know that. Do you? Maybe Ludovic can help clarify? A word should always be used in the common sense. In free software, supported means that a hardware/software can run, until anyone can fill a bug report or indicate that it is not supported. And then people propose patches. This is the common sense of "supported". Take the example of smartcards in OpenSC. A lot of them are declared "supported", but presently only 3 or 4 work very well and are not end of life. Again: * Supported and reviewed by libccid author: Means that the hardware is supported and carefully reviewed. This is an indication of quality, but also that the vendor paid money. * Supported This is the usual meaning. Here is the R-301-v2. * Unsupported The reader did not fully pass the benchmark. There should be an indication of impact on OpenSC. If a reader is reported to work with OpenSC, users should know. -- Jean-Michel Pouré - Gooze - http://www.gooze.eu ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Misleading information about capabilities of readers
On Jan 13, 2011, at 7:08 PM, Peter Stuge wrote: > Jean-Michel Pouré - GOOZE wrote: >>> I've been under the impression (based on the header in "should work" >>> list [1]) that it contains readers which work as expected and which >>> Ludovic has. >> >> The names should be then: >> * Unsupported. >> * Supported (and not should work). >> * Supported and reviewed (and not Supported). > > The good names depend on what "support" means in this context. I > don't know that. Do you? Maybe Ludovic can help clarify? > > >>> So please fix my impression and help others who would want to know: >>> how large is the sum of money one needs to pay? >> >> This information is none of my business. >> It cannot and shouldn't be posted in public. > > I disagree if I understand you correctly, but I am still not sure if > I do.. :) > > libccid is an open source project, so can be assumed to have an open > attitude. > > That said, things still cost money so if "supported" translates to > some kind of commitment from anyone in the community for that project > then of course there can be costs for listing a hardware as > supported. And maybe those costs are negotiated on case by case > basis, which is fine, but I see no reason to not make the process > public. > > I'm less interested in the sums involved since I'm no reader vendor, > but I am very curious to understand the process that you are > describing, because it doesn't really fit my previous understanding - > so maybe I overlooked something that you know more about, and I don't > think it's a problem to share that knowledge? > > >> Sure, there is a difference between supported and reviewed. > > "reviewed" is another term that I am now not at all sure if I > understand correctly in this context. :) > > >> But the users should know the difference and not believe that the >> only "supported" devices are those from vendor which pay. > > I agree that it is important to have good definitions of terms. > > >> Anyway, I am very grateful to Ludovic work. > > Me too! :) > > >> Are we really going to argue about that? IMHO, this is not >> interesting and I will not answer other emails. Sorry for that. > > I don't think we are arguing. It's good that you started this > discussion, because it seems to me that there is a misunderstanding > and I certainly want to have a clear understanding. > > > //Peter > ___ > opensc-devel mailing list > opensc-devel@lists.opensc-project.org > http://www.opensc-project.org/mailman/listinfo/opensc-devel -- @MartinPaljak.net +3725156495 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Misleading information about capabilities of readers
Hello, On Jan 13, 2011, at 7:08 PM, Peter Stuge wrote: > Jean-Michel Pouré - GOOZE wrote: >>> I've been under the impression (based on the header in "should work" >>> list [1]) that it contains readers which work as expected and which >>> Ludovic has. >> >> The names should be then: >> * Unsupported. >> * Supported (and not should work). >> * Supported and reviewed (and not Supported). > > The good names depend on what "support" means in this context. I > don't know that. Do you? Maybe Ludovic can help clarify? > > >>> So please fix my impression and help others who would want to know: >>> how large is the sum of money one needs to pay? >> >> This information is none of my business. >> It cannot and shouldn't be posted in public. > > I disagree if I understand you correctly, but I am still not sure if > I do.. :) Private communication is supposed to be kept private, so no, I don't need the *exact* details either, the following text by Peter describes my questions as well. > libccid is an open source project, so can be assumed to have an open > attitude. > > That said, things still cost money so if "supported" translates to > some kind of commitment from anyone in the community for that project > then of course there can be costs for listing a hardware as > supported. And maybe those costs are negotiated on case by case > basis, which is fine, but I see no reason to not make the process > public. > > I'm less interested in the sums involved since I'm no reader vendor, > but I am very curious to understand the process that you are > describing, because it doesn't really fit my previous understanding - > so maybe I overlooked something that you know more about, and I don't > think it's a problem to share that knowledge? Same here. -- @MartinPaljak.net +3725156495 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Misleading information about capabilities of readers
Jean-Michel Pouré - GOOZE wrote: > > I've been under the impression (based on the header in "should work" > > list [1]) that it contains readers which work as expected and which > > Ludovic has. > > The names should be then: > * Unsupported. > * Supported (and not should work). > * Supported and reviewed (and not Supported). The good names depend on what "support" means in this context. I don't know that. Do you? Maybe Ludovic can help clarify? > > So please fix my impression and help others who would want to know: > > how large is the sum of money one needs to pay? > > This information is none of my business. > It cannot and shouldn't be posted in public. I disagree if I understand you correctly, but I am still not sure if I do.. :) libccid is an open source project, so can be assumed to have an open attitude. That said, things still cost money so if "supported" translates to some kind of commitment from anyone in the community for that project then of course there can be costs for listing a hardware as supported. And maybe those costs are negotiated on case by case basis, which is fine, but I see no reason to not make the process public. I'm less interested in the sums involved since I'm no reader vendor, but I am very curious to understand the process that you are describing, because it doesn't really fit my previous understanding - so maybe I overlooked something that you know more about, and I don't think it's a problem to share that knowledge? > Sure, there is a difference between supported and reviewed. "reviewed" is another term that I am now not at all sure if I understand correctly in this context. :) > But the users should know the difference and not believe that the > only "supported" devices are those from vendor which pay. I agree that it is important to have good definitions of terms. > Anyway, I am very grateful to Ludovic work. Me too! :) > Are we really going to argue about that? IMHO, this is not > interesting and I will not answer other emails. Sorry for that. I don't think we are arguing. It's good that you started this discussion, because it seems to me that there is a misunderstanding and I certainly want to have a clear understanding. //Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Misleading information about capabilities of readers
Hello, On Thu, 2011-01-13 at 11:37 +0100, Ludovic Rousseau wrote: > Found the bug (I think). > > The CCID driver calculate a timeout accordings to the card ATR. In > your case the timeout is 1428 ms rounded to 2 seconds. > Log says: > 0007 ifdhandler.c:791:IFDHSetProtocolParameters() Timeout: 2 seconds > > The same timeout is used by the reader and by the CCID driver. I think > the CCID driver (libusb in fact) triggers its timeout just before the > reader does. So the driver do not get the reader error message. I don't think that libccid is the source of trouble. Check out this: grep -A 1 "3B\ F.\ 18\ ..\ ..\ 81\ 31\ FE\ 45" smartcard_list.txt Regards Andre ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Misleading information about capabilities of readers
Dear all, > I've been under the impression (based on the header in "should work" > list [1]) that it contains readers which work as expected and which > Ludovic has. The names should be then: * Unsupported. * Supported (and not should work). * Supported and reviewed (and not Supported). > So please fix my impression and help others who would want to know: > how large is the sum of money one needs to pay? This information is none of my business. It cannot and shouldn't be posted in public. > But keep in mind, that you as a company (or a manufacturer of > hardware), who profit from people like Ludovic writing software that > allows you to sell your products and make a profit, it is reasonable > to expect that you either a) pay a premium and get some benefits b) > not pay and be happy that your product works well with open source. Sure, there is a difference between supported and reviewed. But the users should know the difference and not believe that the only "supported" devices are those from vendor which pay. Anyway, I am very grateful to Ludovic work. Are we really going to argue about that? IMHO, this is not interesting and I will not answer other emails. Sorry for that. Kind regards; -- Jean-Michel Pouré - Gooze - http://www.gooze.eu ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Misleading information about capabilities of readers
Hello, On Jan 12, 2011, at 2:04 PM, Jean-Michel Pouré - GOOZE wrote: > Le mercredi 12 janvier 2011 à 13:26 +0200, Martin Paljak a écrit : >> >>> Per discussion, we have to pay to get the reader out of the >> unsupported >>> list, and this is quite a large sum of money. >> Pay whom? How much? Please be specific: who has to pay whom and how much? Name, sum in €, with any kind of extra fees (taxes, commissions, bribes) included. > I would say 'technical review', nothing special. Reviewing a smartcard > reader is a long job. This is probably the case. > > The libccid supported list is for companies which pay technical review. > When companies do not pay, readers are listed in "Should be supported". Are you talking about the open source CCID driver "unsupported" and "shouldwork" lists? I've been under the impression (based on the header in "shouldwork" list [1]) that it contains readers which work as expected and which Ludovic has. As is the case with OpenSC - we can only test what we have, and thus only support what we can test. So please fix my impression and help others who would want to know: how large is the sum of money one needs to pay? But keep in mind, that you as a company (or a manufacturer of hardware), who profit from people like Ludovic writing software that allows you to sell your products and make a profit, it is reasonable to expect that you either a) pay a premium and get some benefits b) not pay and be happy that your product works well with open source. -- @MartinPaljak.net +3725156495 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Misleading information about capabilities of readers
Le jeudi 13 janvier 2011 à 11:37 +0100, Ludovic Rousseau a écrit : > The CCID driver calculate a timeout accordings to the card ATR. In > your case the timeout is 1428 ms rounded to 2 seconds. Are all CCID readers impacted? Kind regards, -- Jean-Michel Pouré - Gooze - http://www.gooze.eu ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Misleading information about capabilities of readers
2011/1/13 Aventra : > Hi, > > Sorry, a typo when doing logging... > Attached is a new log. Found the bug (I think). The CCID driver calculate a timeout accordings to the card ATR. In your case the timeout is 1428 ms rounded to 2 seconds. Log says: 0007 ifdhandler.c:791:IFDHSetProtocolParameters() Timeout: 2 seconds The same timeout is used by the reader and by the CCID driver. I think the CCID driver (libusb in fact) triggers its timeout just before the reader does. So the driver do not get the reader error message. Patch to try: in src/ifdhandler.c edit the function T1_card_timeout() (at the end of the file) and replace return timeout; by return timeout+1; Then regenerate a log again. Thanks -- Dr. Ludovic Rousseau ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Misleading information about capabilities of readers
Hi, Sorry, a typo when doing logging... Attached is a new log. Kind regards, Toni > -Original Message- > From: Ludovic Rousseau [mailto:ludovic.rouss...@gmail.com] > Sent: 12. tammikuuta 2011 19:29 > To: Aventra > Cc: opensc-devel > Subject: Re: [opensc-devel] Misleading information about capabilities of > readers > > 2011/1/12 Aventra : > > Hi, > > > > I have attached the requested logs. > > Try again with _exactly_ what is documented on the web page: > LIBCCID_ifdLogLevel=0x000F > export LIBCCID_ifdLogLevel > pcscd --foreground --debug --apdu > > Thanks > > -- > Dr. Ludovic Rousseau pcscd.log Description: Binary data ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Misleading information about capabilities of readers
Hello, > -Original Message- > > On 12.01.2011 18:41, Aventra wrote: > > My questions are: > > - have other OpenSC users tried cards that use T=1 protocol? > > - have somebody managed to use MyEID cards without adjusting the > > configuration? > > In OpenSC-trunk r5087 MyEID card is normally working (erase,init,import > PKCS#12) without changes in pcsc reader configuration section. > Maximal send/receive sizes 255/255. > The reader is OmniKey CardMan 3121. Thanks! This is good news, so perhaps it's only in a certain environment with specific Linux, pcsc-lite and ccid versions?? So this means we, for now, can keep the section on the MyEID wiki page, but change the phrase to something like "Some readers or environments...". > > -- > Viktor Tarasov ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Misleading information about capabilities of readers
Le mercredi 12 janvier 2011 à 23:41 +0100, Peter Stuge a écrit : > What do you mean by this? It sounds really obnoxious, but I think > there is a language barrier here and I do not want to jump to > conclusions. Sure, French is my mother tongue, not English. I am a nice guy, always pleasant with everyone if you know me. To get listed in the Supported list of libccid, smartcard makers need to pay for technical review. Because there is some work included for technical review. I guess there is a lot of work included for Ludovic. Other companies which don't pay get listed on "Should work" page. My personal opinion is that I only trust GOOZE and OpenSC users. In the past I posted several bugs about entersafe driver. Now I am really happy with the driver. So you can count on me to recognize bugs and publish them. As for the R-301-v1 and R-301-v2, I always was VERY HAPPY with the readers. Event if libccid test suite did not pass, it had no impact on OpenSC. So I did not care for these pages "supported", "unsupported" and "should work". Kind regards, -- Jean-Michel Pouré - Gooze - http://www.gooze.eu ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Misleading information about capabilities of readers
Jean-Michel Pouré - GOOZE wrote: > The libccid supported list is for companies which pay technical review. > When companies do not pay, readers are listed in "Should be supported". What do you mean by this? It sounds really obnoxious, but I think there is a language barrier here and I do not want to jump to conclusions. I believe that Ludovic keeps the list updated according to testing he has done himself, as well as input from the community. Do you have a different understanding? > Therefore, some companies, are more visible on Internet. Again, I believe that is because their products behave as expected and according to specification, and not because they are paying someone extra money to get special treatment. But of course it can cost a little more to develop something that is actually standards compliant. //Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Misleading information about capabilities of readers
On 12.01.2011 18:41, Aventra wrote: > My questions are: > - have other OpenSC users tried cards that use T=1 protocol? > - have somebody managed to use MyEID cards without adjusting the > configuration? In OpenSC-trunk r5087 MyEID card is normally working (erase,init,import PKCS#12) without changes in pcsc reader configuration section. Maximal send/receive sizes 255/255. The reader is OmniKey CardMan 3121. -- Viktor Tarasov ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Misleading information about capabilities of readers
On Wed, 2011-01-12 at 19:41 +0200, Aventra wrote: > Hi, > > > -Original Message- > > > > -Original Message- > > > > From: Andre Zepezauer [mailto:andre.zepeza...@student.uni-halle.de] > > > > Sent: 12. tammikuuta 2011 12:46 > > > > > > > > > > There is nothing special about MyEID that would cause the issue. In > > > windows > > > > > everything works just fine if we follow the readers maxIFSD value. > > > > > One difference with many other cards supported by OpenSC that they > use > > > T=0 > > > > > protocol (MyEID use T=1). > > > > > > > > I have a guess about the source of trouble: MyEID cards do not support > > > > T1-Block-Chaining. > > > > > > MyEID supports this block chaining because it is based on standard NXP > JCOP > > > smartcard chips. > > > However, block chaining is used only after the maximum packet size is > > > reached, i.e. above 256 bytes, > > > so it would not be used here anyway. > > > > > > From our point of view, this is handled totally transparently by the > reader > > > and the smartcard chip. > > > > Manually adjusting max_*_size to some magic value isn't transparent at > > all. So the question is, why MyEID needs such adjustment whereas other > > cards don't. You should definitely start investigating that issue. > > Yes, I agree that this is something that we would not want to do, but we are > stuck with it for the moment. > > My questions are: > - have other OpenSC users tried cards that use T=1 protocol? CardOS and E-Token were very popular in the past. These are T=1 only devices too (T=0 unsupported): 3B F2 18 00 02 C1 0A 31 FE 58 C8 08 74 They work out of the box with SCM SCR-335 readers driven by libccid. No adjustments required. Extended-APDUs up to 300+X bytes are working. > - have somebody managed to use MyEID cards without adjusting the > configuration? > > > As a short term solution you could provide a list of readers known to > > work. That would be most valuable for your customers. > > Since we have only encountered readers that require the configuration tweak, > we have decided to add the information on how to change the configuration to > the wiki page. > Hope this can be solved somehow in the future. Just a guess: Quotation from Java Card (TM) Platform, Version 2.2.1: "The incoming APDU data size may be bigger than the APDU buffer size and may therefore need to be read in portions by the applet. Similarly, the outgoing response APDU data size may be bigger than the APDU buffer size and may need to be written in portions by the applet. The APDU class has methods to facilitate this." Regards Andre ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Misleading information about capabilities of readers
Hi, > -Original Message- > > > -Original Message- > > > From: Andre Zepezauer [mailto:andre.zepeza...@student.uni-halle.de] > > > Sent: 12. tammikuuta 2011 12:46 > > > > > > > > There is nothing special about MyEID that would cause the issue. In > > windows > > > > everything works just fine if we follow the readers maxIFSD value. > > > > One difference with many other cards supported by OpenSC that they use > > T=0 > > > > protocol (MyEID use T=1). > > > > > > I have a guess about the source of trouble: MyEID cards do not support > > > T1-Block-Chaining. > > > > MyEID supports this block chaining because it is based on standard NXP JCOP > > smartcard chips. > > However, block chaining is used only after the maximum packet size is > > reached, i.e. above 256 bytes, > > so it would not be used here anyway. > > > > From our point of view, this is handled totally transparently by the reader > > and the smartcard chip. > > Manually adjusting max_*_size to some magic value isn't transparent at > all. So the question is, why MyEID needs such adjustment whereas other > cards don't. You should definitely start investigating that issue. Yes, I agree that this is something that we would not want to do, but we are stuck with it for the moment. My questions are: - have other OpenSC users tried cards that use T=1 protocol? - have somebody managed to use MyEID cards without adjusting the configuration? > As a short term solution you could provide a list of readers known to > work. That would be most valuable for your customers. Since we have only encountered readers that require the configuration tweak, we have decided to add the information on how to change the configuration to the wiki page. Hope this can be solved somehow in the future. Kind regards, Toni > Regards > Andre ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Misleading information about capabilities of readers
2011/1/12 Aventra : > Hi, > > I have attached the requested logs. Try again with _exactly_ what is documented on the web page: LIBCCID_ifdLogLevel=0x000F export LIBCCID_ifdLogLevel pcscd --foreground --debug --apdu Thanks -- Dr. Ludovic Rousseau ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Misleading information about capabilities of readers
On Wed, 2011-01-12 at 17:22 +0200, Aventra development wrote: > Hi, > > > -Original Message- > > From: Andre Zepezauer [mailto:andre.zepeza...@student.uni-halle.de] > > Sent: 12. tammikuuta 2011 12:46 > > > > > > There is nothing special about MyEID that would cause the issue. In > windows > > > everything works just fine if we follow the readers maxIFSD value. > > > One difference with many other cards supported by OpenSC that they use > T=0 > > > protocol (MyEID use T=1). > > > > I have a guess about the source of trouble: MyEID cards do not support > > T1-Block-Chaining. > > MyEID supports this block chaining because it is based on standard NXP JCOP > smartcard chips. > However, block chaining is used only after the maximum packet size is > reached, i.e. above 256 bytes, > so it would not be used here anyway. > > From our point of view, this is handled totally transparently by the reader > and the smartcard chip. Manually adjusting max_*_size to some magic value isn't transparent at all. So the question is, why MyEID needs such adjustment whereas other cards don't. You should definitely start investigating that issue. As a short term solution you could provide a list of readers known to work. That would be most valuable for your customers. Regards Andre ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Misleading information about capabilities of readers
Hi, > -Original Message- > From: Andre Zepezauer [mailto:andre.zepeza...@student.uni-halle.de] > Sent: 12. tammikuuta 2011 12:46 > > > > There is nothing special about MyEID that would cause the issue. In windows > > everything works just fine if we follow the readers maxIFSD value. > > One difference with many other cards supported by OpenSC that they use T=0 > > protocol (MyEID use T=1). > > I have a guess about the source of trouble: MyEID cards do not support > T1-Block-Chaining. MyEID supports this block chaining because it is based on standard NXP JCOP smartcard chips. However, block chaining is used only after the maximum packet size is reached, i.e. above 256 bytes, so it would not be used here anyway. >From our point of view, this is handled totally transparently by the reader and the smartcard chip. Kind regards, Toni ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Misleading information about capabilities of readers
Le mercredi 12 janvier 2011 à 13:26 +0200, Martin Paljak a écrit : > > > Per discussion, we have to pay to get the reader out of the > unsupported > > list, and this is quite a large sum of money. > Pay whom? How much? I would say 'technical review', nothing special. Reviewing a smartcard reader is a long job. This is probably the case. The libccid supported list is for companies which pay technical review. When companies do not pay, readers are listed in "Should be supported". Therefore, some companies, are more visible on Internet. In our case, about the R-301-v1, from I remember, the error was just a timeout. It had no impact on OpenSC and to speak frankly, I doubt this was a problem as we never had ONE product return. Also, I don't want to go further into discussions about theses issues. Members of the mailing list, especially those using the R-301-v1 can have their own mind. Again, if you have a problem with the R-301-v1, drop me an email on GOOZE and I will replace your reader. But I doubt this will happen. -- Jean-Michel Pouré - Gooze - http://www.gooze.eu ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Misleading information about capabilities of readers
On Jan 12, 2011, at 1:22 PM, Jean-Michel Pouré - GOOZE wrote: > Le mercredi 12 janvier 2011 à 12:07 +0200, Martin Paljak a écrit : >> Jean-Michel, what were the symptoms of the bug? > > As for R-301-v1, it used to have an unsupported message, but it proved > to be an OpenCT incompatibility. So everything was fine. Is the original description available? > Per discussion, we have to pay to get the reader out of the unsupported > list, and this is quite a large sum of money. Pay whom? How much? -- @MartinPaljak.net +3725156495 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Misleading information about capabilities of readers
Le mercredi 12 janvier 2011 à 12:07 +0200, Martin Paljak a écrit : > Jean-Michel, what were the symptoms of the bug? Feitian R-301 was updated recently with a new CCID firmware, which works fine: http://www.gooze.eu/feitian-r-301-v2 In the CCID database, it is listed as the Feitian SCR310: http://pcsclite.alioth.debian.org/ccid/shouldwork.html#0x096E0x0505 But we call the reader the Feitian R-301 v2. As for R-301-v1, it used to have an unsupported message, but it proved to be an OpenCT incompatibility. So everything was fine. We never had any problem with the R-301 v1. We never had a single return of the R-301 v1. This is good to do libCCID automatic testing, but when an error has no impact of OpenSC, it is unfair to keep listing a reader in the unsupported list. Per discussion, we have to pay to get the reader out of the unsupported list, and this is quite a large sum of money. So our official position is: * If you own an R-301v1 reader and you have incompatibility problems, then ship it back to us so that we can reproduce the problem. We will replace it with an R-301 v2 at no cost. We are really interested, as it never arrived before. * The R-301 v2 works perfectly. Kind regards, -- Jean-Michel Pouré - Gooze - http://www.gooze.eu ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Misleading information about capabilities of readers
2011/1/12 Andre Zepezauer : > On Wed, 2011-01-12 at 12:26 +0200, Aventra development wrote: >> There is nothing special about MyEID that would cause the issue. In windows >> everything works just fine if we follow the readers maxIFSD value. >> One difference with many other cards supported by OpenSC that they use T=0 >> protocol (MyEID use T=1). > > I have a guess about the source of trouble: MyEID cards do not support > T1-Block-Chaining. > > @Ludovic: What's your opinion? I need a pcscd trace to know. Use the Gemalto Twin reader to generate the trace and follow [1]. You can also join the associated opensc debug trace. Thanks [1] http://pcsclite.alioth.debian.org/ccid.html#support -- Dr. Ludovic Rousseau ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Misleading information about capabilities of readers
On Wed, 2011-01-12 at 12:26 +0200, Aventra development wrote: > Hi, > > > -Original Message- > > From: opensc-devel-boun...@lists.opensc-project.org [mailto:opensc-devel- > > boun...@lists.opensc-project.org] On Behalf Of Ludovic Rousseau > > Sent: 12. tammikuuta 2011 11:22 > > To: opensc-devel > > Subject: Re: [opensc-devel] Misleading information about capabilities of > > readers > > > > 2011/1/11 Andre Zepezauer : > > > Hello, > > > > > > the wiki page of MyEID [1] contains the following paragraph: > > > > > > "Many readers don't support receiving the default amount of data (254). > > > Problems will only appear when reading larger files from the card (e.g. > > > certificates). So if you have problems with reading the card with no > > > apparent reason, try to set this to e.g. 192, to be on the safe side. > > > You can then try to iterate to find the maximum for your card reader." > > > > > > That statement is simply wrong, because every USB reader can handle > > > Short-APDUs of every size. For that reason no other card has similar > > > problems. > > > > Every _non-bogus_ reader. > > For example the Feitian SCR301 [2] is bogus and can't support CASE 2 > > APDU with Le=0 (256 bytes). That is why this reader is listed in the > > "unsupported" list of my CCID driver. > > > > > If there are readers that don't work properly with MyEID, then list them > > > explicitly by name. That would definitely of more help to users then > > > such a vague statement like "Many readers don't support [...]". > > > > The reader above has a problem with Le=256. Le=254 should work and the > > reader should not have a problem with MyEID. > > > > I don't know which readers have problem with MyEID. An explicit list > > of bogus readers would be great so that users can avoid buying such > > readers. > > > There is nothing special about MyEID that would cause the issue. In windows > everything works just fine if we follow the readers maxIFSD value. > One difference with many other cards supported by OpenSC that they use T=0 > protocol (MyEID use T=1). I have a guess about the source of trouble: MyEID cards do not support T1-Block-Chaining. @Ludovic: What's your opinion? ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Misleading information about capabilities of readers
Hi, > -Original Message- > From: opensc-devel-boun...@lists.opensc-project.org [mailto:opensc-devel- > boun...@lists.opensc-project.org] On Behalf Of Ludovic Rousseau > Sent: 12. tammikuuta 2011 11:22 > To: opensc-devel > Subject: Re: [opensc-devel] Misleading information about capabilities of > readers > > 2011/1/11 Andre Zepezauer : > > Hello, > > > > the wiki page of MyEID [1] contains the following paragraph: > > > > "Many readers don't support receiving the default amount of data (254). > > Problems will only appear when reading larger files from the card (e.g. > > certificates). So if you have problems with reading the card with no > > apparent reason, try to set this to e.g. 192, to be on the safe side. > > You can then try to iterate to find the maximum for your card reader." > > > > That statement is simply wrong, because every USB reader can handle > > Short-APDUs of every size. For that reason no other card has similar > > problems. > > Every _non-bogus_ reader. > For example the Feitian SCR301 [2] is bogus and can't support CASE 2 > APDU with Le=0 (256 bytes). That is why this reader is listed in the > "unsupported" list of my CCID driver. > > > If there are readers that don't work properly with MyEID, then list them > > explicitly by name. That would definitely of more help to users then > > such a vague statement like "Many readers don't support [...]". > > The reader above has a problem with Le=256. Le=254 should work and the > reader should not have a problem with MyEID. > > I don't know which readers have problem with MyEID. An explicit list > of bogus readers would be great so that users can avoid buying such > readers. There is nothing special about MyEID that would cause the issue. In windows everything works just fine if we follow the readers maxIFSD value. One difference with many other cards supported by OpenSC that they use T=0 protocol (MyEID use T=1). We have not investigated this further, because the setting solves the problem. Kind regards, Toni > > Bye > > > [1] http://www.opensc-project.org/opensc/wiki/MyEID > [2] http://pcsclite.alioth.debian.org/ccid/unsupported.html#0x096E0x0503 > > -- > Dr. Ludovic Rousseau > ___ > opensc-devel mailing list > opensc-devel@lists.opensc-project.org > http://www.opensc-project.org/mailman/listinfo/opensc-devel ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Misleading information about capabilities of readers
Hello, On Jan 12, 2011, at 11:22 AM, Ludovic Rousseau wrote: > Every _non-bogus_ reader. > For example the Feitian SCR301 [2] is bogus and can't support CASE 2 > APDU with Le=0 (256 bytes). That is why this reader is listed in the > "unsupported" list of my CCID driver. Interesting. Too bad the original problem description [1] from the commit message is not available any more. Jean-Michel, what were the symptoms of the bug? [1] http://www.gooze.eu/forums/support/gnu-linux/can-t-get-feitian-r-301-reader-to-work-with-feitian-pki-card -- @MartinPaljak.net +3725156495 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Misleading information about capabilities of readers
Hello, On Jan 12, 2011, at 11:34 AM, Aventra development wrote: > Readers we have tested are: > - ACS ACR38 CCID This is a very broad range, ACS re-uses the chip in different incarnations in several products that are marketed under different names and I would not bet on it being 100% the same chip (firmware) all the time. > - Gemalto Twin Reader > - and some OmniKey reader (maybe 3121 if remember correctly) > > All of these have the same issue, so I suspect that they are not the cause > of the problem. > Many of our customers have had the same problem and setting this value has > helped also them, so it is not only in our environment. > > We have not investigated this further, because this setting solves the > problem, and does not affect performance that much that it would matter. Please provide a failing OpenSC debug log. -- @MartinPaljak.net +3725156495 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Misleading information about capabilities of readers
Hi, Well this is just something we (and our customers) have encountered with the readers that we have tested. I don't know what causes the limitation (probably not the reader itself, because they work in windows just fine). So it might be in pcsc-lite, the ccid driver or something to do with usb in linux?? Readers we have tested are: - ACS ACR38 CCID - Gemalto Twin Reader - and some OmniKey reader (maybe 3121 if remember correctly) All of these have the same issue, so I suspect that they are not the cause of the problem. Many of our customers have had the same problem and setting this value has helped also them, so it is not only in our environment. We have not investigated this further, because this setting solves the problem, and does not affect performance that much that it would matter. Kind regards, Toni > -Original Message- > From: Andre Zepezauer [mailto:andre.zepeza...@student.uni-halle.de] > Sent: 12. tammikuuta 2011 0:21 > To: Aventra development > Cc: opensc-devel > Subject: Misleading information about capabilities of readers > > Hello, > > the wiki page of MyEID [1] contains the following paragraph: > > "Many readers don't support receiving the default amount of data (254). > Problems will only appear when reading larger files from the card (e.g. > certificates). So if you have problems with reading the card with no > apparent reason, try to set this to e.g. 192, to be on the safe side. > You can then try to iterate to find the maximum for your card reader." > > That statement is simply wrong, because every USB reader can handle > Short-APDUs of every size. For that reason no other card has similar > problems. > > If there are readers that don't work properly with MyEID, then list them > explicitly by name. That would definitely of more help to users then > such a vague statement like "Many readers don't support [...]". > > Regards > Andre > > [1] http://www.opensc-project.org/opensc/wiki/MyEID > > ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Misleading information about capabilities of readers
2011/1/11 Andre Zepezauer : > Hello, > > the wiki page of MyEID [1] contains the following paragraph: > > "Many readers don't support receiving the default amount of data (254). > Problems will only appear when reading larger files from the card (e.g. > certificates). So if you have problems with reading the card with no > apparent reason, try to set this to e.g. 192, to be on the safe side. > You can then try to iterate to find the maximum for your card reader." > > That statement is simply wrong, because every USB reader can handle > Short-APDUs of every size. For that reason no other card has similar > problems. Every _non-bogus_ reader. For example the Feitian SCR301 [2] is bogus and can't support CASE 2 APDU with Le=0 (256 bytes). That is why this reader is listed in the "unsupported" list of my CCID driver. > If there are readers that don't work properly with MyEID, then list them > explicitly by name. That would definitely of more help to users then > such a vague statement like "Many readers don't support [...]". The reader above has a problem with Le=256. Le=254 should work and the reader should not have a problem with MyEID. I don't know which readers have problem with MyEID. An explicit list of bogus readers would be great so that users can avoid buying such readers. Bye > [1] http://www.opensc-project.org/opensc/wiki/MyEID [2] http://pcsclite.alioth.debian.org/ccid/unsupported.html#0x096E0x0503 -- Dr. Ludovic Rousseau ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] Misleading information about capabilities of readers
Hello, the wiki page of MyEID [1] contains the following paragraph: "Many readers don't support receiving the default amount of data (254). Problems will only appear when reading larger files from the card (e.g. certificates). So if you have problems with reading the card with no apparent reason, try to set this to e.g. 192, to be on the safe side. You can then try to iterate to find the maximum for your card reader." That statement is simply wrong, because every USB reader can handle Short-APDUs of every size. For that reason no other card has similar problems. If there are readers that don't work properly with MyEID, then list them explicitly by name. That would definitely of more help to users then such a vague statement like "Many readers don't support [...]". Regards Andre [1] http://www.opensc-project.org/opensc/wiki/MyEID ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
