Плагин Modbus
-
Произошло.
Вижу разницу в поведении наглядно.
Видно, что плагин отключается, и включается, попытки повторяются, пока не прилетит хоть какой нибудь ответ, видимо.
После восстановления связи плагин это заметил, и перезапускаться перестал. Но работа не восстановилась. Ошибки дебагера видны - это ошибки связи.
В информации на микротике видно, что висит старое соединение, с таймаутом 23 часа, и второе новое, которое не может начать работать по каким то причинам.
Убивание старого соединения на микротике не помогло. Заработало в этот раз только после перезапуска контроллера.
Перед тем, как написать в поддержку контроллера, есть последний вопрос.
Этот таймаут соединению - 23 часа - не плагин ли устанавливает? Нет возможности уменьшить его до стандартных 10 минут?
-
Произошло.
Вижу разницу в поведении наглядно.
Видно, что плагин отключается, и включается, попытки повторяются, пока не прилетит хоть какой нибудь ответ, видимо.
После восстановления связи плагин это заметил, и перезапускаться перестал. Но работа не восстановилась. Ошибки дебагера видны - это ошибки связи.
В информации на микротике видно, что висит старое соединение, с таймаутом 23 часа, и второе новое, которое не может начать работать по каким то причинам.
Убивание старого соединения на микротике не помогло. Заработало в этот раз только после перезапуска контроллера.
Перед тем, как написать в поддержку контроллера, есть последний вопрос.
Этот таймаут соединению - 23 часа - не плагин ли устанавливает? Нет возможности уменьшить его до стандартных 10 минут?
Нет, конечно. Плагин не может так держать соединение, чтобы не давать контроллеру его сбросить.
Тем более он сам перезагружается, то есть закрывает со своей стороны.
Судя по логу - TCP соединение устанавливается, а вот по Modbus контроллер не отвечает.
Возможно, нужно радикально увеличить таймаут со стороны плагина, чтобы не дергать контроллер так часто.
В контроллерах обычно есть такой параметр - таймаут для Modbus соединения (и даже иногда его можно настроить, но это не обязательно, хотя бы знать).
-
В моем контроллере на виду его нигде нет.
Описал проблему на форуме поддержки контроллера. Посмотрю, что скажут.
Пока могу по факту значка "авария" на модбас-актуаторе и наличию пинга до контроллера принимать решения о его перезагрузке автоматически.
Но не могу пока смоделировать в каких еще ситуациях такие условия могут совпасть.
Контроллер то работает, климатом управляет, только отображение работы "отваливается".
Будет неправильно свалить его в череду перезагрузок.
-
В моем контроллере на виду его нигде нет.
Описал проблему на форуме поддержки контроллера. Посмотрю, что скажут.
Пока могу по факту значка "авария" на модбас-актуаторе и наличию пинга до контроллера принимать решения о его перезагрузке автоматически.
Но не могу пока смоделировать в каких еще ситуациях такие условия могут совпасть.
Контроллер то работает, климатом управляет, только отображение работы "отваливается".
Будет неправильно свалить его в череду перезагрузок.
Перезагрузка контроллера - это не решение. Нужно попытаться решить вопрос штатно.
Хорошо бы логировать трафик с помощью tcpdump (wireshark, etc.) и затем проанализировать.
-
микротиком собрал в packet sniffer начало взаимодействия (включение плагина). 2 раза.
https://yadi.sk/d/ZOGm_D1kwDq84g
https://yadi.sk/d/A7l6akA5DD9Tpg
смотрелка
192.168.88.46 - сервер IH
192.168.13.25 - контроллер
88.99.91.165 - облачный сервис, контроллер с ним по MQTT взаимодействует.
-
Видно, что время IH задает, а контроллер соглашается (первые пакеты на картинке).
-
Покажите, где IH задает время для контроллера
-
первый пакет.
Источник 192.168.88.46 - это IH.
задает TSVal = 602011810. В милисекундах это 167 часов.
А, наоборот.
Источник контроллер.
Извиняюсь.
-
Убивание старого соединения на микротике не помогло. Заработало в этот раз только после перезапуска контроллера.
Перед тем, как написать в поддержку контроллера, есть последний вопрос.
Этот таймаут соединению - 23 часа - не плагин ли устанавливает? Нет возможности уменьшить его до стандартных 10 минут?
Добрый день, данное время вы можете настроить самостоятельно нажав кнопку "Tracking"
Из документации микротика: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 адреса для закрытия существующих соединений, если они есть?
-
первый пакет.
Источник 192.168.88.46 - это IH.
задает TSVal = 602011810. В милисекундах это 167 часов.
А, наоборот.
Источник контроллер.
Извиняюсь.
Да, приходит с обеих сторон. Но используется на транспортном уровне TCP
RFC 4433: TSVal - Поле Timestamp Value (TSval) содержит текущее значение временной метки передавшего опцию модуля TCP…..
Одной из важных причин использования временных меток является детектирование повторного использования порядковых номеров.
-
первый пакет.
Источник 192.168.88.46 - это IH.
задает TSVal = 602011810. В милисекундах это 167 часов.
А, наоборот.
Источник контроллер.
Извиняюсь.
Да, приходит с обеих сторон. Но используется на транспортном уровне TCP
RFC 4433: TSVal - Поле Timestamp Value (TSval) содержит текущее значение временной метки передавшего опцию модуля TCP…..
Одной из важных причин использования временных меток является детектирование повторного использования порядковых номеров.
Здесь лучше описано
https://www.freesoft.org/CIE/RFC/1323/9.htm
даже с автопереводом понятно
-
Куда тогда копать?
Можно попробовать использовать фиксированный порт на стороне плагина.
Если не поможет - переходить на mqtt, он у нас есть
-
там mqtt только для облачного сервиса.
Настроек в интерфейсе нет, т.е. переназначить на другой брокер без хакерства не получится.
Можно только отключить передачу, или включить.
С фиксированным портом должно помочь. Если таймштамп не помешает.
В идеале нужно запоминать время начала последнего таймштампа, чтобы при обрыве/восстановлении связи встроиться в него, или послать fin, если он не истек.
-
С фиксированным портом должно помочь. Если таймштамп не помешает.
В идеале нужно запоминать время начала последнего таймштампа, чтобы при обрыве/восстановлении связи встроиться в него, или послать fin, если он не истек.
У timestamp нет начала и нет конца.
timestamp - это всего лишь метка времени когда произошло событие (в рамках TCP - когда передан пакет, когда получен пакет …)
Она принципиально не может мешать кому либо
-
https://www.freesoft.org/CIE/RFC/1323/9.htm
Тут написано что оно изменяется пропорционально паузам.
Или что тогда не дает восстановить связь?
Если "Она принципиально не может мешать кому либо", значит причина в чем то другом.
Попробуйте начинать соединение с отправки fin. Вдруг есть хвост от старого. Если этому ничто мешать не может.
???
Можно попробовать использовать фиксированный порт на стороне плагина.
Как это сделать? Не нашел настройки порта на стороне плагина.
-
Попробуйте начинать соединение с отправки fin. Вдруг есть хвост от старого. Если этому ничто мешать не может.
???
Если соединение штатно закрывается, FIN всегда посылается. Это выполняется не на прикладном уровне, а на уровне ОС.
Если соединение РАЗОРВАНО, то после возобновления это уже новое соединение.
Другая сторона (контроллер) должен открыть второе подключение или хотя бы сбросить старое после адекватного тайм-аута.
Иначе так можно ждать fin до конца света
Хотелось посмотреть дамп именно в случае, когда после разрыва новое соединение создается, но контроллер не отвечает.
Можно попробовать использовать фиксированный порт на стороне плагина.
Как это сделать? Не нашел настройки порта на стороне плагина.
Такой возможности пока нет. Сделаем by special order
Завтра выложим на github для тестирования.
-
Хотелось посмотреть дамп именно в случае, когда после разрыва новое соединение создается, но контроллер не отвечает.
Сделаю, когда повторится.
-
Если соединение штатно закрывается, FIN всегда посылается. Это выполняется не на прикладном уровне, а на уровне ОС.
Если соединение РАЗОРВАНО, то после возобновления это уже новое соединение.
Другая сторона (контроллер) должен открыть второе подключение или хотя бы сбросить старое после адекватного тайм-аута.
Иначе так можно ждать fin до конца света
Я вообще не понимаю ситуацию.
Если выдергивать патчкорд (чем не грубый обрыв связи), или гасить порт на коммутаторе - при восстановлении связи и работа плагина восстанавливается. Ни разу не смог руками воспроизвести ситуацию. Хотя fin он не мог послать в этом случае.
А когда падает канал у оператора - каждый раз проблемы. Он как то по-особенному падает. Не просто связь пропадает. Успевает утянуть за собой логику посторонних процессов.
Поймать бы момент падения.
-
Можно попробовать использовать фиксированный порт на стороне плагина.
Как это сделать? Не нашел настройки порта на стороне плагина.
На github опубликован релиз плагина 0.0.8 https://github.com/intrahouseio/intraHouse.plugin-Modbus/releases/tag/v0.0.8
Добавлена возможность фиксировать порт на плагине
