Opened 5 years ago
Closed 5 years ago
#36 closed улучшение (fixed)
No service
| Reported by: | san | Owned by: | alx |
|---|---|---|---|
| Priority: | major | Milestone: | 1 очередь |
| Keywords: | Cc: | andrei |
Description
Записано со слов пользователя:
К устройству Сервер были подключены Клиент1 и Клиент2. Через соединение передавались данные RS-232 И Ethernet.
Примерно в Jul 4 1:00 UTC пользователь обнаружил, что данные перестали проходить.
Подключившись локально пользователь увидел в веб-интерфейсе сервера и клиент2 в информации о подключениях (где обычно было LTE) написано "no service", при этом синий индикатор на модуле постоянно горит.
Примерно в 4:00 UTC перезапустили процесс 3GD на сервере, после этого сервер вышел в сеть, клиент1 подключился, а клиент2 так и остался в состоянии "no service".
Нужно попытаться разобраться почему устройства попали в такое состояние и почему они не смогли из него сами выйти(но после того как пользователь перезапустил 3gd устройство перешло в рабочее состояние)
r140
логи: xchange\alx\Test_and_bugs\Рамис\0704
Change History (11)
comment:1 by , 5 years ago
follow-ups: 3 8 comment:2 by , 5 years ago
мы можем видеть только его результат...
Тогда выходит нужно ввести ещё какой-то критерий для рестарта модуля SIM, когда он почему-то стал "no service".
comment:3 by , 5 years ago
Replying to san:
нужно ввести ещё какой-то критерий для рестарта модуля SIM, когда он почему-то стал "no service".
Зачем?
follow-up: 5 comment:4 by , 5 years ago
Судя по тому, что говорит пользователь, устройства "застряли" в этом состоянии "no service" на долго, а вышли оттуда только после перезапуска 3gd (рестарта SIM).
Т.е. возможность работать у сима была, но пока его не пнули он работать не стал или это какая-то ошибка на стороне оператора связи, но в любом случае, раз есть некая проблема, которая может произойти, и у нас есть возможность из неё выйти, то нужно попробовать.
comment:5 by , 5 years ago
Replying to san:
Т.е. возможность работать у сима была, но пока его не пнули он работать не стал
Не вижу пока фактов, свидетельствующих в пользу этого предположения. Я сейчас обратил внимание, что тикет имеет тип "баг". Я пока не вижу оснований предполагать, что связь отсутствовала в результате бага. Связи может не быть по многим причинам, например базовая станция оператора была отключена (проводились какие-нибудь работы)...
раз есть некая проблема, которая может произойти, и у нас есть возможность из неё выйти,
Не думаю, что в описанном случае у нас такая возможность есть.
то нужно попробовать.
С другой стороны, в описанной ситуации от рестарта модуля хуже все равно не будет...
Так что возражений против такого улучшения у меня нет, хотя его полезность сомнительна...
follow-up: 7 comment:6 by , 5 years ago
Связи может не быть по многим причинам
Здесь проблема не в том что связь пропала, а в том что она не восстановилась сама, а восстановилась только после рестарта 3gd.
Что бы исключить простое совпадение пользователь сначала перезапустил 3gd только на сервере в 04:04:11, после этого у сервера связь появилась
04:06:04 3gd[20958]: tls_tty.cpp:169: TLS connection established
а клиент2 так и остался в no service, затем через некоторое время в 05:46:11 пользователь перезапустил 3gd на клиенте2 и на нём вскоре тоже появилась связь
05:47:45 3gd[17863]: tls_tty.cpp:169: TLS connection established
comment:7 by , 5 years ago
Replying to san:
Здесь проблема не в том что связь пропала, а в том что она не восстановилась сама,
Это я понял.
но зато сразу восстановилась после рестарта 3gd.
Я пока не вижу доказательств наличия причинно-следственной связи между рестартом 3gd и восстановлением связи. Впрочем, доказательств отсутствия такой связи тоже нет.
пользователь перезапустил 3gd на клиенте2 и на нём вскоре тоже появилась связь
Это может быть совпадением. Возможно, что если бы он не перезапускал 3gd, связь все равно вскоре появилась бы. Как бы то ни было, я не представляю, каим образом я могу разобраться, почему устройство попало в такое состояние. В описании модуля SIM я не встречал ничего, что могло бы помочь в диагностике его внутренних проблем...
follow-up: 10 comment:8 by , 5 years ago
| Type: | баг → улучшение |
|---|
Replying to san:
нужно ввести ещё какой-то критерий для рестарта модуля SIM, когда он почему-то стал "no service".
Так как других предложений нет, я согласен реализовать токое улучшение, но не прямо так, как ты предлагаешь, а чуть-чуть по-другому: выполнять рестарт модуля не по факту состояния "No service". Предполагаю, что нахождение модуля в таком состоянии еще не говорит о нештатной ситуации. Например в этом состоянии модуль наверняка находится сразу после его включения, пока ищет подходящую сеть и регистрируется в ней. Я предлагаю другой вариант - выполнять рестарт при отсутствии соединения PPP в течение 5 минут. Похожий механизм у нас уже был реализован, когда обнаружилось, что модуль может не отвечать на команды pppd, только сейчас этот механизм работает лишь при старте, а я предлагаю сделать так, чтобы он работал все время.
comment:9 by , 5 years ago
О, я только сейчас обнаружил, что у нас механизм рестарта модуля при отсутствии соединения PPP, о котором я писал в предыдущем комментарии, вообще не работает, так как он был завязан на сообщения NMEA, а после замены SIM5320 на SIM7600 сообщения NMEA нам больше не приходят...
comment:10 by , 5 years ago
Я предлагаю другой вариант - выполнять рестарт при отсутствии соединения PPP в течение 5 минут. Похожий механизм у нас уже был реализован, когда обнаружилось, что модуль может не отвечать на команды pppd, только сейчас этот механизм работает лишь при старте, а я предлагаю сделать так, чтобы он работал все время.
Поддерживаю, это закроет более широкий диапазон причин отсутствия связи.
Replying to san:
Не представляю, как мы можем попытаться это сделать. Весь процесс регистрации в мобильной сети скрыт от нас внутри модуля, мы можем видеть только его результат...