Действительно, такая проблема существует и мы в настоящий момент занимаемся ее решением.
С выходом нового релиза Windows-драйверов все проблемы интероперабельности Windows и Unix будут решены.
Как временное решение, мы разрабатываем патчи для linux библиотек, учитывающие особенности поведения Windows-драйверов.
Временные заплатки, решающие проблемы взаимодействия linux+openct+pcsc+rdesktop и Windows,  а также для портированного в Windows opensc, уже готовы.
Если у Вас есть потребность протестировать их, пожалуйста, напишите на rutoken@hotline.ru

Спасибо.

Почему при экспорте локального токена с Linux-машины в терминальную сессию Win2003 через RDP (rdesktop -r scard)
при работе с устройством наблюдаются многочисленные проблемы?
Начиная с "перевернутого" задом на перед серийного номера и неправильных размера свободной памяти и имени устройства,
и заканчивая полной неработоспособностью rtCert, Cert2Cont, КриптоПро CSP.

Почему при локальном подключении токена в Linux-машину все работает замечательно (opensc-*, rutoken-tool, pkcs15-*),
а при локальном подключении в Win-машину этого-же токена такая-же портированная версия opensc с этим токеном уже не
работает?

Создается впечатление, что весь Win-софт для работы с токеном написан с учетом некоторых особенностей реализации
ifdhandler-а для Windows-платформы, что приводит к неработоспособности RuToken в "смешанных" решениях Windows-Linux.
Сопоставление APDU и USB команд в Linux и Windows косвенно это подтверждает.

С имеющимися у нас USB-токенами и SC-считывателями других производителей такой особенности не наблюдается.

Можете прокомментировать или уточнить данную ситуацию?
Планируется-ли в следующих выпусках драйверов и ПО от Aktiv Co. устранить подобную несовместимость?

Спасибо за ответы!

(RuToken S, rdesktop-1.6.0, pcsc-lite-1.5.5, opensc-0.11.9, openct-0.6.18)