none
[MS-RDPERP] Language Profile Information PDU RRS feed

  • Question

  • Hi,

    I am asking this question as a developer of a third-party RDP client (FreeRDP).

    Is Language Profile Information PDU (TS_RAIL_ORDER_LANGUAGEIMEINFO in 2.2.2.10.1 of MS-RDPERP) actually supported by any Microsoft Windows RDP servers?

    As specified by 2.2.1.1.1 'Remote Programs Capability Set' of MS-RDPERP, the server confirms the TS_RAIL_LEVEL_LANGUAGE_IME_SYNC_SUPPORTED flag in its Demand Active PDU, and the client replies that it also supports this capability in its Confirm Active PDU. But apparently nothing happens on the server side when the client sends a valid Language Profile Information PDU.

    On the other hand, MS-RDPERP explicitly says in 3.3.7.2 that the server reaction to Language Profile Information PDU is optional. Thus the behavior of the server is not wrong. It is allowed to ignore the PDU.

    However, I may be misunderstanding the intended meaning of this PDU. I expect that Language Profile Information PDU is intended to allow the client to explicitly switch the keyboard layout or the IME method that is currently in use by the remote application.

    Could you please clarify the meaning and possible restrictions of the Language Profile Information PDU?

    Monday, February 22, 2016 9:48 AM

Answers

