Пробросить com-порт из линукса в винду

Есть один компьютер с archlinux. На нем запущена виртуалка с windows 7 с помощью qemu-kvm. К компьютеру подключен переходник USB-to-serial, который виден в линуксе как /dev/ttyUSB0.

Пытался пробросить его c помощью

Пытаюсь пробросить непосредственно tty устройство как с помощью

Что я не так делаю? Может у кого-нибудь получалось успешно пробросить com-порт?

А права у пользователя на COMпорт есть?

Qemu запускаю из-под рута

Упс. Стоит опция «-runas » )

А какой вариант правильный для проброса -serial /dev/ttyUSB0 или -chardev serial,id=tty1,path=/dev/ttyUSB0 не знаешь? В интернете что-то вообще нет информации по этой теме

Не, по qemu не подскажу, пробрасывал только в wine или vbox.

У tty-устройств группа uucp. Сделал chown /dev/ttyUSB0 — не помогло

в убунте похоже tty и dialout. Всеравно лучше бы в группу добавил, мало ли где еще она требуется

Я пробрасывал тупым -serial /dev/ttyS0 . Причём в эмулируемой системе порт был на совсем другом чипе, но на удивление всё работало.

Здравствуйте. у меня та же беда, пытаюсь порт КОМ пробросить для Виндовской утилиты работы с терминалом не подскажете как быть?

Есть машина на ней стоит Ubuntu к машине подключено оборудование, типа кассового аппарата. аппарат соединен ЮСБ кабелем с компьютером, но это как бы COM Порт для аппарата. Программа, специально написанная под линукс, работает по этому порту. В ее настройках так и прописано: /dev/ttyACM0

Есть утилиты, для работы с этим оборудованием, но они под ВИНДОВС. WINE я установил утилиты запускал, но не к чему конектиться, как таковых COM портов нет ладно, создал: ln -s /dev/ttyACM0

/.wine/dosdevices/com3 Запускаю утилиту — ТОЛКУ НОЛЬ, не видит. Скачал программу тестирования ком портов — запускаю. облом, не может проверить подскажите, как заставить ВИНДОВСКИЕ утилиты конектиться к оборудования через COM Порт в линухе ?

Может /dev/ttyACM0 надо настроить. Утилитой stty выставить скорость, четность, итд

Попробовал пробпросить СОМ порт через TCP/IP Сделал так (на одно машине, с себя на себя через ВАЙН):

1) Прописал COM7 ( ln -s /dev/ttyACM0

2) Сервер (к нему подключен фискальный регистратор): socat tcp-l:5555,reuseaddr,fork file:/dev/ttyACM0,raw

3) Клиент, на котором из-под wine работает Программа с com7: (тот же ПК, но под ВАЙН) socat pty,link=$HOME/.wine/dosdevices/com7,raw tcp:192.168.1.23:5555,mss=1400

После прописывания СОМ7 в п 1, при подключении утилиты к регистратору получил сообщение: «НЕВЕРНЫЙ» После пункта 2 = «НЕВЕРНЫЙ» После пункта 3 = «client parameter is incorrect» подключиться опять не удалось, но уже красивше ))) подскажите кто-то что-то еще.

Зачем именно 7? Винда-вайн точно умеет 7? Может,

Информационный портал по безопасности

Проброс COM-портов из Linux в Windows

Автор: admin от 20-08-2011, 05:29, посмотрело: 13 240

Доброго времени суток уважаеме хабра-сообщество! Сегодня как вы уже догадались мы поговорим о так называемом «пробросе» старого доброго COM-порта из среды Linux в среду Windows. Использовать будем по возможности бесплатные программы ( их будет несколько со стороны Windows ).

Linux

После установки пакета в конфигурационном файле необходимо добавить интересующее устройство и описать параметры подключения.

Так выглядит фаил настроек до внесения изменений (коментарии от автора)

# Банер — эта строчка выдается в TCP порт клиенту при подключении и может содержать, порт, скорость
# работы с текущим портом и имя устройства в системе. Вывод банера актуален скорее для telnet метода
# подключения к порту, нам он не нужен. Можно закоментировать строчку, чтоб не мазолила глаз.

BANNER:banner:rnser2net port p device d [ s ] ( Debian GNU / Linux ) rnrn

# Параметры для подключения к портам /dev/ttyS0 и /dev/ttyS1
# Конфиг ниже имеет следующий формат:
# TCP port : state : timeout : device : options (option1 option2 — через пробел)

# TCP port — тут все ясно, это порт который будет слушать наш сервер.

# State — может принимать значение raw или rawlp или же telnet. Так же может быть off.

# Timeout — время ( в секундах ) по истечении которого клиент будет
# отсоединен при неактивности. Значение 0 отключает функцию.

# Device — тот самый девайс который хотим «вывесить» наружу. Пишем тут нечто похожее на:
# /dev/ttyS0 или /dev/ttyUSB0

# Options — устанавливает дополнительные параметры работы с портом. Все параметры переводить не буду
# в конфиге все прекрасно изложено.

# Настройки по-умолчанию:
2000 :telnet: 600 : / dev / ttyS0: 9600 8DATABITS NONE 1STOPBIT banner
2001 :telnet: 600 : / dev / ttyS1: 9600 8DATABITS NONE 1STOPBIT banner
3000 :telnet: 600 : / dev / ttyS0: 19200 8DATABITS NONE 1STOPBIT banner
3001 :telnet: 600 : / dev / ttyS1: 19200 8DATABITS NONE 1STOPBIT banner
# Как мы можем видеть, тут настроены 2 физических COM-порта
# И 4 типа подключения к ним на разных скоростях и портах соответственно.

А так настройки выглядят у меня

В нашем случае тип связи с портом будет RAW. Таймаут 0. Скорость необходимая моему устройству 9600. Четность не проверять. Стоп бит один. Биты данных 8-ми битные. XON/XOFF выключено. Аппаратное управление потоком выключено. Мониторинг модемных линий DTR — как я понял. Конфиг маленький, при возникновении проблем смотрим в syslog.

После внесения необходимых изменений сохраняем фаил настроек и перезагружаем демона:

Проверяем логи — убеждаемся, что демон запустился и слушает порт. После чего откладываем терминал в сторону впереди Windows…

Windows

HW Virtual Serial Port

На страничке проекта ser2net эта программа указана как совместимая, жаль что начал я в первый раз не с нее.Нас интересует HW VSP Singleport — так как multiport версия поддерживает только устройства от HW Group и в наших целях непригодна. Программа поддерживает Windows 7 и x64 битные платформы. Ограничением является лишь то, что с её помощью мы сможем «пробросить» только 1 COM-порт. Для желающих на сайте можно приобрести HW VSP3 Source codes.

Во время установки нас интересует установка сервиса и GUI к нему. После установки запускаем программу из меню пуск или рабочего стола и нажимаем login. Пароль будет уже введен и останется только нажать на OK. Для начала переходим во вкладку Settings и отмечаем галочку Create VSP Port when HW VSP Start-up ( по желанию конечно, но очень часто бывает нужно ). Сама программа при этом может быть закрыта, работу выполняет сервис который можно обнаружить в остнастке Windows (Пуск-Выполнить: services.msc).
Далее переходим во вкладку Virtual Serial Port. Назначим номер виртуального COM-порта на который будет подключен наш удаленный порт. Далее вводим IP и Порт нашего сервера с ser2net демоном (см. картику выше). И нажимаем Create COM. В LAN статусе вскоре должно загорется Connected, а в VSP статусе Created. Порт подключен и готов к соединению. Скачать

MCSI2000

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

