Keepalive timeout trassir что

Ошибки облачного сервиса TRASSIR и их решение

Данная статья рассматривает частые ошибки TRASSIR Server / TRASSIR Client.

Выполнив рекомендации, указанные в разделе «Основные требования» — вы избавитесь от большинства возможных ошибок TRASSIR Cloud.

• Основные требования
  • Версия ПО
  • DNS
  • Настройка сетевых интерфейсов (TRASSIR OS)
  • Доступность ресурсов
    • Проверка доступности ресурсов
    • Ошибка: ошибка в узле или тикете
      • Где взять тикет?
      • В личном кабинете при нажатии «Добавить устройство» есть только пункты Hikvision и Hiwatch

      Основные требования

      Версия ПО

      TRASSIR сервер так же как и клиент обязательно должен быть обновлен до версии 4.2.
      Инструкция по обновлению доступна по ссылке.

      DNS

      Рекомендуется использование публичного DNS. Большинство ошибок с облаком решается выставлением публичного DNS.

      Как дополнительный DNS можно установить DNS провайдера, либо адрес шлюза:

      

      Настройка сетевых интерфейсов (TRASSIR OS)

      На сервере должны быть корректно настроены сетевые интерфейсы.
      Если используется 2 сетевых интерфейса на регистраторе – шлюз прописан должен быть только на одном из них.
      Инструкция по настройке сетевых интерфейсов.

      Доступность ресурсов

      Для работы с облаком со стороны сервера должны быть доступны следующие ресурсы:

      • globaldb.cloud.trassir.com (IP 178.159.249.108)
      • b30.ru.cloud.trassir.com (IP 95.163.90.190)
      • b31.ru.cloud.trassir.com (IP 95.163.90.189)
      • b32.ru.cloud.trassir.com (IP 95.163.90.188)
      • c30.ru.cloud.trassir.com (IP 79.137.213.138)
      • d30.ru.cloud.trassir.com (IP 92.38.235.133)
      • d32.ru.cloud.trassir.com (IP 92.38.235.44)
      • e30.ru.cloud.trassir.com (IP 92.38.235.189)
      • f30.ru.cloud.trassir.com (IP 79.137.213.180)
      • h30.ru.cloud.trassir.com (IP 89.208.210.119)
      • g30.ru.cloud.trassir.com (IP 89.208.34.31)
      • i30.ru.cloud.trassir.com (IP 89.208.32.160)
      • i32.ru.cloud.trassir.com (IP 89.208.32.157)
      • j30.ru.cloud.trassir.com (IP 46.21.255.53)
      • f32.ru.cloud.trassir.com (IP 79.137.213.139)
      • g32.ru.cloud.trassir.com (IP 89.208.34.28)
      • l30.ru.cloud.trassir.com (IP 89.208.79.204)
      • c32.ru.cloud.trassir.com (IP 79.137.213.181)
      • k30.ru.cloud.trassir.com (IP 141.105.67.213)
      • j32.ru.cloud.trassir.com (IP 46.21.255.108)
      • m30.ru.cloud.trassir.com (IP 95.163.121.70)
      • m32.ru.cloud.trassir.com (IP 95.163.104.38)

      Общение TRASSIR с облаком идет по 443 порту. Отправка и получение данных происходит по протоколам TCP и UDP.

      Проверка доступности ресурсов

      Доступность облачных серверов можно проверить с помощью командной строки cmd — ping на ОС Windows:

      

      • ping globaldb.cloud.trassir.com

      и с помощью данного скрипта на TRASSIR OS.
      Результат его работы можно посмотреть в лог-файле скрипта в папке «Скриншоты».
      Выполнять ping необходимо по доменному имени, а не по IP адресу.

      Распространенные ошибки облака

      Ошибка: ошибка в узле или тикете

      Проверьте правильность данных во вкладках «Имя пользователя» и «Тикет».
      Проверьте чтобы эти данные совпадали с теми, что указаны в личном кабинете облака.
      Если после ручного ввода тикета ошибка остается — можно попробовать скопировать тикет из личного кабинета и вставьте в поле «Тикет».

      Где взять тикет?

      В личном кабинете облака: https://trassircloud.com/
      Подробно описано в инструкции по ссылке.

      В личном кабинете при нажатии «Добавить устройство» есть только пункты Hikvision и Hiwatch

      Данная проблема не связана с облаком TRASSIR, а вызвана некорректным отображением страницы личного кабинета в браузере.
      Для решения можно проверь эту же страницу в режиме «инкогнито» или открыть её в другом браузере, а также почистить кэш браузера.

      Ошибка: неправильное имя пользователя или пароль

      Данная ошибка может возникнуть на клиенте. В клиенте используются логин и пароль, а не логин и тикет.
      Если вы не знаете свой пароль от учетной записи, можно воспользоваться процедурой сброса на сайте https://trassircloud.com/. Личный кабинет – кнопка «Забыли пароль?».

      Ошибка подключения к облаку / cloud communication error

      Чаще всего решается вписыванием публичного DNS, если он прописан проверьте командой «Ping» адрес globaldb.cloud.trassir.com.
      Если команда ping проходит проходит успешно, а ошибка остается – необходимо выслать журналы и дампы падений в техническую поддержку.

      Ошибка соединения с облаком: cloud connect is not available

      Данная ошибка свидетельствует о блокировки передачи данных по 443 порту UDP. Проверьте не блокируется ли файрволом передача данных по UDP.
      Также убедитесь, что указан публичный DNS в качестве основного. Если не поможет – необходимо выслать журналы и дампы падений в техническую поддержку.

      Ошибка: toolong beacon send cancelled

      Обычно данная ошибка свидетельствует о проблемах с передачей данных по 443 порту UDP . Убедитесь, что прописан публичный DNS, проверьте не блокируется ли файрволлом передача данных. Если блокировки нет – снимите журналы и дампы падений и затем перезагрузите сервер.
      Если после перезагрузки сервера ошибка уйдет и облако заработает – пришлите дампы в техническую поддержку, с указанием ошибки и того что перезагрузка помогла.

      Ошибка: import_account empty or invalid

      Ошибка говорит о том, что регистратор не смог корректно импортировать облачного пользователя из облака.
      Для исправления ошибки:

      1. Отключите облако TRASSIR;
      2. Удалите облачного пользователя из вкладки «Пользователи»;
      3. Удалите сервер из личного кабинета облака;
      4. Перезагрузите сервер;
      5. Включите облако, и заново введите логин и тикет.

      Если это не поможет — пришлите журналы и дампы падений в техническую поддержку.

      Что значит параметр keep alive timeout у клиента pppoe?

      Всем доброго. Не ругайте строго, ибо читал, но не понял 🙁
      В настройках pppoe клиента роутера (mikrotik) есть поле keep alive timeout на вики говорится что это ограничение времени активных подключений и по умолчанию равно 60 секунд.
      А можно как то поподробние 🙂

      П.С. Дело в том,что время от времени у меня на микротике как бы «залипает» этот pppoe, после переподключения опять работает, провайдер говорит что у него все ок, что это у меня что то с железом,вот я теперь и изучаю все настройки pppoe клиента.
      Зарание спасибо за помощь

      • Вопрос задан более трёх лет назад
      • 17507 просмотров

      Комментировать
      Решения вопроса 0
      Ответы на вопрос 2

      

      АртемЪ @Jump Куратор тега Системное администрирование
      Системный администратор со стажем.

      Ну вот работает PPoE тоннель поверх интернета, и вдруг раз и связь прервалась.
      Возникает вопрос — тоннель сразу разрывать, или удерживать какое-то время, в надежде что связь наладится.
      Вот этот параметр как раз определяет сколько будет поддерживаться активным тоннель в случае падения связи.

      Если у вас он 60 секунд — то при падении связи на 30секунд, PPoE не оборвется.

      Ответ написан более трёх лет назад
      Комментировать
      Нравится 4 Комментировать

      

      Кирилл Васильев @vasilevkirill
      Сертифицированный тренер MikroTik TR0417

      после того как пакеты по туннелю перестанут ходить, MikroTik будет слать keepalive пакеты в туннель и если в течении указанных секунд не будет подтверждения, туннель будет считаться мёртвым.

      Ответ написан более трёх лет назад
      Комментировать
      Нравится 1 Комментировать
      Ваш ответ на вопрос

      Войдите, чтобы написать ответ

      

      • Windows
      • +1 ещё

      Где найти список созданных сетей Windows 10?

      • 1 подписчик
      • 22 часа назад
      • 95 просмотров

      Saved searches

      Use saved searches to filter your results more quickly

      Cancel Create saved search

      You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session.

      sanic-org / sanic Public

      Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

      By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

      Already on GitHub? Sign in to your account

      KeepAlive Timeout: what is it? #1093

      smlbiobot opened this issue Jan 18, 2018 · 13 comments

      KeepAlive Timeout: what is it? #1093

      smlbiobot opened this issue Jan 18, 2018 · 13 comments

      Comments

      smlbiobot commented Jan 18, 2018

      Since upgrading from 0.5.0 to 0.7.0 I am seeing a lot of these in my logs:

      [2018-01-18 17:37:16 +0800] [5425] [INFO] KeepAlive Timeout. Closing connection. [2018-01-18 17:37:16 +0800] [5425] [INFO] KeepAlive Timeout. Closing connection. [2018-01-18 17:37:16 +0800] [5425] [INFO] KeepAlive Timeout. Closing connection. [2018-01-18 17:37:16 +0800] [5425] [INFO] KeepAlive Timeout. Closing connection. [2018-01-18 17:37:16 +0800] [5425] [INFO] KeepAlive Timeout. Closing connection. [2018-01-18 17:37:16 +0800] [5425] [INFO] KeepAlive Timeout. Closing connection. 

      What are these and are they normal or is there something in my code that I need to fix?

      The text was updated successfully, but these errors were encountered:

      frnkvieira commented Jan 19, 2018

      They are perfectly normal (in most cases). In HTTP/1.1 connections are keep-alive by default which means your browser keeps the connection open after it made all the requests. After some time if you don’t request a new page this connection will timeout. Not sure why Sanic devs log such thing in INFO mode. IMHO this would be a DEBUG level since most users don’t even understand what’s going on.

      Member Author
      smlbiobot commented Jan 21, 2018

      Also, I kept on getting these, which also didn’t use to happen:

      WARNING:asyncio:Executing created at /usr/local/Cellar/python3/3.6.4_1/Frameworks/Python.framework/Versions/3.6/lib/python3.6/asyncio/tasks.py:639> took 0.828 seconds 

      What am I being warned about exactly? The site runs fine and I don’t quite understand what I am supposed to fix.

      Contributor
      arnulfojr commented Jan 21, 2018 •

      As @frnkvieira said, this are perfectly normal messages, you can take a look into the docs for more information.
      I would only disagree in the logging level that frnkviera says, as this is configurable (can be switched off) makes sense to have it in INFO level, also because it is connection-related information.

      I would suggest to keep it on, if the client requesting will request several «resources» (i.e. frontend client) but if you’re only dealing with a single API call from time to time then you can switch it off (if you want to ignore it it’s ok but you can switch it off while developing).

      hope it helps 🙂 (if so then please don’t forget to close the issue)

      yunstanford commented Jan 21, 2018

      I’m also thinking this could be DEBUG level

      xen commented Jan 21, 2018

      @smlbiobot this is a notification that you have some code that runs longer than expected by Sanic.

      Member Author
      smlbiobot commented Jan 25, 2018

      ah ok thanks very much — that is helpful. If I encounter many of those, am I supposed to add in some asyncio.sleep(0) every now and then?

      zjuchenyuan commented Jan 29, 2018
      ashleysommer commented Jan 30, 2018

      @smlbiobot Theres some confusion and misunderstanding in this thread that I’d like to clear up.
      And some useful points to discuss.

      Some background:
      Last year, sanic did not have Response Timeout nor Keepalive Timeout. It only had a Request Timeout.
      But that request timeout was used to indicate three different things.

      1. A request took too long to arrive from the client to the server.
      2. A response took too long to be generated by the server app, or too long to send back to the client.
      3. The Keep-Alive feature was used, and the keep alive timer timed out.

      The Request Timeout variable was default to 60 seconds.
      In all three of these cases a RequestTimeout exception was thrown if this timeout triggered, and a HTTP Client Error response was generated by the server with code 403 «RequestTimeout» and was sent back to the client.

      This was correct behaviour for scenario 1, but not for 2 or 3. The biggest problem was that every time a client connected using the KeepAlive function, we would see an unexplainable RequestTimeout Exception thrown by the server 60 seconds later, logged to the console, and 403 response sent to the client, as reported in Issue #902.

      In response to that, in PR #939 I wrote some code to split the Request Timeout into three different timeouts. Each with their own configurable timeout length in seconds. Read about them in the docs as pointed out by @arnulfojr and @zjuchenyuan here:
      http://sanic.readthedocs.io/en/latest/sanic/config.html#what-is-keep-alive-and-what-does-the-keep-alive-timeout-value-do

      The biggest change #939 introduced is that we are no longer treating KeepAliveTimeout as an error. It is a normal thing to happen. Every KeepAlive-enabled connection is expected to timeout at some point after it is created. So rather than throwing an exception (as per previous behaviour), it now simply logs it using the normal server-level logging output. So rather than seeing logs polluted with RequestTimeout exceptions as per #902, we are now seeing logs polluted with KeepAlive Timeout notifications, as per OP’s issue here.

      this is a notification that you have some code that runs longer than expected by Sanic

      This is not correct. You are thinking of a ResponseTimeout exception.

      @frnkvieira @arnulfojr @yunstanford
      My decision to make this INFO level was quite arbitrary. It is certainly not at ERROR level nor WARNING, but I also consider it to be more important than DEBUG level. So I landed on INFO level.

      After seeing this Issue thread, and the confusion that it is causing some users, I think perhaps it is better to move it to DEBUG level, but I want the opinion of others on that matter too.

      Arxont

      Вводная: Есть удалённая система видеонаблюдения. Необходимо предоставить к ней доступ из офиса и интернета. Проблема в том, что есть ТОЛЬКО gsm, который предоставляет «серый» ip к которому нельзя обратиться напрямую (сервисы типа DynDNS и прочие не работают, так как им требуется динамический айпишник).

      Решение: Будем использовать для работы роутер RB951G-2HnD — у него имеется USB порт для подключения 3G модема. В офисе установлен роутер RB2011.

      Вначале прописываем параметры центрального узла.

      Включаем pptp сервер
      interface pptp-server server set enabled=yes keepalive-timeout=120

      Создаём пользователя для подключения к pptp серверу
      ppp secret add local-address=10.10.10.2 name=videotest password=TestPassword profile=default-encryption remote-address=10.10.10.3 service=pptp

      Создаём подключение к pptp
      interface pptp-server add name=videotest user=videotest

      Создаём eoip туннель
      interface eoip add mac-address=02:29:9F:25:31:B4 name=eoip-tunnel1 remote-address=10.10.10.3 tunnel-id=0

      Создаём бридж между локальной сетью офиса и eoip туннелем
      interface bridge add l2mtu=1598 name=bridge1
      interface bridge port add bridge=bridge1 interface=ether6
      interface bridge port add bridge=bridge1 interface=eoip-tunnel1

      На этом настройка центрального узла закончена.

      Далее перейдём к настройке удалённого роутера.
      Прописываем подключение через модем (в нашем случае МТС).
      interface ppp-client add apn= internet.mts.ru disabled=no info-channel=1 name=ppp-out1 password=mts port=usb2 user=mts

      Создаём подключение к офису (pptp сервер, необходимо прописать его адрес, логин и пароль)
      interface pptp-client add allow=mschap1,mschap2 connect-to=pptp.example.com disabled=no name=pptp-out1 password=TestPassword user=videotest

      Здесь также создаём eoip тунель
      interface eoip add mac-address=02:34:DB:C5:A5:03 name=eoip-tunnel1 remote-address=10.10.10.2 tunnel-id=0
      и бридж между тунелем и интерфейсом на котором сидит видеорегистратор
      interface bridge add l2mtu=1598 name=bridge1
      interface bridge port add bridge=bridge1 interface=ether5
      interface bridge port add bridge=bridge1 interface=eoip-tunnel1

      Теперь можем проверять работу — видео теперь в одном широковещательном домене с сетью офиса и должен быть прямой доступ.

      PS: Ссылки на документацию
      http://wiki.mikrotik.com/wiki/Manual:Interface/PPTP
      http://wiki.mikrotik.com/wiki/Manual:Interface/EoIP
      http://wiki.mikrotik.com/wiki/Russian/Построение_VPN_с_помощью_технологии_EoIP

      PS2: Рекомендую сделать отдельную подсеть для видеонаблюдения (с отдельным широковещательным доменом) чтобы минимизировать широковещательный трафик через канал.

      Похожие публикации:

      1. Как открыть файл с гитхаба
      2. Как создать окно в c visual studio
      3. Как создать проект django в pycharm
      4. Чем закрыть камеру на ноутбуке