On Friday 17 March 2006 15:20, Justin Karneges wrote: > On Friday 17 March 2006 08:19, Chaskiel M Grundman wrote: > > Since it doesn't seem to break this device, I would put back the other > > card_reset code you pulled out, since it might be needed with other > > hardware (and it might deal with the extraneous 0 in the ATR, which is > > also visible in the usb snoop log) > > I noticed that OpenSC seems to be aware of this. When the extra 0 appears, > OpenSC reports: > > sc.c:540:_sc_parse_atr: invalid sync byte in ATR: 0x00 > > Maybe it is a common problem. I've noticed it happens immediately after > insert. Every operation after that is fine. If a leading 0 is never good, > perhaps I can account for it in eutron_init (ignore the first byte if 0). > I wonder how SafeSign deals with it..
Follow-up: According to the log, it looks like SafeSign works around the problem by requesting the ATR twice. This is apparently what the 0x09 control request is for. SafeSign does: ctrl: 42 a2 ctrl: 42 0a ctrl: 42 09 At this point, the card sends the ATR. SafeSign reads it, and then does: ctrl: 42 09 and the card sends the ATR again, this time properly. I'd like to make ifd-eutron do the same thing, although I'm not sure of the best approach. My "guess" is that SafeSign determines that the first response is wrong, and then rerequests the ATR, but I don't know how this wrongness would be detected, especially since the whole ATR string would need to be read (and how do you determine the end of it if the data is wrong?). One idea I have is to just ignore a leading zero byte in the first response, in which case I wouldn't even need to rerequest it. But this surely differs from SafeSign's algorithm. What do you think? On Friday 17 March 2006 08:19, Chaskiel M Grundman wrote: > NAD identifies the who the packet is being sent to (not interesting here, > since there's no separate "reader" to talk to) > PCB is the "procedure byte". there are a bunch of control bits. As this > serial channel is unlikely to ever have errors, we're only going to see Can you explain the "control bits" in the PCB, or refer me to some documentation on it? The exchange I'm unsure about is this one: send: 00 c1 01 fe 3e recv: 00 e1 01 fe 1e The 0x40 bit is set in here, but of course there are others too. I'd also like to find out what the meaning of the content is as well (0xfe), to determine whether or not this exchange belong in eutron_init. -Justin _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
