Проброс USB-устройств и принтеров через RDP с Linux на Windows

Есть ли истории успеха по поводу проброса принтеров или произвольных USB-устройств на Windows-машину через линуксовый RDP-клиент?

Все мои попытки на данный момент заканчивались неудачей.

Например, принтер пытался поднять по этой инструкции: https://github.com/FreeRDP/FreeRDP/issues/961

EPSON_L110_Series — так называется соответствующая очередь печати CUPS.

Но вообще никаких результатов. xfreerdp при этом выводит:

Где он должен появиться в Windows вообще? Нужно ли на windows какой драйвер ставить?

Или я кардинально неправильно всё делаю? Я первый раз этим занимаюсь, а с windows дела вообще очень давно не имел.

Насчёт RDP не знаю, но кроссплатформенно пробрасывать USB и принтеры умел NoMachine

может и сейчас умеет, если не поломали

В бесплатной версии или только в платной?

не знаю, можешь скачать проверить

вроде и в бесплатной было

Произвольное USB — не бывает гарантированно никак.

Принтеры скорее да, чем нет.

Драйвер на Windows либо родной принтера, тогда очередь cups в режиме raw, либо Postscript (какой-нибудь HP или Microsoft Publisher), а обработка для принтера на стороне cups. Имя драйвера можно передавать со стороны RDP клиента, но нужно его установить на Windows.

Это в целом, безотносительно твоего принтера.

PS. И там, где у тебя «usblp» должно быть имя windows-драйвера принтера

x2go(развитие бесплатного NX) вроде как тоже умеет проброс. Есть ли у него клиент под винду — не знаю

Драйвер на Windows либо родной принтера, тогда очередь cups в режиме raw

На Linux-машине, где клиент, удалил мой принтер, добавил его заново как Local Raw Printer, выбрав соответствующий драйвер. Называется он так же, EPSON_L110_Series. На удалённом Windows установил драйвер данного принтера, он называется «EPSON L110 Series». Выполняю

и ничего. Где вообще что-то должно появится? Windows 2008 R2.

Так, новая информация. Из винды тоже пробросить не получается. Надо будет попросить помощи у коллег-вендоузятнегов.

Вообще самое страшное для Linux-админа — настраивать взаимодействие Linux и Windows. Причём виноват обычно Windows. Вот сейчас даже заметил, что буфер обмена в RDP у меня не работает, причём не только с Linux-клиента, но и с Windows.

Проброс USB-портов из Windows 10 для удалённой работы

Когда человек много лет рыл бункер и запасал там продукты, он должен испытывать глубокое моральное удовлетворение, если бункер понадобился. Он будет довольный заявлять: «А я говори-и-и-ил!» То же касается и того, кто делал запасы продуктов в кладовой, когда все закупались в магазинах только на сегодня. А вот с нашим комплексом для удалённой работы Redd как-то и не хочется злорадствовать. Он проектировался для удалёнки в мирное время. И использовался задолго до первых новостей из Китая.

Давно я про него ничего не писал. Другие проекты отвлекают, да и интерес, судя по рейтингу последней из опубликованных статей, уже упал. Сил на подготовку статьи отнимают много, и это имеет смысл делать только если оно нужно достаточному числу читателей.

Но так как сейчас удалёнка у всех на устах, возникло желание поделиться одной наработкой, которая может кому-то помочь. Это не наша разработка, я проводил исследования в рамках работы над сервисом удаленной работы с отладочными платами All-Hardware. Вот их результаты сейчас и опишу. Проект USB/IP известен многим. Но он давно свёрнут авторами. Самые свежие драйверы были под WIN7. Сегодня я опишу, где скачать вариант для WIN10, и покажу, как я его проверял. Кроме того, разработчики современного аналога уверяют, что у них сделан не только Windows-клиент, но и Windows-сервер (правда, в этом режиме я тестирование не вёл: задача того не требовала). Но кому-то это тоже может оказаться полезным.

Введение

