none
[MS-RDPERP] Server doesn't send Window Alternative Secodary Orders RRS feed

  • Question

  • Hi,
    Sorry for English.
    I am Roman Barabanov from FreeRDP project. Now I am working on RAIL implementation in FreeRDP and I have a problem.
    I done all for establish RAIL session and now my fork able to run 'wordpad' in RAIL mode.
    So virtual channel communication is OK.
    Now I need to implement window support, but server doesn't send me any Window Alternative Secondary order at all. But server send other Alternative Secondary orders such as TS_ALTSEC_SWITCH_SURFACE and TS_ALTSEC_CREATE_OFFSCR_BITMAP.
    Capabilities packets are same for mstsc and freerdp sessions (I already compare capabilities packets in sniffer)
    Rdp client version is 0x00080004
    INFO_RAIL bit in Client Info PDU flags is set. 
    Server is working on Windows Server 2008 R2 SP1.
    Can you point me to possible problem in this case?
    Maybe I need some unknown conditions for receiving Window Alternative Secondary orders?
    Best regards,
    Roman Barabanov

    Tuesday, July 12, 2011 9:27 PM

Answers

  • Forum Update:

    This issue is now resolved. The picture in section 1.3.2.1 of MS-RDPERP suggests that client first sends the handshake PDU and server responds to it whereas section 2.2.2.2.1 states the right behavior as follows:

     

    The Handshake PDU is exchanged between the server and the client to establish that both endpoints are ready to begin RAIL mode. The server sends the Handshake PDU and the client responds with the Handshake PDU.

     

    A future release of MS-RDPERP will incorporate the modifications to remove the discrepancy.


    Regards, Obaid Farooqi
    Monday, July 25, 2011 10:05 PM
    Owner

All replies

  • Hi Roman,

    Thank you for your question.  A colleague will contact you soon to investigate this issue.

    Regards,
    Mark Miller
    Escalation Engineer
    US-CSS DSC PROTOCOL TEAM

    Tuesday, July 12, 2011 10:29 PM
  • Hi Roman:

    I'll help you with this issue and will be in touch as soon as I have an answer.


    Regards, Obaid Farooqi
    Friday, July 15, 2011 6:33 PM
    Owner
  • Hi Obaid!

    What I need to do for help you to resolve this issue?

    I can create Virtual Box Ubuntu image with compiled bugged version and you can try to run it and debug on server side.

    Or I can send you Wireshark traffic from mstsc and FreeRDP for comparing or other actions. Do you able to decrypt TLS RDP Wireshark traffic by server private SSL key?


    Best regards,
    Roman Barabanov
    Sunday, July 17, 2011 8:05 PM
  • Hi Roman:

    I appreciate your patience in this matter.

    I am still investigating this issue. There is a third option which is that I'll send you some binaries that you can install on your Windows server and collect traces and send them to me.

    Please send an email to dochelp (at) microsoft (dot) com to my attention and I'll sen you instructions on how to collect traces.


    Regards, Obaid Farooqi
    Monday, July 18, 2011 4:09 PM
    Owner
  • Hi, Obaid!

     

    Done.

    I sent letter to required email from my own email.

     

    Best regards,

    Roman Barabanov

     

    Monday, July 18, 2011 8:00 PM
  • Forum Update:

    This issue is now resolved. The picture in section 1.3.2.1 of MS-RDPERP suggests that client first sends the handshake PDU and server responds to it whereas section 2.2.2.2.1 states the right behavior as follows:

     

    The Handshake PDU is exchanged between the server and the client to establish that both endpoints are ready to begin RAIL mode. The server sends the Handshake PDU and the client responds with the Handshake PDU.

     

    A future release of MS-RDPERP will incorporate the modifications to remove the discrepancy.


    Regards, Obaid Farooqi
    Monday, July 25, 2011 10:05 PM
    Owner