search

licel / jcardsim

https://jcardsim.org
224 stars 123 forks source link

CardChannel does not support status word 0x61xx (SW_BYTES_REMAINING_00) #19

Open licel opened 11 years ago

licel commented 11 years ago

From erick...@bitflash.net on September 20, 2013 21:53:17

What steps will reproduce the problem? Create an applet that returns long responses using ISO7816.SW_BYTES_REMAINING_00 status words. What is the expected output? What do you see instead? The CardChannel implementation should transparently handle these long responses, so that clients using the CardChannel only get one long ResponseAPDU, with the status being the status of the final response to the original command. Instead, the 0x61xx response code is returned to the application. What version of the product are you using? On what operating system? jCardSim-2.2.1, OS-independent Please provide any additional information below. Support for this and other "artifacts of the transmission protocol" should be handled by the smartcardio implementation, as described in the API docs. http://docs.oracle.com/javase/7/docs/jre/api/security/smartcardio/spec/javax/smartcardio/CardChannel.html#transmit%28javax.smartcardio.CommandAPDU%29

Original issue: http://code.google.com/p/jcardsim/issues/detail?id=19

licel commented 11 years ago

From erick...@bitflash.net on September 20, 2013 10:56:09

I fixed this by recursing to transmitCommand() in SimulatorRuntime when SW1 is 0x61. Seems to work okay. Let me know if you could use diffs.

licel commented 11 years ago

From jcard...@licel.ru on September 21, 2013 07:47:49

Status: Accepted

klali commented 10 years ago

I'd like to see this bug fixed (and am happy to write code to fix it)..

I think the most sensible way to handle this would be to return the request as it's sent, data and the 61XX SW at the end. Letting the user of the simulation unwind the chaining themselves. Would a pull request implementing that be merged? or would you like to see this solved in another fashion?