none
[MS-RDPECLIP] mstsc sends unannounced 4-byte zero pad to all cliprdr messages RRS feed

  • Question

  • Hi,

    I just completed initial working server-side clipboard in FreeRDP/FreeRDS. I would like to solve a mystery: mstsc is apparently always sending a 4-byte zero pad with cliprdr messages. This pad is not documented, and probably a bug. Since other clients like FreeRDP do not have this bug and there is no way to know if the messages are going to be padded or not, I added some code which checks if there is more data to be read at the end of a message, read 4 bytes and then ignore the bytes if they are set to zero. Luckily, a value of zero is invalid for the first 4 bytes of a cliprdr header, so there is no ambiguity there. I did some testing with mstsc, and this 4-byte zero pad is always of value zero, and is always present regardless of the size of the message. It does not appear to be an alignment pad.

    We have other server-side virtual channels working in FreeRDP/FreeRDS, and none of the other channels have this problem. I do not exclude the possibility that we have a problem somewhere in our server-side virtual channel code, but it looks unlikely as other channels work. To explain the difference there would need to be something special or different about the cliprdr channel, and I have no explanation for why it would be handled differently right now.

    Can someone at Microsoft confirm or infirm this? Is mstsc sending a 4-byte zero pad after all cliprdr messages? Each message starts with an 8-byte CLIPRDR_HEADER (http://msdn.microsoft.com/en-us/library/cc241097.aspx). CLIPRDR_HEADER.dataLen contains the length of the message excluding the size of the header, so the total message length is CLIPRDR_HEADER.dataLen + 8. In the case of mstsc, I always get 4 extra bytes on top of that, such that the total message length is CLIPRDR_HEADER.dataLen + 8 + 4, where the last 4 bytes is the mystery 4-byte zero pad.

    Monday, December 22, 2014 2:24 PM

Answers

  • Update to forum.  The outcome below was communicated with Marc-Andre.  The following update was made to [MS-RDPECLIP]:

    Section 2.2.1   Clipboard PDU Header (CLIPRDR_HEADER)
    Added a product behavior note regarding the dataLen field.

    BEFORE:

    dataLen (4 bytes): An unsigned, 32-bit integer that specifies the size, in bytes, of the data which follows the Clipboard PDU Header.

    AFTER:

    dataLen (4 bytes): An unsigned, 32-bit integer that specifies the size, in bytes, of the data which follows the Clipboard PDU Header.<nnn>

    <nnn> Section 2.2.1: The operating systems Windows Server 2003, Windows Vista, Windows Server 2008, Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012, Windows 8.1, and Windows Server 2012 R2 append four bytes to the end of clipboard PDUs. These four bytes are not included in the PDU size specified by the dataLen field and can be ignored.


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

    Wednesday, January 6, 2016 4:13 PM
    Moderator