We Keep Coding

Android/Xamarin detect when smart card inserted into USB attached device

Assistance in trying to detect when an actual smart-card is inserted into a USB smart-card reader attached to a handheld Android device.
I have an existing (and completely working) instance of the BroadcastReceiver and am successfully detecting when the actual smart-card reader device is connected via the filters of
myFilter.AddAction(UsbManager.ActionUsbDeviceAttached);
myFilter.AddAction(UsbManager.ActionUsbDeviceDetached);
What I am looking for now is when an actual card is inserted or removed from the device.
By using ADB (Android Debug Bridge) program and using the logcat, I can redirect the output to a file to see what is going on such as
adb logcat -c (to clear log)
adb logcat > c:\SomeFolder\MyAndroidLog.txt
Before starting the log above, I have my handheld device ready, the smart-card reader attached. Immediately after that is when I clear the log and start a fresh capture. Then I insert my smart card, wait a few seconds and then stop the log with Ctrl+C. Upon viewing the log, I am getting
--------- beginning of main
10-07 11:43:26.458 827 827 I chatty : uid=1000(system) /system/bin/surfaceflinger expire 14 lines
10-07 11:43:26.459 827 827 I ConfigStore: android::hardware::configstore::V1_0::ISurfaceFlingerConfigs::hasHDRDisplay retrieved: 0
10-07 11:43:26.861 556 556 W hwservicemanager: getTransport: Cannot find entry vendor.qti.hardware.servicetracker#1.0::IServicetracker/default in either framework or device manifest.
10-07 11:43:26.925 556 556 I chatty : uid=1000(system) hwservicemanage identical 14 lines
10-07 11:43:26.928 556 556 W hwservicemanager: getTransport: Cannot find entry vendor.qti.hardware.servicetracker#1.0::IServicetracker/default in either framework or device manifest.
10-07 11:43:26.930 7529 7529 D BoundBrokerSvc: onUnbind: Intent { act=com.google.android.gms.feedback.internal.IFeedbackService dat=chimera-action:com.google.android.gms.feedback.internal.IFeedbackService cmp=com.google.android.gms/.chimera.GmsBoundBrokerService }
10-07 11:43:27.481 827 827 I ConfigStore: android::hardware::configstore::V1_0::ISurfaceFlingerConfigs::hasHDRDisplay retrieved: 0
10-07 11:43:27.483 827 827 I chatty : uid=1000(system) /system/bin/surfaceflinger identical 2 lines
10-07 11:43:27.484 827 827 I ConfigStore: android::hardware::configstore::V1_0::ISurfaceFlingerConfigs::hasHDRDisplay retrieved: 0
10-07 11:43:27.780 1170 1170 I HSMCOUNTER: Wrote to EEPROM: ret: 0
10-07 11:43:28.444 827 827 I ConfigStore: android::hardware::configstore::V1_0::ISurfaceFlingerConfigs::hasHDRDisplay retrieved: 0
So it is showing some context of a ConfigStore, but nothing that indicates the "intent" action that other activities are capturing such as when the USB device is connected such as:
10-07 12:05:15.068 1512 1828 I ActivityManager: START u0 {act=android.hardware.usb.action.USB_DEVICE_ATTACHED flg=0x11000000 cmp=com.gemalto.gempcsc.gempcscserviceactivity/com.gemalto.gempcsc.gempcscservice.USBBroadcastReceiver (has extras)} from uid 1000
Additionally, if there is a generic way to capture ALL intents going on vs having to manually add all filters and not even knowing what they all COULD be, might help me narrow it down.

You need to talk to the reader using the CCID protocol. See my previous answer.
For example (sequence numbers in bold):
Send PC_to_RDR_GetSlotStatus (message 0x65 for slot 0):
-> 65000000000000000000
And receive RDR_to_PC_SlotStatus (message 0x81):
Example response for no card present:
<- 81000000000000020000
Example response for inserted unpowered card
<- 81000000000000010000
Below is a base-64 encoded wireshark USB trace detecting card in a GemPC Twin Reader(decode it to binary file and open it in Wireshark, then right-click any packet and select "Decode As...", change to "USB Device" tab, select "USBCCID" protocol and click "OK"):
-----BEGIN PCAP-NG CAPTURE FILE-----
H4sIAAAAAAAAA+Pi5eWSYWBg8LXRlmIE0v+hACQG4usA8R0GEGBhYGJgZygtTsrNzzNg4ATKsjFA
AEgNiJ0D5X96xcrA/SrFzgvIBmGGA9Pfnpn0/38wM5MCI4Muw8opHskg4dO6rAy9QLu4gGwuBtwg
FYmdg8WumteYdjkzN6HYZaPPClaP0y4mCNWIxMNml7LHFLhdB8S6FiH7aw3ULuWjbCT4iw2nvxZ7
YtoF8xfMrsXH2EjwFxsjzC5WNLsi2HztGRlkGJzzS/NKUouKFQqK8ssyU1JTFJIqFVJKcwuSEwuY
GDjAas8cN7NjhrIDgPpYgOwUZohZrEA2MgDZAQDbbEGJZAIAAA==
-----END PCAP-NG CAPTURE FILE-----
(Note: Sequence numbers in capture file have holes as packets are extracted from a longer dump)

