This content has been marked as final. Show 1 reply
I guess your card is using the T=0 protocol.
Doc for setOutgoing states: "In T=0 (Case 4S) protocol, this method will return 256 with normal semantics."
So everything is working as designed (I'm not saying: at is should have been designed).
There is no problem if you know the expected length of the answer (that is the integer Ne, coded by Le) from the spec of the APDU and its input parameters excluding Le, and 0<Ne<256. In that case just set that Nr=Ne using setOutgoingLength and send Nr data bytes with sendBytes. The card will tell Nr to the reader (as part of a conventional status word), some glue code in the bowels of the Java runtime library or application should issue a Get Response command, and everything will be fine. This might work with Ne=256, coded by Le=00h, but do not bet on that without trying.
There is no problem either if you are happy with the default behavior of truncating the Nr bytes of outgoing data to Ne coded by Le. Just do as above as if you knew Ne was the maximum it could be, and everything will be fine.
If your in-card applet really needs (rather than know or assume) Ne, one option is to instead change the spec of the APDU and move Ne to P1,P2, or some of the ingoing data where you can get it.
Else, well... I'd rather not dive into these messy details if the previous three simple options apply.