По окончании установки появится диалог добавления виртуального порта. Указываем номер виртуального порта в системе. Выбираем Direct ( Прямое подключение, без автообнаружения ) вбиваем IP нашего сервера. Тип подключения RAW, порт соответствующий вашим настройкамв ser2net и нажимаем Add. Программа установки предложит вам добавить еще один порт. Когда все порты добавлены кликаем Done, после чего программа установки предложит перезагруить компьютер. Из потенциальных минусов — отсутствие поддержки x64 и Windows 7. Из плюсов — можно добавить немалое колличество портов. Скачать

Tibbo Device Server Toolkit

Принципиально настройка ничем не отличается от предедущих. После установки запускаем из меню пуск Tibbo VSP Manager и кликаем Add. Одним из плюсов этой программы является возможность сохранить профиль подключений. В том числе и сопоставить с пользователем, что бывает очень удобно. Устанавливаем номер виртуального порта, Connection mode: immediatly, On-the-fly-commands: disabled, а так же IP адресс и порт сервера.

К сожалению у меня данная программа не заработала. Вот что я увидел заглянув в Диспетчер устройств.

Проверить на чем либо другом, как я уже писал — у меня нет возможности.
Скачать (необходима регистрация)

Все вышеперечисленные программы не позволяют в данной конфигурации использовать RTS вывод COM. Для получения данного функционала необходимо установить полностью соместимое ПО как на Windows хост так и на Linux. Либо использовать специализированое железо aka Serial to Ethernet.

Спасибо max_rip за наводку в Q&A и всем кому данный пост был интересен. Успехов!

Porting an application from Linux to Windows [closed]

Want to improve this question? Update the question so it focuses on one problem only by editing this post.

Closed 7 years ago .

I have one application, which has been developed on Linux (gcc based), I need to port the entire application to Windows.

Can you suggest me which tool/interface should choose to build the environment?

If I choose Visual Studio, will it support GCC compiler tool chain or which one is suitable among MinGW and Cygwin ?

Please give me some Inputs and the challenges will there while porting.

2 Answers 2

I would recommend an abstraction layer for all your OS-dependent routines. You then provide two implementations of those routines. One for Linux, one for Windows, and you compile one or the other depending on the current platform. You should keep the portable code well separated from the platform-specific code.

Of course you could also use an already existing platform abstraction layer, like Qt’s Core module (which provides abstractions for threading and I/O) or the Network module, which provides portable networking. Of course I cannot determine whether this is suitable in your case or not, since I don’t know what kinds of system calls you need or if C++ is even acceptable, but it might be worth looking into it (or other similar portability libraries.)

As a compiler, you can actually build the Windows binaries under Linux. I’ve been doing that for a long time now, since I’m not a Visual Studio kind of guy. I prefer the likes of CMake or Autotools. For that, I recommend MXE.

Best environment to port C/C++ code from Linux to Windows

I’d like to make a big project of mine buildable on Windows platforms. The project itself it’s written in C/C++ following POSIX standards, with some library dependencies such as libxml2, libcurl and so on. I’m more a Linux developer rather than a Windows developer, so i have no idea of which compiler suite i should use to port the code. Which one offers more compatibility with gcc 4.4.3 i’m using right now?

My project needs flex and bison, is there any «ready to use» environment to port such projects to windows platforms?

4 Answers 4

If it were me, I would install the following:

MinGW port of the GCC compiler from Twilight Dragon (this is only at 4.4.1 at present, but I’d guess it will meet your needs, and I’ve found it to be very reliable)

This is effectively the environment I do my own programming in, and it works very well. If you want an IDE, I’d recommend Code::Blocks, but both gvim and emacs are available for Windows too.

If you don’t use any UNIX system calls so you can run on Windows freely. There are flex & bison for windows too: http://gnuwin32.sourceforge.net/packages.html . You can go ahead with MinGW: http://www.mingw.org/ .

If you have UNIX system calls, then you have to use cygwin: http://www.cygwin.com/ , http://en.wikipedia.org/wiki/Cygwin .

