IgaX
-
Posts
950 -
Joined
-
Last visited
-
Days Won
3
Content Type
Profiles
Forums
Gallery
Downloads
Blogs
Events
Posts posted by IgaX
-
-
1 час назад, Le ecureuil сказал:
Уже задан, MTU на интерфейсах без IP везде и так максимален.
Спс. Я просто к тому, что на 802.11 max MSDU до шифрования (в которую можно запихнуть IP datagram) - 2304 (!) .. так что если перебирать бриджи в плане клиентов, то тут тоже есть потенциал для улучшения с учетом, конечно, вопроса IP-фрагментации.
Я к чему .. конечно не Jumbo .. но если брать 802.11 в качестве DS линка, то eoip_allow_fragment может быть лишним.
И заодно такой вопрос: как я понимаю, на уровне бриджа все кошки серые .. поэтому можно ли включить EoIP в состав непосредственно беспроводного интерфейса, чтобы получить трушный прозрачный 802.11 на который можно повесить все плюшки? С учетом, например, этих особенностей:
Скрытый текст
.. по идее, в такой конструкции беспроводная механика могла бы полностью раскрыться, т.к. на другой стороне туннеля был бы сразу тот же родной 802.11.
-
1 час назад, Le ecureuil сказал:
Тут к сожалению аппаратное ограничение - PDMA (а именно самая ключевая часть сетевой карты роутера) не поддерживает jumbo-фреймы, потому мы ничего не можем сделать на текущих чипах.
Ок, пусть без Jumbo, но Experimental Ethernet ведь можно? Включаем на порту и на интерфейсе или где это возможно ip mtu уже задан максимальный?
Цитатаinterface 1 ip mtu 1536
interface GigabitEthernet0/Vlan101 ip mtu 1536 -
1 минуту назад, r13 сказал:
@IgaX а Eoip в данной схеме зачем? Что не прозрачного в схеме соединения 2х точек по лан?
я ждал, спасибо
смысл в том, что если просто бриджевать, то при выборе wifistation вроде как все равно за-mat-ит и здравствуй proxy-arp .. а так предложение в стиле универсальной схемы: нужно просто придумать L3-линк, что м.б. будет проще для пользователя .. м.б. потом сделать одним из видов "режимов" для широкого применения .. типа купите два Кинетика и WDS/Mesh в два клика .. в любом месте .. с Enterprise-grade EAP .. секурно как в банке
.. или чтобы юзер видел свой роутер на даче и его клиентов как если бы они были на основном роутере посредством того же IPsec NAT Traversal (вроде тоже несложно навесить в теории на автомате для пресета) .. и нет проблем .. если те же камеры только в локалке пашут.
"бью в бубен, раскрываю потенциал".
-
10 минут назад, Le ecureuil сказал:
Свитч на гигабитных (между портами) поддерживает Jumbo, больше же нигде Jumbo кроме baby-jumbo (pppoe + vlan) не поддерживаются.
ок, раз принципиальных возражений по гибкости и потенциально оптимальному перформансу схемы в целом у начальника транспортного цеха нет, то мне осталось только понудеть по настройкам, в которых я мог бы все сделать дальше .. даже майки позволяют пусть и через реестр часто, но главное, что педали есть, а мы что, хуже? =)
Скрытый текст
-
1 час назад, IgaX сказал:
.. или вместо этого, если железо свитча роутера поддерживает Jumbo(?), то м.б. на меж-линке поднимем IP MTU до 1542:
- на К1 и К2
interface 1 ip mtu 1542
и/или заодно/вместо(?):
interface GigabitEthernet0/Vlan101 ip mtu 1542
-
4 часа назад, Le ecureuil сказал:
Не забудьте про eoip_allow_fragment, иначе может быть "бо-бо".
Если проца будет хватать при наполнении до краев, то почему бы и нет, но .. "экономика должна быть экономной" (с)
Все же хотел бы немного уточнить, а то иногда бывает путаница с HW MTU в плане включения L2 Header.
Всем известен IP MTU (равный Ethernet MTU) в 1500. Сам же кадр = IP_MTU(1500) + L2_Header(12+2) + FCS(4) + Vlan_Tag_если_задан(на каждый по 4). Если я правильно понял, в наших стандартных конфигурациях кадры от роутера маркируются если задан vlan на соответствующем интерфейсе (отличный от vlan 1, который native для 802.1q), соответственно, в провод обычно (если не vlan1) попадает кадр 1500+14+4+4=1522 .. а там еще и preamble если глубже копать.
Наш провод на GbE (м.б. не весь) поддерживает, как я понял, в т.ч. Experimental Ethernet, для которого IP MTU согласно RFC 895 - 1536. Таким образом, провод может, в теории, у нас переварить кадр, например, 1536+22=1558 .. а там еще вроде обещали Jumbo для G3 и LTE .. поэтому фз .. если на проводном меж-линке роутеров доступен Jumbo - точно нужен eoip_allow_fragment ?
Как бы там ни было. По идее 1536 для IP datagram в Exp.Eth.
Если берем стандартный IP MTU в 1500 для всех клиентов, то к бриджу, например, по проводу приходит тэгированный кадр размером 1522 (для воздуха вроде тоже можно vlan, но ждем настроек) .. попадая в бридж FCS и Vlan_Tag убираются, т.е. остается 1514.
Далее для EoIP заворачиваем это в "GRE"(8) + добавляем IP_Header(20) .. итого IP datagram = 1514+8+20 = 1542.
Если Jumbo нет, то в max. 1536 для IP datagram в Exp.Eth не влезаем. Формально, чтобы не напрягать без надобности проц - стараемся избегать IP-фрагментации, поэтому, как вариант, - на бриджах выставлять IP MTU с учетом дельты 1542-1536=6 (разница в 1500 и 1494 не очень существенна, поэтому для удобства и минимального напряга для всех передаем IP MTU в 1494 в т.ч. через 26-ю опцию DHCP) .. т.е. примерно так:
- на К1
ip dhcp pool _WEBADMIN option 26 1494 ip dhcp pool _WEBADMIN_GUEST_AP option 26 1494 # не забываем про бриджи, в т.ч. на К2: interface Home ip mtu 1494 interface Guest ip mtu 1494
.. или вместо этого, если железо свитча роутера поддерживает Jumbo(?), то м.б. на меж-линке поднимем IP MTU до 1542:
- на К1 и К2
interface 1 ip mtu 1542
Если ничего выше никак, то да, взводим:
- на К1 и К2
system set net.core.eoip_allow_fragment 1
Поэтому, наверное, будут полезны всем желающим ответы на вопросы (если не затруднит): все правильно или где-то накосячил? что из этого возможно? какие модели К* поддерживают в т.ч. Experimental Ethernet, а какие Jumbo?
Исходя из цели добиться максимального перформанса через минимальный напряг проца на потенциальные операции фрагментации EoIP-трафика.
-
Подумал на тему - как бы я это сделал.
Цель: обеспечить прозрачное бриджевание, чтобы в т.ч. на соответствующий прозрачный бридж можно было повесть всякие вкусности по настройке дров радио в части 802.11k и 802.11r, привязать тот же hostapd с любым выходом на EAP .. ну и потом уже просить пакетики из буфера пытаться перекидывать в нужную очередь, если дрова не умеют .. а то мало ли, вдруг, как-то умеют.
Вопрос по радиопланированию ячеек итп. настройкам не рассматриваю.
Значит, например, есть 2 гордые коробки (далее по тексту К1 и К2) с в т.ч. гостевым сегментом.
Будем все делать прозрачным мостом через EoIP. EoIP пойдет по проводу отдельным физ.линком а-ля вторым wan, чтобы меньше думать, т.к. настройки "ленивые" для режимов ИЦ.
Если что-то пропустил - прошу добавить, м.б. будет полезно для желающих подобной схемы.
1) Выделим, например, 1-й желтенький порт под физ.линк, соединим шнурком и далее из серии:
- на К1
interface GigabitEthernet0/0 rename 1 switchport mode access switchport access vlan 101 up ! # Поставим public, чтобы не думать + сетку на 2 хоста ptp interface GigabitEthernet0/Vlan101 description "Wired DS Link" security-level public ip address 172.16.0.1/30 up ! # Если, вдруг, нет маршрута для 172.16.0.0/30, то для поинта ip route 172.16.0.2 GigabitEthernet0/Vlan101- на К2
interface GigabitEthernet0/0 rename 1 switchport mode access switchport access vlan 101 up ! # Поставим public, чтобы не думать + второй поинт interface GigabitEthernet0/Vlan101 description "Wired DS Link" security-level public ip address 172.16.0.2/30 up ! # Если, вдруг, нет маршрута для 172.16.0.0/30, то для зеркального поинта ip route 172.16.0.1 GigabitEthernet0/Vlan101-> по идее, имеем рабочий линк а-ля второй wan, с мини-зонтиком.
2) Поднимем тоннельчеги для "Home" и "Guest":
- на К1
# Для Home interface EoIP0 tunnel destination 172.16.0.2 tunnel eoip id 1 up ! # Для Guest interface EoIP1 tunnel destination 172.16.0.2 tunnel eoip id 2 up !- на К2
# Для Home interface EoIP0 tunnel destination 172.16.0.1 tunnel eoip id 1 up ! # Для Guest interface EoIP1 tunnel destination 172.16.0.1 tunnel eoip id 2 up !-> security-level итп. не указываем, т.к. включим в мосты и навесим.
3) Наведем красоту, предположим, К1 у нас мастер-шлюз с выходом в мир:
- на К1
interface Bridge0 rename Home description "Home WDS" inherit GigabitEthernet0/Vlan1 include AccessPoint include AccessPoint_5G include EoIP0 security-level private ip address 192.168.1.1/24 up ! interface Bridge1 rename Guest description "Guest WDS" inherit GigabitEthernet0/Vlan3 include GuestWiFi include EoIP1 security-level protected ip address 10.1.30.1/24 up ! # на К1 ставим DHCP обслуживающий весь прозрачный бридж ip dhcp pool _WEBADMIN range 192.168.1.3 192.168.1.254 default-router 192.168.1.1 dns-server 8.8.8.8 8.8.4.4 lease 25200 bind Home enable ! ip dhcp pool _WEBADMIN_GUEST_AP range 10.1.30.3 10.1.30.254 default-router 10.1.30.1 dns-server 8.8.8.8 8.8.4.4 lease 25200 bind Guest enable !- на К2
interface Bridge0 rename Home description "Home WDS" inherit GigabitEthernet0/Vlan1 include AccessPoint include AccessPoint_5G include EoIP0 security-level private ip address 192.168.1.2/24 up ! interface Bridge1 rename Guest description "Guest WDS" inherit GigabitEthernet0/Vlan3 include GuestWiFi include EoIP1 security-level protected ip address 10.1.30.2/24 up ! # можно, конечно, нарезать на случай войны, но лучше учет в одном месте ip dhcp pool _WEBADMIN no enable ! ip dhcp pool _WEBADMIN_GUEST_AP no enable ! # помогаем самому К2 видеть мир ip route default 192.168.1.1 Bridge0 ip name-server 8.8.8.8 "" on Bridge0 ip name-server 8.8.4.4 "" on Bridge0.. м.б. что-то забыл, но вроде ничего из важного .. м.б. для пользования а-ля DynDNS на К2, возможно, придется на Bridge0 еще ip global повесить .. если с MAC-ами на EoIP все норм(?), то вроде как все гуд .. сохраняемся .. ребутаем при необходимости, для проверки чтобы заработало само собой.
.. предположим, это 2xG3 с AC1200 на GbE + беспровод вылизан и с учетом средней 65% MAC-эффективности 802.11 потенциально нагружает с обоих диапазонов на средние 780Mbps (1200*0.65) на каждом поинте + проводные (потенциально) saturate до полной картины -> вопрос: проц справится с программным EoIP или не выйдет упереться в проводное ограничение с учетом оверхеда? ppe поможет? или как лучше?
.. и мяч на стороне разработчиков, "воздух" выходит в штрафную и .. =)
-
Из теории:
1) Глава 11 + Приложение C
https://drive.google.com/open?id=0BwkqH1x6vsOFWW5lR3dyN04tWFU2) Немного тут
https://technet.microsoft.com/en-us/library/cc727740(v=ws.10).aspx3) Полезный дамп с примером вечных выборов
https://wiki.wireshark.org/SampleCaptures#Browser_Elections4) RFC 1001, 1002
https://tools.ietf.org/pdf/rfc1001.pdf
https://tools.ietf.org/pdf/rfc1002.pdf5) Крохи, не вижу оригинала:
https://www.wireshark.org/docs/dfref/b/browser.htmlВ общем, как я понял, основной посыл пользователя: включить, например, мелкомягкого клиента и увидеть почти сразу роутер с шарой в сетевом окружении или чтобы сетевой диск без проблем привязывался по NetBIOS-имени. Пожелание Master Browser из серии выделенного WINS (чтобы ни о чем не думать), что разумно для малых сетей, т.к. роутер всегда работает .. но если сложно, то тот же OPKG/Samba или ручками в реестре все роли и твики, имхо, лучше на FSR/FT/Radius бросить силы.
Т.е. есть нюанс с резолвингом, м.б. роутер не откликается на броадкаст-запрос NBNS - NetBIOS Name Query Request после инициализации того же мелкомягкого клиента из-за процесса выборов. М.б. желательно дополнительно сделать так, чтобы роутер откликался (если еще нет) в т.ч. по LLMNR для систем Linux(?) и выше Vista. Что еще тут можно придумать .. м.б. по DHCP дополнительно пытаться ставить (на всякий случай), например, 46-й опцией: b-node (вроде когда-то были репорты, что может глючить в зависимости от комбинаций). DNS без правки реестра вроде норм по резолвингу для выше W2000, но как быть с теми, кто указывает другие DNS на клиенте .. если только перехватом.
Какие еще мысли .. nbtstat -A по роутеру показывает:
Таблица NetBIOS-имен удаленных компьютеров Имя Тип Состояние ---------------------------------------------------- KEENETIC-GIGA <00> Уникальный Зарегистрирован WORKGROUP <00> Группа Зарегистрирован KEENETIC-GIGA <20> Уникальный Зарегистрирован Адрес платы (MAC) = 00-00-00-00-00-00Дамп по 138-му на Host Announcement KEENETIC-GIGA, Server, Print Queue Server, NT Server .. нет упоминаний по * Workstation не смотря на KEENETIC-GIGA <00>, т.е. роль в данном случае redirector формально не анонсируется, м.б. в этом тоже есть затык.
+ формально на клиенте-мастере:
WORKGROUP <1D> Уникальный
.. и это логично для мастера, но в его сторону все равно идет броадкаст и в других дампах тоже, так что непонятно что с RFC 1001 п.17.2 .. м.б. вообще попробовать в сторону Destination name '*' согласно тому же п.17.2 .. т.к. м.б. пока идут выборы и, возможно, нет:
WORKGROUP <1D> Уникальный
.. то анонс роутера м.б. никто не принимает и визуально этим вызывается задержка появления роутера (cifs) в сетевом окружении .. как бы один фиг де-факто броадкаст, попробовать бы другой Destination name.
В общем .. это гемор, учитывая что M$ сами признают, что NBT особо никто не занимается и м.б. даже поломан, то трушной схемы на том же W10 уже может не быть, поэтому предлагаю проверить тему с LLMNR, mDNS для яблочников, м.б. перехват DNS для имени роутера (но чтобы гибко можно было бы вкл/выкл .. м.б. на уровне компонентов .. и самбу для мастера заодно раз ovpn можно).
-
23 часа назад, ndm сказал:
Мы могли бы сделать что-то более примитивное, например, слушать Host Announcement-ы и добавлять их в DNS
чтобы была польза в проводнике - для DNS придется вроде реестр править на клиентах - EnableDns.
в принципе, понимаю почему не хочется делать Master Browser без готового кода .. я бы тоже не стал учитывая: это, это и это, а отправил бы делать мастеры и бэкапы на мелкомягких клиентах самостоятельно + м.б. уменьшил временной интервал при необходимости.
***
так-то по памяти вроде было неудобство, что роутер (cifs) мог в сетевом окружении появиться не сразу + вроде бы не с первого раза откликался по имени в проводнике .. второе "вылечилось" вроде бы закрепленным ярлыком по ip, в том плане, что имя сервера стало разрешаться уже без прямого ip (т.е. NB отработал и запись ушла в кэш nbtstat -c), т.е. после коннекта со стороны клиента .. и то, что появляется не сразу наводит на мысль, что nbdgm с Host Announcement рассылаемый роутером раз в 30 сек. (а точно не будет конфликта? - а то там речь про 1-12 мин. выше) - не воспринимается .. nbss вроде норм каждые 30 сек. между клиентом и сервером в части smb (p.s. прошивка старая) .. первое впечатление, что не слышат друг-друга в разных частях древней логики (и фз кто "сломался"), но если пнуть другим механизмом, то заводится.специально в болото не полезу, напишу если увижу неувязку с позиции протокола в ближайшее время.
-
-
16 минут назад, ndm сказал:
Помогите собрать инфу, в чем это выражается с точки зрения протокола
Подробно не разбирал проблему в целом с выборами Master Browser, но подозреваю, что как обычно все было в настройках а-ля:
preferred master = yes os level = 4
И, м.б., косяки с конфликтами от Winbind. В результате выборы, видимо, никогда не заканчивались. А так вот с примерами в т.ч. по выборам и разными моментами для проверки (как гайд для валидации выбора Master Browser на Linux).
Не так чтобы свет клином сошелся на NBNS/NBT-NS учитывая весь набор, косяки могут быть и в других составляющих при траблшутинге .. все же, имхо, чаще всего это кривые фаеры и их инициаторы.
-
7 минут назад, r13 сказал:
Тогда вопрос если отказываемся от небезопасного smb v1 то зачем нужен master browser?
Там мухи и котлеты в плане NetBIOS. Смотря как отключать. Если убирать фичу, то на некоторых системах заодно вырубается Browser как часть логики (крайний абзац):
Скрытый текст
Поэтому рекомендуется на клиентах через тот же:
To disable SMBv1 on the SMB client, run the following commands: sc.exe config lanmanworkstation depend= bowser/mrxsmb20/nsi sc.exe config mrxsmb10 start= disabled
.. тут все для массовки.
-
2
-
-
36 минут назад, BACbKA сказал:
будем размышлять
А чего тут размышлять. Стартап с оценкой в US $46 bln просто не может сделать нормальный wifi для людей.
Скрытый текст
-
4 часа назад, Le ecureuil сказал:
Как часто нужно будет пробивать в DNS IP-адреса?
Можно было бы, как и задумано, по TTL из ответов того же https://developers.google.com/speed/public-dns/docs/dns-over-https#dns_response_in_json
Но блочить по ip, имхо, плохо, "совсем дибилы" не вкусят цимеса. А матчить http.host или sni в tls хш и блочить aka - это вполне бы, уже привычно пользователю.
-
4 часа назад, BACbKA сказал:
Для полного просветления читать тут
как бы это 2SS на 20МГц и на другой AP все ок, поэтому не просветляет.
-
1
-
-
20 минут назад, vst сказал:
зачем?
Проблема с protocol-downgrade и mitm существует для пользователей, расшаривающих в сторону wan. По идее, нужна профилактическая работа для этой части "экосистемы" по объяснению обычным пользователям как отключить поддержку SMBv1 (как наиболее уязвимой составляющей) как на клиентской, так и на серверной части. Настройки по принудительности шифрования были бы тоже нелишними (да и всегда лучше, когда все гибко). Да и вроде медленная SMBv1. Я бы по-умолчанию вырубил как legacy.
Для сугубо домашнего применения, конечно, это излишне (и в этом всём основная часть фокус-группы), но простыню с рекомендациями для желающих выставить шару во внешку я бы давал, чтобы снизить потенциальный напряг на ТП по этим вопросам.
-
2
-
-
3 часа назад, Usatyj сказал:
cli можно не советовать - адреса серые и keendns не пускает telnet
если, вдруг, все же понадобится, то:
http://my.keenetic.net/#web.tc --> parse
адреса любые, главное, http(s)
-
1
-
-
5 часов назад, OverKot сказал:
Доступа нет. Действующая ранее форма входа(логи-пароль) - не принимается. Отмена парольного входа(что крайне не желательно),то же не срабатывает. Требования логина-пароля сохраняются. Ни одна связка логин-пароль не принимается,в том числе и админская.
а если в таком стиле:
net use x: \\192.168.1.1\obschaya_papka /user:localhost\Guest
(на мелкомягком клиенте) .. или, например, чтобы от имени userok с запросом пароля при предположении, что можно запросить пользователя с роутера:
net use x: \\192.168.1.1\obschaya_papka /user:KEENETIC-GIGA\userok *
**
А возможность принудительно вырубить поддержку SMBv1 появилась на стороне NQ CIFS Server? -
Формально нет NOTIFY, поэтому срабатывает логика:
Скрытый текстCACHE-CONTROL
REQUIRED. Field value MUST have the max-age directive (“max-age=”) followed by an integer that specifies the number of seconds the advertisement is valid. After this duration, control points SHOULD assume the device (or service) is no longer available; as long as a control point has received at least one advertisement that is still valid from a root device, any of its embedded devices or any of its services, then the control point can assume that all are available. The number of seconds SHOULD be greater than or equal to 1800 seconds (30 minutes), although exceptions are defined in the text above. Specified by UPnP vendor. Other directives MUST NOT be sent and MUST be ignored when received.При изменении параметра для "max-age", видимо, надежда только на первый ответ на M-SEARCH. Возможно, режутся NT, а ST проходят.
-
и немного букв, чтобы была возможность валидировать процесс:
http://upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.1.pdf -
еще, наверное, можно попробовать из серии:
interface Home ip alias 239.255.255.250/32
чтобы SSDP точно заходил на Home если TTL не подрезается
-
1
-
-
нам нужен более глубокий захват.
и то, вот легко такая сказка: если, предположительно, постоянно скачет GI с 800 на 400, м.б. страдать все уже начинает на уровне PLCP (и тогда фз, поможет ли более глубокий захват), тогда тема с HT-Mixed PPDU уже может нормально не восприниматься, все скатывается на Non-HT Legacy PPDU (как раз уровень 802.11g) и красивый линк с одной антенны в 135/150 Mbps на 40МГц сваливается (незаметно) под нагрузкой по скорости в ~+- 65 Mbps на 20МГц .. и скок там .. 65*0.65/8 ~ уже вот скорость потолка в ~ +- 5MBps на клиентах под нагрузкой в 40МГц на 802.11n вполне легко объяснима не только состоянием радиоэфира .. а если уже и Non-HT нормально не выходит, то добро пожаловать к более простым 802.11bg.
и тут бы почти в любой админке можно было бы сразу выставить принудительно любой из двух GI и проверить теорию выше, но мы нет .. а, это все бесполезно, wishlist по воздуху уже опухший месяцами, движения нет, немое кино.
-
1
-
-
В 15.06.2017 в 16:51, Dhampir113 сказал:
Ну не знаю что дальше делать, сегодня весь день все устройства были подключены к Huawei E5832S никаких перегрузок и разрывов не было, стоило только снова включить Keenetic 2
Надо на это делать упор - проблем с другими реализациями нет.
В 16.06.2017 в 17:00, vasek00 сказал:KII если в N стандарте и брать по отдельности устройства на какую ширину канала сажает каждое?
А какая разница? Есть, например, и такие, которые в 2.4ГГц посадят себя на 20МГц просто потому что решили за владельца (даже без юр.предписаний) чтить bss coexistence (даже если рядом никого), при том что в том же 5ГГц легко замутят 40МГц.
Тема постоянно бажная сколько я себя здесь помню. Либо мы ее сами крутим, проверяем и для нас, потребителей, ее пилят как нам надо, либо никто не заинтересован в том, чтобы нас все устраивало (чтобы постоянно баили и дебажили по кругу одну и ту же муть). Сказки нафиг.
-
12 часа назад, KorDen сказал:
Будет ли это вообще работать, или все будут сходить с ума при удалении от одного роутера и приближении к другому?
скорее всего, дела обстоят так:
управления роумингом для отстрела disassoc по rssi, чтобы клиент переподключался к bssid с лучшим сигналом при достижении определенного порога rssi на покидаемой bssid пусть в рамках essid - нет - если только на клиенте можно настроить, если нет, то линк будет сначала деградировать пока не отвалится и не переподключится к тому, чей маяк первым услышит.
чтобы было незаметно нужно в т.ч. снимать кадры с буфера покидаемой AP и перекидывать их в очередь AP куда клиент пришел по роумингу - это если не думать про небольшой перерыв при хэндшейке на роуминге .. или про возможно заметный перерыв если ключи на базе а-ля радиус.
чтобы совсем минимизировать время хэндшейка нужно, чтобы клиент заранее по-возможности получал уже готовые ключи от PMK по совпадению в своем кэше (чтобы сократить время согласования).
как бы настройки есть в т.ч.:
PreAuth PMKCachePeriod EAPifname PreAuthifname итп. для аутентификатора
осталось загадать базовую реализацию FSR и чтобы Band Steering потенциально не мешал (а лучше самим его тоже настраивать через настройки, которые для этого есть в т.ч. на уровне дров) .. и чтобы народ не зря голосовал за воздух =)
.. или чтобы юзер видел свой роутер на даче и его клиентов как если бы они были на основном роутере посредством того же IPsec NAT Traversal (вроде тоже несложно навесить в теории на автомате для пресета) .. и нет проблем .. если те же камеры только в локалке пашут.
Keenetic III, 2.10, баги
in 2.10
Posted
а всего их четверо .. Чума, Война, Голод и Смерть .. восхвалим же админов! .. да осветит их прошивка путь всем пользователям! .. amen.