Lorawan-stack: Базовая интеграция станции: состояние гонки при обработке повторного подключения вызывает постоянный сбой пересылки по восходящей линии связи.

В последнем обновлении время ожидания было изменено с 60 до 600 с. Но основная проблема остается, и ее можно надежно воспроизвести с помощью описанных выше шагов.

Я попытаюсь смоделировать это и настроить параметры прокси, чтобы увидеть, в чем проблема. Но следует отметить, что это влияет только на определенный процент шлюзов.
На следующем графике нарастающий фронт всплеска сообщений о состоянии соответствует окну ожидания 600 с. Каждый раз, когда шлюз повторно подключается, мы регистрируем одно сообщение о состоянии (которое учитывает этот всплеск). Но если вы видите трафик, то падение незначительное, но не настолько сильное, чтобы указывать на проблему со всеми шлюзами:

Привет, Кришна, проблема связана не с отключениями на стороне сервера, а с тем, как сервер обрабатывает нечистые отключения на стороне клиента с немедленным повторным подключением. Проблема действительно затрагивает все шлюзы на базе базовой станции и может быть надежно воспроизведена с помощью приведенных выше инструкций.

Схема ошибки выглядит так:

• Устройство некорректно прерывает соединение (цикл питания, аппаратный сброс, отключение Wi-Fi, отключение / подключение TTIG и т. Д.)
• Устройство немедленно повторно подключается
• В течение 600 секунд после отключения (это число было 60 секунд) переадресованные пакеты видны в LNS.
• Через 600 с и более после отключения перенаправленные пакеты НЕ видны в LNS.

Увеличение тайм-аута с 60 до 600 сделало проблему более серьезной: при 60 секундах пользователю, отключающему свой TTIG, просто приходилось ждать 60 секунд, прежде чем снова подключать его, чтобы не столкнуться с проблемой. Это могло происходить достаточно часто, особенно когда люди выполняли сброс настроек до заводских. Теперь с 600s, больший процент столкнется с проблемой, что также можно наблюдать.

Больно ли вообще отключить этот тайм-аут? Базовая станция поддерживает TCP по умолчанию (https://github.com/lorabasics/basicstation/blob/c29b8502f8c715daecec6666835da6e981dc820a/src/sys.c#L637). Разве этого не достаточно для проверки работоспособности соединения?

Для меня похоже, что ошибка также возникает, если провайдер отключит ваше интернет-соединение, и вы получите новый IP-адрес при повторном подключении :(
В настоящий момент каждый день мой шлюз TTIG больше не работает, и когда я показываю в журналах своего приложения, последнее полученное мной значение является коротким до того, как соединение было отключено, а затем снова подключено.
Чтобы шлюз снова заработал, мне нужно отключить его, немного подождать, а затем снова подключить.

Но такое поведение происходит только с 29.01, раньше это никогда не было проблемой.

@JackGruber, можете ли вы подтвердить, что вы также можете нормально получать аплинки в течение первых 600 секунд после отключения интернет-соединения? (Если быть точным: 600 секунд, минус время, необходимое для полного переподключения модема и шлюза.)

Или, если вы не видите никаких исходящих соединений в течение этих 600 секунд: как часто ваши устройства передают данные? (Другими словами: ожидаете ли вы получить несколько аплинков в течение этих 600 секунд?)

Контролируемое мной устройство передает данные каждые 5 минут.

02:42 Кадр RX
02:47 Кадр RX
02:53 Кадр RX
02:56 Подключиться
02:58 Кадр RX
без рамок
07:30 Отключить / снова подключить TTIG
07:36 Кадр RX

Учитывая 600 секунд после повторного подключения 2:56, я предполагаю, что после восходящего канала 2:58 можно также ожидать восходящего канала 3:03 (который все еще до 2:56 плюс 600 секунд = 3:06). Но, возможно, тайм-аут в 600 секунд сбрасывается после восходящего канала 2:53 (а не после некоторого более позднего сообщения keep-alive / status), заставляя TTN ошибочно стирать контекст / состояние только тогда, когда должен быть получен восходящий канал 3:03. (И, конечно, аплинки могут не быть получены и по другим причинам.)

Кроме того, все в порядке при перезапуске TTIG в 7:30, а затем отсутствии проблем снова через 600 секунд после этого, похоже, подтверждает ( отличный ) анализ @beitler , который предполагает, что TTN ошибочно стирает некоторый общий контекст / состояние в примерно 3:03 или 3:06.

Сегодня я внимательно посмотрел на время
Я также прикрепил файл журнала из TTIG.
К сожалению, не с момента переподключения провайдера.
При желании я создаю долгосрочный журнал, чтобы также было включено повторное подключение
TTIG.log

Расписание (UTC + 1)
02:46 Сообщения RX
02:51 RX сообщения
02:56 RX сообщения
02:58 RX сообщения
02:58 переподключение ISP
03:01 RX сообщения
03:03 RX сообщения
03:06 RX сообщения
сообщений больше не получено

Консоль TTN
Статус: не подключен
Последний визит: 11.02.2020 03:05:04

06:46 Короткое отключение / повторное включение TTIG (нет питания в течение 10 секунд)

Консоль TTN
Статус: подключен
Последний визит: 11.02.2020 06:47:12

06:48 Сообщения RX
....

Я обнаружил ошибку в своем правиле брандмауэра: основное соединение CUPS (rjs.sm.tc) было запрещено, только CUPS-BACKUP (mh.sm.tc).

Благодарим за сообщение, проблема обнаружена и мы ее исправляем. Эта проблема существует в нашей собственной кодовой базе, но здесь будет закрыта.

Что-то изменилось в серверной части с +/- 18 часов сегодня днем?
Сейчас почти невозможно запустить TTN Indoor Gateway дольше 10 минут, хотя, насколько я знаю, он работал нормально в течение нескольких месяцев.
Смена IP-адреса через DHCP-сервер дает 10 минут подключения к сети TTN, но затем снова теряется. (replug тоже работает 10 минут)

@ TD-er, вы оставляли его отключенным более 10 минут (600 секунд)?

Как объяснялось выше, это было необходимо после изменения 6 февраля. До 7 февраля его нужно было отключить от сети на 60 секунд. Мне неясно, было ли развернуто сегодняшнее объединенное исправление.

Нет, не отключили так долго.
В отключенном состоянии он был отключен всего на несколько секунд.
С изменением IP-адреса DHCP устройство даже никогда не выключало и снова включало питание, оно просто получило новый IP-адрес от DHCP-сервера и, таким образом, восстановило свое сетевое соединение. Это заставило его работать почти ровно 10 минут, пока он снова не стал недоступен.

Сейчас я отключу его от сети на некоторое время, а затем посмотрю, что произойдет после того, как я его снова подключу.

Если бы он был выключен примерно на 25 минут, а теперь подключен примерно на 15 минут, он все еще работает :) Посмотрим, будет ли он работать завтра утром.

Сегодня мы выпускаем v3.5.3, содержащую исправление, и, вероятно, сможем развернуть его на серверах, к которым подключается TTIG. Надеюсь, это скоро решится.

Будем надеяться, что он еще не развернут, так как мой внутренний шлюз снова отключен примерно на 3 часа.

Мы не слышали об этой проблеме после установки последних исправлений. Пожалуйста, не стесняйтесь открывать снова, если снова заметите.