System.TimeoutException being Thrown when Attempting to Write to Holding Registers using NModbus

I'm attempting to write a Modbus master program in C# that writes values into the holding registers of a single slave device over a RTU serial connection.
void SerialTimerTick(object sender, EventArgs e) {
_sp.WriteLine(inputText.ToString());
slaveAddress = (byte)slaveAddressNumericUpDown.Value;
startAddress = (ushort)startAddressNumericUpDown.Value;
registerAddress = (ushort)registerNumericUpDown.Value;
targetRegisterValue = (ushort)targetValueNumericUpDown.Value;
modbusMaster.WriteSingleRegister(slaveAddress, registerAddress, targetRegisterValue);
SerialTimer.Enabled = false;
sendButton.Enabled = true;
}
The problem is that when I attempt to send the write request to the slave, I get the following error:
System.TimeoutException: The operation has timed out.
which happens after the program outputs these numbers to the debug console in SharpDevelop three times, indicating three attempts:
254
120
128
34
32
25
To fix it, I've tried using break points to diagnose the problem, and it appears that NModbus is expecting some kind of ACKNOWLEDGE response from the slave in order to confirm that the data was sent correctly, only no such response is given.
When I look at my slave's communications feed, I see that something is happening on the slave's end when both the master and slave applications are running and my computer is connected to itself using two USB to Serial adapters:
Port COM 3 opened.
Port I/O buffers configured.
Port configured 256000,8,N,1
Timeouts configured (100ms/500ms)
Modem status : [CTS_][DSR_RING_]
RX: 0D 0A 0A 06 00 01
RX: 00 01 19 CA
RX: 01 06 00 01 00 01
RX: 19 CA
RX: 01 06 00 01 00 01
Instead, what I expected is for the first attempt to succeed and for the 40001 register to change its value from zero to one. I've tried changing NModbus versions, I've tried messing with the timeout and attempt settings of the IModbusMasterobject and I've also tried removing the exception entirely, which seems to be the only way I've gotten the program to work correctly, however this isn't an acceptable solution in my case.
The only thing I haven't tried so far is changing the slave application I'm using, which is currently the free PLC Simulator, which is written in C++ and not C#. This might be part of the problem, but I'm not sure.
I've only been using Modbus for a few weeks, and am working with a rather old version of the NModbus library. Any help would be much appreciated.

I haven't used NModbus, but I have written my own Modbus "stack" in C++ and C# so this answer is based more on my experience with Modbus than on how NModbus works.
There should be a response from Modbus commands EXCEPT when broadcasted (slave address 0). It should be normal operation for Modbus code to send the request and wait for a response. If the response is not received in a some specified amount of time, I would expect a timeout error.
Looking at the modbus spec; the write single register function should have an identical request and response ADU (if successful). It sounds like you are trying to write slave address 1 register 1 with a value 1. In that case, both the request response ADUs should be "01 06 00 01 00 01 19 CA" ("19 CA" is the correct CRC for this PDU). I do see what could be data from a request or response, but there seems to be something interfering:
RX: 0D 0A (NOT SURE WHAT THIS DATA IS FROM)
RX: 0A 06 00 01 00 01 19 CA (LOOKS CLOSE, BUT ADDRESS IS WRONG)
RX: 01 06 00 01 00 01 19 CA (LOOKS CORRECT)
RX: 01 06 00 01 00 01 (LOOKS CORRECT, BUT INCOMPLETE)
Just to test, try a much slower baud rate (9600) and use even parity. Some USB to Serial converters have driver parameters that can be tweaked. Do you have termination enabled on both converters (first and last devices terminated)? Is there a way to configure the NModbus response timeout?

