|
Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com |
Re: [Muscle] CCID bogus firmware checking is ... well ... bogus :)
From: Iain MacDonnell (muscle
dseven.org)
Date: Fri Mar 31 2006 - 15:51:34 CST
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Ludovic Rousseau wrote on 03/31/06 04:06 AM:
> On 29/03/06, Iain MacDonnell <muscle
dseven.org> wrote:
>> Ludovic Rousseau wrote on 03/28/06 10:56 PM:
>>> Can you run the ccid-1.0.0/src/parse command with each of your readers
>>> and send me the outputs?
>> Attached.
>>
>> idVendor: 0x09C3
>> iManufacturer: ActivCard
>> idProduct: 0x0008
>> iProduct: ActivCard USB Reader V2
>> bcdDevice: 0.CA (firmware release?)
>>
>> idVendor: 0x04E6
>> iManufacturer: SCM Microsystems Inc.
>> idProduct: 0xE001
>> iProduct: SCRx31 USB Smart Card Reader
>> bcdDevice: 2.06 (firmware release?)
>
> That is very strange. I also have these readers and don't have this "problem".
>
> Where did you get the readers? Did you upgrade the firmwares yourself?
>
> Another explanation is that the Solaris libusb interprets the
> bcdDevice field in a different way than the "normal" libusb. You
> should have a look at the Solaris implementation to see what happens
> there. I look at libusb [1] and could not find anything special about
> bcdDevice.
The USB 2.0 spec, section 9.6.1, states that bcdDevice is Binary Coded
Decimal, but, annoyingly, it is not specific about the translation.
I'm assuming it's the same as bcdUSB, which is described as:
"The bcdUSB field contains a BCD version number. The value of the bcdUSB
field is 0xJJMN for version JJ.M.N (JJ - major version number, M - minor
version number, N - sub-minor version number), e.g., version 2.1.3 is
represented with value 0x0213 and version 2.0 is represented with a
value of 0x0200."
Technically, "5.18" cannot be represented in that format, but a hex
value of 0x518 should be interpreted as "5.1.8", so it appears that
the CCID IFD handler is interpreting the value *almost* correctly - to
be completely correct, it should split out the minor and sub-minor
version numbers.
That aside, it does appear that there's something wrong in the libusb
implementation that I'm using, so discard my bug report, and I'll go
off and explore the problem elsewhere. FWIW, it's not a problem with
the Solaris libusb implementation in general, but with a plugin to that
implementation that I've been experimenting with.
Thanks!
~Iain
_______________________________________________
Muscle mailing list
Muscle
lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]