Moxa nport linux driver

Вики IT-KB

Пошаговые руководства, шпаргалки, полезные ссылки.

Инструменты пользователя

Инструменты сайта

Боковая панель

Содержание

Трансляция COM-порта с устройства Moxa Nport 5610 в виртуальную машину с Linux Debian 8 (Jessie)

В этой статье описан пример того, как GSM-модем, подключенный к физическому COM-порту (RS-232) устройства Moxa NPort транслировать в виртуальную машину с гостевой ОС Linux Debian 8 (Jessie). В данном примере используется устройство Moxa NPort 5610 8-Port RS-232 Device Server (с прошивкой версии 3.8 Build 17030709).

К одному из COM-портов устройства (в нашем примере это будет порт 2) подключаем GSM-модем. В данном случае в качестве модема используется терминал Siemens TC35i Terminal.

Настройка COM-порта на устройстве Moxa Nport

Переходим в веб-консоль управления устройства Moxa NPort и в разделе Serial Settings > Port 2 настраиваем параметры порта в соответствии со спецификацией поддерживаемых режимов работы подключенного к порту устройства:

Затем переходим в раздел веб-консоли Operating Settings > Port 2 и устанавливаем режим работы порта как Real COM Mode

Далее переходим в раздел веб-консоли Accessible IP Settings, включаем опцию Enable the accessible IP list и в табличной части указываем IP-адресы хостов, которые могут подключаться к нашему устройству Moxa NPort для трансляции COM-портов по сети. То есть, в нашем случае, здесь указывается IP-адрес виртуального Linux-сервера, в который мы в дальнейшем будем подключать транслируемые COM-порты. Дополнительно о настройке данного ограничивающего доступ списка можно почитать в Moxa FAQ.

Внимание!
Если на устройстве опция Enable the accessible IP list ранее не была включена, то при её включении после нажатия кнопки Submit устройство Moxa NPort будет автоматически перезагружено.

Поиск и получение драйвера Moxa Nport для Linux

Все драйверы, которые должны устанавливаться в систему, принимающую по сети транслируемые COM-порты можно найти на официальном сайте Moxa в разделе Support. В частности для Linux-систем драйвер для нашей модели доступен по ссылке

На данный момент нам доступен старый драйвер: NPort Real TTY Driver for Linux — Edition 1.18 — Released on Mar 20, 2012
В заметках к драйверу, которые доступны по ссылке есть информация о том, что данная версия драйвера поддерживает ядро Linux Kernel до версии 3.1.0-7. В нашем же случае используется более новая версия ядра, установленная из официальных репозиториев Debian Jessie:

Сразу скажу, что драйвер со страницы загрузки у меня даже не установился. Поэтому пришлось воспользоваться более свежей версией драйвера, которую удалось обнаружить на форуме Moxa в ветке Установка Real TTY Driver в Debian. Действующая на данный момент ссылка на файл, опубликованная в этой ветке: npreal2_1.18.65_build_17062316.tgz

Установка драйвера Moxa Nport на стороне Linux Debian

Переходим на наш виртуальный сервер с Debian Jessie, и распаковываем в отдельный каталог загруженный по указанной ранее ссылке драйвер:

Ознакомится с документацией, поставляемой с драйвером можно в файле README.TXT в распакованном подкаталоге с драйвером:

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

Переходим в каталог с распакованным драйвером и запускаем скрипт установки с ключом m64 , так как в нашем случае используется 64-битная ОС Linux:

Вывод скрипта установки будет примерно таким:

После успешного окончания установки все инструменты управления драйвером мы можем найти в каталоге /usr/lib/npreal2/driver . В частности, нам могут быть полезны утилиты:

Обратите внимание на то, что в в последующем, в случае обновления ядра Linux, может потребоваться повторное выполнение утилиты mxinst, так как модуль ядра npreal2 может перестать загружаться.

Подключение портов Moxa Nport на стороне Linux Debian

Итак, давайте подключим COM-порт c устройства Nport с помощью утилиты mxaddsvr, передав ей в качестве параметра IP адрес устройства и количество портов, которые мы хотим создать в системе

Вывод должен быть примерно таким:

В результате в нашей Linux-системе должно появится устройство /dev/ttyr01 , которое мы будем использовать в дальнейшем для обращения девайсу, подключенному к удалённому COM-порту. Конфигурация подключения к устройству Moxa NPort при этом будет записана в файл /usr/lib/npreal2/driver/npreal2d.cf .Если вы захотите править этот файл вручную (внимательно читайте инструкции в README.TXT ), то после его правки для вступления изменений в силу нужно запускать утилиту /usr/lib/npreal2/driver/mxloadsvr .

Теперь нам остаётся убедиться в том, что добавленный в процессе установке драйвера скрипт инициализации /etc/init.d/npreals успешно отрабатывает в процессе перезагрузки системы. Перезагружаем наш Debian сервер и проверяем наличие информации о загруженном драйвере в dmesg

Если драйвер по какой-то причине на попал в загрузку, смотрим о способах решения данной проблемы в README.TXT

