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