- This topic has 8 replies, 2 voices, and was last updated 7 years ago by
.
-
Posts
-
Has anyone/everyone here had good use cases with wireless? We’re utilizing D10DPs in some mobile carts, and the experience is a bit hit or miss. We’re still working with our wireless team on some tweaking, but, though I’d look to see if anyone else using WTOS on wireless feels it’s a good pairing.
The one issue we see fairly often, is a loss of input between the terminal, and the Horizon session it’s in. What I mean is, the mouse/keyboard will either have a delay in registering their input into the VM, or they’ll be hung completely, no input is registered at all until a terminal reboot. Even if I VNC into the problem terminal, I can move around/interact with ThinOS, but the VM will not receive anything. If I console to the VM through vCenter, I can, which verifies the VM isn’t hung up, it’s just a loss of connectivity between mouse/keyboard and VM.
We are also experiencing the same issue with our pilot of Dell 5040 ThinOS 8.3_108 devices. Connecting to Cisco WAPs. What ThinOS version are you running?
John
We were on 8.3_012, and we’ve just upgraded to 8.3_109. It remains to be seen if we still see it. I’m leaning towards it being caused by poor design of the crats we’re using (they were originally deployed with cheap keyboards, cheap USB hubs).
We have gone back to our deployment techs and re-designed what we deem an acceptable config. We want all USB devices plugged directly into the terminal, we want 0 USB hubs, and we want them on 8.3_109 firmware. Thus far I would say our issues are much less, but, whether it’s permanent, is yet to be seen.
Separately, but wireless related, we got some feedback from Dell that 5Ghz might not be the best route to take. In our INI we are specifying 5Ghz only. Since it’s a concern, we’re testing going 2.4Ghz only instead, but, it’s very early on. I don’t know that this is at all related to the issues we’ve seen with inputs, but, as the input issue ONLY happens on wireless units, we aren’t ruling anything out.
We probably have a good 500+ carts out in the wild.
We have 12 Pilot medical carts, and are preferring 5G in our config.
I’d love to know what Dell shared with you, as we are struggling with wireless in the field. Dell was the one that told us we should be using 5G, because on of our earlier ThinOS builds would not connect to 5G, (PEAP) and they gave us a Beta build to use until the December release that supported 5G better…One thing that Dell figured out for us was that an old Imprivata virtual channel was causing delays upon connection, and asked we added the following to our config. We verified with Imprivata that this was no longer needed, and it did in fact help with connection timing.
SessionConfig=ALL EnableImprivataVC=no
Side-Note: I’d like to chat about your Imprivata configuration sometimes… I see you are using Autolog, and we never got that working well. We are connecting directly to each session as the User. Just wondering if you think it’s worth revisiting.
Actually I misspoke. It looks like issue with 5G were addressed in 8.3_105. This was what we got from Dell:
Having said all that, there was a known issue with 5Ghz on the 5010/5040 Intel platform. Please reference CIR 89831, as the issue was fixed in build 8.3_105.19.
This is good, because we’ve switched a few carts to 2.4Ghz only, and they have worked terribly. Glad to see I simply misread that declaration by Dell.
We’re not using that EnableImprivata line in our config. What exactly does that do?
And sure, we can discuss Imprivata some. Do you have a Twitter account? We could DM there.
Here are my notes regarding the Imprivata Virtual Channel (VC)
1) We were having slight random delays in the login process from the Wyse 5040 devices. It would randomly have a 5-10 second delay when connecting to a disconnected session. We traced it back to the Imprivata Virtual Channel which is on by default. This ImprivataVC does USB redirection, and was conflicting with the VMware USB mapping from the ThinOS device. We disabled the Imprivata Virtual Channel in the WNOS.ini… and it seems to connect much faster.
SessionConfig=ALL EnableImprivataVC=no
Imprivata Support (9/20/2016): “EnableImprivataVC={yes,no}, tells the device to use USB Redirection to pass devices into the VM instead of using the virtual channel, which is what OneSign leverages to pass the device through. If attempting use USB Redirection when this setting is toggled to “yes”, the OneSign agent can get confused if it should use the USB device locally or in the virtual machine. If that’s the case, then toggling the setting to “no” should correct the issue. ”
@JohnTwilley
We’re not seeing a delay like that, so, don’t think we’re seeing the same issue. Our terminals autologin to the environment and get a VM. At that point the VM is locked by Imprivata, which is installed locally on the VM. The user then taps in on the badge reader, which authenticates them on the VM.
Just followed there.
For the benefit of those reading this post, and looking for ThinOS wireless answers. We’ve been working a couple cases with Dell Support and have found a few issues. We were running 8.3_108 & 8.3_109 and there is a ‘input lost on PCoIP session’ bug where you randomly lose keyboard/mouse input into the PCoIP session.
Dell support (depending on the Tech you get) may offer a couple options. I’m throwing those options out there for your consideration. For my specific PCoIP issue, they suggested the 8.4_006 beta. They have added “many enhancements” to the 8.4 wireless code. One of these is (finally) the removal of the -5 dBm threshold roaming limit. So far, the PCoIP input issue is gone, and the wireless seems to roam better. Your mileage may vary…
- The 8.3_210.36 is the 8.3 build with the DEMO code for the IEEE coredump patch applied.
- The 8.4 build is the BETA for 8.4 (containing the ‘input lost on PCoIP session‘ enhancements and the DEMO code for the IEEE coredump patch applied.
- You must be logged in to reply to this topic.