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

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

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

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



    Предыдущие статьи цикла
    1. Разработка простейшей «прошивки» для ПЛИС, установленной в Redd, и отладка на примере теста памяти.
    2. Разработка простейшей «прошивки» для ПЛИС, установленной в Redd. Часть 2. Программный код.
    3. Разработка собственного ядра для встраивания в процессорную систему на базе ПЛИС.
    4. Разработка программ для центрального процессора Redd на примере доступа к ПЛИС.
    5. Первые опыты использования потокового протокола на примере связи ЦП и процессора в ПЛИС комплекса Redd.
    6. Веселая Квартусель, или как процессор докатился до такой жизни.
    7. Методы оптимизации кода для Redd. Часть 1: влияние кэша.
    8. Методы оптимизации кода для Redd. Часть 2: некэшируемая память и параллельная работа шин.
    9. Экстенсивная оптимизация кода: замена генератора тактовой частоты для повышения быстродействия системы.
    10. Доступ к шинам комплекса Redd, реализованным на контроллерах FTDI
    11. Работа с нестандартными шинами комплекса Redd
    12. Практика в работе с нестандартными шинами комплекса Redd


    Введение


    Сначала краткий рассказ, что такое 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.

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

    sudo apt-get update 
    sudo apt-get upgrade 
    sudo apt-get install usbip

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

    sudo modprobe usbip-core
    sudo modprobe usbip-host
    sudo usbipd -D

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

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

    user@redd:~$ sudo usbip list -l
    - busid 1-3 (046d:082d)
       Logitech, Inc. : HD Pro Webcam C920 (046d:082d)
    
     - busid 1-4 (1366:0101)
       SEGGER : J-Link PLUS (1366:0101)
    
     - busid 1-5.1 (067b:2303)
       Prolific Technology, Inc. : PL2303 Serial Port (067b:2303)
    
     - busid 1-5.4.1.1 (0483:5740)
       STMicroelectronics : STM32F407 (0483:5740)
    
     - busid 1-5.4.1.3 (0483:3748)
       STMicroelectronics : ST-LINK/V2 (0483:3748)
    <...>

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

    Даём команду:

    sudo usbip bind --busid=1-5.4.1.3

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

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


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

    usbip.exe install

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

    usbip.exe list --remote=192.168.10.123

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

    usbip.exe attach --remote=192.168.10.123 --busid=1-5.4.1.3

    В менеджере устройств появляется новое 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, вторая — в роли отлаживаемого устройства.

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

    pi@raspberrypi:~ $ sudo usbip list -l
     - busid 1-1.1 (0424:ec00)
       Standard Microsystems Corp. : SMSC9512/9514 Fast Ethernet Adapter (0424:ec00)
    
     - busid 1-1.4 (c251:f001)
       Keil Software, Inc. : unknown product (c251:f001)

    Понятно, что здесь экспортируем и импортируем устройство 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 позволит бросить оборудование в произвольных местах.
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 15

      0
      Очень важная статья, на самом деле. Ну лично я просто использовал RDP
        0
        Если есть такая возможность — однозначно.

        Но в первую очередь, Малину можно положить рядом с поделкой, с которой слишком круто оставлять настольную машину. Она маленькая, и цена у неё не такая кусачая (тем более, что по сусекам многие могут наскрести даже не одну валяющуюся без дела Малину).

        Плюс иногда RDP подтормаживает. Понятно, что и отладка будет при тех же условиях не идеальной. Но разработка текста идёт дольше по времени, чем связь в процессе отладки.

        В общем, RDP — лучше в целом, а этот подход — может пригодиться в особых случаях.
          0
          Я почти десять лет назад тут писал о том как удалённо отлаживать железо :) habr.com/ru/post/118773. Только у меня была другая проблема: я был на работе, а железо дома.
        0

        Спасибо, актуально, OpenOCD для удалённой отладки не пробовали использовать, вроде бы норм.

          0
          Исследование велось для Кейла, а он с OpenOCD не дружит. В этом его главная проблема. Из сетевых он дружит с J-LINK, но по факту, работа по сети именно из Кейла с JLINK — абсолютно нестабильная. Постоянные сбои.
          0
          А если через JLinkRemoteServer.exe?
            0
            Когда JLINK работает по сетке с удалённым сервером средствами Эклипсы и IAR, он не работает средствами Кейла при тех же условиях. Возможно, когда-нибудь я сделаю большую статью на эту тему, мы нашли даже наиболее вероятную причину… Виноваты потери пакетов в UDP. Просто я запускаю сервер на той же машине, что и компилятор — если обращаюсь к localhost — всё работает, если по локальному IP — уже сбои!!! И это в домашней сети при отсутствии других активных устройств и при связи с роутером по кабелю (в реальной конторской сетке — и подавно)! Это именно из Кейла, из других сред всё в порядке.

            Причём мы пытались общаться с поддержкой как Segger, так и Кейла. Сделали для них подробное описание, сняли кино с показом, когда работает, когда — нет… Сеггеры сказали, что хоть у нас и подлинный адаптер, но эта модель не подразумевает поддержки. Кейлы сказали, что DLL для связи делали Сеггеры, так что они бы и рады, да ничего сделать не могут. Обращайтесь к Сеггерам.

            А через туннельный сервер Сеггеровский — ещё веселей. Вот ответ поддержки Кейла:

            But the tunnel server mode doesn't work. The reason is due to that the dialog «Options for Target — Debug — Settings» in uVision you cannot define the serial number of the J-Link, unlike the jlink command line utility by calling ip tunnel:. Thus, even uVision can connect to the segger server, but it cannot connect to your j-link, because serial number is missing.
              0
              STLink это конечно специфично, а вот проброс USB-токенов для подписи документов в налоговую/банк — это актуально для тысяч конторок с зарубежными терминальными серверами для бухгалтерии. Если Ваш вариант это поддерживает — это реально поможет простым женщинам из бухгалтерии.
                0
                Честно говоря, проброс по сети отлично работал давным давно и ничего не терялось и работало по TCP. Правда, помнится, пришлось пачку скриптов инициализации и загрузки написать, но на выходе был полный успех.
                  0
                  Именно с Кейлом? С другими средами разработки проблем нет, но в рамках All-Hardware надо было учиться поддерживать все популярные среды, вот и разбирались со всеми…
              +2
              Я давно пользуюсь free версией VirtualHere: VirtualHere allows USB devices to be used remotely over a network just as if they were locally connected!
              Есть сервера и клиенты для достаточно большого количества операционок и архитектур.
              Пока выявлена только одна проблема — неустойчивая работа программы Quartus Signal Tap для FPGA от Intel.
                0
                Прикупил вот такую штуку:
                SILEX SX-3000GB Device Server — New in Box
                Рекламная фотка
                image

                Работает только по Виндой и МакОСью, но последнее не пробовал.
                Флешки, диски, РуТокен, клавы-мыши работают. Можно подключать девайсы используя хаб. Доступ монопольный для конкретного устройства.
                  0
                  Пользуемся AnywhereUSB для проброски токенов — тоже всё отлично работает :)
                  0
                  Мы с прошлого года так научились отлаживать устройства, подключенные в Китае из РФ. Работает, конечно, медленно и психологически неудобно. Но это лучше, чем ждать пока в РФ приедет.
                    0
                    пользовался INU от seh-technology, никаких проблем под Windows 10

                    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                    Самое читаемое