Himmler

Вставлю свои 5 копеек. В мае этого года во время грозы бахнуло очень рядом и погибло: -Порт у провайдера -Порт WAN у кинетика -Порт LAN у кинетика, в который был подключен ПК -Вмазанная сетевуха на материнской плате -Клокер на материнской плате -Мультик на материнской плате Заметьте, что к материнской плате это всё пришло аж через 3 гальванических развязки, так что никакой медный свитч не защитит от лютого импульса. На данный момент поставил перед кинетиком два медиаконвертора (суммарно 500 рублей на вторичном рынке), то есть оптическую развязку. Кинетику с выгоревшими портами очень поплохело, поначалу не грузился вообще, потом стал грузиться через раз, сейчас работает без нареканий (с переназначенными портами и двумя выгоревшими). Не иначе как самовосстановление наноботами.

Хорошо, что хотя бы так. Да и баг нечастый, не требует немедленного исправления.

Я бы и рад предоставить больше сведений, вот только роутер в этом состоянии еле живой, и максимум дебажной информации мне удалось получить только из лога через telnet.

Брандмауэр отключен, а вот KeenDNS я отключить не могу, ибо нужен постоянно, а баг случается раз в полгода.

Итак, на неделе вновь случилось, теперь на 2.16. Очень редкий баг (1 - 2 раза в год.), описывался мною ранее: Ребята, ну вы бы хоть посмотрели, а то вроде как 2.16 это "старая/добрая/стабильная/надёжная", а баг тянется ещё вон откуда.

Опишу более подробно: В веб-морду заходит и через ip, и через keenDNS-имя. При первом заходе в поломанном состоянии удаётся даже авторизоваться, но dashboard после этого не загружается (пустая страница) Все последующие попытки авторизации безуспешны, потому как в консоли браузера при загрузке веб-морды: Ошибка синтаксического анализа XML: корневой элемент не найден Адрес: http://192.168.1.1/auth Строка 1, символ 1: Telnet при этом худо-бедно работает, даёт глянуть лог и кое-что прочее, но вот reboot не выполняет.

Ну что ж, спустя 2,5 месяца я вновь поймал ту же самую проблему. W [May 7 22:03:09] ndm: Core::Watchdog: Event sender holds SSL_SERVER (19) lock 19439 seconds acquired May 7 16:39:10. Опять точно такие же симптомы, что и ранее, без каких-либо отличий, кроме того, что теперь это на 2.15.C.3.0-2. Ребята, с этим надо что-то делать.

Сегодня впервые за годы поймал на удалённом кинетике 2.14 такую же проблему, которая продолжается до настоящего времени. Веб-морда не грузится, CLI работает худо-бедно (system reboot не исполняется). В логах CLI весьма насторожила многократно повторяющаяся строчка: W [Feb 27 20:18:38] ndm: Core::Watchdog: Event sender holds SSL_SERVER (19) lock 15660 seconds acquired Feb 27 15:57:37. Аптайм около 9-10 суток, памяти свободно около 40%, CPU загружен на 1-5 %.

У Вас как-то очень резко растёт среднее время задержки с ростом размера пакета. На моём канале для icmp-пакета с "нагрузкой" в 32 байта среднее время 7 мсек, при 65000 байтах - 22 мсек. А у вас уже на 2500 байт такая задержка, хотя на мелких пакетах она меньше моей. Ну это не очень относится к делу, а вот логи трансляции может что-то и скажут, почему же трансляция не стартует. Они лежат в C:\Program Files (x86)\Steam\logs, файлы: streaming_log.txt StreamVideoTrace.txt StreamAudioTrace.txt Возможно, там будет что-то явно указано, что именно не удалось клиенту steam.

В настройках трансляции можно включить отображение статистики. Расширенное отображение включается/выключается клавишей F6 во время трансляции. Там указана задержка ввода, задержка отображения, текущий реальный битрейт и прочее. Интересно, почему без туннеля клиенты находят друг друга, но трансляция не запускается? Пробовали в таком режиме пинговать пакетами более 1500 байт?

HD4670 AGP.

У меня на одной стороне Pentium 4 3,4 Ггц на s478. Даже если там очень-очень оптимизированное шифрование со всякими SSE, для канала в 40 мегабит мой ЦП будет добавлять миллисекунд 10, а может и более. Потому как старичку 15 лет и он примерно в 10 раз менее производителен, чем i7 2700K (который тоже уже немолод) Так что в моём случае время точно увеличится, и заметно. Потому как мой случай близкий к предельному (с точки зрения производительности).

Разве что на каждом из клиентов работает софтварное шифрование, которое сколько-то добавляет к задержке. Очень вероятно, что менее 1 мсек.

Насколько я знаю, сервер hamachi используется при установке соединения, сам же трафик через сервер не проходит, а идёт напрямую от клиента 1 до клиента 2.

Ну, если сарай пустой, то дверь можно в принципе не закрывать. К тому же, для поднятия туннеля, нужно чтобы адрес назначения на обоих концах был верный. А задаётся он из настроек кинетика. Так что для подключения нужно либо угадать и заиметь тот адрес, который я прописал в настройках, либо эти настройки изменить. На мой взгляд, нужно быть чертовски кулхацкером, чтобы проделать первое и/или второе.