All replies

  • Hello ilammy,

    Thank you for your [MS-RDPERP] question. One of the Open Specifications team members will assist you shortly.

    Thank you,
    Kamil Sykora

    Monday, February 22, 2016 1:57 PM
  • Hi ilammy,

    I can research this for you.  While I suspect you want the answer for all operating systems, what OS are you presently focused on?


    Bryan S. Burgin Senior Escalation Engineer Microsoft Protocol Open Specifications Team

    Monday, February 22, 2016 2:59 PM
    Moderator
  • Hi Bryan,

    Thank you for your assistance.

    I am currently focused on the systems which support RDP 8.1 (Windows 8.1 and Windows Server 2012 R2).

    I also have access to systems which support RDP 7.1 (Windows 7, Windows Server 2008 R2), but I have found that these systems do not announce TS_RAIL_LEVEL_LANGUAGE_IME_SYNC_SUPPORTED flag, so they seem to be out of scope. But you are right, I am interested in all systems in the end.

    Monday, February 22, 2016 4:31 PM
  • Hi ilammy,

    For ProfileType == TF_PROFILETYPE_KEYBOARDLAYOUT, we call:
      LoadKeyboardLayout()
      https://msdn.microsoft.com/en-us/library/windows/desktop/ms646305%28v=vs.85%29.aspx?f=255&MSPPError=-2147217396

    For ProfileType == TF_PROFILETYPE_INPUTPROCESSOR, we call
      ITfInputProcessorProfiles::EnableLanguageProfile()
      https://msdn.microsoft.com/en-us/library/windows/desktop/ms628550%28v=vs.85%29.aspx?f=255&MSPPError=-2147217396

    Nothing is returned to the client.

    I have a decrypted, uncompressed [MS-RDPERP] network (Netmon) trace.  If you send mail to the Dochelp alias ("dochelp (at) microsoft (dot) com"), I will send it to you.


    Bryan S. Burgin Senior Escalation Engineer Microsoft Protocol Open Specifications Team

    Monday, February 22, 2016 10:07 PM
    Moderator
  • Hmm...

    Thus it appears that TS_RAIL_ORDER_LANGUAGEIMEINFO only loads a layout into the system. It does not make a layout switch request (like calling ActivateKeyboardLayout() or posting WM_INPUTLANGCHANGEREQUEST). Am I right?

    Though, I am still not sure that the client sends a valid PDU. The spec does not include an example for this one. I have dropped at email to dochelp and would be grateful if you could sent me a relevant network trace.

    Wednesday, February 24, 2016 11:15 AM
  • In response to your direct email, I replied:

    It's attached (to the email, not this forum post).  You want to specify "DecryptedPayloadHeader" as the "Display Filter" to view just the decrypted frames (i.e., to filter out the TLS-encrypted frames).  To narrow your view to just RAIL, use "DecryptedPayloadHeader and rdperp".

    You can get Network Monitor at http://www.microsoft.com/en-us/download/details.aspx?id=4865.  This installs an older parser package.  Updated parsers (but still quite old) are available at https://connect.microsoft.com/site216/Downloads.  You can also use Message Analyzer.  I attached presentations I gave to decrypt RDP traffic using both Network Monitor or Message Analyzer.

    The TsDemandActive PDU is frame 106 and the TsConfirmActive PDU is frame 111 (showing the RAIL capabilities exchange).  The TS_RAIL_ORDER_LANGUAGEIMEINFO frame is 661 (RDPERP.Hdr.OrderType == 0x11).  I believe that this trace shows HiDef RAIL.

    Regarding your comment " Thus it appears that TS_RAIL_ORDER_LANGUAGEIMEINFO only loads a layout into the system. It does not make a layout switch request (like calling ActivateKeyboardLayout() or posting WM_INPUTLANGCHANGEREQUEST). Am I right?", after calling LoadKeyboardLayout() or ITfInputProcessorProfiles::EnableLanguageProfile(), depending on ProfileType, we call ActivateProfile().


    Bryan S. Burgin Senior Escalation Engineer Microsoft Protocol Open Specifications Team

    Wednesday, February 24, 2016 3:31 PM
    Moderator
  • Hi Brian,

    The netmon dump you provided and the presentations were very helpful, I believe I have found the cause of the issue.

    MS-RDPERP specifies in section 2.2.2.10.1 that TS_RAIL_ORDER_LANGUAGEIMEINFO has length of 48 bytes:

    • 4 bytes: TS_RAIL_PDU_HEADER
    • 4 bytes: ProfileType
    • 4 bytes: LanguageId
    • 16 bytes: LanguageProfileCLSID
    • 16 bytes: ProfileGUID
    • 4 bytes: KeyboardLayout

    However, the network dump shows that this PDU is in fact 46 bytes long, with TS_RAIL_PDU_HEADER.orderLength equal to 46.

    I suppose that MS-RDPERP incorrectly specifies the type of the LanguageId field. If it is mapped onto LANGID type then it should be a 2-byte unsigned value rather than a 4-byte one.

    If I modify the client to send a 46-byte PDU then the server successfully adds the specified keyboard layout after receiving the PDU. However, the newly added layout does not activate after that. I have to manually switch to it. Unfortunately, I am not able to make mstsc.exe to send TS_RAIL_ORDER_LANGUAGEIMEINFO in order to observe the server behavior in my environment. Could you please advise on this?

    Finally, the reference for ITfInputProcessorProfileMgr::ActivateProfile reveals another possible discrepancy in the specification. The reference says that both clsid and guidProfile arguments must be null if dwProfileType is TF_PROFILETYPE_KEYBOARDLAYOUT. However, MS-RDPERP states that LanguageProfileCLSID field of TS_RAIL_ORDER_LANGUAGEIMEINFO must be null when ProfileType is TF_PROFILETYPE_KEYBOARDLAYOUT, but ProfileGUID field must be null when ProfileType is TF_PROFILETYPE_INPUTPROCESSOR.


    • Edited by ilammy Thursday, February 25, 2016 9:13 AM typos
    Thursday, February 25, 2016 9:11 AM
  • I'll research this for you.


    Bryan S. Burgin Senior Escalation Engineer Microsoft Protocol Open Specifications Team

    Thursday, February 25, 2016 10:05 PM
    Moderator
  • ilammy,

    I completed my research and you are correct: LanguageId is only two byes as you discovered.  I will file an issue against [MS-RDPERP] to correct the specification.  Thank you for raising this issue.


    Bryan S. Burgin Senior Escalation Engineer Microsoft Protocol Open Specifications Team

    Tuesday, March 1, 2016 5:47 PM
    Moderator
  • Regarding:

    "Finally, the reference for  ITfInputProcessorProfileMgr::ActivateProfile reveals another possible discrepancy in the specification. The reference says that both clsid and guidProfile arguments must be null if dwProfileType is TF_PROFILETYPE_KEYBOARDLAYOUT. However, MS-RDPERP states that LanguageProfileCLSID field of TS_RAIL_ORDER_LANGUAGEIMEINFO must be null when ProfileType is TF_PROFILETYPE_KEYBOARDLAYOUT, but ProfileGUID field must be null when ProfileType is TF_PROFILETYPE_INPUTPROCESSOR"

    I filed a bug against [MS-RDPERP] to correct this.  Thank you for reporting this issue.


    Bryan S. Burgin Senior Escalation Engineer Microsoft Protocol Open Specifications Team

    Tuesday, March 1, 2016 6:34 PM
    Moderator