Плагин Modbus



  • @Erik:

    Куда тогда копать?

    Можно попробовать использовать фиксированный порт на стороне плагина.

    Если не поможет - переходить на mqtt, он у нас есть 🙂



  • там mqtt только для облачного сервиса.

    Настроек в интерфейсе нет, т.е. переназначить на другой брокер без хакерства не получится.

    Можно только отключить передачу, или включить.

    С фиксированным портом должно помочь. Если таймштамп не помешает.

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



  • @Erik:

    С фиксированным портом должно помочь. Если таймштамп не помешает.

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

    У timestamp нет начала и нет конца.

    timestamp - это всего лишь метка времени когда произошло событие (в рамках TCP - когда передан пакет, когда получен пакет …)

    Она принципиально не может мешать кому либо



  • https://www.freesoft.org/CIE/RFC/1323/9.htm

    Тут написано что оно изменяется пропорционально паузам.

    Или что тогда не дает восстановить связь?

    Если "Она принципиально не может мешать кому либо", значит причина в чем то другом.

    Попробуйте начинать соединение с отправки fin. Вдруг есть хвост от старого. Если этому ничто мешать не может.

    ???

    @intrapro:

    Можно попробовать использовать фиксированный порт на стороне плагина.

    Как это сделать? Не нашел настройки порта на стороне плагина.



  • @Erik:

    Попробуйте начинать соединение с отправки fin. Вдруг есть хвост от старого. Если этому ничто мешать не может.

    ???

    Если соединение штатно закрывается, FIN всегда посылается. Это выполняется не на прикладном уровне, а на уровне ОС.

    Если соединение РАЗОРВАНО, то после возобновления это уже новое соединение.

    Другая сторона (контроллер) должен открыть второе подключение или хотя бы сбросить старое после адекватного тайм-аута.

    Иначе так можно ждать fin до конца света

    Хотелось посмотреть дамп именно в случае, когда после разрыва новое соединение создается, но контроллер не отвечает.

    @Erik:

    @intrapro:

    Можно попробовать использовать фиксированный порт на стороне плагина.

    Как это сделать? Не нашел настройки порта на стороне плагина.

    Такой возможности пока нет. Сделаем by special order 🙂

    Завтра выложим на github для тестирования.



  • @intrapro:

    Хотелось посмотреть дамп именно в случае, когда после разрыва новое соединение создается, но контроллер не отвечает.

    Сделаю, когда повторится.



  • @intrapro:

    Если соединение штатно закрывается, FIN всегда посылается. Это выполняется не на прикладном уровне, а на уровне ОС.

    Если соединение РАЗОРВАНО, то после возобновления это уже новое соединение.

    Другая сторона (контроллер) должен открыть второе подключение или хотя бы сбросить старое после адекватного тайм-аута.

    Иначе так можно ждать fin до конца света

    Я вообще не понимаю ситуацию.

    Если выдергивать патчкорд (чем не грубый обрыв связи), или гасить порт на коммутаторе - при восстановлении связи и работа плагина восстанавливается. Ни разу не смог руками воспроизвести ситуацию. Хотя fin он не мог послать в этом случае.

    А когда падает канал у оператора - каждый раз проблемы. Он как то по-особенному падает. Не просто связь пропадает. Успевает утянуть за собой логику посторонних процессов.

    Поймать бы момент падения.



  • @Erik:

    @intrapro:

    Можно попробовать использовать фиксированный порт на стороне плагина.

    Как это сделать? Не нашел настройки порта на стороне плагина.

    На github опубликован релиз плагина 0.0.8 https://github.com/intrahouseio/intraHouse.plugin-Modbus/releases/tag/v0.0.8

    Добавлена возможность фиксировать порт на плагине

    modbus_param.png



  • Поставил.



  • Связь после обрыва не восстанавливается.

    Вот пакеты попытки старта плагина.

    https://yadi.sk/d/N_AurooQUkBZxA



  • @Erik:

    Связь после обрыва не восстанавливается.

    Вот пакеты попытки старта плагина.

    А что на микротике?



  • то же самое.

    2 соединения.

    Старое на 23 часа,\

    и новое на 0 сек.

    Научился повторять проблему.

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

    VPN восстанавливается, а работа модбас - нет. VPN между двумя микротиками поднят.

    Видимо соединение контроллер - микротик является ключем к проблеме.



  • Совсем то же самое.

    Настройки порта плагина сделаны, но игнорируется.



  • Сам отвечаю.

    Нужно было обязательно сервер IH перезагрузить, чтобы настройка заработала.

    Но с ней стало все намного хуже.

    Т.е. связь не восстанавливается вообще.

    Даже после перезагрузки контроллера.

    Выключил фиксированный порт, перезапустил контроллер - заработало.

    Перезапуск микротика на стороне контроллера на помогает ни в каком случае.



  • @Erik:

    Сам отвечаю.

    Нужно было обязательно сервер IH перезагрузить, чтобы настройка заработала.

    Нет, достаточно перезагрузить плагин

    @Erik:

    Но с ней стало все намного хуже.

    Т.е. связь не восстанавливается вообще.

    Даже после перезагрузки контроллера.

    Выключил фиксированный порт, перезапустил контроллер - заработало.

    А какая ошибка в плагине?

    При переиспользовании порта проходит некоторое время, пока ОС его освобождает даже при нормальном отключении.

    @Erik:

    Перезапуск микротика на стороне контроллера на помогает ни в каком случае.

    Раз вы можете моделировать ситуацию, попробуйте радикально уменьшить "TCP Established Timeout" на микротике на стороне контроллера

    https://frm.intrahouse.ru/viewtopic.php?f=18&t=5493&start=80



  • Чтобы локализовать проблему предлагаю установить любой modbus клиент на свой компьютер.

    1. При нормальной работе плагина попробовать зайти на контроллер с помощью modbus клиента.

    Если не получается, значит контроллер не разрешает несколько одновременных подключений по modbus

    Тогда ситуация становится понятнее. Контроллер не закрывает старое соединение и при этом не разрешает новое.

    2. Отключить плагин. Подключиться modbus клиентом. Cмоделировать ситуацию с отключением. Сможет ли modbus клиент подключиться к контроллеру?



  • @Erik:

    Связь после обрыва не восстанавливается.

    Вот пакеты попытки старта плагина.

    https://yadi.sk/d/N_AurooQUkBZxA

    Результат анализа дампов:

    Удачное соединение (первый отправленный файл)

    Трехэтапное рукопожатие

    13 2.823605 192.168.88.46 192.168.13.25 TCP 74 33770 → 502 [SYN, ECN, CWR]

    16 2.841734 192.168.13.25 192.168.88.46 TCP 60 502 → 33770 [SYN, ACK]

    19 2.854543 192.168.88.46 192.168.13.25 TCP 54 33770 → 502 [ACK]

    Обмен данными

    22 2.863566 192.168.88.46 192.168.13.25 Modbus/TCP 66 Query: Trans: 1; Unit: 1, Func: 3: Read Holding Registers

    25 2.870976 192.168.13.25 192.168.88.46 Modbus/TCP 65 Response: Trans: 1; Unit: 1, Func: 3: Read Holding Registers

    28 2.880465 192.168.88.46 192.168.13.25 TCP 54 33770 → 502 [ACK]

    ….

    Неудачное соединение

    Трехэтапное рукопожатие - все нормально

    53 12.880903 192.168.88.46 192.168.13.25 TCP 74 38416 → 502 [SYN, ECN, CWR]

    56 12.883667 192.168.13.25 192.168.88.46 TCP 60 502 → 38416 [SYN, ACK]

    59 12.892805 192.168.88.46 192.168.13.25 TCP 54 38416 → 502 [ACK]

    Но контроллер сразу отправляет пакет FIN - завершение

    62 12.895657 192.168.13.25 192.168.88.46 TCP 60 502 → 38416 [FIN, ACK]

    Сервер после рукопожатия успел отправить первый запрос

    65 12.900399 192.168.88.46 192.168.13.25 Modbus/TCP 66 Query: Trans: 1; Unit: 1, Func: 3: Read Holding Registers

    Но контроллер кроме FIN завершения еще посылает RST - прекратить немедленно (обычно используется или FIN или RST)

    68 12.903004 192.168.13.25 192.168.88.46 TCP 60 502 → 38416 [RST, ACK]

    69 12.903004 192.168.13.25 192.168.88.46 TCP 60 502 → 38416 [RST, ACK]

    70 12.903147 192.168.13.25 192.168.88.46 TCP 54 502 → 38416 [RST, ACK]

    Сервер соглашается завершить

    71 12.905900 192.168.88.46 192.168.13.25 TCP 54 38416 → 502 [ACK]

    74 12.907799 192.168.88.46 192.168.13.25 TCP 54 38416 → 502 [FIN, ACK]

    Контроллер еще пять раз присылает прекратить

    77 12.908491 192.168.13.25 192.168.88.46 TCP 60 502 → 38416 [RST, ACK]

    ….....

    На этом сеанс завершается. При следующей попытке все повторяется

    Почему контроллер категорически отказывается соединяться - в этом вопрос.



  • @intrahouse:

    Чтобы локализовать проблему предлагаю установить любой modbus клиент на свой компьютер.

    1. При нормальной работе плагина попробовать зайти на контроллер с помощью modbus клиента.

    Если не получается, значит контроллер не разрешает несколько одновременных подключений по modbus

    Тогда ситуация становится понятнее. Контроллер не закрывает старое соединение и при этом не разрешает новое.

    2. Отключить плагин. Подключиться modbus клиентом. Cмоделировать ситуацию с отключением. Сможет ли modbus клиент подключиться к контроллеру?

    Сделаю на выходных.



  • @intrapro:

    Почему контроллер категорически отказывается соединяться - в этом вопрос.

    Скопировал на форум контроллера.

    Но они не быстрые там совсем. 😞



  • @intrapro:

    @Erik:

    Сам отвечаю.

    Нужно было обязательно сервер IH перезагрузить, чтобы настройка заработала.

    Нет, достаточно перезагрузить плагин

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

    Написанный в настройках взял только после перезагрузки IH.

    @intrapro:

    @Erik:

    Но с ней стало все намного хуже.

    Т.е. связь не восстанавливается вообще.

    Даже после перезагрузки контроллера.

    Выключил фиксированный порт, перезапустил контроллер - заработало.
    А какая ошибка в плагине?

    При переиспользовании порта проходит некоторое время, пока ОС его освобождает даже при нормальном отключении.

    Та же самая ошибка. Но она не прекращается и после перезагрузки контроллера. Может порт 7999 не допустим для модбаса?

    @intrapro:

    @Erik:

    Перезапуск микротика на стороне контроллера на помогает ни в каком случае.

    Раз вы можете моделировать ситуацию, попробуйте радикально уменьшить "TCP Established Timeout" на микротике на стороне контроллера

    https://frm.intrahouse.ru/viewtopic.php?f=18&t=5493&start=80

    Попробую.


Авторизуйтесь, чтобы ответить