Hi, what commands did you use? load and install in a single command, or separate loading, then instanciation?
6a80 may come from the instanciation step (install for install) if you don't give a correct instance initialization data array. according to GP 2.1.1, the load command does not throw 6A80, but the install command can. also, be sure not to use any -nvdatalimit et al options in gpshell, they are totally useless, but if by chance, the applet is bigger than the limits, the load will fail. I hope this gives you some hints, waiting for your feedback. Sebastien PS: just to be sure: what is the ijc format? IIRC this is the concatenation of all CAP components. Why don't you use the generated CAP from the trusted logic captransf tool directly? this is what I did and it was successful. On Wed, May 27, 2009 at 9:39 AM, Jakob Bohm <[email protected]>wrote: > Hi, > > I am having severe problems installing the CardEdge applet on a Cyberflex > e-gate 32k (aka Gemalto TOP US), the first card listed as compatible in > the applet README file. > > 1. When I try to install the applet using gpshell, the card refuses the > "load" command with error 6A80 ("invalid data"). I have tried both gpshell > 1.4.0 and 1.5.0 and both the downloadable > http://www.identity-alliance.com/CardEdgeCflex.ijc, a self-compiled > applet from the latest svn sources (using the ant scripts) and a > self-compiled applet compiled using a short shell script that I tested to > otherwise create working applets for that card (tested with HelloWorld.java > and a small test applet of my own). > > And yes, this implies that I do have and use captransf.jar version 1.5 from > www.trusted-logic.fr . > > So far, nothing helps, what am I missing? > > > 2. The current svn sources don't compile as-is, due to at least 4 bugs: > > 2.1 common.xml uses Windows-only path separators (backslashes), not the > portable slashes. > > 2.2 common.xml does not set the javac option to produce .class files > compatible with the JavaCard tools (target="1.1" source="1.2"). > > 2.3 The build instructions are not sufficiently clear about which kits to > unpack, what kit files and additional tools to move/copy/patch etc. It > took > a lot of work to figure this out. > > 2.4 CardEdge.src does not compile with the JavaCard 2.1.1 kit due to a > small > bug in the addition of Extended APDU support. Here is my patch: > > > Index: CardEdge.src > =================================================================== > --- CardEdge.src (revision 286) > +++ CardEdge.src (working copy) > @@ -910,8 +910,8 @@ > private void ComputeCrypt(APDU apdu, byte[] apduBuffer) { > /* Buffer pointer */ > byte[] buffer = apduBuffer; > +#ifdef WITH_EXT_APDU > short dataOffset = apdu.getOffsetCdata(); > -#ifdef WITH_EXT_APDU > short LC = apdu.getIncomingLength(); > short bytesLeft = apdu.setIncomingAndReceive(); > > @@ -925,6 +925,7 @@ > bytesLeft = LC; > } > #else > + short dataOffset = ISO7816.OFFSET_CDATA; > short bytesLeft = Util.makeShort((byte) 0x00, > buffer[ISO7816.OFFSET_LC]); > if (bytesLeft != apdu.setIncomingAndReceive()) > > > > -- > This message is hastily written, please ignore any unpleasant wordings, > do not consider it a binding commitment, even if its phrasing may > indicate so. Its contents may be deliberately or accidentally untrue. > Trademarks and other things belong to their owners, if any. > _______________________________________________ > Muscle mailing list > [email protected] > http://lists.drizzle.com/mailman/listinfo/muscle >
_______________________________________________ Muscle mailing list [email protected] http://lists.drizzle.com/mailman/listinfo/muscle