c# SerialPort: how to send "0 byte" transfers (AKA ZLP: zero length packet)?

I've done some playing around with SerialPort (frustratingly so) and have finally hit a point where I absolutely have no idea why this isn't working. There's a USB CDC device that I'm trying to send hex commands to, the way I'm doing this is over the COM port interface it exposes. I can handshake with the device, when I say HI it replies with HI back, but then I send another command to it which must be followed by a zero byte packet or else the device stops responding altogether. Keep in mind, this zero byte packet has ABSOLUTELY nothing in it, meaning it doesn't have a \0 or a 0x00 or 0 or even a null (SerialPort throws an exception on null).
Now, one way I was able to circumvent this was to use libusbdotnet. I accessed the CDC device directly instead of the COM interface, set the endpoints correctly and sent hex commands like that. I'm able to successfully send "0 byte" packets using this method with the following c# code:
string zlpstring = "";
byte[] zlpbyte = Encoding.Default.GetBytes(zlpstring);
....snip
ecWrite = writer.SubmitAsyncTransfer(zlpbyte, 0, zlpbyte.Length, 100, out usbWriteTransfer);
zlpbyte is the buffer, 0 is the offset, zlpbyte.Length is the packet length in bytes, 100 is the timeout, and out usbWriteTransfer is the transfer context.
When I use this same method on the COM port:
string zlpstring = "";
byte[] zlpbyte = Encoding.Default.GetBytes(zlpstring);
_serialPort.Write(zlpbyte, 0, zlpbyte.Length);
the USB logger reports that absolutely nothing was sent. It's as if the COM port is ignoring the zero byte transfer. Before it's mentioned that "you cannot do this", there's various programs out there that can send a zero-byte packet to this exact device's COM port without doing ANY driver manipulation. This is what I'm going for, which is why I'm trying to ditch libusbdotnet and go straight to the COM port.
EDIT:
After some more toying around and a different USB logger I don't find zero bytes being sent but rather this:
IRP_MJ_DEVICE_CONTROL (IOCTL_SERIAL_WAIT_ON_MASK)
I think this may be the issue. If a 0 byte was being sent then I assume it would show up as:
IRP_MJ_WRITE > UP > STATUS_SUCCESS > (blank) > (blank)
My program is sending back a response of 01 00 00 00, however while logging another successful program it's SETTING the wait mask:
IRP_MJ_DEVICE_CONTROL (IOCTL_SERIAL_SET_WAIT_MASK) DOWN STATUS_SUCCESS 01 00 00 00
If my assumptions are right, this question might've just turned into how do I set a serial port's/COM port's wait mask? There's absolutely nothing about this in the c# SerialPort class...which is why I can now see why so many articles called it "lacking". I also took a look around c++: https://msdn.microsoft.com/en-us/library/aa363214(v=vs.85).aspx this also does not seem to cover the wait mask. Using the USB filter libusb is starting to look a lot more pleasing each minute...(although I'm going to question myself forever why sending a zero byte works there but it doesn't over SerialPort).
SECOND EDIT:
I'm a moron. It was definitely a setting that the manufacturer probably didn't figure anyone would ever touch nor know how to set:
#define EV_RXFLAG 0x0001
SetCommMask(hSerial, EV_RXFLAG);
I then saw this over the USB logs:
IRP_MJ_DEVICE_CONTROL (IOCTL_SERIAL_SET_WAIT_MASK) DOWN STATUS_SUCCESS 01 00 00 00
Bingo. The RXFLAG was originally set to 0x0002. I couldn't find a way to change this in C# yet. So I had to do with some C++ code for now. It totally works, and sends the "zero byte" like it's supposed to without me actually sending it from the code. This setting I assume was the "handshake" method between my device and whatever else it's interacting with in Flash mode. Hope this helps someone else out there whose COM/Serial device is rejecting/discarding zero byte packets yet requiring ZLP at the same time...how goofy?!

have you tried to concatenate an extra new line or carriage return or both at the end of the data?
I would say add a 0xA (new line), or 0xD (carriage return), or both 0xA and 0xD to the end of your byte array and see if you get something.
byte[] zlpbyte = new byte[1] {0};
_serialPort.Write(zlpbyte, 0, 1);
[Update]
Based on our discussions, it appears that you are trying to have control over the control signals of the serial port. I have not tried it before but I can see that it is possible to set the control signals (if i understand the source properly) into certain states.
Try to set the Handshake property
public enum Handshake
{
None,
XOnXOff,
RequestToSend,
RequestToSendXOnXOff,
}
I am not sure exactly how it affects the IOCTL settings but it should be able to affect it somehow I believe

