none
RDPDR device redirection RRS feed

  • Question

  • I am writing my own rdp client with smart card redirection. I've worked my way through the RDPEFS initialization messages but am receiving NTSTATUS error STATUS_INVALID_PARAMETER as the resultcode in my CoreDeviceAnnounceRsp from my device list announce.

    Could someone enlighten me  as to what parameter(s) this could refer too? I've compared to the examples in protocol pdfs and havn't noticed anything in particular.


    The only parameters in the device announce are DeviceID and PreferredDosName. Unless the invalid_parameter might refer to a capabilities mismatch earlier on.
    • Edited by ethosunum Friday, March 15, 2013 1:33 PM
    Friday, March 15, 2013 1:18 PM

Answers

  • Ethosis,

    I set up two systems and captured the [MS-RDPEFS] & [MS-RDPESC] traffic and also reviewed our code.  You are correct that the PreferredDosName of “SCARD” is required.  I filed a document bug against the specifications to verify this and to ensure that the requirement is added.

    The frame I captured in my trace is below (bottom of this mail).

    I used the technique described in my blog at http://blogs.msdn.com/b/openspecification/archive/2012/07/24/hitchhiker-s-guide-to-debugging-rdp-protocols-part-2.aspx to capture and decrypt Windows-to-Windows traffic.

     

      Frame: Number = 746, Captured Frame Length = 107, MediaType = DecryptedPayloadHeader

    + DecryptedPayloadHeader: FrameCount = 1, ErrorStatus = SUCCESS

      TLSSSLData: Transport Layer Security (TLS) Payload Data

    + TLS: TLS Rec Layer-1 SSL Application Data

      ISOTS: TPKTCount = 1

    + TPKT: version: 3, Length: 50

    + X224: Data

    + T125: Data Packet

    + RDPBCGR: RDPEFS

      VirtualChannelData: RDPEFS

    - RDPEFS: RDPDrCoreDeviceListAnnounceReq

      - RdpdrHeader: Component = RDPDR_CTYP_CORE, PacketId = PAKID_CORE_DEVICELIST_ANNOUNCE

         Component: RDPDR_CTYP_CORE

         PacketId: PAKID_CORE_DEVICELIST_ANNOUNCE

      - DrCoreDeviceListAnnounceReq: DeviceCount = 1

         DeviceCount: 1 (0x1)

       - Device: RDPDR_DTYP_SMARTCARD: Smart card device

          DeviceType: RDPDR_DTYP_SMARTCARD: Smart card device

          DeviceID: 1 (0x1)

          PreferredDosName: SCARD

            DeviceDataLength: 0 (0x0)


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

    Tuesday, March 19, 2013 4:40 PM
    Moderator

All replies

  • Update: Changing the PreferredDosName to "SCARD" seems to move things along. Was there some where specified that the preferred dos name must be SCARD?
    Friday, March 15, 2013 2:29 PM
  • Hi ethosis,

    Thank you for your question. A member of the Protocol Documentation support team will respond to you soon.

    Regards,
    Vilmos Foltenyi - MSFT

    Friday, March 15, 2013 5:30 PM
  • Hi Ethosis,

    Can you send me mail at "dochelp (at) microsoft (dot) com"?  Using the techniques I outline at http://blogs.msdn.com/b/openspecification/archive/2012/07/24/hitchhiker-s-guide-to-debugging-rdp-protocols-part-2.aspx, I am collecting a network trace of a working [MS-RDPESC] exchange.


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

    Monday, March 18, 2013 4:15 PM
    Moderator
  • Ethosis,

    I set up two systems and captured the [MS-RDPEFS] & [MS-RDPESC] traffic and also reviewed our code.  You are correct that the PreferredDosName of “SCARD” is required.  I filed a document bug against the specifications to verify this and to ensure that the requirement is added.

    The frame I captured in my trace is below (bottom of this mail).

    I used the technique described in my blog at http://blogs.msdn.com/b/openspecification/archive/2012/07/24/hitchhiker-s-guide-to-debugging-rdp-protocols-part-2.aspx to capture and decrypt Windows-to-Windows traffic.

     

      Frame: Number = 746, Captured Frame Length = 107, MediaType = DecryptedPayloadHeader

    + DecryptedPayloadHeader: FrameCount = 1, ErrorStatus = SUCCESS

      TLSSSLData: Transport Layer Security (TLS) Payload Data

    + TLS: TLS Rec Layer-1 SSL Application Data

      ISOTS: TPKTCount = 1

    + TPKT: version: 3, Length: 50

    + X224: Data

    + T125: Data Packet

    + RDPBCGR: RDPEFS

      VirtualChannelData: RDPEFS

    - RDPEFS: RDPDrCoreDeviceListAnnounceReq

      - RdpdrHeader: Component = RDPDR_CTYP_CORE, PacketId = PAKID_CORE_DEVICELIST_ANNOUNCE

         Component: RDPDR_CTYP_CORE

         PacketId: PAKID_CORE_DEVICELIST_ANNOUNCE

      - DrCoreDeviceListAnnounceReq: DeviceCount = 1

         DeviceCount: 1 (0x1)

       - Device: RDPDR_DTYP_SMARTCARD: Smart card device

          DeviceType: RDPDR_DTYP_SMARTCARD: Smart card device

          DeviceID: 1 (0x1)

          PreferredDosName: SCARD

            DeviceDataLength: 0 (0x0)


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

    Tuesday, March 19, 2013 4:40 PM
    Moderator