Сначала краткий рассказ, что такое USB/IP. Это комплекс программ, которые позволяют пробросить USB-устройство через сеть. Само устройство подключено к серверу. Клиент располагается на другой машине. При этом на клиентской машине имеется приложение, совершенно не рассчитанное на работу с сетью. Оно хочет настоящее USB-устройство. И оно получает информацию, что это устройство подключено. На это устройство встаёт штатный драйвер. В общем, клиент считает, что он работает с локальным USB-устройством.

Кто-то так пробрасывает ключи защиты. Мы же проверяли возможность удалённого доступа к JTAG-адаптеру.

Проект USB/IP активно развивался до 2013 года. Затем Windows-ветка остановилась. В целом, был выпущен даже двоичный подписанный драйвер. Но он был под Windows 7. Linux-ветка же продолжила развитие, и этот сервис оказался встроенным в саму операционную систему. По крайней мере, в сборку Debian он точно встроен. Причём для Linux имеется и клиент, и сервер, а для Windows исходно был сделан только клиент. Сервер под Windows сделан не был.

Существует очень хорошая статья на Хабре, которую можно использовать и как справочник по работе с данным сервисом, и как отзыв о работе с ним.

Вариант под актуальную версию Windows

Но как бы ни была хороша Windows 7, а она уже мертва. В рамках работ над All-Hardware мы рассматривали разные варианты решения одной из проблем, и надо было просто проверить ряд альтернатив по принципу «подойдёт — не подойдёт». Тратить много человеко-часов на проверку было невозможно. А переделка драйвера под Windows 10 могла затянуть в себя. Поэтому был проведён поиск в сети, который вывел на проект usbip-win. На момент его обнаружения свежий вариант был датирован 23 февраля 2020 года, то есть проект живой. Он может быть собран и под WIN7, и под WIN10. К тому же, в отличие от оригинального проекта, может быть собран не только Windows-клиент, но и Windows-сервер.

Я проверил, проект прекрасно собирается и устанавливается, поэтому дальнейшая работа велась с ним. В файле readme есть ссылка на готовый двоичный код для тех, кто не хочет самостоятельно производить сборку.

Грустная часть проверки: серверная часть

Сначала я расскажу, как проводилась проверка в рамках нашего проекта. Там всё кончилось не очень хорошо. Проверяли адаптер ST-LINK, установленный в корпус комплекса Redd, благо я уже отмечал, что в комплексе используется ОС Linux сборки Debian, а эта сборка содержит встроенный сервис USB/IP.

Согласно статье, устанавливаем сервис:

Дальше в статье подробно рассказано, как автоматизировать процесс загрузки сервиса. Как я разбираюсь в Линуксе, я уже многократно писал. Плохо разбираюсь. У меня нет привычки с умным лицом цитировать чужие тексты, слабо понимая суть. Поэтому я ещё раз напомню ссылку на замечательную статью, где всё рассказано, а сам покажу, что делал я при каждом старте ОС (благо всё было нужно только для проверки):

Назначение первых двух из вышеприведённых заклинаний мне неизвестно, но без них не создаются какие-то каталоги, а без этих каталогов потом не будет экспорта USB-порта. Каталоги создаются только до перезапуска системы. Так что создавать их надо каждый раз. Третья строка — с нею всё понятней, она запускает сервис.

Теперь смотрим, как зовут устройство:

Получается, что нам нужно устройство и busid, равным 1-5.4.1.3.

Всё, сервер готов к работе.

Грустная часть проверки: клиентская часть

В Windows устанавливаем драйвер (делаем это только один раз, дальше он будет всегда установлен). Для этого запускаем от имени администратора файл usbip.exe с аргументом install:

Теперь смотрим, доступно ли нам устройство:

Убеждаемся, что оно присутствует в списке. Ну, и подключаем его:

В менеджере устройств появляется новое USB-устройство, Keil его прекрасно видит…

Но на этом всё приятное кончается. Небольшая программа заливается во флэшку около минуты. Попытки шагать по строкам идут от 5 до 20 секунд на каждую строку. Это неприемлемо. Во время паузы в обе стороны идёт трафик примерно 50 килобит в секунду. Долго и вдумчиво идёт.

Честно говоря, ограничение по времени привело к тому, что я только предполагаю, почему всё было так плохо. Подозреваю, что там по сети бегает JTAG-трафик. А он бегает небольшими пакетами в обе стороны, отсюда и проблемы. Так было завершено исследование с результатом: «Для проекта не подходит».

