Forum Replies Created
-
Posts
-
UPDATE:
The ORDER of certain wireless config lines in the INI can cause the ‘Network I/O’ errors.
It was the ROOT cause of our Network I/O errors all along. Our ‘Network I/O’ issues did not happen until ThinOS 8.6.
It turns out that the older ConfGen tool generated the INI file with the ‘Device-wireless’ line at the END. (tested with 7.4) Newer versions generate the same line AT THE BEGINNING of the wireless section. (tested with 8.5)
Example:
From 2019
IEEE8021X=yes network=wireless access=WPA2-ENT eap=yes eaptype=EAP-PEAP peapmschapdm=MyDomain.com peapeap=EAP-MSCHAPV2 \
peapmschapun=UserID1 \
peapmschappwdEnc=!!!!!!!!!!!!!!!!!!!!!!!!!!!
Device=Wireless Mode=Infrastructure SSID=”OurSSID” RoamSensitive=-69dbm PreferBand=5G DisableWLAN=EnetUp Priority=”MySSID”
vs
2022
Device=Wireless Mode=Infrastructure SSID=”OurSSID” RoamSensitive=-69dbm PreferBand=5G Priority=OurSSID DisableWLAN=EnetUp
IEEE8021X=yes network=wireless Profile=OurSSID access=WPA2-ENT eap=yes eaptype=EAP-PEAP peapmschapdm=MyDomain.com peapeap=EAP-MSCHAPV2 \
peapmschapun=UserID1 \
peapmschappwdEnc=NNEH6MFCIHBCN6ACPGAAFFLIDFLL
Changing the order alone will not resolve the issue. We had to add “Device=NIC Default=WLAN” to the devices INI files to trigger some odd change within the device. Once we did this, the devices no longer lost their default gateway after 4-5 hours of activity. You can also just manually change the Default Gateway locally on the device once to “fix” the issue.
Another interesting issue is that you cannot manually change the Default Gateway in any of the ThinOS 8.6.x builds. Try it yourself. Change the default gateway in the Network settings…go back and see if it sticks. It will not. It may just be a GUI bug, but something odd is going on here.
Dell Support is aware of this, but ThinOS 8.6 is EOL and not being updated. So this workaround will have to do for the thousands of Dell 5040s we have under warranty until 2024. I thought I’d share my finding so that I could help someone else with this odd issue.
We are trying the following as a work-around on our 8.6_807 devices until Dell gets it sorted out. Applied via the SN.ini or Advanced WMS Console area.
Device=NIC Default=WLAN
Did anyone ever come up with a Fix for the ThinOS Default Gateway Bug?
Our hospital has this issue on 8.6_807 and the devices just loose the default gateway every 4-5 hours. Rebooting resolves it for another 4-5 hours.
We cannot even set/modify the Default Gateway in Network Settings. It’s like that value is read-only.
Any workarounds would be helpful.
ThinOS 9.1.6108 fixes the renaming issue when changing groups. We could not migrate devices to a new server using the 9.1.5067 build without having to manually rename the device again. Now it works fine.
Same thing here. Dell 5470s install the BIOS package, but it does no upgrade the bios
LOL. I can’t believe I had this issue as well… Drive space issue here as well…
Used your guide to copy the files over, and I’m back in business. Thank you for helping, as I didn’t want to re-build this old WDM server.
Yes. I know. I should move to WMS…
Here’s what I do to test a particular BIOS using WDM.
Each of our devices has a SN.ini file that I can use to target individual devices for upgrades… so I rename the BIOS to something like Manual_PAIO10G_bios.bin and drop it in the root of the WDM share.
SN.ini sample:
autoload=2 # ENABLE a FORCED firmware UPGRADE process
PlatformConfig=”D Class” Firmware=PD10_wnos_8.6_27 BIOS=Manual_PAIO10G_bios.bin # — Force Zero Client to look for a different Firmware/BIOSafter stations updated to Windows 10 v 1903
I’d fix that problem first. These should be highly managed. 1903 is too cutting edge…asking for issues. Anyways, that’s not why we are here.
There are lots of things to ask here:
- What OS/Build were you running previously that ran smooth?
- What protocol are the endpoints connecting via? PCoIP, Blast, RDP
- Are they connecting via TCP or UDP. Controlled via Group Policy
- Were the images Optimized? VMware Optimization Tool and/or tweaks.
We are experiencing “I/O Error” pop-ups when trying to tap in on random RFIdea readers. A reboot of the ThinOS 8.6_019 resolves it for awhile.
Here are any reference to “Monitors” in the Release Notes for 8.6_019:
- CIR97705/TIR97720 ELO IntelliTouch monitor ET2201L stability improvements
- CIR98126/TIR98195 Resolved an ET2201L monitor issue where the Touchscreen tab in the user interface was greyed out
- CIR98990/TIR98993 Improved client stability when using 2k monitors
- CIR98994/TIR98995 5040, Resolved an issue where the main screen changes from monitor 1 to monitor 2 when using dual displays
- CIR98496/TIR98653 3040, Resolved an issue where DP Audio was limited to DP2 when using dual monitors
- CIR98922/TIR99053 3020, Resolved an issue where screen swap left to right did not also swap the mouse
- CIR98994/TIR98995 5040, Resolved an issue where the main screen changes from monitor 1 to monitor 2 when using dual displays
- CIR98922/TIR99053 3020, Resolved an issue where screen swap left to right did not also swap the mouse
Our Dell 5040 PCoIP AIO normally use PD10_BIOS.bin…
The naming convention of PAIO10G_bios.bin seems to be new? Or am I just misreading?
The new Dell Support site is…difficult. 😉
VMware Solution: This is an example of a PowerMic II
You could SPLIT the composite device, so we can leave some of the components locally on the ThinOS device. Group Policy settings are required.
Horizon Agent:
We turned off “Allow Auto Device Splitting” so we could control the process.
We setup the GPO to “Split Vid/Pid Device.
o:vid-0554_pid-1001(exintf:00;exintf:01;exintf:02)
How did we determine the Interface numbers?
From the VMware Client debug logs (on a Windows PC) you can determine the sub-interfaces of a composite device. C:\ProgramData\VMware\VDM\logs\debug-*.txt
In this example, we see the four interfaces of a Nuance PowerMicIII.
<vmware-usbd> [vmware-remotemks] DevFltr: Interface [0] – Family(s): audio
<vmware-usbd> [vmware-remotemks] DevFltr: Interface [1] – Family(s): audio,audio-in
<vmware-usbd> [vmware-remotemks] DevFltr: Interface [2] – Family(s): audio,audio-out
<vmware-usbd> [vmware-remotemks] DevFltr: Interface [3] – Family(s): hid
In WNOS.ini (Or MAC.ini / SN.ini) add the following line to FORCE the USB redirection. Note, the USB Redirection must be installed in the VDI desktop as part of the Horizon Agent.
Device=vusb ForceRedirect=0x0554,0x1001,0x00,0x00,0x00 Type=PCoip
FROM A THINOS device: you see the following.
ThinOS Device logs. Insert a PowerMic II device…
Event logs show the following.
13:18:04 VUSB: Local Device 0x0451,0x2036,0x09,0x00,0x00)
13:18:04 USB: Found a new 12Mbps device “HUB” on port 9
13:18:04 VUSB: Redirectable Device(0x0554,0x1001,0x01,0x01,0x00)
13:18:05 USB: Found a new 12Mbps device “USB AUDIO” on port 1
13:18:05 USB: Found a new 12Mbps device “usbhid” on port 1
13:18:05 AUDIO: Change record device to PowerMicII-NS
13:18:05 AUDIO: Change playback device to PowerMicII-NS
13:18:06 VUSB: Local Device(0xdf04,0x0004,0x03,0x01,0x02)
13:18:06 USB: Found a new 12Mbps device “usbhid” on port 2
Also…I’m getting reports from some users about the Audio being “Very Low”. In troubleshooting, the ThinOS volume is set to high (25) but it is still low. Factory reset does not help. it only effects a handful of devices, although there configurations are all the same.
Rolling back to 8.5.x resolves the low volume issue…
In summary – Stay Away from 8.6_013.
Here’s an example of the two GSOD that we are seeing with 8.6_013.
One is wireless, the other with our Tap-Reader (RFIDeas). The “rfideas poll” trap is about 90% of our GSOD.
Dell Support said there are a few cases similar, one being an Imprivata bug. I’ll let you guys know what our Support ticket turns up….
