Плагин Modbus
-
первый пакет.
Источник 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
Добавлена возможность фиксировать порт на плагине
-
Поставил.
-
Связь после обрыва не восстанавливается.
Вот пакеты попытки старта плагина.
-
Связь после обрыва не восстанавливается.
Вот пакеты попытки старта плагина.
А что на микротике?
-
то же самое.
2 соединения.
Старое на 23 часа,\
и новое на 0 сек.
Научился повторять проблему.
У меня дача с квартирой VPN связана. Проблема возникает, если VPN рубануть.
VPN восстанавливается, а работа модбас - нет. VPN между двумя микротиками поднят.
Видимо соединение контроллер - микротик является ключем к проблеме.
-
Совсем то же самое.
Настройки порта плагина сделаны, но игнорируется.
-
Сам отвечаю.
Нужно было обязательно сервер IH перезагрузить, чтобы настройка заработала.
Но с ней стало все намного хуже.
Т.е. связь не восстанавливается вообще.
Даже после перезагрузки контроллера.
Выключил фиксированный порт, перезапустил контроллер - заработало.
Перезапуск микротика на стороне контроллера на помогает ни в каком случае.
-
Сам отвечаю.
Нужно было обязательно сервер IH перезагрузить, чтобы настройка заработала.
Нет, достаточно перезагрузить плагин
Но с ней стало все намного хуже.
Т.е. связь не восстанавливается вообще.
Даже после перезагрузки контроллера.
Выключил фиксированный порт, перезапустил контроллер - заработало.
А какая ошибка в плагине?
При переиспользовании порта проходит некоторое время, пока ОС его освобождает даже при нормальном отключении.
Перезапуск микротика на стороне контроллера на помогает ни в каком случае.
Раз вы можете моделировать ситуацию, попробуйте радикально уменьшить "TCP Established Timeout" на микротике на стороне контроллера
https://frm.intrahouse.ru/viewtopic.php?f=18&t=5493&start=80