Более весёлая часть: подготовка

Ещё тогда мне запало в голову, что я краем глаза видел, что в JTAG-адаптере CMSIS DAP по USB ходит не чистый JTAG-трафик, а команды. Сам JTAG-трафик формируется уже внутри адаптера. Давно хотел проверить это, да всё руки не доходили. Массовый перевод на удалёнку заставил это сделать (возникла задачка). Что такое CMSIS DAP? Это JTAG-адаптер, рекомендованный самой компанией ARM для контроллеров Cortex-M. Исходные коды для разных контроллеров выложены на GitHub, можно спаять адаптер на базе любого из них. Я сейчас дам ссылку на клон проекта, адаптированный под макетную плату «Голубая пилюля»: https://github.com/x893/CMSIS-DAP, но поисковые системы могут вывести и на официальный аккаунт ARM.

Чтобы не тратить на сервер целую PC, для проверки, я сделал этакий комплекс Yelloww (чисто по цвету пластика, из которого сделан корпус):

Роль сервера выполняет Raspberry Pi с установленной ОС Raspbian (это тот же Debian, а значит, там имеется требуемый сервер). Одна из «голубых пилюль» выступает в роли адаптера CMSIS DAP, вторая — в роли отлаживаемого устройства.

Точно так же ставим и настраиваем сервис. Разве что здесь список устройств, допустимых к экспорту, намного скромнее:

Понятно, что здесь экспортируем и импортируем устройство busid=1-1.4.

И вот тут конкретно с CMSIS DAP у меня периодически возникает небольшая проблемка. В менеджере устройств я вижу такую неприятность:

Напомню, что статья пишется по принципу «Лучше неплохая, но сегодня, чем идеальная, но завтра». Проблемы удалённой работы возникают прямо сейчас. Надеюсь, в обозримом будущем они уже будут не актуальны. А пока актуальны — показываю, как я обхожу данную проблему вручную. Сначала я отключаю устройство:

Затем сразу же включаю:

И оно начинает работать без проблем. В Keil меняем отладчик на CMSIS DAP:

При работе по локальной сети всё просто летает. Но понятно, что локальная сеть никому не интересна. Я попробовал пробросить порт устройства у себя дома, а затем удалённо зайти на машину на работе и потрассировать «прошивку» оттуда. Связь у моего домашнего провайдера весьма и весьма тормозная, особенно — от меня наружу. Прошивается контроллер примерно втрое медленнее, чем при прямом подключении к USB. Трассировка… Ну около секунды на строку, точно не больше. В общем, терпимо. С хорошими провайдерами, надеюсь, будет лучше.

Заключение

Проект usbip-win является современной заменой для проекта USB/IP. Он живёт и развивается. При этом он предоставляет для ОС Windows не только функцию клиента, но и функцию сервера. Совместимость с Linux-версией сохранена.

Устойчивость работы удалённого USB-устройства неожиданно поразила. Я был уверен, что возникнут таймауты. Возможно, где-то они и возникнут, но для JTAG-адаптеров не было замечено ни одного сбоя. К сожалению, не все USB-устройства могут быть проброшены через сеть по причине низкого быстродействия получившейся системы. Но в случае с JTAG-адаптерами можно рассмотреть альтернативные вещи. В частности, CMSIS-DAP вместо ST-LINK.

Оба рассмотренных проекта (usbip-win и CMSIS-DAP) могут быть скачаны с GitHub в виде исходных кодов.

Если это поможет кому-то организовать удалённый доступ к оборудованию, я буду рад. Использование Raspberry Pi позволит бросить оборудование в произвольных местах.

Windows-терминалы WTware

Программа-клиент службы терминалов Windows Terminal Services, для бездисковых терминалов и загрузки по сети. Основной сайт http://www.wtware.ru

Перенаправление USB возможностями RDP 8

Перенаправление USB возможностями RDP 8

Сообщение d@vinchi » Вс янв 11, 2015 4:27 pm

Re: Перенаправление USB возможностями RDP 8