I very much doubt either cygwin nor mingw is up to 4.4.3 yet. I would bet on being able to upgrade the compiler in mingw to be easier.

You’ll need cygwin if you’re actually using any Linux specific stuff. The libraries you listed off aren’t an issue I don’t think. POSIX could be, depending.

A nice new alternative is Cygnal. The basic idea:

• First, compile the code under Cygwin for Cygwin itself using its «native» toolchain (not MinGW).
• Next, deploy the program with the Cygnal version of the Cygwin DLL.

Cygnal is a fork of the primary Cygwin DLL which changes certain behaviors which are too Unix like.

Cygwin’s motto is «get that Linux feeling on Windows». Cygnal tones down that feeling; it brings back some of the Windows feeling to programs, so that those programs work for Windows users outside of the Cygwin environment using Windows conventions.

Programs understand native paths, and such. None of the rich API functionality in Cygwin is removed, only a small portion of it is adjusted.

Перекрестное опыление: управляем Linux из-под Windows, и наоборот

В прошлой статье я обещал рассмотреть механизм удаленного подключения с Windows на серверы под управлением *nix, и наоборот при помощи PowerShell. Обещанного обычно ждут три года, но я успел чуть раньше. Что ж, если хочется с верного макбука управлять гетерогенной инфраструктурой, или наоборот ― с Surface Pro рулить Linux-серверами без всяких putty, ― прошу под кат.

Microsoft Loves Linux

Еще в 2015 году Microsoft торжественно объявила о запуске программы «Microsoft Linux». Сюда вошла как банальная поддержка гостевых *nix-like OS на Hyper-V, так и встроенная в Windows 10 Ubuntu и возможность запуска в Docker продуктов Microsoft, таких как SQL Server.

Компания также опубликовала исходный код PowerShell, что позволило запускать «Ракушку Мощи» не только на Windows. Из-под одноименного аккаунта на Github, помимо исходного кода, выложены и бинарники под большинство современных систем (лицензия MIT).

Это позволяет настроить удаленное управление с помощью единого инструмента ― PowerShell. Помимо подключения к консоли компьютера, можно запускать отдельные команды, в том числе и на нескольких серверах одновременно. Довольно удобно для автоматизации задач администрирования, таких как массовое изменение настроек, инвентаризация, сбор логов.

Порой удобно совмещать традиционные консольные команды со вставками PowerShell:

Для подключения к Windows-машинам при помощи PowerShell используется протокол WS-Man. Для GNU\Linux привычен SSH. Так как сегодня становятся универсальными оба протокола, разберем их подробнее.

PowerShell 6.0 под Windows и *nix, пока еще находится в бете. Поэтому не рекомендую без хорошего тестирования применять на боевых серверах описанное ниже.

Магомед не идет к горе

Когда технология удаленного доступа при помощи PowerShell только набирала обороты, единственным универсальным способом подключения к разным системам был протокол WS-Man. Для тестового стенда я взял Windows Server 2016 и Centos 7, для которых и буду настраивать возможность удаленного подключения и выполнения команд при помощи этого протокола.

Для начала установим на Centos свежий PowerShell:

После установки появилась возможность запускать привычные Windows-администратору командлеты. Например, посмотрим версию PS и получим список запущенных процессов командлетами $PSVersionTable и Get-Process:

Работаем в консоли PowerShell на CentOS.

Чтобы подключаться к Linux-машине с консоли Windows, нам понадобится установить и настроить:

• OMI (Open Management Infrastructure) ― адаптация WMI, которую также можно использовать для управления компьютерами с ОС, отличными от Windows;
• PSRP (PowerShell Remoting Protocol) ― библиотека, необходимая для удаленного подключения PowerShell.

Подробно с работой и эволюцией OMI и PSRP можно ознакомиться в отличном материале от Matt Wrock, я же просто установлю OMI командой:

