none
[MS-RDPBCGR] Undocumented GCC client data block 0xC009 (Lync RDP client) RRS feed

  • Question

  • Hi,

    I am working on Lync RDP client/server support in pidgin-sipe with FreeRDP for desktop sharing. I am currently testing sharing from Linux with pidgin-sipe to a Windows Lync 2013 client. Desktop sharing does not yet work, but one odd thing I have noticed on the server-side is that the Lync 2013 RDP client is sending an undocumented GCC client data block with id 0xC009. GCC client data blocks are documented in MS-RDPBCGR, and this one is definitely missing.

    This unknown GCC client data block is only 4 bytes long, with the following data:

    05 01 00 00

    I guess it could be a UINT32 number (261) or maybe a version number, no idea.

    Can MS-RDPBCGR be updated to document this GCC client data block?

    Best regards,

    -Marc-Andre

    Tuesday, November 18, 2014 7:19 PM

Answers

  • I just checked in mstscax.dll, and the equivalent function uses the documented GCC data block id 0xC00A instead. I guess that in some earlier version 0xC009 was used and appshvw.dll was not updated later on. I will update my code to treat both 0xC009 and 0xC00A as CS_MULTITRANSPORT, unless it turns out it's not the same thing.
    Thursday, November 20, 2014 12:46 AM

All replies

  • Hello Marc-Andre,

    Thank you for your question. A member of the protocol documentation team will respond to you soon.

    Best regards,
    Matt Weber | Microsoft Open Specifications Team

    Tuesday, November 18, 2014 8:20 PM
  • Hello Marc, I am currently researching the problem and will provide you with an update soon. Thank you for your patience.

    Regards,
    Sreekanth Nadendla
    Microsoft Windows Open specifications

    Tuesday, November 18, 2014 10:32 PM
    Moderator
  • Hi Sreekanth,

    Thanks for looking into it. I have no idea if this unknown GCC is important or not, but I still haven't been able to get my FreeRDP-based Lync RDP server working with a Lync 2013 client. It appears to me that the moment I sent graphical updates from my server, the Lync 2013 client throws an error. I have tried forcing different codecs on the server without luck. I made sure that my updates are sent once the client state is activated. If you find anything that would explain why this happens while investigating this, let me know. If I force disabling all updates on my server, then I see a black window appear in the Lync 2013 area. I noticed that once the black window appears in the Lync 2013 staging area, a mouse event is sent. I tried delaying updates up to that point, but it would still throw an error. It looks like the Lync 2013 client is expecting something from the server that I am not sending it before it is ready to accept graphical updates. What this would be is a mystery to me, but it's definitely not a problem for FreeRDP as a Lync RDP client (not server) connected to a Lync 2013 desktop sharing session.

    As for guessing what this unknown GCC data block is, I think I may have found a hint. It's a stretch, but would it be possible that the constant I observe over the wire is WM_SYSKEYUP (0x0105)?

    http://msdn.microsoft.com/en-ca/library/windows/desktop/ms646287%28v=vs.85%29.aspx

    I found the hint in appshvw.dll's CTSInput::IHInjectKey function. As I said, it's a stretch, I really have no idea if there is a link.

    Thursday, November 20, 2014 12:28 AM
  • Hi,

    Forget what I just suggested. I think I found what it was:

    http://msdn.microsoft.com/en-us/library/jj217498.aspx

    GCC data block 0xC009 appears to be the same as CS_MULTITRANSPORT but with a different id.

    The block contains a UINT32 flags field:

    TRANSPORTTYPE_UDPFECR        0x01
    TRANSPORTTYPE_UDPFECL        0x04
    TRANSPORTTYPE_UDP_PREFERRED    0x100

    Combining all 3 possible flags, we get the observed value over the wire.

    The function producing this data block is CNC::NC_GetMULTITRANSPORTSData, and it checks "UseMultiTransports" and "DisableUDPTransport" registry keys.

    Thursday, November 20, 2014 12:42 AM
  • I just checked in mstscax.dll, and the equivalent function uses the documented GCC data block id 0xC00A instead. I guess that in some earlier version 0xC009 was used and appshvw.dll was not updated later on. I will update my code to treat both 0xC009 and 0xC00A as CS_MULTITRANSPORT, unless it turns out it's not the same thing.
    Thursday, November 20, 2014 12:46 AM
  • Marc,

    Your assessment is correct. Microsoft RDP server implementation ignores blocks with unknown id values. At one point we did have Lync sending data for TS_UD_CS_MULTITRANSPORT with 0xc009 instead of 0xc00a although multi transport feature is not applicable to Lync.  So your server implementation must ignore data  block with id 0xc009.

    Regards,
    Sreekanth Nadendla
    Microsoft Windows Open specifications

    Wednesday, November 26, 2014 2:59 AM
    Moderator