Теряются данные по пути от nPort до приложения Linux

[Знайка]

От эксперимента присылали вот такой дамп https://disk.yandex.ru/d/DHwUzaMurtl3gQ , посмотрите. UDP:4800 в режиме RealCOM использоваться не должен, там работают только TCP:950 и TCP:966. Не буду утверждать за наличие/отсуствие неполадок в драйвере, связанных с использованием этой службы, но когда у вас преобразователь, скажем, отделён от сервера брандмауэром, то и без описания этого сокета у вас всё будет работать. Описание протокола имеется, могу дать в обмен на серийный номер одной из ваших NE.

[kia0]

Посмотрел Ваш дамп. Обмен похож на то, что я наблюдал с версией драйвера 1.19 под ядром 2.6.32: те же регулярные запросы-ответы по порту 4800 UDP. Запрос от npreal2d 24 байта, команда 0x1d (в коде npreal2d.cf этому соответствует ветка "send dsc_GetNetstat_ex" в функции void poll_nport_send(servp)), ответ от NE'шки 392 байта. Но пауз в передаче данных через порт нет,так что тест был "не чистый"

Вот одна из NE:

Model name       : NE-4100T
MAC address      : 00:90:E8:32:3C:CA
Serial No        : 1866
Firmware version : 4.1 Build 07061517
 

[Знайка]

В этом случае SN нужен полностью, не только последние 4 цифры

[kia0]

Удаленно не посмотреть...
Есть фото внутренностей резервного датчика, номер NE на нем TAEFB1078210, mac-адрес 00:90:e8:4d:f3:88. Так пойдет?

[Знайка]

Да, так подойдёт. Отправил в ЛС, просьба публично не выкладывать

[kia0]

Продолжение.

В четверг для пробы на временной ВМ обновили версии ядра и драйвера. Ядро 4.1.12 (Oracle Linux UEKR4 4.1.14-124.16.4.el6uek.x86_64), драйвер 4.0.19 Build 210701. Работает без сбоев

TCP-соединения (порты 950/966) однократные, далее не обрываются вне зависимости от наличия/отсутствия сигналов с датчика. По порту 4800 udp также присутствует обмен, по пакету в каждую сторону с интервалом ~10-15сек, команда 0x1d с параметрами и ответ в 392 байта, аналогично поведению драйвера 1.19

 

[Знайка]

Ну давайте понаблюдаем