Messages getting overwritten on IBM MQ

I am sending 3 messages
Message1 - correlation id:5000
empty message (no body/message)-correlation id:5001
Message2 - correlation id:5002
My outbound queue processes like this
Message1 - correlation id:5000
Message1-correlation id:5001 => same previous message ovewritten on the empty message.*
Message2 - correlation id:5002
The second line above should not have had Message1, instead just empty. Any thoughts?
My get method
mqGetMsgOpts = new MQGetMessageOptions();
if (mqQueue != null)
{
//Get options for the messsage
mqGetMsgOpts.Options = MQC.MQGMO_BROWSE_FIRST | MQC.MQGMO_WAIT | MQC.MQOO_INQUIRE;
mqGetMsgOpts.MatchOptions = MQC.MQMO_NONE;
mqGetMsgOpts.WaitInterval = 5000; // 5 seconds limit for waiting
}
if (mqMsg.MessageLength > 0 && mqMsg.DataLength > 0)
{
messageData = mqMsg.ReadString(mqMsg.MessageLength);
}
If I don't do the length check, i will get stream reader related exception.
My put method
if(mqQueue==null)
mqQueue = mqQMgr.AccessQueue("Queue Name", MQC.MQOO_OUTPUT | MQC.MQOO_INPUT_SHARED | MQC.MQOO_INQUIRE);
mqMsg.WriteString(message);

I have not heard messages getting overwritten in WMQ. I suspect this must be an issue with application. This line of code:
mqGetMsgOpts.Options = MQC.MQGMO_BROWSE_FIRST | MQC.MQGMO_WAIT | MQC.MQOO_INQUIRE;
The MQC.MQGMO_BROWSE_FIRST option will make WMQ to return always the first message that satisfies the conditions specified in MQMD structure. I can't make out from your code snippet if this option is modified at a later point to specify MQGMO_BROWSE_NEXT to read the next message in the queue.
Instead of MQC.MQGMO_BROWSE_FIRST you can specify MQGMO_BROWSE_NEXT option to continuously read messages.
Also you have specified MQC.MQOO_INQUIRE which is not valid for GMO options. You need to remove that.
More details browse options are here

I can imagine two possible issues that could cause this.
Your putting application did not send an empty message body for message two.
Your getting application is showing you the message buffer from message one. If there is no message buffer delivered from MQ, your previous message buffer contents will remain.
To determine which has happened to you I suggest you put all the messages, but before running your sample to get them, instead run something like the supplied sample amqsget to rule out the possibility of 1.
Then you can focus on the get buffer in your application. Make sure you are not using it if MQ said the length of the returned message is zero.

Ingenico 6550 won't display signature box

I'd call Ingenico's tech support, but I don't have a month to wait for their callback.
Our app uses the 6550 and it displays all the forms just fine except, on one machine it's not showing the signature box on the signature capture form. It shows the buttons and text just fine.
I've tried using our app, I've tried the Ingenico test app. Everything seems to check out fine. The only thing I get in th log is this:
2/17/2011 8:43:33 AM (31813 ms) EC0000 Device name [Ing6XXX] - UPOS-Interface-App error code=0xFD
It's followed by these lines after I dismiss the form:
2/17/2011 8:43:33 AM (31860 ms) EC0000 Device name [Ing6XXX] - Last platform error code from device=0x2, desc=SingleButtonEntry: ssaSecFuncKe
2/17/2011 8:43:33 AM (31860 ms) EC0111 Device name [Ing6XXX] - SIG - Direct IO - Command 12 - Invalid command, or function code missing. Length 5 [Package {00 05 95 FD 6D}] [Translation {iDataLength 0}{ucFunctionCode 95}{ucResponseCode FD}{ucResultCode 6D}{sData }]
2/17/2011 8:43:33 AM (31860 ms) EC0111 Device name [Ing6XXX] - SO APP - Direct IO - Command 12 - Invalid command, or function code missing. Length 5 [Package {00 05 95 FD 6D}] [Translation {iDataLength 0}{ucFunctionCode 95}{ucResponseCode FD}{ucResultCode 6D}{sData }]
I'm not sure if that's related. Does anyone have experience with these things. Any idea what might cause the failure to display the signature box?

The problem turned out to be a missing registry setting for the form location. Not sure how we missed that.