It does work partially (!). For me it looks like, that the "back channel" in the vmware pcscd does not working correctly and libpsclite in RHEL drops the result, or waits for more data, to come....
See more...
It does work partially (!). For me it looks like, that the "back channel" in the vmware pcscd does not working correctly and libpsclite in RHEL drops the result, or waits for more data, to come. For debugging I'm using the command: >pkcs11-tool -L The output should be (depending on the reader type): >Slot 0 (0x0): Gemalto PC Twin Reader 00 00 When I strace the different components I can see, that the following works: But first, the setup: On the VDI host "v110" (the host to which I connect with vmware-view 4.10), I strace the pcscd from vmware. On the client "e120" (the host which starts vmware-wire and connects to "v110", I strace pcsd (from redhat) too. The sequence is: I connect from e120 with vmware-view and log into v110. There I open a terminal and start: >pkcs11-tool -L The strace on "v110" shows: 7700 write(1, "\33[36m00001019\33[0m bora/apps/rde/scrediragent/pcscd/winscard_svc.c::420:ContextThread() Received command: CMD_GET_READERS_STATE from client 9\n", 140) = 140 7700 write(1, "\33[36m00000201\33[0m \33[01;31mbora/apps/rde/scrediragent/pcscd/pcscd-ipc.c:337:IPCRequest() has received the connection from plugin\33[0m\n", 132) = 132 7700 select(8, NULL, [7], NULL, NULL) = 1 (out [7]) The important part is the CMD_GET_READERS_STATE, which is the command to list the readers. ("-L option") This is actually forwarded to "e120". There the pcscd log shows: [pid 7942] write(1, "\33[36m00010040\33[0m winscard_svc.c:317:ContextThread() Receive command: CMD_GET_READERS_STATE from client 12\n", 108) = 108 [pid 7942] select(13, NULL, [12], NULL, NULL) = 1 (out [12]) [pid 7942] sendto(12, "Gemalto PC Twin Reader 00 00............. And this is seen on the "v110" too: 4536 read(7, "\277\16M*\0\0\0\0\0\0\0\0\0\0\0\0\36\0\0\0Gemalto PC Twin Reader 00 00..." 7700 write(1, "\33[36m00001391\33[0m \33[01;31mbora/apps/rde/scrediragent/pcscd/pcscd-ipc.c:337:IPCRequest() has received the connection from plugin\33[0m\n", 132) = 132 7700 sendto(7, "\277\16M*\0\0\0\0\2\0\0\0\\\\?PnP?\\Notification\0%s:%d:%s() calloc failed.\0%s:%d:%s() return value 0x%x\n\0%s:%d:%s() rv = 0X%08X.\0\0\0\0\0\0\0\0\1\0 The answer "PNP\\Notification" looks suspicious, mostly because it contains the "calloc failed". PNP Notification is a part ofthe PCSC Protocoll for Status change messages, but it may be ok. When I now strace the binary pkcs11-tool I see [1]: read(3,Gemalto PC Twin Reader 00 00...",5888)=2944 Thus it ends in libpcsclite. But the binary does not "exit". Maybe this can be debugged with libpcscspy.so. As a result: pkcs11-tool -L issues a CMD_GET_READERS_STATE in libpcsclite [1], which forward it to the local pcscd on v110, which forward it to libscrediragent, which is part of the agent process and this paket is forwared to the vmware-view client on host "e120", which writes it into the local libpcsclite and this forwards it to the pcscd on e120. This daemon really knows whats going on, and its answer "Gemalto PC Twin Reader 00 00". This is passed the whole chain back, and end up in the pcscd on "v110". Then pcscd even writes it back into [1], but the binary does not exit and blocks forever. Edit: added missing colums (80+) from strace
