KorDen

Да Да

Имеем агрегацию: В некоторых случаях наблюдаются потери. При balance-xor со стороны сервера потерь не наблюдается, хотя может просто не словил. Одна из версий при наблюдении на зеркале обоих портов: - потери наблюдаются только у нетегированного трафика (который access vlan 22), тегированный трафик (vlan 21) не теряется - потери что до самого роутера, что до устройств в соседних acceess-портах - при этом потери, когда трафик роутер->сервер идет через порт 6, теряются ответные пакеты сервер->роутер через тот же порт 6 (через 5 нормально) При этом похоже оно воспроизводится не всегда, но похоже гарантированно воспроизводится сразу после ребута роутера Такое отдаленное ощущение, что switchport mode access на втором порту в группе криво назначается на входящий трафик сразу после ребута (или настройки), а потом какие-то телодвижения исправляют ситуацию.

Верпоятнее всего отвалился чип 5 ГГц. Без фикса, имеющегося в 2.11/2.16 (например, на 2.06) у вас бы роутер ушел в циклический ребут из-за невозможности поднять 5 ГГц, а так он просто вырубил его...

WPA-Enterprise...?

Например через консоль "interface Home traffic-shape rate 80000" Иными словами, ставите один кинетик, без свичей, для приставки выделяете LAN-порт (галка "порт для IPTV" в настройках WAN), для домашнего сегмента выставляете ограничение скорости (по идее будет нормально при 80-85 мбит/с) - и всё.

Зачем ставить свич? На любом кинетике можно любой LAN-порт сбриджевать с WAN, это же прямо и есть режим для IPTV. Вам нужно просто ограничить для всего домашнего сегмента скорость например до 80 мбит/с, чтобы приставке оставался запас.

Скорее всего у вас конфликт со стороны роутеров соседей, например оба отдают 192.168.1.x

С возвращением вкладки "активных соединений" вернулась старая проблема тормозов, так как /rci/show/ip/nat подгружается всегда при открытии "Диагностики", а не только когда открыта вкладка "Активные соединения". Если в conntrack даже 3 тысячи соединений - вся страница диагностики начинает подтормаживать, особенно ощущается при работе с захватом пакетов - создание/редактирование правил захвата очень тормозит. Предлагаю всё же перестать грузить и обновлять список соединений при неактивной вкладке.

Видимо не полностью? Словил единократный ребут Peak дней 5 назад, в чате есть жалобы на ребуты 1011 - или это уже что-то другое?

Для работы роуминга клиентов (11r) нужно чтобы между всеми ТД ходил мультикаст бродкаст. Для работы "WiFi-системы" в части согласования путей нужно чтобы корректно ходил STP. На управляемых коммутаторах надо на этих портах либо отключать STP, либо настраивать BPDU Bridge, либо поиграться с параметрами STP и тогда теоретически коммутаторы так же могут участвовать в построении пути, но будет ли это работать нормально - хз.

....? Явно лишнее: - Приложения - Общие настройки > Производительность - Диагностика > Активные соединения В общих настройках описание компонентов, режимов работы, сброса - везде про режим роутера так или иначе говорится

Да куда угодно. Сейчас - скорее всего в админку, но если потом появятся какие-то иструменты анализа/диагностики прямо в RMM - возможно и в них. Речь именно о том, чтобы связать сущности в обе стороны. Сценарий - звонящий клиент/знакомый/родственник. Не помню, как назвал его сеть среди пары десятков - то, что было логично N месяцев назад, сейчас уже забылось. Ну или работа в команде. Надо определить клиента по имеющимся признакам - "посмотрите на этикетке" (sn/tag)/"зайдите в настройки мобилы/ноута и скажите адрес" - и вот от этого значения плясать.

Я сейчас о ситуации "знаю MAC клиента, надо зайти на роутер, к которому этот клиент сейчас подключен"

У вас кто-то раздал репитеру левый IP, вот и всё: Jul 23 17:26:17 ndhcpc: Bridge0: received OFFER for 192.168.0.111 from 192.168.0.50.

А 192.168.1.3 случаем не пингуется?

Подсеть дефолтная 192.168.1.x или нет? Она вообще пингуется?

2.4ГГц: 1-6-11 при ширине 20 МГц, режим N-only (если нет старых устройств с g), мощность 50%, возможно лучше 25% 5 ГГц: 36-52-149 при ширине 80 МГц, режим N+AC, мощность 75%, возможно лучше 50% Рекомендации по мощности обусловлены симметрией с клиентами, которые практически всегда слабее. В РФ только один канал шириной 160 МГц в 5 ГГц (36-64), так что если нет реальной цели получить по WiFi практические скорости выше 650мбит/с возле ультры, смысла от него нет

- Peak или Hero на дефолте, переведенный в режим ретранслятора, раздаем ему IP по DHCP - вырубаем 2.4 ГГц в разделе ретранслятор - домашняя сеть (не на главной) - врубаем там же - ??? - девайс свалился на дефолтный 192.168.1.3, а 2.4 ГГц так и не включился. self-test после этого в приложении

Баг или фича?

Тогда надо поправить web (дефолтное отображение 160) и в CLI Manual заодно

3.7 Beta 0.2, в дефолте Peak вещает 5 GHz AP с шириной 80 MHz (в конфиге channel width отсутствует), а строчка "channel width 160" появляется в конфиге только после применения настроек WiFI 5 GHz (где по дефолту кружок на 160) Вроде бы и в Ultra 1810 аналогично. Баг или фича?

На текущий момент уже добавленные роутеры никак не различить по неизменным признакам: серийник, сервисный код, MAC-адрес. Предлагаю: - добавить отображение какого-то из этих признаков в список устройств - добавить поиск сетей и устройств по всем возможным признакам - серийный номер, сервисный код, MAC-адреса устройства. Причем в случае с MAC-адресом, по-хорошему должны обрабатываться все возможные MAC-адреса: дефолтные WAN, LAN, все BSSID/STA. - добавить поиск в разделе устройств по IP/MAC/Hostname - сделать интерактивные переходы не только из разделов сетей/устройств в разделы устройств/клиентов с фильтром по данной сети/устройству, но и обратные переходы из списка клиентов и устройств к спискам устройств и сетей.

Смешались в кучу кони, люди... При использовании WPA2-PSK и отключенном WPS вся ваша безопасность - это ключ сети (passphrase). Немного улучшить ситуацию можно только включив PMF, но в контексте "взлома" это защитит вас только от отправки deauth. Скрытый SSID - бестолковое и даже в некотором роде вредительское "улучшение". GTK - это всего лишь общий ключ шифрования бродкаста/мультикаста. При отключенном WPS, WPA3-SAE+PMF = хренвзломаешь. WPA2-PSK+PMF с длинным ключом - брутфорсить очень долго. Всё остальное - опасная ошибочная видимость безопасности.

Возьмите у кого-нибудь или купите (500р) тестер витой пары и будет всё понятно. Ну или если не хочется покупать, смотреть внутренности всех розеток

1) галка IKEv2 при включенном IKEv2 имеет value="[object Object]" (потому что в выводе ipsec.ikev2.enable а не ipsec.ikev2), как следствие не отображает реальное состояние 2) замечу, что для IKEv2-туннелей важно совпадение ID интерфейса ("IPIP25"), который сейчас не отображается, а по-хорошему бы иметь возможность задавать при создании