Проверяем доступность транслированного в Linux устройства

Проверяем доступность подключенного через Nport и транслируемого в нашу систему GSM-модема. Для этого установим утилиту screen:

Подключаемся к порту:

Должен открыться новый пустой экран консольной сессии с модемом. Набираем команду получения информации о модеме

В ответ мы должны получить от модема его модель. Например, в нашем случае ответ выглядит так:

Если ответ получен, значит желаемый результат нами достигнут.

Завершаем screen сессию клавишами «Ctrl+a» затем «\»

Внизу экрана появится вопрос

Жмём «y». Сессия screen будет завершена и соединение с модемом на порту /dev/ttyr0 будет завершено.

Отключение портов и удаление драйвера Moxa Nport в Linux

Как удалить подключение к устройству Moxa Nport:

Как удалить драйвер Moxa NPort:

Проверено на следующих конфигурациях:

Версия Moxa NPort Firmware	Версия ОС Linux	Версия драйвера Real TTY
3.8 Build 17030709	Linux Debian 8.6 (Jessie) Kernel 3.16.0-4-amd64	1.18.65

Автор первичной редакции:
Алексей Максимов
Время публикации: 15.09.2017 11:08

Источник

Alexandr Engineer VoIP

воскресенье, 20 мая 2018 г.

Подключение к MOXA NPort 5110

Я качал драйвер: npreal2_mainline_v1.19_build_17110917.tgz 88.6 кбайт

2 Распаковываем в папочку. В папочке есть файл README.TXT в котором все требования и необходимые приложения для работы. Мне было нужно доставить OpenSSL и build-essential.
При запуске скрипта скрипта, если что-то будет не так, он скажет чего не хватает

3 После установке запускаем в формате, после адреса ставим количество терминалов одновременных соединений(8 шт.).

sudo /usr/lib/npreal2/driver/mxaddsvr 10.20.141.130 8

4 Как посмотреть что все работает исправно и запустилось:

5 Из выше изложенного получаем что параметры Миникома для подключения к мередиану через МОХА:

pu port /dev/ttyr00 — вот это один из 8-каналов созданных
pu baudrate 9600
pu rtscts No
pu xonxoff Yes

6 Когда закончили работу, то нам надо отключиться от МОХА

sudo /usr/lib/npreal2/driver/mxdelsvr [IP-addres]

7 Доп утилиты которые есть

После успешного окончания установки все инструменты управления драйвером мы можем найти в каталоге /usr/lib/npreal2/driver . В частности, нам могут быть полезны утилиты:

8 Вот собстенно говоря и сама моха

Источник

MOXA Nport — взгляд изнутри

Серверы сбора данных по последовательным портам MOXA Nport и им подобные — в настоящее время являются стандартом де факто в области построения систем передающих или принимающих данные через интерфейсы RS-232,RS-485 и RS-422.

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

Все, что может генерировать данные или управляться удаленно и имеет интерфейс RS-232, RS-485 и RS-422 — работает через данные преобразователи.

Общий смысл их использования — обычно заключается в следующем: пробросить интерфейсы RS-232,RS-485 и RS-422 через существующую локальную сеть, подключить устройство или прибор имеющий один из последовательных интерфейсов к ПК (серверу, SCADA) через Ethernet, подключится к прибору имеющему последовательный интерфейс через Internet для удаленного управления и т.п.

Цены на данные преобразователи не сильно высоки, младшие модели можно взять за 100-200$. Но учитывая что на любом автоматизированном производстве таких устройств может быть установлено сотни а то и тысячи — вырисовывается довольно лакомый кусочек для отечественных «импортозамещальщиков».

Им то я сегодня и попытаюсь помочь.

Что будем делать?

Во первых — разберемся в теории, как оно устроено внутри.

Во вторых — вычленим минимальный функционал для запуска работы в режиме Real Com Mode (то есть по сути для проброса виртуального COM порта до устройства через Ethernet).

В третьих — ради интереса разберем протокол поиска и конфигурирования устройства через утилиту NPort Administration Suite. Получим полное понимание, как создать pin-to-pin аналог железки, которую можно воткнуть вместо существующей MOXA Nport при этом получив полную поддержку со стороны родного ПО и драйвера.

Ну и на последок — попробуем посчитать, сколько индусов писало код прошивки MOXA.

Часть 1. Вводная

Итак, у нас на столе подопытный (на самом деле их было несколько, поэтому не удивляйтесь если увидите в статье различные идентификаторы моделей и различные MAC адреса)

На нем есть порт Ethernet и два порта RS-422/RS-485 — это физически.
А в программном плане — на устройстве открыты:
UDP порт 4800 — он отвечает за ловлю пакетов поиска устройства и отдает данные о самом устройстве в утилиту конфигурирования.

TCP порт 4900 — на него приходят команды конфигурирования устройства. Через этот порт настраивается время устройства, имя, IP адрес, режим работы, скорости и настройки портов и прочие базовые параметры, которые можно настроить через основной интерфейс утилиты NPort Administration Suite:

TCP порт 80 — отвечает за работу WEB интерфейса
TCP порты 966, 967, (и 968, 969 у 4х портовых устройств) — это порты управления передачей. По ним бегают команды открытия/закрытия соответствующего COM порта, установка скорости порта, проталкивание данных, мониторинг заполненности буфера передачи / приема и тд. Порт 966 отвечает за работу первого порта соответственно.

TCP порты (по умолчанию) 950, 951, (и 952, 953 у 4х портовых устройств) — это порты непосредственной передачи данных. То есть то, что непосредственно должно оказаться на RS-232/485/422 порте у устройства — передается в данные порт. Только данные, управление потоком в данном порту идет по 966, 967, 968, 969 портам соответственно.

Надеюсь общая картинка понимания работы устройства в голове сложилась. Давайте перейдем к следующей части:

Часть 2. Эмулируем MOXA

Наверняка многим уже стало понятно, что для того чтобы прикинутся MOXA Nport в минимальной конфигурации — необходимо на своем железе поднять TCP сервер на 2х портах: 966 для управления передачей и 950 для непосредственно передачи данных. Естественно придется корректно отвечать и обрабатывать запросы драйвера по 966 порту, но как показал анализ средствами wireshark — запросов не так много и они простейшие.

Дабы не перегружать текст статьи выкладками с описанием запросов и ответов — подготовил и выложил отдельно в виде pdf файла описание всех разобранных запросов, ответов и передаваемых параметров.

Скачать: Описание разбора протокола MOXA.pdf
То есть данный набор знаний позволяет реализовать устройство, которое может работать в паре с родным драйвером и передавать данные как MOXA. Половина работы выполнена, но есть один момент — как поменять конфигурацию? Было бы здорово использовать для этих целей родную утилиту NPort Administration Suite.

Часть 3. Ищем и находим

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

В этой части копнем немного глубже и посмотрим, как же проводился анализ самого обмена.
Мы знаем, что на устройстве открыт UDP порт 4800, давайте подключим устройство, запустим NPort Administration Suite, Wireshark и посмотрим что происходит при поиске устройств родной утилитой.

Смотрим отправленные пакеты:

Видим, что NPort Administration Suite отправляет бродкаст на адрес 255.255.255.255 то есть надеется, что пакет разлетится по всей сети.

В payload пакета содержатся данные:

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

На данный запрос отзываются все MOXы.

Конкретно наша ответила:

Вроде все элементарно просто, смущает только значение 12 03 00 80 32 03, отвечающее за интерпретацию конкретной модели устройства.

Но, так как данное значение сверяется с каким то эталонным справочным — значит оно должно где то хранится.

Немного изучив директорию с ПО — находим, что в NPort Administrator Suite v1.22 данные значения хранятся в файле C:\Program Files\NPortAdminSuite\bin\dsci.dll

Посидев с Wireshark и устройством несколько дней — получаем полный лог обмена и понимание какие коды функций что получают в ответ. Для удобства восприятия — все найденное описано в том же pdf файле, ссылка на который указана в статье ранее.

Для полноты понимания картины — лишь напомню, что по UDP 4800 идет получение первичных сведений о устройстве, все параметры которые требуют настройки и установки — настраиваются посредством запросов на TCP порт 4900.

Правильно обработав все поступающие запросы на 4800 и 4900 порты — мы сможем полноценно прикинуться устройством, так что даже родное ПО не заметит подвох.

Часть 4. Считаем индусов*

В ходе анализа протокола — меня не покидало ощущение, что различные куски протокола обмена писали разные люди, слишком отличаются значения функций и их интерпретации.

UDP порт 4800 коды функций начинаются с:

TCP порт 4900 коды функций начинаются с:

TCP порты 966, 967, 968, 969 коды функций начинаются с:

То есть используется уже одно байтовый идентификатор функции, а не двухбайтовый как ранее.
Тут кстати вылез забавный момент. По портам 966, 967, 968, 969 ответ на установку параметров всегда состоит из 3х байт.

Первый — это номер функции, а остальные 2 это 4f 4b или есть посмотреть в таблицу ASCII — «O» «K»

Ну OK с ним, идем далее.

Вторая замеченная особенность — мешанина Big и Little Endian в пределах одного ответа.

Размер пакета кодируется одним образом, а все числовые значения (год, месяц, день . ) другим. Отсюда можно сделать вывод, что обработку пользовательской части начиная с 75 00 04 00…… писал другой программист.

Подведем итог: Минимум 3 разных человека писали протокол обмена, 1 писал обработку пользовательской части данных и еще как минимум 1 писал обработчик WEB интерфейса. По моим подсчетам над проектом трудилось примерно 5 программистов.
А сколько насчитали вы?

*Под понятием «Индус» в данном случае подразумевается наемный работник, выполняющий свои обязанности за еду и ипотеку, способный кодить отсюда и до обеда не особо вникая в глобальные планы компании работодателя.

Источник