Далее нужно настроить порты и аутентификацию в конфигурационном файле /etc/opt/omi/conf/omiserver.conf, после чего перезапустить сервер командой:

Для упрощения эксперимента я не буду настраивать ни NTLM-аутентификацию, ни Kerberos. Еще и шифрование отключу ― разумеется, в боевой среде делать этого не стоит. Для включения текстовой аутентификации и шифрования на стороне Windows в работе winrm достаточно выполнить следующие команды:

После настройки можно проверить работу OMI из консоли Windows:

Подключаемся к CentOS из cmd.

Теперь проверим работу обратным подключением ― из Linux к Windows:

… а затем с CentOS подключаемся к Windows.

После того, как WMI\OMI заработал, нужно установить и настроить PSRP. К сожалению и вопреки инструкции, бинарник отсутствует. Библиотеку пришлось компилировать, долго и нудно исправляя возникающие ошибки зависимостей:

Теперь мы сможем подключаться с Windows на Linux и наоборот при помощи PowerShell. Начнем с Windows на Linux:

С Windows на Linux.

Аналогичным образом можно провести и обратное подключение.

Invoke-Command можно «натравить» на список компьютеров, и с рабочей станции Windows создать пользователя на всех серверах Linux командой вида:

Надо сказать, что способ не самый удобный и эффективный. Минусов добавляет компиляция библиотек, разнообразные баги ― например, на момент написания статьи PSRP не позволял нормально подключиться из Linux в Windows.

Да и сами разработчики рекомендуют не плясать вокруг WS-Man, а обратиться к проверенному способу ― SSH. Что ж, попробуем и его.

Гора идет к Магомету

На этот раз машина с Windows получит чуть больше специфической подготовки ― нужно установить свежий PowerShell и OpenSSH.

После можно проверить синтаксис командлета New-PSSession. Если все произошло как надо, то командлет, помимо привычного параметра ComputerName, будет поддерживать и HostName.

PowerShell 6.0.0-beta.9 и обновленный синтаксис командлета.

Качаем последний релиз или используем пакет из репозитория Chocolatey. Все это разархивируем в \Program Files\OpenSSH.

В консоли с правами администратора переходим в папку с разархивированным содержимым и запускаем установку командой:

Теперь генерируем ключи:

В тестовой среде мы будем использовать парольную аутентификацию, поэтому стоит убедиться что она включена в файле sshd_config:

Если вы также хотите автоматически запускать PowerShell при подключении по SSH, то в параметре subsystem нужно прописать путь к желаемой версии PS:

Для работы клиента SSH нужно добавить директорию в %PATH% любым удобным способом. Например, таким:

Остается только настроить и запустить службы:

После установки уже можно наслаждаться подключением к серверу Windows по ssh.

C Windows через Putty на Linux, с Linux обратно на Windows по SSH.

На достигнутом останавливаться не будем и перейдем к настройке Linux. При настройке сервера SSH по умолчанию достаточно прописать PowerShell в Subsystem:

Теперь проверим подключение через командлет New-PSSession и Invoke-Command.

Работаем из PowerShell с Linux-сервером.

Теперь подключимся из Linux к Windows:

Работаем из PowerShell с Windows-сервером.

В отличие от WS-Man, SSH настраивается намного проще и работает стабильнее. Да и беспарольное подключение по ключам настраивать привычнее.

В хозяйстве пригодится

С однозначным «советом потребителю» все опять сложно: SSH проще в настройке и стабильнее, но WS-Man использует API и позволяет применять инструменты вроде JEA. На боевых серверах использовать WS-Man я бы не стал однозначно, а вот реализация OpenSSH в Windows как сервера, так и клиента мне понравилась. Для самопальной автоматизации вполне подойдет даже без PowerShell.

В любом случае, границы между Linux и Windows хоть и медленно, но начинают стираться, что безусловно радует.