- This topic is empty.
13. March 2012 at 23:29 #7178
got a bunch of T50s and had some users complaining of getting kicked out of their RDP session when they would Ctrl-C or even right click and copy from time to time. Weird. Looks like Wyse addressed the issue with the newest firmware:
the Release notes state:
TIR58001: RDP Crashes after Ctrl+C on Notepad. – resolved!
so I downloaded that and flashed it to one of my clients, now the RDP session seems to crash on login. We have a cluster that usually forces our users to log in twice. Once to the server they initially hit and once to the server the Session Broker re-directs them to. It’s a bit of a pain, but it works.
here’s some info on how this is just how it is…
The problem is with this new firmware the user’s never get to the 2nd login. With the old firmware they’d log in, and it would drop back out to the Ubuntu desktop for a second, then go back to a Windows login screen with their username already populated.
This is a really new firmware, but am I the only one having this problem? pretty frustrating and we were about to order a bunch more T50s…it’s a great price, but getting to be quite a pain in the butt to support…hopefully someone here has some insight.
thanks8. May 2012 at 22:35 #22293
I believe that we are experiencing the same issue you described here since we upgraded our firmware on our T50 to the 20120203-0_U-1.018 version. I have one T50 that is still on the old firmware and it seems to be working just fine. However, this newly upgraded one wont connect to the terminal server farm. We also have a windows 2008 terminal server farm with a session broker and load balancing enabled. It seems that I can connect directly to the terminal server with the session broker on it, but any others it lets me log in and then it says welcome and then it goes back to the home screen of the T50. Its driving me nuts. Did you ever figure out what was causing this? Did you get any leads? Thanks in advance for any help.
Isaac17. May 2012 at 19:16 #22370
hey Isaac, Sorry I missed your reply….
No, it’s not resolved, I have a ticket open with Wyse support:
Update Service Request:2760630 – Copy kills RDP session, after firmware update, no longer works with RDS broker
I spoke with a Wyse tech and we did a packet capture on the thin client (not sure why, seems like a software problem, not anything with the network). We did a webex and he drove the thin client and tried a bunch of stuff, nothing fixed the problem. When you run it from a command prompt we get:
admin@LWT0080649cb1ad:~$ rdpclient chicken
__BASE__: Connect to the host chicken …
-MAIN-: WARNING: 16 bpp Visual not available
PDU READ: RDP: Decompression type is MPPC-64K
-MAIN-: Max gc count: 3
-MAIN-: Max gc count: 10
-MAIN-: Max gc count: 24
__BASE__: cliprdr inQueue count: 0, max 0
__BASE__: rdpsnd inQueue count: 0, max 0
__BASE__: DRDYNVC inQueue count: 0, max 0
__BASE__: AURTCX inQueue count: 0, max 0
__BASE__: USBVDX inQueue count: 0, max 0
__BASE__: MHA_VC inQueue count: 0, max 0
__BASE__: MMRVDX inQueue count: 0, max 0
__BASE__: -MAIN- inQueue count: 0, max 6
__BASE__: gVcPduAvail count: 8, max 8
__BASE__: PDUout count: 0, max 4
__BASE__: PDUout count: 0, max 2
__BASE__: PDUout count: 0, max 0
__BASE__: AvailPDUs: 9, max 9
__BASE__: gFreeNodes count: 17, max 17
and it dies. Yes, our Farm name is Chicken. it’s a chicken farm. We like to have fun when our stuff works. This problem is NOT fun. 🙁
with the old firmware the screen would flicker for a second in between the first server and the 2nd one. now, the first one just goes away and never comes back.18. May 2012 at 15:23 #22372
I’m seriously just about done with Wyse T50s. They don’t work properly for RDP at this point in time…it clearly wasn’t ready for market. here’s how some e-mails went down last night:
Unfortunately, I have bad news for you. Our development team has informed me that RDS Broker connectivity is not supported by the Linux RDP client. They are currently working to add support, but cannot provide any timeframes. I was hoping to have more promising information to provide, but do not want to give you false hope.
Please let me know if you have any questions.
that’s not what page 15 of this document says : http://www.wyse.com/sites/default/files/es/pdf/Wyse-T-class.pdf
That page specifically refers to the T10, which is the WTOS version of this device. All of our WTOS devices (running a 7.1.x firmware) support connecting to RDS Broker. Unfortunately, you cannot convert a T50 into a T10, they look the same, but the internals are slightly different.
yeah, I was wrong…Page 16 states it for the T50, and it worked on the old version of the firmware…..harder to get this stuff right when everything Wyse support is doing for me is after hours and I have to work off my phone while at a Girl Scouts event for my daughter….grrrrr
How did you come across that PDF?? Could you walk me through how you found it? The one linked from our main site (http://www.wyse.com/sites/default/files/products/spec_sheets2012-04-02/Wyse-T-class-IA-AW010212c.pdf) is different…
seriously? what does it matter? it’s official wyse documentation…I don’t know how i found it, it’s on your damn web site….
I just want to throw them all in a box and mail it back to them and demand my money back….this is SOOO frustrating.30. May 2012 at 13:12 #22425deejMember
- Total Post: 2
I maintain 70+ T50 clients connecting on different 2003 TS and 2008 RDP servers. I have a control group upgraded to the latest firmware but have had only one client (not in the control group) experience the copy/paste situtation.
Also, check that your server allows any version or RDP connection. I noticed that once I upgraded my control group, the clients would start to load the server but would then go to back to standby. I had to do this to every one of my new 2008 RDP servers.
You can check this by going to: Computer>Properties>Advanced System Properties>Remote Tab>Check the allow connections from computers running any version of RDP.
I hope this helps.12. June 2012 at 16:44 #22464
here’s what I’ve done to temporarily resolve the connectivity problem….I copied the old /usr/bin/rdpclient to the new firmware.
That fixed the ability to connect to the cluster. It also seemed to leave the copy problem.
I got a file from Wyse support called xfce4-settings_4.7.2-1~ppa1common0hedley15wyse1_armel.deb that seems to resolve it, so I just added that to the wlx.ini
Right now I have T50s that are working really well. 🙂24. December 2012 at 18:37 #23202
I want to apologize that I never responded after your posts. Thank you for continuing to keep us updated. I was able to get the 1.018 version to work with our cluster. Although, now I can’t remember what I did. I believe I followed deej instructions and just made a change on our terminal servers and then it worked and then forgot to reply. It was a crazy time.
However, we are still having issues with these T50s. I am with allroy1975. I am about to just throw in the towel. Although it looks like you may have got something working. Here are the issues we have at this moment:
1. T50s will connect to the cluster. However, after you login it will often kick you back to the home screen again. So you login again. It will do this from 2 – 8 times before it actually connect to the terminal servers and loads your desktop. I am not sure why it is doing this, but I see others having similar problems. We are running DNS round robin with a session broker. Allroy1975 were you able to overcome this problem with your copying of the older firmware RDPclient?
2. Newer Wyse T50s that I bought more recently have problems locking up in the session. Randomly the session just stops allowing for the mouse to work. The keyboard still works. We are currently trying different usb mouse instead of the ps/2 mouse through the keyboard to see if that works. I’m not holding my breath. Looking at some other forum posts it looks like many have been having this issue and were even wondering if it is a bad batch of T50s or something.
You are right. Page 16 of the specs shows that it should work with the Session Broker.
Any help I can get would be greatly appreciated! Thanks and I hope each of you got these figured out too.
Thanks30. April 2013 at 8:06 #23803jmcpMember
- Total Post: 1
Wyse support have confirmed via a telephone conversation there are known issues with revision: U-1.018 on the T50 when initiating Session Brokered connections on RDSH.
I have uploaded the older revision of compatibile fw you can flash to the T50.
U-1.012 is confirmed working.
U-1.018 doesnt work (obviously) – Segmentation fault
U-1.022 I tested and with our balanced environment still doesnt work. Segmentation fault14. May 2013 at 17:30 #23838
Thank you so much for your post. I have been watching the firmware and hoping they will update it, but nothing. Its like they have stopped working on these devices. I believe in the future I am going to go with a different OS. I’ve heard the WyseOS has no problems with this. Thank you so much for the older firmware post! I had been looking for that everywhere. Once I get a few minutes I will try and restore these terminals back to the older version and I will report back if it worked for me. Thanks.29. May 2013 at 15:23 #23896acraMember
- Total Post: 16
- Regular Joe
We’ve had the issue with the term server farm with having to authenticate twice/more.
We found that enabling Network Level Authentication stops the issue, as all the authenticating happens before you hit the broker – although this creates a new issue as it can’t handle password expiry, forcing users to either remember to change their password before it expires, or making us change passwords manually!
Our experience with the T50s has been really disappointing to date – all seemed fine during testing – we had a demo T10 and demo T50, and were happy with the performance of the T50 so went for it as it was cheaper than the T10…
Now we’re finding that aside from this issue, ours are running RDP really laggy by comparison to a Windows box, and have already had to do several ‘bodge-jobs’ to get ‘features’ working like a numlock that comes on at boot, and having our keyboard layout/language persist from the local to the RDP!
Honestly it’s a bit of a joke – do any of you notice these problems?
- You must be logged in to reply to this topic.