Forum Replies Created
-
Posts
-
It was a long shot, but setting the network speed in the INI for the C50LEs did not solve the problem with them freezing.
I decided to convert my C50LEs to C10LEs because I have just had too many issue with the Wyse Linux OS. While testing a demo C10LE, it froze, similar to how the C50LEs have been freezing. The technician said that there is a known issue with the C class’s ethernet card. Specifically, their network speed auto-detect on gigabit networks. He said that unless the network speed is set to a specific speed, they can become unstable and non-responsive over time. I set the network speed to 100M-F in the INI for the C10LE, and it has not frozen again in the last 2 weeks. Has anyone else has run across this issue? If it is a hardware issue, and not a driver issue, then setting the speed on my C50LEs may resolve my sporadic freezing problem. I just updated the INI and rebooted the unit, I will post the results.
On a side note, even if this resolves this particular issue with the C50LEs, I am still going to convert them to Thin OS. This is just the latest in a series problems I’ve had with them. My V10LEs just work. Thin OS maybe lacking some of the features of Wyse Linux, like PCoIOP, but it seems more refined and stable. Just my 2 cents.
I’m not sure if it is the same issue, but I had a BMP background deployed to my C50LEs. It worked fine until 11.1.052. Then on most of the Thin Clients it would show up distorted in the top 20% of the screen. On others, I would just have a black background. I have since removed the background.
I have not bothered contacting support about this issue because I have had so many issues with the Wyse Enchanced Linux OS, I am converting them call to Thin OS.
A Wyse Support Technician sent emailed me the following addon and it seems to have fixed the problem.
xset_no_blank-1-0.sletc11sp1.rpm
He said it will likely be included in the next firmware. Since its not in 11.1.052 (or the 11.1.053 beta) it might be a while. Anyone having this issue may want to contact support and request this file.
Back in July, I found a bug with my C50LEs, which probably effects all the Enhanced SUSE Linux thin clients. I use some of my C50LEs as displays which autologin and connect to a VMWare View session, then sit idle pretty much indefinitely. What I found is that even if you add the Screensaver=0 to your INI file, the screen will still go black after 10 minutes if there is no interaction with the thin client. Once there is any interaction with it, whether at the terminal or over VNC, the Thin Client screen will not go black again. Wyse Support has been able to reproduce this problem and filed a CIR for this issue. The tech I have dealing with hoped the latest firmware (11.1.053) would address the issue, but it has not.
If this is the problem your having, you may want to contact Wyse about it. There is no solution, but if enough people show its affecting them, maybe it will be higher priority for them to develop a fix.
I was mistaken. Short version, the first line of the $mac.ini file must be Include=$mac.ini
I thought the thin client read would read in any include statement it found in the $mac.ini file. It will, but only if the first line of the $mac.ini file is Include=$mac.ini. This seems to contradict the documentation which states, “NOTE: Only one level of include is allowed (nesting is not allowed).” Since the opening Include=$mac.ini seems to instruct it to used the rest of the file, which has another include statement.
As far as I can tell, the entire $mac.ini file implementation for the C50LE, and I imagine all of the Wyse enhanced SUSE Linux thin clients, is fubar. One has only to see how simply and easily it works with the ThinOS thin clients, to see how poorly it is implemented on the Wyse enhanced SUSE Linux thin clients.
I have a work around, but it is not pretty. I put the $mac.ini files in the same directory as the wlx.ini file. The first two lines of the $mac.ini files are:
include=wlx.ini
Include=$mac.ini
I found if I put anything before them, even a comment, it does not work. To my mind, this should cause a loop, but it seems to work. If anyone has a better way of doing this, please let post back.I found the problem. Looking through the INI Ref Guide, I found a reference to “include=$mac.ini“. The documentation states that this line should be added wlx.ini file, to have it include parameters from the $mac.ini. But the documentation also states that “If the thin client locates a $MAC.ini file (it is stored in the same directory as a wlx.ini file), then the wlx.ini file is not accessed.” So in cases where the $mac.ini file is the only file being accessed, you have to add “include=$mac.ini” to the beginning of the $mac.ini file.
So now my question is, how do you format the path in the “include” statements, so you can store the $mac.ini in another directory? The documentation defines the include parameter as “Include=path/filename”, so it should be possible. I would like to store the $mac.ini files in a subdirectory:
/wyse/wlx/inc/$mac.ini
I have tried:
include=/wyse/wlx/inc/$mac.ini
include=wyse/wlx/inc/$mac.ini
include=/wlx/inc/$mac.ini
include=wlx/inc/$mac.ini
include= /inc/$mac.ini
include= inc/$mac.ini
The file and folder have the same permissions as the /wyse/wlx/wlx.ini file, which reads in fine.
Any ideas?Adding a login delay will allow you can cancel the auto login and enter another user. It also resolves an issue I have had with the VNC service failing to start properly.
Autologin=yes CountDown=60
Autologin=yes CountDown=60
That works to delay the login to the thin client. I am looking for a way to delay the AutoConnect to the VMWare session.
I have more testing to do, but I may have found a work around. It seems that a single user interaction with the VM, mouse or keyboard, may be enough to prevent the screen from going black, indefinitely. Many of my thin clients are used for displays do not have mice and keyboards. Today I found that one C50LE that I had been working with Friday, was still displaying properly. I restarted it and the screen went blank after 10 min. After being the screen back by moving the mouse and clicking a few times, I left it idle and the screen has not gone black again.
Now the question is whether the interaction fixed the problem or cycling in and out the black screen fixed it. To test this I will restart the C50LE and interact with the VM a bit then leave it idle. If the interaction is what is fixing it, it should never go black. If not, its cycling in and out of the black screen. I will also be testing whether a remote shadow interaction is enough to keep the screen active or if a physical mouse needs to be used. I will post the results back here.
**********************************************
I ran through the tests outlined above. As long as there in any kind of interaction with the C50LE, either locally or through VNC, the screen will not go black (assuming you have it set that way). While its a work around, I am still waiting for Wyse tech to get back to me as it is still an issue for me.Thank you for the reply and the update about base64 encryption. I missed the part in the release notes about no longer accepting plain text. I downloaded the newest ConfGen, but it produced plain text. (see below) I ran the text through another encoder and that worked. It also fixed the problem I had with it not auto-connecting to the View Server.
