-
-
Notifications
You must be signed in to change notification settings - Fork 212
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Post commit 2d4bb36c145bd8c13606f12aa14e6e29d8ecef78 GPPro versions fail to install applet on NXP cards #355
Comments
I've dug into the pcscd logs and I can see that the actual error seems to be that we start to see these Here's a small excert of the logs
|
After further analysing the pcscd logs, I think I know why this happens. In the logs I can see 2 primary clients. There's client 13, which I'm not entirely sure what that is actually, but I presume it's some system service polling for cards in the reader. It is continously acquiring and releasing a lock on the reader to do a short transmit. And then there is client 18, which is GlobalPlatformaPro. With versions prior to the commit 6347f0f? the logs show clearly that all of the TRANSMIT commands are wrapped inside BEGIN_TRANSACTION - END_TRANSACTION and this cuts off the client 13. However, with newer versions of GPP there is no trace of BEGIN_TRANSACTION for client 18, instead it just goes on with the TRANSMIT commands without establishing a transaction and then at random moment in the middle of client 18 issuing its TRANSMIT commands, client 13 activates again issues CONNECT, followed by BEGING_TRANSACTION and that's when client 18 gets its first SCARD_E_SHARING_VIOLATION and is never able to recover. So, this is actually quite clear now. The original connect lines handled connecting like this, clearly establishing an exclusive transaction: GlobalPlatformPro/tool/src/main/java/pro/javacard/gp/GPTool.java Lines 190 to 194 in 2d4bb36
but with the breaking commit, it was reduced to just this and no calls to begin (or end) exclusives exists
So, the fix is to reintroduce exclusive transaction locks. Shouldn't be that difficult to recover the old behaviour. |
I created a PR to restore the old behaviour. Works great for me: |
This may or may not be the same issue as this #255, but since that issue hardly contained any useful information I figured a clean new issue is probably in order.
So, in short, I can not install (any) applet with any of the prereleases (or self built "next") to any of my JCOP cards. I can install applets with latest stable and self built up-to commit 2d4bb36, but with the next commit 6347f0f it no longer works. I suspect this is likely due to the apdu4j update, but I haven't yet gotten that far that I could definitely say that.
The card in question is NXP J3R180 SecId, I also have another card that is suppose to be pretty much the same, but reports different ATR, so I'm not entirely sure. It has the same issues. For additional context, I can tell that I actually have the same issues with the GPShell, but I haven't debugged that any deeper yet.
With our normal applet of code size of 6479 bytes it's always the CAP loading that fails.. usually around chunck 14 or 15, but sometimes even 16, but also sometimes it can also fail right off the bat on first chunk.
If I try to just install a minimal applet of code size 1206 bytes, it actually sometimes succeeds loading it, but at least so far, it then still fails with making it selectable.
Log of failure to make selectable
Log where it fails already during load
The text was updated successfully, but these errors were encountered: