mvogt1's Posts

The isue is gone. I had this when RealTime Audio was not setup correctly. Chrome worked (withouth audio of course, but with video) and firefox did not show any video, which was possible a side effec... See more...
The isue is gone. I had this when RealTime Audio was not setup correctly. Chrome worked (withouth audio of course, but with video) and firefox did not show any video, which was possible a side effect of the non working audio channel. Thus, as soon as realtime audio was setup and worked, firefox worked too (video and audio)    
I'm using RedHat el 9.2, and build the kernel module according to Install V4L2 loopback driver and build with the Real-Time-Audio extension . I modified /etc/vmware/config to:   RTAV.logLevel=trac... See more...
I'm using RedHat el 9.2, and build the kernel module according to Install V4L2 loopback driver and build with the Real-Time-Audio extension . I modified /etc/vmware/config to:   RTAV.logLevel=trace VVC.RTAV.WebcamMaxFrameRate=15 VVC.RTAV.WebcamMaxResWidth=1920 VVC.RTAV.WebcamMaxResHeight=1080 VVC.RTAV.WebcamDefaultResWidth=1280 VVC.RTAV.WebcamDefaultResHeight=720     In the log file /tmp/vmware-vmwblast/vmware-RTAV-XYZ.log:   RTAV: virtual void FFmpegDecoder::GetConfiguration() - forceQSV: 0, forceNV: 1, threads: 1 HostCPUs: 4 mThreadCounts: 1 RTAV: static DWORD ConfigSettings::GetDWORD(std::string, DWORD) - key='rtav.h264_loglevel' default=8 RTAV: virtual bool FFmpegDecoder::InitFFmpegDecoder(): enable Nvidia hardware acceleration decoder In(05) host-21552 RTAV: OnRecvData - Recv - DataLen=11779 QLen=0 In(05) host-23689 RTAV: Decode: mDecParams (wxh) = (1280,720) In(05) host-23689 RTAV: Decode: mFrame (wxh) = (1280,720), format = 98 In(05) host-23689 RTAV: Decode: mFrame->linesize(0,1,2) = (0,0,0) In(05) host-23688 RTAV: static bool MediaPlayerLinux::VdoServiceThreadCB(void*, VMWThread*) - Play Video: New data arrival notification received In(05) host-23688 RTAV: SendImgData: Write data 1843200     Thus it works, 11779 bytes h264 video frame come in and gets decoded in HW to 1843200 bytes (YUV,RGB who knows), But this does only work with google-chrome. It does not work with firefox Firefox and Google share the same webrtc implementation, the one from google https://webrtc.googlesource.com/src/ and of course firefox works in these scenarios local webcam with firefox Virtual Channel webcam windows_client -> windows_agent The Virtual Channel webcam windows_client -> linux_agent does not work. ==> Therefore I suspect the kernel loopback interface does not support everything which firefox calls. Anyone have tried to enable ioctl debugging or have a patch?      
  I try to use the smartcard with el9, it looks okay up to now. But the issue since 2019 is still present. If no-one is logged it blocks in libpcsclite, this accumulates e.g. cron jobs which check... See more...
  I try to use the smartcard with el9, it looks okay up to now. But the issue since 2019 is still present. If no-one is logged it blocks in libpcsclite, this accumulates e.g. cron jobs which checks for updates. I posted the problem already here Trouble-with-VMware-Smartcard-support/  The patch is to not block if no one is logged in. This shoud be done on a different layer and faster than with "system", given that vmware replaces pcscd and pcscd should know if serialisation (MS-RDPESC) can work. But with this patch it works. (You need to compile libpcsclite with the same compiler optione as in el9)        
  It looks like Agent 8.8 replaces pcscd with something new, maybe based on 1.8.23 ? Issues: - my applications hangs sometimes (pkcs11-tool -L) - firefox hangs sometimes Anyone having the same ... See more...
  It looks like Agent 8.8 replaces pcscd with something new, maybe based on 1.8.23 ? Issues: - my applications hangs sometimes (pkcs11-tool -L) - firefox hangs sometimes Anyone having the same issues?
  Attached is a rather long log, which is reduced to "host 7400" and there only the last part from the last BEGIN_TRANSATCTION: SCARD_IOCTL_BEGINTRANSACTION, completionID=0000120f, ioStatus=000000... See more...
  Attached is a rather long log, which is reduced to "host 7400" and there only the last part from the last BEGIN_TRANSATCTION: SCARD_IOCTL_BEGINTRANSACTION, completionID=0000120f, ioStatus=00000000 to the last Transmit (when the channel dies) It ends with: ScRedirVvc_DumpMsg():1053: Entry 72 44 Header->RDPDR_CTYP_CORE = 0x4472 43 49 Header->PAKID_CORE_DEVICE_IOCOMPLETION = 0x4943 ScRedirVvc_DumpMsg():1096: Exit ERROR(c0000023) | 7400|: Incorrect IO completion status ScRedirVvc_ParseIOCompletion():1473: Exit ERROR(c0000001) | 7400|: Failed to parse IO completion message But there is no dump from the failed completion message, which is the interesting part. ScRedirVvc_RedirectScResponse():2025: Exit ERROR(c0000001) | 7400|: Failed to redirect SC IO completion packet ScRedirVvc_HandleRequests():2159: Exit        
>When freeze, can you dump the APDU that SCARD_TRANSMIT command sends out but fail to get response? >Is it "00 CB 3F FF 03 5C 01 7E" ? It seems vmware patched pcscd so it does not log anymore apdu ... See more...
>When freeze, can you dump the APDU that SCARD_TRANSMIT command sends out but fail to get response? >Is it "00 CB 3F FF 03 5C 01 7E" ? It seems vmware patched pcscd so it does not log anymore apdu commands. I started pcsd with --foreground --apdu --debug  and there are no apdus. I grepped through the log file for "rv=", which seems the only option to look for errors. Here is the only part which looks suspicious: 00000022 winscard_svc.c:641:ContextThread() BEGIN_TRANSACTION rv=0x0 for client 7 00000036 winscard_svc.c:793:ContextThread() TRANSMIT rv=0x0 for client 7 00000030 winscard_svc.c:793:ContextThread() TRANSMIT rv=0x0 for client 7 00000027 winscard_svc.c:793:ContextThread() TRANSMIT rv=0x0 for client 7 00000034 winscard_svc.c:793:ContextThread() TRANSMIT rv=0x0 for client 7 00000027 winscard_svc.c:661:ContextThread() END_TRANSACTION rv=0x0 for client 7 00000005 winscard_svc.c:493:ContextThread() CMD_STOP_WAITING_READER_STATE_CHANGE rv=0x0 for client 7 00000005 winscard_svc.c:493:ContextThread() CMD_STOP_WAITING_READER_STATE_CHANGE rv=0x0 for client 7 00000013 winscard_svc.c:493:ContextThread() CMD_STOP_WAITING_READER_STATE_CHANGE rv=0x0 for client 7 00000013 winscard_svc.c:493:ContextThread() CMD_STOP_WAITING_READER_STATE_CHANGE rv=0x0 for client 7 00000005 winscard_svc.c:493:ContextThread() CMD_STOP_WAITING_READER_STATE_CHANGE rv=0x0 for client 7 00000011 winscard_svc.c:493:ContextThread() CMD_STOP_WAITING_READER_STATE_CHANGE rv=0x0 for client 7 00000013 winscard_svc.c:493:ContextThread() CMD_STOP_WAITING_READER_STATE_CHANGE rv=0x0 for client 7 00000019 winscard_svc.c:493:ContextThread() CMD_STOP_WAITING_READER_STATE_CHANGE rv=0x0 for client 7 00000005 winscard_svc.c:493:ContextThread() CMD_STOP_WAITING_READER_STATE_CHANGE rv=0x0 for client 7 00000004 winscard_svc.c:493:ContextThread() CMD_STOP_WAITING_READER_STATE_CHANGE rv=0x0 for client 7 00000005 winscard_svc.c:493:ContextThread() CMD_STOP_WAITING_READER_STATE_CHANGE rv=0x0 for client 7 00000017 winscard_svc.c:493:ContextThread() CMD_STOP_WAITING_READER_STATE_CHANGE rv=0x0 for client 7 00000013 winscard_svc.c:493:ContextThread() CMD_STOP_WAITING_READER_STATE_CHANGE rv=0x0 for client 7 00000015 winscard_svc.c:493:ContextThread() CMD_STOP_WAITING_READER_STATE_CHANGE rv=0x0 for client 7 00000015 winscard_svc.c:493:ContextThread() CMD_STOP_WAITING_READER_STATE_CHANGE rv=0x0 for client 7 00000014 winscard_svc.c:493:ContextThread() CMD_STOP_WAITING_READER_STATE_CHANGE rv=0x0 for client 7 00000005 winscard_svc.c:493:ContextThread() CMD_STOP_WAITING_READER_STATE_CHANGE rv=0x0 for client 7 00000013 winscard_svc.c:493:ContextThread() CMD_STOP_WAITING_READER_STATE_CHANGE rv=0x0 for client 7 00000030 winscard_svc.c:641:ContextThread() BEGIN_TRANSACTION rv=0x0 for client 7 00000048 winscard_svc.c:793:ContextThread() TRANSMIT rv=0x0 for client 7 00000038 winscard_svc.c:793:ContextThread() TRANSMIT rv=0x0 for client 7 00000025 winscard_svc.c:661:ContextThread() END_TRANSACTION rv=0x0 for client 7 00000016 winscard_svc.c:493:ContextThread() CMD_STOP_WAITING_READER_STATE_CHANGE rv=0x0 for client 7 00000020 winscard_svc.c:622:ContextThread() DISCONNECT rv=0x0 for client 7 00000019 winscard_svc.c:530:ContextThread() RELEASE_CONTEXT rv=0x0 for client 7 00000009 winscard_svc.c:440:ContextThread() CMD_VERSION rv=0x0 for client 7 00000055 winscard_svc.c:511:ContextThread() ESTABLISH_CONTEXT rv=0x0 for client 7 00000002 winscard_svc.c:440:ContextThread() CMD_VERSION rv=0x0 for client 8 00000109 winscard_svc.c:511:ContextThread() ESTABLISH_CONTEXT rv=0x0 for client 8 00000012 winscard_svc.c:493:ContextThread() CMD_STOP_WAITING_READER_STATE_CHANGE rv=0x0 for client 8 00000042 winscard_svc.c:577:ContextThread() CONNECT rv=0x0 for client 7 00000008 winscard_svc.c:840:ContextThread() CONTROL rv=0x80100004 for client 7 00000005 winscard_svc.c:840:ContextThread() CONTROL rv=0x80100004 for client 7 00000035 winscard_svc.c:622:ContextThread() DISCONNECT rv=0x0 for client 7 00000030 winscard_svc.c:577:ContextThread() CONNECT rv=0x80100069 for client 7 00000031 winscard_svc.c:577:ContextThread() CONNECT rv=0x0 for client 7 00000006 winscard_svc.c:840:ContextThread() CONTROL rv=0x80100004 for client 7 00000007 winscard_svc.c:840:ContextThread() CONTROL rv=0x80100004 for client 7 00000024 winscard_svc.c:622:ContextThread() DISCONNECT rv=0x0 for client 7 00000002 winscard_svc.c:950:MSGSignalClient() SIGNAL rv=0x0 for client 8 00000003 winscard_svc.c:440:ContextThread() CMD_VERSION rv=0x0 for client 9    
>What kind of smart card and driver do you use? I have a PIV card, below is the command output: Thanks for your reply. The driver is from cryptovision a read only driver for StarCos. Version scinter... See more...
>What kind of smart card and driver do you use? I have a PIV card, below is the command output: Thanks for your reply. The driver is from cryptovision a read only driver for StarCos. Version scinterface-8.0.1-1.x86_64. You are right, if I remove the module from firefox it starts fine. Now its easy to say contact your pkcs11 driver vendor". I did that. But its turns out that the driver works "locally" fine and even with horizon windows->windows connection. (Okay some error pops up), but overall it works. But under Linux it freezes. Thus its both, the driver and the Smartcard virtual Channel extension and on top of that: It freezes only with Linux. My assumption is that it's the Smart Card virtual channel extension, which triggers the behavior, maybe in combination with some unhandled return code in the pkcs11 driver, or something else. On the pcscd side I see only endless SCARD_TRANSMIT but never a reply from the "marshalling" layer. The Vitual Channel implements this: https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-rdpesc/65c30c99-e816-48b6-9293-8d467b10cc39 but its possible that the the problem happens on the IRP layer too, but this is only an assumption.    
I have noticed that Linux firefox does not start anymore if I add "Windows Hello". (The same is true for thunderbird) Setup: - rhel 7.9 Agent version: 8.6 - win10 vmware-view version: 2206/8.6 ... See more...
I have noticed that Linux firefox does not start anymore if I add "Windows Hello". (The same is true for thunderbird) Setup: - rhel 7.9 Agent version: 8.6 - win10 vmware-view version: 2206/8.6 Under Linux the smartcard slots looks like: [vogt]$ pkcs11-tool -L Available slots: Slot 0 (0x0): Alcor Micro USB Smart Card Reader 0 (empty) Slot 1 (0x4): Microsoft IFD 0 (empty) Slot 2 (0x8): Windows Hello for Business 1 token label : UserPIN (GIDS card) token manufacturer : www.mysmartlogon.com token model : PKCS#15 emulated token flags : login required, token initialized, PIN initialized hardware version : 0.0 firmware version : 0.0 serial num : 4d8e5bbcf2badc3b pin min/max : 4/15 If I remove smartcard support from Linux firefox, or remove "Windows Hello" from Windows, my Linux firefox starts as expected. This can be reproduced with: - create "Windows Hello" slot - check that its exported with "pkcs11-tool -L" - start firefox and verify that its not working - stop firefox (CTRL-C) - Keep Horizon session open - Open cmd.exe and type: - certutil.exe -DeleteHelloContainer After that you can verify on Linux that slot2 ist gone. Now start Linux firefox. ==> firefox works again It's unclear if it's firefox or the VMware Virtual channel extension which causes this behaviour. When I enable pcscd logging I see countless SC_CARD_TRANSMIT but no replies, so it may be helpfull do enable IRP smartcard debugging, but this changed in vmware horizon from the last time I had a problem with it: https://communities.vmware.com/t5/Horizon-for-Linux/Smartcard-on-Linux-clients-firefox-does-not-start/m-p/2840682    
  After some experiments I found out: - If the login is successfull you need to logout from the rest API otherwise you will soon get out of "handles" etc and login does not work anymore.      
  I think, I'm hitting a rate limit in the rest API and there is no documentation about it. I run on a host while true; do check_some_value_with_rest_api.py sleep 1 done   This works for maybe... See more...
  I think, I'm hitting a rate limit in the rest API and there is no documentation about it. I run on a host while true; do check_some_value_with_rest_api.py sleep 1 done   This works for maybe a minute or so. After that I get 401 Forbidden. If I stop the script, wait a minute it works, a few times, but not as many times as before. For me it looks like a "rate" limitation, but I cannot find documentation about it.
