Плагин Modbus



  • @Erik:

    В моем контроллере на виду его нигде нет.

    Описал проблему на форуме поддержки контроллера. Посмотрю, что скажут.

    Пока могу по факту значка "авария" на модбас-актуаторе и наличию пинга до контроллера принимать решения о его перезагрузке автоматически.

    Но не могу пока смоделировать в каких еще ситуациях такие условия могут совпасть.

    Контроллер то работает, климатом управляет, только отображение работы "отваливается".

    Будет неправильно свалить его в череду перезагрузок.

    Перезагрузка контроллера - это не решение. Нужно попытаться решить вопрос штатно.

    Хорошо бы логировать трафик с помощью tcpdump (wireshark, etc.) и затем проанализировать.



  • микротиком собрал в packet sniffer начало взаимодействия (включение плагина). 2 раза.

    https://yadi.sk/d/ZOGm_D1kwDq84g

    https://yadi.sk/d/A7l6akA5DD9Tpg

    смотрелка

    https://www.wireshark.org/

    192.168.88.46 - сервер IH

    192.168.13.25 - контроллер

    88.99.91.165 - облачный сервис, контроллер с ним по MQTT взаимодействует.



  • Видно, что время IH задает, а контроллер соглашается (первые пакеты на картинке).



  • Покажите, где IH задает время для контроллера



  • первый пакет.

    Источник 192.168.88.46 - это IH.

    задает TSVal = 602011810. В милисекундах это 167 часов.

    А, наоборот.

    Источник контроллер.

    Извиняюсь. 🙂



  • @Erik:

    Убивание старого соединения на микротике не помогло. Заработало в этот раз только после перезапуска контроллера.

    Перед тем, как написать в поддержку контроллера, есть последний вопрос.

    Этот таймаут соединению - 23 часа - не плагин ли устанавливает? Нет возможности уменьшить его до стандартных 10 минут?

    Добрый день, данное время вы можете настроить самостоятельно нажав кнопку "Tracking"
    w.png
    Из документации микротика:

    Timeout - Time after connection will be removed from connection list. Этот параметр нужен микротику для трекинга.



  • @dev:

    Добрый день, данное время вы можете настроить самостоятельно нажав кнопку "Tracking"

    w.png

    Из документации микротика:

    Timeout - Time after connection will be removed from connection list. Этот параметр нужен микротику для трекинга.

    Очень здорово.

    Если это только микротик использует, значит оно и на ситуацию не влияет.

    Потому, что убивание соединения на микротике к работоспособности не приводило.

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

    Может сервер послать контроллеру перед попыткой установить соединения команду FIN от своего IP адреса для закрытия существующих соединений, если они есть?



  • @Erik:

    первый пакет.

    Источник 192.168.88.46 - это IH.

    задает TSVal = 602011810. В милисекундах это 167 часов.

    А, наоборот.

    Источник контроллер.

    Извиняюсь. 🙂

    Да, приходит с обеих сторон. Но используется на транспортном уровне TCP

    RFC 4433: TSVal - Поле Timestamp Value (TSval) содержит текущее значение временной метки передавшего опцию модуля TCP…..

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

    https://rfc2.ru/4413.rfc/20



  • @intrapro:

    @Erik:

    первый пакет.

    Источник 192.168.88.46 - это IH.

    задает TSVal = 602011810. В милисекундах это 167 часов.

    А, наоборот.

    Источник контроллер.

    Извиняюсь. 🙂

    Да, приходит с обеих сторон. Но используется на транспортном уровне TCP

    RFC 4433: TSVal - Поле Timestamp Value (TSval) содержит текущее значение временной метки передавшего опцию модуля TCP…..

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

    https://rfc2.ru/4413.rfc/20

    Здесь лучше описано

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

    даже с автопереводом понятно 🙂



  • @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:

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

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

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


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