I'm currently discovering the smart card world and there are some things that I don't understand.
I'm developing a driver that talks to my smart card reader (USB) using the CCID protocol (I succeeded in having basic communications).
But then if I want to talk to my card using ISO/IEC 7816-4 specification, I will keep using the CCID protocol and in the PC_to_RDR_XfrBlock() request, in the data part (abData at offset 10 cf $6.1.4 page 30 specification of CCID) I will directly send my ISO/IEC 7816 command as READ_BINARY, WRITE_BINARY, SELECT ... And the smartcard reader will answer me using RDR_to_PC_DataBlock() ($6.2.1 page 49).
This question is OS independent, and not using any existing drivers or OS library.
Am I right?
I found my answer by analysing trames with wireshark. It seems to work as I described it.
Here are somes links that will help user that tries to do the same.
To setup usb capture :
https://wiki.wireshark.org/CaptureSetup/USB
To enable iso 7816 frames analysis in wireshark (inside ccid packets): https://ask.wireshark.org/questions/32594/iso-7816-example-capture
Related
I am very new to USB interfacing and i am trying to build an application for WINCE 2013 device. In my device, one vendor's (let suppose 'X') VID and PID are using for USB mass storage device class.
Now, i have specific use case where communication should be built on USB rndis class. For this communication purpose we are using microsoft generic rndis driver as is (not a custom one). So, can i use the X's VID and PID(which i am using for MASS STORAGE class now) for the Rndis class too or need to purchase a new one again. I know that i can use any VID and PID during development stage but i need VID and PID's for production devices.
Or can i go with Microsoft VID, PID and compatible id's compatible for Microsoft generic rndis driver by changing only the Serial Number for devices?
Please suggest and thanks in advance! :-)
(Do let me know if the query is too vague to understand.)
It's difficult to find a definitive answer, but maybe we'll be able to extrapolate from this post by a Microsoft MVP (emphasis mine):
(...) you don't have to change MS's VID/PID anymore if
you use USB RNDIS to use ActiveSync.
Here's the official response from
Microsoft on this subject (as asked by a fellow MVP regarding a client
who had the same issue):
Question: Should they use the Microsoft PIDVID or create their own? If
they create their own, it means modifying the current .inf file and
therefore this means the driver will be unsigned and therefore may not
be able to be installed. In the past the Microsoft PIDVID gave warnings
to not use this. Now in 6.0 the warnings do not appear.
Answer: The answer is exactly the same as for Windows Mobile: For
ActiveSync usage, YES, you can use Microsoft's VID & PID for your scenario.
This is a change from documentation which says to get your own PID &
VID. Contrary to what the sample Registry file says, the OEM should ship
the device using Microsoft's VID & PID for USB-Serial ActiveSync client.
The latest OEM documentation confirms this (...)
Now, since you don't specifically mention ActiveSync, my understanding is that the above probably does not apply to your use case, which again means you will have to use your own VID and PID.
If you already own a VID/PID combination, I don't see any (legal) issues using this with RNDIS as well. It is the same device after all, and the USB host would load one of two different class (not custom) drivers to communicate with the device.
However, if you use your own VID/PID you will have to either
supply a signed INF file to end-users that contains your custom VID/PID, or
instruct users to manually select the RNDIS driver when your device is connected to the PC for the first time
I need a software or application with API support to capture USB packet and data buffer. I would like to analyse the captured data using LabVIEW.
Suggest applications for usb packet and data capture with API support, so that I can access them using LabVIEW.
Or
Alternate methods to capture and analyse usb data using LabVIEW
I had tried a approach using logman.exe . But that doesn't log all the USB packets. Has anyone tried logman to capture the usb packets?
you can consider using VISA functions.
A few examples are shipped with Labview (open example finder and look for USB).
Here is a starting point giving instructions about how to give VISA access to the device.
You need find out some windows dll's and use it in labview. the examples provided for NI USB devices.
I have here a unit of King Pigeon S275 Remote Terminal Unit..
this RTU has communication modules for GSM, GPRS and TCP/IP (via RJ45 connection)
I can also communicate with this RTU by connecting it to my computer via USB .
The Manual I uploaded in this link...
https://www.mediafire.com/?gnfzfz5l7pess1p
This RTU can be configured using a configurator Software that is included in the purchase. By using that configurator software, you can also see the data/readings of all sensors connected to it, you can also see the status of all Digital Input/contacts connected to the RTU...
I have been researching about MODBUS the past days and I would like to create my own MODBUS program so that the S275 RTU can also send the sensors' data, or all the I/O data to my own program....
However ... I still do not know where I can start ...
Can I make this Modbus Program
1. using VB?
2. using PHP?
What other parameters do I need to know ?
and tutorials for making this modbus software...
I also uploaded here the S275's;
1. GPRS Custom Protocol
2. MODBUS TCP Handshake Communication Protocol
3. Register Address
https://www.mediafire.com/?khnfu53a4p12nrd
Thanks
PHP and ModBus sounds challenging. You want to control a serial port via PHP.
The easiest way is to get/purchase a library for ModBus/RTU.
Otherwise you have to implement the whole protocol by yourself from http://www.modbus.org/specs.php
You can use nmodbus API to add how reference in your VB or C# project.
There you have the manual.
Supports serial ASCII, serial RTU, serial over USB ASCII, serial over USB RTU, TCP, and UDP protocols.
These kinds of RTU’s are pretty inexpensive which means your greatest cost will be the time you will spend developing and debugging a driver. With that in mind I would first check if the RTU comes with its own OPC Server. Implementing an OPC client in C# or vb.net is very straight forward with plenty of code example out there. Some examples can be found here:
https://opcfoundation.org/developer-tools/developer-kits-unified-architecture/-net-stack-and-sample-applications/
If the RTU does not come with its own OPC server then, you can purchase a Modbus OPC Server from $900 to $2000 which will still be much more cost effective than writing and debugging your own driver and tends to be easier to setup. It will also significantly reduce the time to deliver your solution to your end customer which will be important if keep to project schedule is critical. I would check out, https://www.kepware.com/ and http://www.matrikonopc.com/
The other advantage of OPC is that it is a standardized interface which means should the RTU be replaced with a different model that supports a different protocol you would only have to purchase a new OPC server without the need to update your source code.
If the RTU does not have an OPC server or spending up to $2000 also not an option then there is plenty of open source implementations of the Modbus protocol, however implementation tends to be a bit more complex.
No problem, I used PHPModBus in several projects and it works like a charm!
This library supports Modbus TCP and UDP.
Try it, it is quite easy and straightforward.
I learned on OSDev wiki that Endpoint 0 is the default control pipe, allowing for bi-directional control transfers. This is used for device configuration, e.g. to retrieve device descriptors. The USB 2.0 spec explains this more thorougly in section 5.5 Control Transfers.
There are also a limited amount of endpoints available (2 for low-speed, 15 for full- and high-speed devices). Somewhere in the USB 2.0 spec, I have read that there must be at least one control pipe. This implies that there may be multiple control endpoints, but what is the use of it? Do you know any particular USB device or class that has an EP configured as control pipe?
Later, I found this in the spec, section 10.1.2 Control Mechanisms:
A particular USB device may allow the use of additional message pipes
to transfer device-specific control information. These pipes use the
same communications protocol as the default pipe, but the information
transferred is specific to the USB device and is not standardized by
the USB Specification.
If I understand it correctly, this means that non-EP0 cannot be used to configure the device (say, a standard request such as GET_DESCRIPTOR). But the setup/data/status stages seem still to be available ("[..] use the same communications protocol [..]"). Is this correct? Or is the use of standard/class requests forbidden for non-EP0?
Background: while working on an emulated USB device in QEMU, the need for a USB monitor for debugging purposes appeared. During inspection of the QEMU core USB code, I noticed that it only processed control commands for EP0. Other endpoints would be treated as data. There are some virtual devices (host-libusb) that always reject control transfers for those other endpoints. Hence the question whether this is the correct behavior or not (and if valid, whether there exist devices that really implement this).
As far as I can tell, there is no use for a non-EP0 control endpoint. I have developed several products that use custom control transfers on endpoint 0 as the main way to send device-specific requests and I have not encountered any fundamental problems with doing that.
If you did make a non-EP0 control endpoint I think your understanding is correct; you wouldn't be able to use it for standard requests but you would be able to use it for custom requests and the transaction sequences would be the same as on EP0.
In a Windows 8 Store App I would like to read Data from a SmartCard. After installing the SmartCard reader (USB Device) I can read its device path and connection state via the Windows.Devices.Enumeration namespace. Even the device interface id is retrievable (50dd5230-ba8a-11d1-bf5d-0000f805f530) and I put this as a required capability in the App's manifest file.
For the interaction with the device I use a C++ Component calling the CreateDeviceAccessInstance Method. But this call always results in an ACCESS_DENIED exception.
Further research taught me, that interacting with a custom hardware device (everything that is not a printer, microphone, mouse, ...) would need several adjustments in the device driver published to the windows 8 driver store.
I'd be glad to do so, but I am no IHV and would like to use the generic driver and the generic interface.
Could anyone give me a hint how to proceed from here and use the generic interface for USB SmartCard devices?
This is not a real answer, but I have the same problem and I have spent quite some time looking for the hard-to-find bits of information on this subject around the internet, and I'd like to share my results.
Windows 8.1 has some specific APIs for (virtual) SmartCards (API reference, sample), but it seems like they can only be used for authentication and there is no way to send APDU commands to a card at the moment (see this comment by Himanshu Soni). I guess one could use the new USB APIs to talk to the reader directly, but then you'd have to implement the whole protocol yourself.