The problem goes away with a newer agent version. eg: Agent 8.4 works with view client 8.4. But Agent 8.0 does not work with client 8.4 (8.3.1 client is the latest which works with agent 8.0)
  Hello, I noticed that the current horizon client does not export its screen over eg. MS Teams. You only get a black screen. Steps to reproduce: - Use windows with 8.4.0 client - connect with ... See more...
  Hello, I noticed that the current horizon client does not export its screen over eg. MS Teams. You only get a black screen. Steps to reproduce: - Use windows with 8.4.0 client - connect with it to a linux desktop - Share the linux desktop with eg. MS Teams with coworker "Bob". Result: - Bob does not see the linux desktop, only a black screen It works with Horizon client 8.3.0.
After a windows re-install the problem is gone. This demo program showed it with runtimes of around 10 seconds and sometime more, but because it was not reproducible and only happend on my machine,... See more...
After a windows re-install the problem is gone. This demo program showed it with runtimes of around 10 seconds and sometime more, but because it was not reproducible and only happend on my machine, its gone now. After a windows re-install.
Hello, since last year, the smartcard support from the vmware view client is unusable. Firefox does not start, thunderbird or other smartcard apps hang. This happens when the windows version of ... See more...
Hello, since last year, the smartcard support from the vmware view client is unusable. Firefox does not start, thunderbird or other smartcard apps hang. This happens when the windows version of the vmware view client is used. The attached demo program show this behaviour. Its from: https://github.com/LudovicRousseau/PCSC/blob/master/doc/example/pcsc_demo.c The demo should runs in less than a seconds, and needs an insterted smartcard. It only queries basic reader calls from the PCSC API "winscard". Here are some benchmarks. (linux->linux works fine) Horizon client remote OS (time) linux linux 0.2sek (good!) windows linux 20secs linux windows (does not work) windows windows 90secs (hangs sometimes)   RDP sessions (windows client to windows Server) is fast too, with around 2 secs. As a result, the windows horizon client to a linux machine is not usable with VMWare Horizon and firefox/mozilla. The demo only issues a few calls, where firefox will issue thousands of them. Attached program contains pre-build binaries and source code.  
  VMware fixed this bug. The fix should appear in the next major update VMware-Horizon-Client-2103-8.2.0
