Tagged: kerberos, pdu_recv_data
- This topic has 13 replies, 5 voices, and was last updated 6 years, 3 months ago by ASwingler.
-
AuthorPosts
-
April 24, 2015 at 9:37 am #8531
We are running about 80 WYSE clients 50:50 split between T10 and C10LE.
Firmware from 8.0_214 to 8.0_508Randomly users are getting disconnected from their sessions, Wyse box event log shows:
12:22:30 RDP: Start session to COMPUTERNAME
12:22:30 RDP: Connect to COMPUTERNAME ...
14:48:17 RDP: pdu_recv: err code 104
14:48:17 RDP error(0x112f) : protocol error
14:48:41 RDP: Start session to COMPUTERNAMEUsers experiencing those are running on different firmware version and different devices. Some of the are getting disconnected 2-3 times a day, others every few days or weeks.
The only common thing is that they are connecting via RDP to their respective Windows 7 machines. Their respective VMs are running fine. When they reconnect their session still running.Config:
WNOS.iniautoload=2
EnableLocal=yes HideDefault=yes
Privilege=High
Locale=English
Language=Uk
AutoPower=yes
DesktopColorDepth=16 RGB565=yes
Screensaver=15 LockTerminal=no Type=0
Timeserver=10.0.24.1 Timeformat="24-hour format" Dateformat=dd/mm/yyyy
End=100507 TimeZoneName=GMT DayLightName=GMT
TimeZone='Greenwich Mean Time' ManualOverride=yes Daylight=yes Start=030507 End=100507 TimeZoneName="GMT Standard Time" DayLightName="GMT Daylight Time"
Device=Ethernet Speed="Auto"
WakeOnLan=yes
SignOn=No
MaxVNCD=1 VNCD_Zlib=yes
VncPassword="password"
VncPrompt=No Accept=5 ActiveVisible=yes
SessionConfig=ALL MapDisks=yes DisableSound=No VUSB_DISKS=yes VUSB_AUDIO=yes VUSB_VIDEO=yes Fullscreen=yes Resolution=default
SessionConfig=RDP DefaultColor=1 EnableNLA=no EnableGFX=no Dragging=no Animation=no EnableUDP=yes
Include=$mac.ini
MAC.ini
Terminalname=WYSE01
CONNECT=RDP
Host=COMPUTERNAME
Description="Your Computer Name"
Colors=16m
Fullscreen=yes
Rdp_No_Wallpaper=No
Rdp_No_Dragging=yes
Rdp_No_Animation=yes
Rdp_No_Theme=No
Rdp_No_Fontsmoothing=yes
Resolution=default
Domainname=DOMAINNAME
Mapdisks=yes
Disablesound=No
LocalCopy=no
Exit=YesAny ideas?
March 2, 2016 at 2:40 pm #42503We are experiencing the same disconnections, with same error code, on ours T10, firmware 8.1_027, on 2012R2 server.
April 1, 2016 at 12:44 am #42650Im experiencing the same problem with thin client S10, firmware 7.233, on Windows 2008 and 2012
April 1, 2016 at 12:47 am #42651I found some info relate to this topic, but this doesnt apply to my problem. I’m already using firmware version 7.
http://en.community.dell.com/techcenter/enterprise-client/wyse_thin_clients/f/4952/t/19637017April 1, 2016 at 12:48 pm #42655Are you using NIC teaming on your server?
If yes, disable NIC Teaming and change the following settings:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\EnableTCPA
netsh int tcp set global chimney=disabled
netsh int tcp set global rss=disabledCG
April 1, 2016 at 3:33 pm #42664Hi, sorry we are not using NIC teaming on our terminal servers. We are also experiencing the same issue on our windows 2008 servers as well. I have the feature ” NoReducer” set to no ( NoReducer=no) Im just curious if the could be the issue. Thanks for your reply.
May 11, 2016 at 12:50 pm #42791Hi,
For us, it seems to be MTU related: we have the disconnections only on our WAN link with the lower MTU.
As suggested here: http://en.community.dell.com/techcenter/virtualization/vworkspace/b/vworkspace-blog/archive/2011/06/14/mtu-size-mismatch-a-major-cause-of-disconnections
I’ve tried to lower the MTU on servers. It seems ok, I’ll post update in some days.May 18, 2016 at 4:31 pm #42823No more error after some days after fixing the MTU at 1476 !
I hope it can help others.The parameter is:
Device=Ethernet Speed=”Auto” MTU=1476May 18, 2016 at 4:51 pm #42826Hi Atmora,
I just wanted to share my experience in order to enforce that adding this line to the WNOS file really works.
I opened up a ticket with Dell wyse 2 weeks ago and the tech did the exact same thing under the WNOS.INI file, but he set the MTU size to 1412, as per below:
Device=Ethernet Speed=”Auto” MTU=1412Since then no more issues. The only challenge i had was to ask users to reboot the wyse terminal device so they can pickup the new parameters. After that all good, no more random disconnections
December 12, 2017 at 10:39 pm #45794Apologies if forum rules don’t allow posting to existing questions.
I’m getting the same problem when I attempt to log on using a smart card. Password-based login appears to work. I’m using WMS to configure a C10LE running 8.3_109. NLA=Yes. Logon=Yes without NTLM.
Error message on Remote Desktop Services logon screen is “RD broker sign-on failed”.
The log records:
ERROR: pdu_recv_data: err code 104
KRB: Other error. Error code: -3001
I looked at MTU but everything appears okay there. I am loading the root (and intermediate) certificates which I’ve checked are okay. Time is set correcly. The RDSH servers are virtualized so don’t have NIC teaming (although the virtualization hosts have teamed NICs but I’m unable to touch those).
It appears to be a Kerberos negotiation issue (the wireshark trace found that it stops during TGS-REQ with an unreassembled packet) whereas the password-based negotiation succeeds.
I’ve looked extensively for more information on this issue but I’ve found very little. I’d be very grateful for any assistance please.
– Andrew.
December 12, 2017 at 11:14 pm #45796Note: tcp chimney was already off but I disabled RSS and NetDMA on the virtualization host and also the RDSH virtual server and restarted them both. I still get the same error.
December 15, 2017 at 11:44 am #45805If it is Kerberos related, is your time/date setting correct?
CG
December 15, 2017 at 3:45 pm #45809Yes. I’m pulling it via NTP.
December 20, 2017 at 4:23 pm #45846What’s confusing me is that NLA/Kerberos works just fine using userid/password, but fails using smart card. Are there any other smart card related settings (aside from RequireSmartCard=yes)?
Smart cards work just fine on Windows clients so it’s not network or server-related as far as I can tell.
Any help appreciated.
Thanks, Andrew.
-
AuthorPosts
- You must be logged in to reply to this topic.