t800
-
Постов
205 -
Зарегистрирован
-
Посещение
Тип контента
Профили
Форумы
Галерея
Загрузки
Блоги
События
Весь контент t800
-
Есть вопрос. До 5.1 настройки роуминга 802.11 r/k/v распространялись на весь сегмент. Имя мобильного домена и ключ были одинаковыми, и можно указать для какого диапазона работает FT. В 5.1b настройки точек доступа в сегменте стали полностью независимыми. Но при этом всё равно можно в каждой указать диапазон, в котором должен работать FT. А какая тут логика, если точка доступа чисто 5GHz? И как в этом случае работает band steering (и работает ли)?
-
Только в его? )) У меня сейчас два роутера (остальные откатил на стабильную версию) - KN-1010 и NC-1012 с той же проблемой. Достаточно разных генераций и настроенные по-разному. Осмелюсь утверждать, что проблема с интерпретацией конфига радиоточек носит системный характер. И мне крайне удивительно, что проблема эта вылезла именно в бете, а не на этапе альфа-версий. А кроме того, объективно нет намёков на то, что с дефектом работают. Я в состоянии управлять роутером через CLI, но отсутствие в WebUI основных элементов управления, как мне кажется, достаточно серьёзный повод приоритезировать работу по устранению именно этого дефекта
-
@eralde 5.1 Beta 0.3 - точек доступа 5GHz в web-ui как не было, так и нет. Может вам данных для анализа проблемы не хватает?
-
Ну и еще какая-то непонятка с настройкой Wifi-роуминга. Каждая точка доступа в сегменте имеет вроде бы свою индивидуальную конфигурацию, но по факту она общая - совпадает имя домена и ключ. Если уже менять подход в сторону общих настроек и индивидуальных, то имеет смысл делать это без путаницы. Потому что в текущем варианте это здорово путает и заставляет думать, что сеть 2.4 и сеть 5 имеют индивидуальные настройки роуминга P.S. На кой чёрт было менять то, что хорошо работало и к чему все привыкли, полагаю, вопрос останется без ответа.
-
Ну, как следует из моего сообщения выше, поправили так себе. Я еще не все роутеры обновил, из тех, где наблюдалась проблема, на Viva - все починилось, а вот Гига 1010 осталась без фикса, точку 5 гигагерц я там не наблюдаю. А она есть (c)
-
Вот добавить я не пробовал, просто существующая точка появилась в сегменте Вообще, ощущение, конечно, таково, что с маркировкой "бета" погорячились
-
@eralde обновление до 5.1 Beta 0.2 решило проблему с отсутствием точки доступа 5GHz не на всех роутерах. На том KN-1010, с которого я снимал для вас диагностику, всё осталось как есть:
-
Выложил в скрытом посте
-
@eralde Если для локализации проблемы нужны логи, дайте знать, пожалуйста
-
На трёх маршрутизаторах - NC-1012, KN-1010, KN-1913 после обновления до 5.1 Beta 0.1 ни в "Сегментах", ни в "Точках доступа" нет точек доступа 5GHz. Точка поднята, работает, на ней висят клиенты, а в интерфейсе отсутствует как класс. Не всякая альфа так косячит, как эта бета.
-
@Ponywka Вы не рассматриваете возможность реализовать резервный маршрут? Например, в группе указать целевой интерфейс nwg1, и резервный - ppp0? Сейчас МТ работает по принципу "эксклюзивный" маршрут. И если интерфейс падает, то доступа к доменам/подсетям в группе больше не будет, хотя при этом вполне может существовать и альтернативный рабочий интерфейс.
-
@Ponywka Сегодня поймал ситуацию, когда при добавлении новой группы (и правил в ней) МТ внезапно потерял примерно две трети списка, который был до этого Воспроизвести не возьмусь, но мне показалось, что это совпало с очень длинным ожиданием "сохранение изменений", когда я не дождался окончания и перезагрузил страницу
-
@Ponywka Перезагрузил роутер (менял состав компонентов), МТ автоматом не поднялся. /opt/etc/init.d # ./S99magitrickle status Checking MagiTrickle Daemon... dead. При этом в логе кинетика: I [Feb 15 11:40:14] root: Started MagiTrickle Daemon from .
-
Вчера нарвался на ситуацию, когда добавлял в уже существующую группу запись с Wildcard и кнопка сохранения изменений так и не стала активной. Пришлось перезагрузить страницу, и со второй попытки всё сработало. Понятно, что из этой истории выводов не сделать, но тем не менее, как минимум один раз с таким столкнулся.
-
Мы как на разных языках говорим. Вопроса "мало" или "много" вообще нет сейчас. Я хочу разобраться, уменьшится ли число DNS-запросов для одного и того же пакета трафика с приведённой выше конфигурацией (принимая, что xkeen -dns активен).
-
Так я не хочу через dns keenetic. Я хочу, чтобы xray выполнил резолв перехваченного запроса, ответил на него, кешировал ответ и при получении пакета уже на пересылку, использовал бы кешированные данные, когда выполнял повторный запрос по тому же доменному имени
-
Ну тогда вернёмся в самое начало моего вопроса. Вот я настроил перехват DNS, используя фичу 1.1.3.9, потом сделал настройки: 05_routing, самое верхнее правило: "rules": [ { "port": 53, "outboundTag": "dns-out" }, 04_outbounds: { "protocol": "dns", "tag": "dns-out" } Судя по логам, запросы корректно стали заворачиваться в сервера, указанные в 02_dns. Вопрос тот же - я уменьшил число запросов за счёт кеширования встроенным DNS-сервером xray?
-
Я пытаюсь открыть страницу в сети. Например aaa.com. DNS-запрос уходит в кинетик, тот его резолвит и далее браузер идёт на полученный IP-адрес. Этот пакет перехватывается xray, там включён sniffing. xray в свою очередь ТОЖЕ делает резолв, чтобы получить IP-адрес для маршрутизации по IP. Или я не прав, и xray не делает резолв, потому что видит домен в SNI и destination IP в пакете?
-
Я прочитал. Но именно из этого описания не понял с ходу о чём речь. Сейчас уже более-менее разобрался, спасибо. Буду очень признателен, если поможете понять следующее. Вот моя конфигурация 02_dns.json: { "dns": { "servers": [ { "address": "https+local://1.1.1.1/dns-query", "skipFallback": false }, { "address": "https+local://8.8.8.8/dns-query", "skipFallback": false } ], "useSystemHosts": true, "queryStrategy": "UseIPv4", "tag": "dns_in" } } Я правильно понимаю, что, если перехват DNS-запросов выключен, то фактически обращение к любому ресурсу по fqdn выльется в два запроса: один запрос отправит маршрутизатор, чтобы вернуть IP клиенту, а второй запрос потом отправит xray, чтобы применить правила маршрутизации по доменному имени? При этом, если перехват включён, то теоретически запрос внешнему DNS-серверу будет один: когда запрос от клиента кинетику будет перехвачен и отправлен в xray, потому что ответ кешируется и сам xray уже будет использовать кешированный IP-адрес?
-
Помогло, спасибо На 5.0.* 1.1.3.9 обязательно использовать? Или в общем можно и на 1.1.3.8 работать? upd. Пришлось откатиться на стабильную версию, потому что, судя по логам, по какой-то причине запросы 53 порт роутера перехватывались и отправлялись в туннель. Причём, не у всех клиентов. Глубоко я копать не стал, потому что вой из-за неработающего интернета стоял до небес. На 1.1.3.8 ситуация выправилась и жалобы "тут работает, вот тут как-то не работает" ушли.
-
Привет Честно искал в теме ответ на свой вопрос, но не преуспел. У одного меня restart отрабатывает порядка минуты? Версия - 1.1.3.9, обновлял сегодня. Включал логи, выглядит так, как будто и стоп, и старт прям подолгу длятся.
-
Просто для информации: сегодня в AppStore релизнули версию официального клиента для IOS с поддержкой 2.0. Что в моём понимании говорит о том, что финальная стадия пройдена Всем тем, кто тут так нетерпеливо ждёт новой версии протокола, дам подсказку. Внутри РФ даже базовый wireguard не блокируется. И виртуальную машину с любым линуксом на борту внутри РФ поднять можно не только недорого, но и быстро. Sapienti sat.
-
Кейс в поддержку открыли? Селф-тест в момент, когда проблема наблюдалась, сняли и приложили?
-
А профиль DNS влияет? Должен использоваться только системный профиль или это не принципиально и можно указать один из предустановленных профилей «интернет-фильтров»?
-
5.0 beta 0 Клиенты, подключённые по WiFi к экстендеру Keenetic Giga III, отображаются в списке клиентов контроллера как "подключённые по проводу" Это штатное поведение, или дефект? Сам экстендер, понятно, отображает всех клиентов корректно - с указанием диапазона подключения и т.п.