Debugging. On the Linux Thinclient the horizon client version is 5.4. On a RHEL 7.8 the horizon client ist version 5.2. On the RHEL client the problem does not occur. No, the problem exists... See more...
Debugging. On the Linux Thinclient the horizon client version is 5.4. On a RHEL 7.8 the horizon client ist version 5.2. On the RHEL client the problem does not occur. No, the problem exists on 5.2 too. [root@e120it00 ~]# ps -o thcount 5066 THCNT    22 [root@e120it00 ~]# ps -o thcount 5066 THCNT   204 [root@e120it00 ~]# date Fri Oct 23 09:21:33 CEST 2020 [root@e120it00 ~]# vmware-view --version | grep Client | grep VMware VMware Horizon Client 5.2.0 The above commands are from a RHEL 7.8 client connected with VMWare Horizon Client 5.2.0 to a RHEL 7.8 VM with Agent 7.10
Debugging. [root@e120it00 ~]# ps -o thcount 13523 THCNT    12 hours passed> [root@e120it00 ~]# ps -o thcount 13523 THCNT   179 This happens on a RHEL 7.8 connected to a VM ov... See more...
Debugging. [root@e120it00 ~]# ps -o thcount 13523 THCNT    12 hours passed> [root@e120it00 ~]# ps -o thcount 13523 THCNT   179 This happens on a RHEL 7.8 connected to a VM over Horizon with RHEL 7.8 with Agent 7.10 and Client 5.4.1. ==> bug is present on newest vmware-view.
Debugging. On the Linux Thinclient the horizon client version is 5.4. On a RHEL 7.8 the horizon client ist version 5.2. On the RHEL client the problem does not occur. I have written two scrip... See more...
Debugging. On the Linux Thinclient the horizon client version is 5.4. On a RHEL 7.8 the horizon client ist version 5.2. On the RHEL client the problem does not occur. I have written two scripts running in the background on the thinclient. The scripts counts the number of threads in pcscd and the number of open sockets of vmware-remotemks. It shows that the number of threads increase with no real pattern. But te thread increase has a counterpart in the vmware-remotemks sockets count. while true; do   A=`date`;   B=`ps -o thcount $PID_PCSCD`;   echo "$A : $B" >>/var/tmp/threads.txt;   sleep 30; done Thu Oct 15 16:21:07 CEST 2020 : THCNT  9 Thu Oct 15 16:26:05 CEST 2020 : THCNT  18 Thu Oct 15 16:27:23 CEST 2020 : THCNT  21 Thu Oct 15 16:55:54 CEST 2020 : THCNT  30 Thu Oct 15 16:56:24 CEST 2020 : THCNT  29 Thu Oct 15 16:56:54 CEST 2020 : THCNT  33 Thu Oct 15 17:09:54 CEST 2020 : THCNT  47 Thu Oct 15 17:10:24 CEST 2020 : THCNT  52 Thu Oct 15 17:25:55 CEST 2020 : THCNT  61 Thu Oct 15 17:26:55 CEST 2020 : THCNT  64 Thu Oct 15 17:31:55 CEST 2020 : THCNT  63 Thu Oct 15 17:32:25 CEST 2020 : THCNT  64 Thu Oct 15 17:55:56 CEST 2020 : THCNT  73 Thu Oct 15 17:56:56 CEST 2020 : THCNT  76 Thu Oct 15 17:57:26 CEST 2020 : THCNT  79 Thu Oct 15 18:14:57 CEST 2020 : THCNT  98 Thu Oct 15 18:25:57 CEST 2020 : THCNT  107 Thu Oct 15 18:26:57 CEST 2020 : THCNT  110 Thu Oct 15 18:42:58 CEST 2020 : THCNT  109 Thu Oct 15 18:43:28 CEST 2020 : THCNT  110 Thu Oct 15 18:55:59 CEST 2020 : THCNT  119 Thu Oct 15 18:56:59 CEST 2020 : THCNT  122 Thu Oct 15 19:11:59 CEST 2020 : THCNT  141 Thu Oct 15 19:26:00 CEST 2020 : THCNT  150 Thu Oct 15 19:27:00 CEST 2020 : THCNT  153 Thu Oct 15 19:55:31 CEST 2020 : THCNT  162 Thu Oct 15 19:57:01 CEST 2020 : THCNT  165 Thu Oct 15 20:05:31 CEST 2020 : THCNT  181 Thu Oct 15 20:16:32 CEST 2020 : THCNT  180 Thu Oct 15 20:17:02 CEST 2020 : THCNT  181 Thu Oct 15 20:26:02 CEST 2020 : THCNT  190 Thu Oct 15 20:27:02 CEST 2020 : THCNT  193 Thu Oct 15 20:52:03 CEST 2020 : THCNT  192 Thu Oct 15 20:55:04 CEST 2020 : THCNT  193 Thu Oct 15 20:56:04 CEST 2020 : THCNT  201 Thu Oct 15 20:57:04 CEST 2020 : THCNT  205 while true; do   A=`date`;   B=`lsof -p $PIDOF_VMWARE_REMOTEMKS | grep remote | grep sock | wc -l`;   echo "$A : $B" >>/var/tmp/socket.txt;   sleep 30; done Thu Oct 15 16:28:01 CEST 2020 : 34 Thu Oct 15 16:54:02 CEST 2020 : 33 Thu Oct 15 16:54:32 CEST 2020 : 34 Thu Oct 15 16:55:32 CEST 2020 : 47 Thu Oct 15 16:56:02 CEST 2020 : 43 Thu Oct 15 16:57:02 CEST 2020 : 46 Thu Oct 15 17:10:33 CEST 2020 : 65 Thu Oct 15 17:25:34 CEST 2020 : 78 Thu Oct 15 17:26:04 CEST 2020 : 74 Thu Oct 15 17:27:04 CEST 2020 : 77 Thu Oct 15 17:29:34 CEST 2020 : 76 Thu Oct 15 17:30:04 CEST 2020 : 77 Thu Oct 15 17:55:35 CEST 2020 : 86 Thu Oct 15 17:57:05 CEST 2020 : 89 Thu Oct 15 17:57:35 CEST 2020 : 92 Thu Oct 15 18:14:36 CEST 2020 : 112 Thu Oct 15 18:15:06 CEST 2020 : 111 Thu Oct 15 18:18:06 CEST 2020 : 110 Thu Oct 15 18:18:36 CEST 2020 : 111 Thu Oct 15 18:26:07 CEST 2020 : 120 Thu Oct 15 18:27:07 CEST 2020 : 123 Thu Oct 15 18:53:38 CEST 2020 : 122 Thu Oct 15 18:54:08 CEST 2020 : 123 Thu Oct 15 18:55:38 CEST 2020 : 132 Thu Oct 15 18:57:08 CEST 2020 : 135 Thu Oct 15 19:11:39 CEST 2020 : 154 Thu Oct 15 19:25:40 CEST 2020 : 163 Thu Oct 15 19:27:10 CEST 2020 : 166 Thu Oct 15 19:42:11 CEST 2020 : 165 Thu Oct 15 19:55:12 CEST 2020 : 166 Thu Oct 15 19:56:12 CEST 2020 : 175 Thu Oct 15 20:05:42 CEST 2020 : 194 Thu Oct 15 20:25:43 CEST 2020 : 203 Thu Oct 15 20:26:44 CEST 2020 : 206 Thu Oct 15 20:55:45 CEST 2020 : 214 Thu Oct 15 20:56:45 CEST 2020 : 218 Thu Oct 15 21:06:16 CEST 2020 : 217
Hello, I cannot start thunderbird, firefox every morning, when I start my work day.The problem is smartcard related and only occurs on a Linux client. I have this behaviour usually when I go ... See more...
Hello, I cannot start thunderbird, firefox every morning, when I start my work day.The problem is smartcard related and only occurs on a Linux client. I have this behaviour usually when I go home in the evening and reconnect to a locked session in the morning What happens: Firefox and thunderbird do not start anymore, "sudo -s" or "pkcs11-tool -L"  command hangs. The VM, on which this happens, is a RedHat 7.8 with the necessary smartcard fixes see [1], otherwise SCard does not work at all. What needs to be done, for working SCard, is explained here: [1] https://communities.vmware.com/thread/613996 But SCard,firefox,thunderbird,... works fine, when connected to the VM from Windows clients! My VM runs: RHEL 7.8 with Horizon 7.9 or 7.10 ,windows clients works, no problem. What happens on the Linux Thinclient? pcscd is complaining: pcscdaemoni.c 137 SVServicerunLoop : Problem during the context thread creation winscard_svc.184 CreateContextThread Too many contex running 200 pcscdaeon.c 137:SVServicerunLoop Problem during the context thread creation When I look a the source: listSize = list_size(&contextsList); if (listSize >= contextMaxThreadCounter) {         Log2(PCSC_LOG_CRITICAL, "Too many context running: %d", listSize);         goto out; } So, after some time (evening to morning), something is using all context threads and this is the reason why firefox,thunderbird, pkcs11-tool -L ,etc.. hangs. Rebooting the Thinclient works, and moving the session to another hosts works too to let firefox,thunbird etc. run. Up to now, I cannot reproduce the bug, I must wait for it, for ~12 hours.
This was fixed in >= 7.10