I have a pn5180 reader. I can send WUPA command to an EMV card (ISO 14443-A) with PN5180. I can also get the UID information of the card. I can also send a RATS command to the card and get the ATS statement, which is the answer.
However, after sending a RATS command (a PICC receiving a RATS command goes into a "protocol state") some strange situations can occur. These can be listed as:
a- I cannot read a Register of pn5180.
b- When I send a PPSE command, the responses I get are 0xFF.
c- I get a response to the DESELECT command, but when I send WUPA to the card again, a problem occurs.
In short, why doesn't a PPSE command I send after the RATS command return a proper response? I wonder if some adjustments need to be made before or after the RATS command?
Note:I've asked the same question in the NXP community and haven't gotten an answer yet.
Related
SGP.02 - Remote Provisioning Architecture for Embedded UICC Technical Specification (page 255 of v4.0 specifically) says:
the data format provided by the function caller SHALL NOT depend of the selected OTA protocol capabilities (for example SM-DP can consider there is no limit on data length)
and later
The SM-SR has the responsibility to build the final Command script,
depending on eUICC capabilities and selected protocol:
by adding the Command scripting template for definite or indefinite length,
and, if necessary, by segmenting the provided command script into several pieces
and, if necessary, by adding the relevant Script Chaining TLVs.
I understand it that SM-DP can send arbitrary long data parameter to ES3.SendData and SM-SR should send several APDUs in multiple SMSes if data is too large to fit into one. And that is meant by segmenting.
The problem is I can't find a relevant specification that defines how segmenting should be done. And that's the question: where is the segmenting process defined?
I may be wrong but it seems that is not the same as Concatenated Short Messages described in the section 6.3 of ETSI TS 123 048.
It seems that Script Chaining briefly mentioned in ETSI TS 102 226 is somewhat related so pointers to the specification that defines how it works are also very much welcome (TS 102 226 talks about Script Chaining TLVs but not how to use them, at least I'm definitely missing some broader context how it works so any hints are appreciated).
UPDATE:
ES8.EstablishISDPKeySet function requires 3 APDUs to be sent. And they are quite big as they contain keys. From SGP.02-v4.0 table 150 I understand it that they are sent from SM-DP to SM-SR using Expanded Remote Command Format. The script in this format can be rather large as far as I understand (given that SM-DP can assume that there is no limitation on the data length). And it is not clear how SM-SR should segment it or use chaining. I'm just missing the specs where this is described.
The eUICC has a limited internal buffer, i.e. it cannot store a complete profile package of 10kb or more internally. The message must be chunked. If the eUICC supports just e.g. 1 kb then you have to split the APDU commands after at most 3 APDU commands to stay below 1kb. The SGP.02 specification defines to have at least 1024 bytes. A fully featured SM-SR might store some attributes based on the eUICC vendor in the EID to add special handling and patches for certain eUICCs to support a larger buffer size.
Encode each APDUs chunk (1..n APDUs) into the Expanded Remote Command Format (ETSI TS 102 226, sect. 5.2.1) (compact format can only have one response for the last APDU, but if it works, you could save a few bytes)
Encode each Expanded Remote Commands message into a SMS-DELIVER (TS 123 048 and simalliance Interoperability Stepping Stones release 6) This includes the data encryption using the OTA keys (KiC, KID). gsm0348 is a good Java library for this. Pay attention: For each message the OTA counter must be incremented. Select one reference number and keep it for all messages. I guess this is the identifier how the eUICC knows which messages belong together.
If using SMS (I would suggest to use CAT-TP or HTTPs instead -> faster and more reliable) encode it as SMS-PP Download message (TS 131 111). You will using message concatenation here if the payload is more than 140 bytes.
You will receive as response a SendShortMessage (TS 131 111, 6.4.10). Extract the user data again with TS 123 048 and simalliance Interoperability Stepping Stones release 6. You get the SMS Response message. Look into the response packet to get the user data.
Extract the user data as Expanded Remote Response (ETSI TS 102 226)
The eUICC will handle the streamed messages. The concatenated short messages are only used for a message chunk belonging together during the transit.
The best specification that kind of explains how segmenting and script chaining works in details is SGP.11 Remote Provisioning Architecture for Embedded UICC Test Specification.
It does not have a requirements per se but it has the byte level examples of incoming ES3.SendData and examples of the messages received by eUICC. And this allows to deduce the actual behaviour of the SM-SR pretty easily.
And here is more detailed explanation with references to that specification.
Command script
Command script is a list of commands sent in the data fields of the ES3.SendData. It can be (see data field description in table 150 of SGP.02-v4.0) either:
the list of C-APDUs commands (defined in EXPANDED_COMMANDS method on page 595 of SGP.11-v4.0 and uses in step 2 on page 407 of SGP.11-v4.0)
TLV commands that form a SCP03t script (defined in SCP03T_SCRIPT method on page 600 of SGP.11-v4.0 and used in step 14 on page 408 of SGP.11-v4.0)
Script Chaining
Script chaining is the feature used when there is a need to execute several commands sent in multiple transport messages but when some context of the execution needs to preserved after the first command is executed and used for the next one (for example the first command is INSTALL [for personalization] and the second one is STORE DATA). This context is command session defined in section 4 of TS 102 226.
This is used at least in these cases (which is also supported by Annex K in SGP.02):
when the followup command is based on the response from eUICC
when command script is too large and cannot be sent in one piece
Script chaining is performed by SM-SR and is implemented by adding Script Chaining TLV to the command script in Expanded Remote format. See section 5.4.1.2 in TS 102 226.
Examples of script chaining can be found in SGP.11-v4.0.
For the first case see the scenario for EstablishISDRKeyset procedure in section 4.2.10.2.1.1 . For the second case see the scenario for DownloadAndInstallation procedure in section 4.2.18.2.1.1. The byte level representation of the script chaining is described in SCP80_PACKET method on page 601 (see option CHAINING_OPT).
It seems that explicit chaining is applicable only to SMS or CAT_TP transport. For HTTPS the command session coincides with the administrative session as defined in section 3.6 of Remote Application Management over HTTP – Public Release v1.1.3 so there is not need to add explicit Script Chaining TLVs.
Segmenting
When the command script is too large and cannot be sent in one piece SMSR generates multiple command scripts. The commands that SMSR received from SMDP CMD1, CMD2, …, CMDN (see step 14 on page 408 of SGP.11-v4.0) and that form a command script are split into several command scripts. The first one contains some initial portion of the commands CMD1, CMD2, …, CMDi. The second command script contains commands CMDi+1, CMDi+2, …, CMDj. The third one CMDj+1,…,CMDk and so on.
If SMS or CAT_TP is used then for every command a Chaining TLV is added to the beginning with the appropriate value (see section 4.2.18.2.1.1 in SGP.11-v4.0).
And then every new command script is sent in a separate message to eUICC.
I am trying to understand how I can sent status requests to these label printers to see if they are free to print labels.
The problem I have is that if I send too many label print requests then only some of get printed. I think the problem is that the memory buffer of the printer is getting overwritten and some of the labels are being deleted and not printed.
I have tried to ~HS command but can't figure out what parameter I need to check as the documentation is not very good.
Thanks in advance.
The bufferFullFlag will tell you if the printer's buffer is full and cannot receive any more print jobs. You can query that (it's the 6th parameter). You should also look at the paperOutFlag and pauseFlag to make sure the printer is ready to print.
If you use the Zebra SDK, you can call the ZebraPrinter.getCurrentStatus() and that will return a class that contains the ~HS parameters as primitive data types so that you don't have to parse it yourself. There is also a combo boolean called isReadyToPrint which looks at several of the status bits to see if you can send a job to the printer
I have a serial usb device that is connected to a linux box and it works fine with serial communication programs, such as minicom.
For instance, within that program, I send the string "V" and I get back an answer: "UBW FW D Version 1.4.3".
Now, I'd like to do a shell script that could do the same, in order to test variables. I investigated the possibility to use minicom without being "interactive" but it seems is not possible. I also tried the obvious "echo V > /dev/ttyACM0" but had no luck as well.
Any idea of how can I send and receive strings to/from a serial device in such way I can use the received data in a shell script?
Thanks
In the olden days of modems, we would use the program 'expect' to send and receive data from the serial line. This doesn't exactly solve your problem, but might get you some of the way there.
Have a look at Use expect in bash script to provide password to SSH command
The atinout program does exactly what you are asking for. Example:
$ echo AT | atinout - /dev/ttyACM0 -
AT
OK
$
Now, from you example command and response, I see that your "modem" seems to able to configure or modify to not return the OK Final Result Code, and atinout absolutely needs that for its operation, so make sure the UBW behaves properly.
Trying to implement IOCTL commands, and just encountered as below:
If _IO is for both read and write
than why should I consider _IOR and _IOW
any clue please ?
Actually _IO is for ioctls that don't take any parameters at all. For instance, say that you want to trigger a command that has been previously set up in the driver, you may not need to pass any data at all!
_IOWR is for ioctls that pass parameters in and then out. In my experience these are rare and can be confusing since one parameter is utilized for two very different purposes but it can be useful when you need it.
See the beginning of http://www.mjmwired.net/kernel/Documentation/ioctl-number.txt
There isn't anything in the kernel that enforces the direction, so it is mostly for documentation purposes.
_IOR --- For reading from device to user space app, _IOW --- Write data passed from user space app to device(Hardware) and _IOWR --- For both read/write data from/to device. But _IO --- are basically used to send device configurable commands to intended device i.e. for example if you want to read/write to flash you need to send command first and then read/write data from/to flash. Since read/write command is constant/fixed as specified in the flash datasheet, so there is no need to explicitly send/pass command from user space app to driver ioctl, you can form a command packet as required inside _IO ioctl case and send it to flash. _IO --- Tells that you don't have to pass data(command) from user space app, you in the driver have use hard coded read/write command and send command to the intended device. _IOR or _IOW or _IOWR are used read/write volatile data passed form user space app to/from device (ex:flash). Hope this answer would clarify your doubt :-).
I am using this line to send a message via a Ruby (1.8.7) socket:
##socket.send login_message, 0
(This works fine)
What is the second parameter for? I can't find the send method in the Ruby API docs...
I first thought that it was some C style length of the message. This is why I used login_message.length as second parameter. That worked but I encountered a strange behavior:
Everything works fine when the second parameter is a odd number. If it's an even number the last character gets lost at receiving on the other side (The other side is a C++ program with a C socket). I inspected the network traffic with Wireshark and noticed that the packets look good. All the data is complete. Why is the last character lost when I receive it?
Thank you
Lennart
This is the flags parameter, the same as the last parameter to the send() system call. Normally it should be 0, but may be something like Socket::MSG_OOB (to send out-of-band data). For Ruby 1.9 this is documented under BasicSocket.