Сообщение aka » Вс янв 11, 2015 7:46 pm

Re: Перенаправление USB возможностями RDP 8

Сообщение Гость » Пн янв 12, 2015 5:57 pm

Re: Перенаправление USB возможностями RDP 8

Сообщение aka » Пн янв 12, 2015 8:43 pm

Re: Перенаправление USB возможностями RDP 8

Сообщение Гость » Пн янв 12, 2015 10:01 pm

Re: Перенаправление USB возможностями RDP 8

Сообщение Rushmore » Вт янв 13, 2015 1:19 am

Re: Перенаправление USB возможностями RDP 8

Сообщение Гость » Вт янв 13, 2015 2:50 am

Re: Перенаправление USB возможностями RDP 8

Сообщение aka » Вт янв 13, 2015 3:22 pm

У тебя есть Hyper-V на 2012R2. У него какие-то настройки для RemoteFX или перенаправления USB делались? Роли какие-то кроме Hyper-V руками ставились?

Под хостом стоит гостевой 2012R2, так? Обновления ставил или только дистрибутив? У него какие-то настройки для перенаправления USB делались?

Re: Перенаправление USB возможностями RDP 8

Сообщение aka » Вт янв 13, 2015 3:28 pm

Re: Перенаправление USB возможностями RDP 8

Сообщение Rushmore » Вт янв 13, 2015 4:38 pm

Re: Перенаправление USB возможностями RDP 8

Сообщение Гость » Ср янв 14, 2015 11:24 am

Re: Перенаправление USB возможностями RDP 8

Сообщение aka » Ср янв 14, 2015 3:01 pm

Re: Перенаправление USB возможностями RDP 8

Сообщение Гость » Ср янв 14, 2015 4:53 pm

Re: Перенаправление USB возможностями RDP 8

Сообщение aka » Ср янв 14, 2015 9:38 pm

У меня получилось камеру пробросить, скайп её увидел.

А звук не получилось: USB устройство на сервер передалось, но в список устройств для воспроизведения не добавилось. Что я делаю не так?

Re: Перенаправление USB возможностями RDP 8

Сообщение Rushmore » Чт янв 15, 2015 12:43 am

Проверь, что сервайс Windows Audio запущен. В свойствах соединения проверь, не запрещено ли воспроизведение видео/аудио.

У меня есть проблемы с пробросом композитных устройств (МФУ). Некоторые устройства не желает пробрасывать никак.

Re: Перенаправление USB возможностями RDP 8

Сообщение Гость » Чт янв 15, 2015 2:11 am

[quote=»aka»]У меня получилось камеру пробросить, скайп её увидел.

А звук не получилось: USB устройство на сервер передалось, но в список устройств для воспроизведения не добавилось. Что я делаю не так?[/quote]
Да. первом делом надо сделать так чтобы звук пошел при обычных настройках, без всяких перенаправлений. А вот чтобы звук пошел в USB устройство, над на стороне клиента выставить параметры перенаправления аудио в «Проигрывать на удаленном компьютере», а USB устройство отметить для перенаправления, только в этом случае вывод аудио пойдет в USB-устройство. Я как раз об этом писал выше. Т.е. штатный виндовый клиент создает один аудио-канал между клиентом и сервером, и отдает его на стороне клиента либо в звуковую карту, либо в USB-устройство. Если созвать два аудио-канала и обеспечить возможность в настройках клиента привязывать ети каналы на разные аппаратные ресурсы ввода аудио, то можно будет в удаленной сессии назначать разные аудио-устройства разным приложениям, например, колонки системе, а usb-гарнитуру скайпу. Вот это будет мега вещь, т.к. такого можно добиться только локально, и даже полноценный вндовый клиент такого не позволяет.
Кстати вебка прокидывается в удаленную сессию на низком уровне, что создает трафик порядка 30-40 Мб и нехилую нагрузку на проц, а во если бы WTware принимала поток с веб-камеры, аппаратно его кодировала в Н.264, и гнала в сессию уже Н.264, то это был бы предел мечтаний.

Re: Перенаправление USB возможностями RDP 8

Сообщение aka » Чт янв 15, 2015 9:42 am