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.

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

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

У меня один из самых "чахлых" Lite III rev A. EoIP без шифрования выдаёт 86-88 мбит/с. Если не опасаетесь гонять нешифрованный трафик - можно взять keenetic start 2 рублей за 1200. Адрес у меня белый динамический, привязан к KeenDNS. С серым, насколько знаю, EoIP не поднимется. Для вменяемого качества трансляции нужно около 40 мбит/с для fullHD с h264. Если между машинами пинг более 20 мс - то задержка от ввода до отображения кадра будет около 50-60 мсек, в динамичные шутеры уже некомфортно. У меня между машинами пинг через туннель 7 мсек, задержка от ввода до отображения кадра около 40 мсек - вполне играбельно.

У меня домашняя трансляция Steam работает через EoIP-туннель между двумя кинетиками. Вы уверены, что Вам нужен именно VPN? По сути требуется общий L2 сегмент, EoIP - как раз то, что нужно.

Поддержу предыдущего товарища. Конкретно меня интересует возможность приоритезации трафика. На данный момент в сети есть устройство с трафиком примерно в 35-40 мбит/с, чувствительное к задержкам. И есть несколько других, с трафиком 5-10 мбит/с. Непосредственно пропускной способности хватает на всех (она около 85 мбит/с), но при использовании канала другими устройствами, задержка пакетов для первого устройства заметно возрастает. Можно ли сгладить это влияние ограничением полосы либо приоритезацией ?

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

Провайдер время от времени рвёт PPPoE-сессию и выдаёт новые IP-адреса. В туннелях остаются старые (потому как во время создания туннеля к ddns-имени были привязаны старые). Приходится перезапускать.

Мне бы тоже весьма пригодилось. Кроме того, было бы чрезвычайно полезно добавить хоть какую-то возможность самовосстановления туннелей EoIP (сейчас приходится вручную перезапускать через CLI)

Если кому-то вдруг нужно для статистики - добрались руки до iperf, проверил свой EoIP. Итак, имеется два Keenetic Lite III rev A (без криптомодуля) в сети одного провайдера на расстоянии около 50 километров (один через FTTx , другой через GPON). Туннель безо всякого шифрования, голый EoIP. Выдаёт 86-88 Мегабит при теоретическом потолке в 100. Задержки на маленьких пакетах (до 1500 байт) что внутри туннеля, что вне туннеля - 6-8 мсек. То есть EoIP-туннель не увеличил задержку (по крайней мере сколь-нибудь видимо), и выдал практически 90% от теоретической пропускной способности для идеальных условий. И это на одних из самых "хилых" устройств (насколько знаю, самый бюджетный Keenetic Start II имеет такую же аппаратную платформу, кроме обвязки физики eth) Шифрование, думаю, заметно повлияет на результат, но для моего случая оно не требуется. Вопрос вдогонку: У провайдера есть пул белых динамических адресов, но он частенько заканчивается. Тогда провайдер выдаёт серый адрес. Я решаю это перезапуском PPPoE, и раза с 3-4 мне таки-достаётся белый адрес. Что делать, если со временем получить белый адрес будет всё сложнее и сложнее ? Как наиболее просто в таком случае поднимать EoIP ?

Жаль, не самый удобный вариант.

Наверное да, но это значит, что если другая сторона в самом деле отвалилась (например отсутствие питания), то получим отвал всего бриджа каждые n секунд. Не очень здорово. По-хорошему надо бы передёргивать именно EoIP, не трогая остального.