Cannot connect from Wyse Thin clients #2166
Labels
Comments
|
Hi, thanks for the offer and sorry for the inconvenience. @matt335672 Can you spend time on this? Unfortunately, I can't spend much time on this now even if I received the hardware client. I think you're most eligible person for receiving the hardware client. @jsorg71 How about you? If you received the client, can you work on that? |
|
I remember these from a previous life. I ran one as an ICA client for quite a few years, and it seemed pretty solid. I never tried it with native RDP though. @christheradioguy - we might be able to sort this out without shipping a box depending on how you're set up. TLS may be a non-starter - the protocol has moved on since 2008. Also, in the leaflet linked from #874 (assuming you have an s10), SSL/TLS is only mentioned with respect to ICA. A couple of questions for you:-
If by some chance that works we can improve the security until it breaks. |
|
Thanks for the reply, I'll try compiling the latest version over the weekend. I just tried with on the latest package supplied with Linux Mint 20.3 (xrdp 0.9.12) and just get an immediate disconnection from the thin client and then the following log: |
|
Software version is 6.5.0_30, I'm assuming this is an S10 because it has 0MB of flash (according to the hardware information page in Wyse OS) |
|
Thanks. It looks like it's at least getting the channel list from the client. There's a couple of standard ones there, and then some specials. That's quite early on in the connection sequence ([MS-RDPBCGR]).Technically it's the 'client network data' part of the Client MCS Connect Initial PDU. On the face of it, it looks like were either getting something in the PDU we don't like, or the client doesn't like our response. Please be aware I'm not an expert in this bit of the code. Compiling the latest version will be really helpful. If you build the latest xrdp version with |
|
Alright, had some free time this evening and compiled the latest version from the repo: Tried connecting from the thin client and getting the following log: Let me know what else I can provide |
|
I just realized when I ran make install the crypt and security_layer were reset. I have put them back to RDP and low, here's the latest log |
<
8000
task-lists disabled sortable>
|
Hello! @christheradioguy @matt335672 I had a WYSE 1200LE Terminal over 10 years ago, but no longer have it. I was interested in this issue, so I got a Dell WYSE 3040 from an online auction and tested it. I assume that the connection was made because ThinOS is a newer version. |
Very interesting! I have been unable to get connected using those settings, however, as you say you are running on a much newer version of ThinOS. I'll have to see what the latest version supported by the SX0 is, maybe there's a chance I can upgrade it to a newer version, though I suspect I might be on the latest |
|
I have also looked into the Sx0 series of devices. The Sx0 can be upgraded to netboot-only firmware. |
|
@TOMATO-ONE I have a box of these things so I figured I'd update one of them to 7.1 and it worked. Successful connection to xrdp using the following settings: So the issue seems to be with firmware version 6.5 and earlier. My immediate issue is now resolved with the 7.1 firmware, but @matt335672 if you're still interested in gathering information about the encryption issue on the older firmware I'm happy to help as I have many of these on the older firmware. |
|
I record the situation at the moment for future viewers of this issue. I have installed different versions of ThinOS on my 3040 and tried connecting to xrdp, all with success. Note: Ver 8.5.009 and Ver 8.6.710 are faster than Ver 9.1.6108 in terms of screen update speed. |
|
@TOMATO-ONE - that's really helpful. Thanks for your input. @christheradioguy - the errors you're getting are not related to encryption, but rather to the connection setup sequence to do with channels. Referring to section 1.3.1.1 of [MS-RDPBCGR], xrdp sends an 'MCS Attach User Confirm PDU`, and then expects a number of Looking at the code, it looks like the thin client thinks there are less channels than the server is expecting to support. We can get more logging if you set the logging level to DEBUG. Or you could try playing around with the requested facilities on the ThinOS (although I have no idea how you'd do that). I can't find any on-line release notes for ThinOS that old, so I'm unable to advise you on what extra facilities may be present on the newer firmware. |
|
@christheradioguy - do you want to take this any further? |
|
Yeah, I'll try and gather some more info with the DEBUG log level this weekend. |
|
Alright, here's what I get with DEBUG mode: |
|
There seems to be a mismatch between the number of channels we're expecting, and the number of channel join requests that are sent. What version of xrdp are you using for this? The version I'm looking at has much better logging in this area, but it needs to be built with the |
|
Apologies, I forgot to compile with the This is the version I am running |
|
My bad - sorry. Having a closer look at the code, the messages we want are in xrdp_sec_process_mcs_data_channels(). They are TRACE level. I can't recommend you enable TRACE for all development messages as I'm sure you've got better things to do. However, you can enable them selectively for this function. Edit Then restart xrdp. On my system I get these additional messages:- At the moment I can't see any other logging that'll be useful without making code changes to |
|
Alright, here's what I get from enabling TRACE on that channel |
|
Interesting - thanks. On our side, we expect We could do with still more logging. Can I ask you to apply a patch, and also to add another entry to the The patch is :- --- a/libxrdp/xrdp_mcs.c
+++ b/libxrdp/xrdp_mcs.c
@@ -718,6 +718,10 @@ xrdp_mcs_recv_cjrq(struct xrdp_mcs *self)
{
int opcode;
struct stream *s;
+#ifdef USE_DEVEL_LOGGING
+ int initiator;
+ int channel_id;
+#endif
s = libxrdp_force_read(self->iso_layer->trans);
if (s == 0)
@@ -753,8 +757,13 @@ xrdp_mcs_recv_cjrq(struct xrdp_mcs *self)
return 1;
}
+#ifdef USE_DEVEL_LOGGING
+ in_uint16_be(s, initiator);
+ in_uint16_be(s, channel_id);
+#else
in_uint8s(s, 4); /* initiator (2 bytes)
channelId (2 bytes) */
+#endif
/*
* [MS-RDPBCGR] 2.2.1.8 says that the mcsAUrq field is 5 bytes (which have
@@ -772,8 +781,9 @@ xrdp_mcs_recv_cjrq(struct xrdp_mcs *self)
}
LOG_DEVEL(LOG_LEVEL_TRACE, "Received [ITU-T T.125] ChannelJoinRequest "
- "initiator (ignored), channelId (ignored), "
+ "initiator %d, channelId %d, "
"nonStandard (%s)",
+ initiator, channel_id,
(opcode & 2) ? "present" : "not present");
if (!s_check_end_and_log(s, "MCS protocol error [ITU-T T.125] ChannelJoinRequest"))The complete On my system I get these messages from a Remmina client:- So I can pair up the channel join requests with the channels. That should let us hopefully work out which channel isn't generating a channel join request. It'll take me a while to get back to you on this one - I've got a busy week coming up. I feel we're making progress though. |
|
Finally got around to applying the patch, there's the latest debug log Definitely feel like we're getting somewhere, appreciate the persistance. |
|
Thanks @christheradioguy. When we've gotten to the end of this process I'll merge in some of these logging improvements. It looks like the client isn't sending over a join request for one of the standard channels. I'll take a look later in the week - as I said it's not an area I'm that familiar with. |
|
I've had a think about this, and I think at this point we out to make a quick mod to xrdp to check we're on the right lines. The problem seems to be that we're expecting one more channel join request than the client is sending. It seems likely this is the client's fault as we've not seen this before, and a firmware upgrade fixes the issue, but I don't think even that's certain. Let's try hard-coding xrdp to expect one less channel join request to get over this hurdle, and see how the thin client works then. After applying the patch, line 1247 of for (index = 0; index < self->channel_list->count + 2; index++)Can you change the '+2` to a '+1', so we can see what happens? Thanks. |
|
Apologies for the late reply. I tested the patch by changing Here's a debug log if it helps |
|
Thanks for that. The question then is which join request is xrdp expecting that the client isn't sending. We probably need more logging, but it might take me a while to get to it. |
|
I've had a bit of time to look into this. At the moment I think this is actually a bug on the xrdp side. [MS-RDPBCGR] contains this line in 2.2.1.8 :-
The static virtual channels for this client are clearly logged as 1004 - 1009. In addition we're getting a channel join request for 1003. This is the "I/O channel", and is fixed. The "message channel" isn't actually used by xrdp, so that just leaves the "user channel" which the client isn't sending. There's a bit of interpretation of the spec needed here which I won't go into, but essentially xrdp is setting a user channel of 1002, which is the same as the server channel. This seems odd to me. I've looked at the Microsoft RDP server responses, and also the code in FreeRDP. These both set a user channel which is one more than the last allocated static virtual channel. After (quite) a bit of effort, I've built a branch which I think does what Windows server actually does. Since I imagine your terminals have been tested on Windows targets, I'm quietly confident that this branch might work for you unmodified on your thin clients. If it doesn't the logging will in any case be interesting. I'll give you a couple of options for testing this:-
Please let me know how it goes. I've tested this patch on a Remmina client and mstsc.exe so far. Also, thanks for a very interesting problem - it's getting me into some very interesting corners of [MS-RDPBCGR]! |
|
Thanks for the reply. I checked out the Really appreciate all the time spent on this so far. |
|
Heigh ho. Thanks for getting back to me. I appreciate it's not always easy to find the time to build this and try it. The logging is certainly helpful. I think we can quite clearly see that the client is not sending back a channel join for the user channel. Given that the user channel isn't actually used for any messages (it's just a hang-over from using T.125 I think), that shouldn't affect functionality. The spec does contain this line in 3.2.5.3.8:-
if we were adhering to exactly what the spec does, at this point I'd call a halt to this operation. However, since your clients work OK with some Windows operating systems I don't think MS is adhering to the letter of the spec either. In the event of a mismatch between the spec and real-world operation, we tend to go with the latter. These clients are pretty old. Have you tried them with Windows 10 (or even 11) say? It's a useful data point. I'll have a think about what we could do at this point to move forward and let you know. |
|
I've had another look at #874, which makes the point that this stuff worked for xrdp v0.6.1. Looking at the code for that version, it was a lot more lax on exactly what virtual channel join requests it received from the client. However, it did not have to contend with TLS support which came in with version 5.2 of the RDP protocol, according to Wikipedia at least. I'd like to see what version your clients are - we might be able to do something with that if we can also assume TLS support is not required, like fall back to the older code. I've pushed a new version of the When you've tried to connect you should have a line like the following in I'd like to know what that version is for your clients. The example above is for a Windows 10 client. Thanks again for the challenging problem. |
|
I'll try and slot some time in to re-try with the latest code this week. Regarding connection to modern operating systems, I did have these clients successfully connecting to Win server 2016. There was a few group policy changes I needed to make from what I recall (this was a few years ago heh). I believe I needed to set the encryption level to client compatible, And I needed to set the 'Require use of specific security layer' to 'negotiate.' Also needed to disable network-level auth |
|
That's great - thanks. That fits with my existing mental model of how the Windows side is working. I've got some time here today, so I'll see what I can discover with a modified copy of xfreerdp talking to Windows 10. I'll post back before close-of-play UK time (UTC+1:00) |
|
Bit more info regarding Windows 10 as a server. Just built xfreerdp stable-2.0, commit FreeRDP/FreeRDP@b8be481. First job is to establish a connection using the RDP protocol rather than TLS. That needed the following to be done:-
That's all OK. Next I added this patch to FreeRDP to log the channel connections:- --- a/libfreerdp/core/mcs.c
+++ b/libfreerdp/core/mcs.c
@@ -1085,6 +1085,7 @@ BOOL mcs_send_channel_join_request(rdpMcs* mcs, UINT16 channelId)
return FALSE;
}
+ WLog_INFO(TAG, "\tJoining channel:%" PRIu16 "", channelId);
mcs_write_domain_mcspdu_header(s, DomainMCSPDU_ChannelJoinRequest, length, 0);
per_write_integer16(s, mcs->userId, MCS_BASE_CHANNEL_ID);
per_write_integer16(s, channelId, 0);On my system I got:- So channel 1009 is the user channel, 1003 is the I/O channel, and 1004-1007 are the static channels. I then applied this further patch to FreeeRDP to disable sending the user channel:- --- a/libfreerdp/core/rdp.c
+++ b/libfreerdp/core/rdp.c
@@ -1603,7 +1603,8 @@ int rdp_recv_callback(rdpTransport* transport, wStream* s, void* extra)
return -1;
}
- if (!mcs_send_channel_join_request(rdp->mcs, rdp->mcs->userId))
+ rdp->mcs->userChannelJoined = TRUE;
+ if (!mcs_send_channel_join_request(rdp->mcs, MCS_GLOBAL_CHANNEL_ID))
{
WLog_ERR(TAG, "mcs_send_channel_join_request failure");
return -1;Result:- The connection was successful. The client RDP version for this version of FreeRDP is 10.7 (0x0008000C) Windows server can also cope with the missing user channel with TLS enabled. This can be seen by dropping the Summary so far:-
My proposal is to investigate modifying xrdp to cope without the user channel join in non-TLS mode. This will allow us to support older clients, such as this one, which do not conform to the spec. These clients can in any case not use modern TLS, so users of them will need to take additional security measures in any case. In TLS mode xrdp will be adhere to the spec. This is a pragmatic decision. To support Windows behaviour fully, we'd need to look at the octets after each channel join, and decide whether they were a channel join, an MCS data PDU, or the start of a TLS client hello. for the latter two we'd then need to rewind the channel somehow before continuing. This is going to significantly complicate the code for no benefit that I can see at the moment. I do however see benefit in supporting older clients in non-TLS mode. |
|
@christheradioguy - I've implemented the changes I've proposed in my previous message and repushed my branch. I've only tested so far from a hacked and non-hacked version of xfreerdp, and both seem to work. If it works with your thin client, I think we're there. When you get a chance, let me know how it goes. |
|
Quick update - I've tested the modified branch on mstsc.exe (both TLS and non-TLS) and Moba-xterm (both TLS and non-TLS). It all seems to be good. |
|
Bingo! Confirmation that the latest build of |
|
Great - glad we got there in the end. At the moment we're looking at the next major version of xrdp (v0.10.x possibly), so I'm going to rebase my branch on that. However, we don't have a release date for that yet, so I've made a patch which applies to v0.9.19, so anyone interested in this thread can try it out. wyse_thin_client_v0_9_19.patch.txt Thanks again @christheradioguy for helping to improve the product. |
Closed
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hey All,
I have stumbled across this issue #874 while researching an issue I have been having with some Wyse sx0 thin clients and I believe it is the same issue.
The original issue was closed because the developers were unable to get a hold of one of the clients, I have a box of them and would be happy to ship a few out if it could help fix this issue.
The text was updated successfully, but these errors were encountered: