Description of problem: 2XClient RDP failed to use SD\SC Card. For repeat this BUG you need hardware: 1. Athena ASEDreive IIIe [Athena CCID] 00 00 2. Rutoken/eToken GOST/JaCarta (with GOST key conainer) Software installed in terminal server: 1. Windows 2008 R2 (Microsoft RDP Server) 2. CryptoPro 3.6 R3 3. csScript 4. eToken GOST / JaCarta utilities 5. process monitor Software used to communicate with terminal server: 1. 2XClient (with RDP session) 2. PCSCD 3. CCID Drivers (CryptoPro 3.6 R3 for Linux contains it in package Rutoken/JaCarta) In terminal session: Windows Server logon see readers (ruToken and Athena with smartcard JaCarta) and smartcard but tells that cannot found correct certificates. CryptoPro 3.6 R3 dosen't view containers in card. When csScript try to communicate 2XClient RDP connection fails (but not drops until some time). JaCarta utilities view smartcard and diag util reported that smartcard correct. Process monitor tells that csScript at this connect try to estabilish direct connection with smartcard \\TSCLIENT\SCARD\2 Bug can be reproduced in Debian 7.0 \ Feodora (may be all *nix) When trying to use Windows RDP Client on Windows XP/Windows 8 station all works fine (certificate found, usable, writable). Windows XP/8 station conains same software that have terminal server. Please connect me for additional information if required: desput[at*/]mail.ru ------------ In Linux PC/SC device scanner V 1.4.17 (c) 2001-2009, Ludovic Rousseau <ludovic.rousseau> Compiled with PC/SC lite version: 1.7.4 reports that all correct (f.e. for RuToken): 0: Aktiv Co. Rutoken S 00 00 Sun Jul 7 03:54:55 2013 Reader 0: Aktiv Co. Rutoken S 00 00 Card state: Card inserted, ATR: 3B 6F 00 FF 00 56 72 75 54 6F 6B 6E 73 30 20 00 00 90 00 ATR: 3B 6F 00 FF 00 56 72 75 54 6F 6B 6E 73 30 20 00 00 90 00 + TS = 3B --> Direct Convention + T0 = 6F, Y(1): 0110, K: 15 (historical bytes) TB(1) = 00 --> VPP is not electrically connected TC(1) = FF --> Extra guard time: 255 (special value) + Historical bytes: 00 56 72 75 54 6F 6B 6E 73 30 20 00 00 90 00 Category indicator byte: 00 (compact TLV data object) Tag: 5, len: 6 (card issuer's data) Card issuer data: 72 75 54 6F 6B 6E Tag: 7, len: 3 (card capabilities) Selection methods: 30 - DF selection by path - DF selection by file identifier Data coding byte: 20 - Behaviour of write functions: proprietary - Value 'FF' for the first byte of BER-TLV tag fields: invalid - Data unit in quartets: 1 Command chaining, length fields and logical channels: 00 - Logical channel number assignment: No logical channel - Maximum number of logical channels: 1 Mandatory status indicator (3 last bytes) LCS (life card cycle): 00 (No information given) SW: 9000 (Normal processing.) Possibly identified card (using /usr/share/pcsc/smartcard_list.txt): 3B 6F 00 FF 00 56 72 75 54 6F 6B 6E 73 30 20 00 00 90 00 ruToken-S (USB token) www.rutoken.ru/products/rutoken/rutoken-s/ *Example for Athena ASEDrive IIIe*: Scanning present readers... Waiting for the first reader...found one Scanning present readers... 0: Athena ASE IIIe [ASEDrive CCID] 00 00 Sun Jul 7 04:09:23 2013 Reader 0: Athena ASE IIIe [ASEDrive CCID] 00 00 Card state: Card inserted, ATR: 3B D5 18 00 81 31 FE 7D 80 73 C8 21 10 F4 ATR: 3B D5 18 00 81 31 FE 7D 80 73 C8 21 10 F4 + TS = 3B --> Direct Convention + T0 = D5, Y(1): 1101, K: 5 (historical bytes) TA(1) = 18 --> Fi=372, Di=12, 31 cycles/ETU 129032 bits/s at 4 MHz, fMax for Fi = 5 MHz => 161290 bits/s TC(1) = 00 --> Extra guard time: 0 TD(1) = 81 --> Y(i+1) = 1000, Protocol T = 1 ----- TD(2) = 31 --> Y(i+1) = 0011, Protocol T = 1 ----- TA(3) = FE --> IFSC: 254 TB(3) = 7D --> Block Waiting Integer: 7 - Character Waiting Integer: 13 + Historical bytes: 80 73 C8 21 10 Category indicator byte: 80 (compact TLV data object) Tag: 7, len: 3 (card capabilities) Selection methods: C8 - DF selection by full DF name - DF selection by partial DF name - Implicit DF selection Data coding byte: 21 - Behaviour of write functions: proprietary - Value 'FF' for the first byte of BER-TLV tag fields: invalid - Data unit in quartets: 2 Command chaining, length fields and logical channels: 10 - Logical channel number assignment: by the card - Maximum number of logical channels: 1 + TCK = F4 (correct checksum) Possibly identified card (using /usr/share/pcsc/smartcard_list.txt): 3B D5 18 00 81 31 FE 7D 80 73 C8 21 10 F4 Bank of Lithuania Identification card Version-Release number of selected component: gnome-abrt-0.2.12 Additional info: kernel: 3.9.8-100.fc17.i686 type: libreport
Created attachment 769919 [details] Messages log
Same error occured with xfreerdp / rdesktop compiled with scard support.
Trying with 'rdesktop' 1.7.1 : compiled with --enable-smartcard, --with-debug-smartcard with default settings Windows Terminal Server don't capture smartcard because size is limited in 'scard.c' to 448 bytes. Experimentally, i found that maximum length is 2012 bytes, but it was not enough! 4145 desired for JaCarta SCARD: Reader: "Athena ASE IIIe [ASEDrive CCID] 00 00" SCARD: ATR: 3b:d5:18:00:81:31:fe:7d:80:73:c8:21:10:f4 SCARD: SCardStatus(hcard: 0x00000004 [0x000131b5], reader len: 128 bytes, atr len: 32 bytes) SCARD: -> Success (state: 0x00000034, proto: 0x00000002) SCARD: Reader: "Athena ASE IIIe [ASEDrive CCID] 00 00" SCARD: ATR: 3b:d5:18:00:81:31:fe:7d:80:73:c8:21:10:f4 SCARD: SCardTransmit(hcard: 0x00000004 [0x000131b5], send: 5 bytes, recv: 260 bytes) SCARD: -> Success (44 bytes) SCARD: SCardTransmit(hcard: 0x00000004 [0x000131b5], send: 8 bytes, recv: 18434 bytes) SCARD: -> Success (345 bytes) SCARD: SCardTransmit(hcard: 0x00000004 [0x000131b5], send: 8 bytes, recv: 18434 bytes) WARNING: Card response limited from 4145 to 2012 bytes! SCARD: Truncated 4145 to 2012 SCARD: -> Success (2012 bytes) SCARD: SCardEndTransaction(hcard: 0x00000004 [0x131b5], disposition: 0x00000000) SCARD: -> Success SCARD: SCardDisconnect(context: 0x00000003 [0x103e65d], hcard: 0x00000004 [0x131b5], disposition: 0x00000000) SCARD: -> Success SCARD: SCardReleaseContext(context: 0x00000003 [0x103e65d]) SCARD: -> Success SCARD: SCardGetStatusChange(context: 0x00000001 [0x103faec], timeout: 0xffffffff, count: 2) SCARD: "\\?PnP?\Notification" SCARD: user: (nil), state: 0x00000001, event: 0x00000000 SCARD: "Athena ASE IIIe [ASEDrive CCID] 00 00" SCARD: user: (nil), state: 0x00000022, event: 0x00000000
But for ruToken It is enough! Bingo!! To developers of pcsc-tools: how to find possible error? ---- Please help me as quite as it possible, it very need for a healthcare poject in Chuvash republic in Russian Federation.
Created attachment 769987 [details] PCSCD --foreground --debug when rdesktop failed to connect
Found one comment in early 2006 Today it works with 2012 bytes, but not more. Can anybody help with this magic 448 / 2012 ? ---------------------------------------------------------------------- Comment By: Alexi Volkov (alexi_volkov) Date: 2006-06-26 07:52 Message: Logged In: YES user_id=1357228 For now there is no way found to correctly transmit answer of SCardTransmit function call to Windows if receive buffer length is larger than 448 bytes. In this case Windows simply stop Smart-Card service and you have to relogin. I added check of buffer length and hard limit it on 448 bytes before SCardTransmit call. This is temporarily. If your smart-card worked before this patch it should continue to work as it uses short buffer lengths. ----------------------------------------------------------------------
It looks like a rdesktop (or TDP protocol) issue rather than a pcsc-lite issue. Or even maybe a Windows limitation. I have no idea where the message "WARNING: Card response limited from 4145 to 2012 bytes!" comes from. It does not come from pcsc-lite itself.
It does not com from pcsc-lite itself, it comes from scard.c from rdesktop. I think that it is a windows limitation. Please look at more detailed log attached.
Created attachment 780324 [details] 2400 Bytes received with extended APDU command, then rdesktop dies
Fedora 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.