Мастерим подобие WDS на проводе и без на базе EoIP

[IgaX]

Подумал на тему - как бы я это сделал.

Цель: обеспечить прозрачное бриджевание, чтобы в т.ч. на соответствующий прозрачный бридж можно было повесть всякие вкусности по настройке дров радио в части 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 поможет? или как лучше?  

.. и мяч на стороне разработчиков, "воздух" выходит в штрафную и .. =)

Изменено 5 июля, 2017 пользователем IgaX
и без провода тоже :)

[Le ecureuil]

Не забудьте про eoip_allow_fragment, иначе может быть "бо-бо".

[IgaX]

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-трафика.

[IgaX]

1 час назад, IgaX сказал:

.. или вместо этого, если железо свитча роутера поддерживает Jumbo(?), то м.б. на меж-линке поднимем IP MTU до 1542:

- на К1 и К2

interface 1 ip mtu 1542

и/или заодно/вместо(?):

interface GigabitEthernet0/Vlan101 ip mtu 1542

 

[Le ecureuil]

Свитч на гигабитных (между портами) поддерживает Jumbo, больше же нигде Jumbo кроме baby-jumbo (pppoe + vlan) не поддерживаются.

[IgaX]

10 минут назад, Le ecureuil сказал:

Свитч на гигабитных (между портами) поддерживает Jumbo, больше же нигде Jumbo кроме baby-jumbo (pppoe + vlan) не поддерживаются.

ок, раз принципиальных возражений по гибкости и потенциально оптимальному перформансу схемы в целом у начальника транспортного цеха нет, то мне осталось только понудеть по настройкам, в которых я мог бы все сделать дальше .. даже майки позволяют пусть и через реестр часто, но главное, что педали есть, а мы что, хуже? =)

Скрытый текст

 

[r13]

@IgaX а Eoip в данной схеме зачем? Что не прозрачного в схеме соединения 2х точек по лан?

[IgaX]

1 минуту назад, r13 сказал:

@IgaX а Eoip в данной схеме зачем? Что не прозрачного в схеме соединения 2х точек по лан?

я ждал, спасибо 

смысл в том, что если просто бриджевать, то при выборе wifistation вроде как все равно за-mat-ит и здравствуй proxy-arp .. а так предложение в стиле универсальной схемы: нужно просто придумать L3-линк, что м.б. будет проще для пользователя .. м.б. потом сделать одним из видов "режимов" для широкого применения .. типа купите два Кинетика и WDS/Mesh в два клика .. в любом месте .. с Enterprise-grade EAP .. секурно как в банке  .. или чтобы юзер видел свой роутер на даче и его клиентов как если бы они были на основном роутере посредством того же IPsec NAT Traversal (вроде тоже несложно навесить в теории на автомате для пресета) .. и нет проблем .. если те же камеры только в локалке пашут.

"бью в бубен, раскрываю потенциал".

[Le ecureuil]

12 часа назад, IgaX сказал:

ок, раз принципиальных возражений по гибкости и потенциально оптимальному перформансу схемы в целом у начальника транспортного цеха нет, то мне осталось только понудеть по настройкам, в которых я мог бы все сделать дальше .. даже майки позволяют пусть и через реестр часто, но главное, что педали есть, а мы что, хуже? =)

  Показать содержимое

 

Тут к сожалению аппаратное ограничение - PDMA (а именно самая ключевая часть сетевой карты роутера) не поддерживает jumbo-фреймы, потому мы ничего не можем сделать на текущих чипах.

[IgaX]

1 час назад, Le ecureuil сказал:

Тут к сожалению аппаратное ограничение - PDMA (а именно самая ключевая часть сетевой карты роутера) не поддерживает jumbo-фреймы, потому мы ничего не можем сделать на текущих чипах.

Ок, пусть без Jumbo, но Experimental Ethernet ведь можно? Включаем на порту и на интерфейсе или где это возможно ip mtu уже задан максимальный?

Цитата

interface 1 ip mtu 1536
interface GigabitEthernet0/Vlan101 ip mtu 1536

 

[Le ecureuil]

42 минуты назад, IgaX сказал:

Ок, пусть без Jumbo, но Experimental Ethernet ведь можно? Включаем на порту и на интерфейсе или где это возможно ip mtu уже задан максимальный?

 

Уже задан, MTU на интерфейсах без IP везде и так максимален. 

[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.

[Le ecureuil]

4 часа назад, IgaX сказал:

Спс. Я просто к тому, что на 802.11 max MSDU до шифрования (в которую можно запихнуть IP datagram) - 2304 (!) .. так что если перебирать бриджи в плане клиентов, то тут тоже есть потенциал для улучшения с учетом, конечно, вопроса IP-фрагментации.

Я к чему .. конечно не Jumbo .. но если брать 802.11 в качестве DS линка, то eoip_allow_fragment может быть лишним.

И заодно такой вопрос: как я понимаю, на уровне бриджа все кошки серые .. поэтому можно ли включить EoIP в состав непосредственно беспроводного интерфейса, чтобы получить трушный прозрачный 802.11 на который можно повесить все плюшки? С учетом, например, этих особенностей:

  Показать содержимое

.. по идее, в такой конструкции беспроводная механика могла бы полностью раскрыться, т.к. на другой стороне туннеля был бы сразу тот же родной 802.11.

Сами же можете глянуть код драйверов WiFi, там прекрасно видно, что в систему из него все прилетает уже преобразованное в 802.3, и в него улетает только таким же.

[IgaX]

5 минут назад, Le ecureuil сказал:

Сами же можете глянуть код драйверов WiFi, там прекрасно видно, что в систему из него все прилетает уже преобразованное в 802.3, и в него улетает только таким же.

я так глубоко не копал, только глянул какие рецепты идут в поставке .. подумал, мало ли EoIP еще до границы трансформации заворачивает.

как бы там ни было, в настройках беспроводных дров есть привязки соответствующих интерфейсов и .. вот прямо вижу еще четыре интерфейса wdsN и все остальные настройки .. нет, не вижу, приглючило =)

[IgaX]

19 минут назад, IgaX сказал:

вижу еще четыре

на каждое радио 

[Le ecureuil]

Мне на тему радио писать абсолютно бесполезно, я им не занимаюсь  Сразу @Padavan упоминайте

[IgaX]

1 час назад, Le ecureuil сказал:

Мне на тему радио писать абсолютно бесполезно, я им не занимаюсь  Сразу @Padavan упоминайте

Вот по словам вижу, что тоже хочется выпустить этого джина из бутылки .. просто хэппи-энд затянулся =)

[IgaX]

.. в ожидании @Padavan ..

Или вот, например, есть два устройства с 802.11ac на 5ГГц между которыми с учетом всех path-моментов линк 802.11ac шустр и весел. Располовиним его для WDS (чтобы максимально все наполнить, если "пир" - младшее устройство со 100 Mbps на проводе), а с учетом расстояний надо будет не забыть настроить 2.4ГГц на непересекающихся как мин.

Вместо проводного линка, правим:

- на К1

Цитата

interface WifiMaster1/AccessPoint2
    rename WDSAP1
    description "WDS AP"
    mac access-list type permit                               ! если надо (иначе не указывать),
    mac access-list address aa:bb:cc:dd:ee:ff        ! то mac WifiStation (!) с другой стороны - см. show interface
    security-level public                                           ! поставим public, чтобы не думать + сетку на 2 хоста ptp
    encryption enable
    encryption wpa2
    ip address 172.16.0.1/30
    ssid wdslink1
    hide-ssid
    wmm
    up
!

# Если не хотим выше auth переводить в ns3 прямо в конфиг, то просто командой cli укажем PSK

interface WDSAP1 authentication wpa-psk mYWdSAP1LinkPAsSWoRd

# Если, вдруг, нет маршрута для 172.16.0.0/30, то для поинта

ip route 172.16.0.2 WDSAP1

- на К2

Цитата

interface WifiMaster1/WifiStation0
    rename WDSStation1
    description "WDS Station"
    security-level public
    encryption enable
    encryption wpa2
    ip address 172.16.0.2/30
    ssid wdslink1
    up
!

# Если не хотим выше auth переводить в ns3 прямо в конфиг, то просто командой cli укажем PSK

interface WDSStation1 authentication wpa-psk mYWdSAP1LinkPAsSWoRd

# Если, вдруг, нет маршрута для 172.16.0.0/30, то для поинта

ip route 172.16.0.1 WDSStation1

.. и нет нюансов режима "Повторитель" в плане прозрачного моста.

Если брать не 5ГГц, а 2.4ГГц для линка, то все так же ток: WifiMaster1 -> WifiMaster0

М.б. кому-нибудь поможет в желании настроить. Ток проверяем mtu (мало ли) -> show interface WDSAP1 и show interface WDSStation1

Как бы так тоже можно жить без wdsN, но оверхед и проц в отличие от просто addr4 в mac 802.11 =)

Изменено 5 июля, 2017 пользователем IgaX

[IgaX]

(на всякий) потому что TA поглощает SA в двух случаях из четырех (и в крайнем как раз собака) .. и вот в т.ч. поэтому клиенты сидят под одним чужим маком в arp-кэше если приходят от пира с apcliN:

Скрытый текст

 

[IgaX]

Ну и до кучи в рамках канвы педаль к MACRepeaterEN, чтобы гибридный мак транслировался для требований аккаунтинга в случае стандартного беспроводного бриджевания через и со стороны apcliN .. хотя судя по манускрипту проц импакт и оверкилл, да и вообще только max 16 записей и даже без wpa2-enterprise и плюх роуминга .. но пусть будет, будем знать с чем сравнивать.

**
бьем в бубен

Изменено 5 июля, 2017 пользователем IgaX

[IgaX]

@ndm хороший ведь план, нам не хватает педалек

[IgaX]

И еще, безусловно, есть плюс реализации EoIP в том, что всего на радио в данной версии драйвера - макс 64 подключения вроде и в случае чистой реализации wdsN возможно с этим будут проблемы на mac 802.11, а с EoIP каждая BSS сохранит свою емкость, что очень хорошо в плане числа потенциальных беспроводных клиентов .. тех же вероятных футбольных soho-баров =)

[IgaX]

Срочный комплект для малого бизнеса: "Армия из двух Кинетиков обслужит больше сотни футбольных фанатов!" .. будоражим, будоражим умы, эх, маркетосы =)

**
IntelliQoS фанатам в помощь, если отдельный пресет не сделает навес от 53-го, 80-го и 443-го и про изоляцию помним и так и быть еще 5060, 5061 и 23399 если бармена напрягать будут.

2 часа назад, IgaX сказал:

в данной версии драйвера - макс 64 подключения вроде и в случае чистой реализации wdsN возможно с этим будут проблемы на mac 802.11

хотя, скорее всего, все норм будет и на 802.11 за минусом линков wds (всего 4), там же активные или все же по ключам .. забыл .. если по ключам, то preauth может сыграть дурную шутку и емкость не поднять .. а для фанатского профиля м.б. и норм .. они ведь чаще неподвижны особо, поэтому легкий нюанс с роумингом будет редок, а легкий затык на приложениях не будет массовым, но для VoWLAN конечно нужен preauth aka fsr aka ft aka 802.11r.

p.s. еще 802.11w здесь будет в тему (поддержка вроде уже реализована ток список устройств не до конца понятен).

Изменено 5 июля, 2017 пользователем IgaX

[IgaX]

Небольшие поправки по ветру:

1) манускрипт намекает на макс. 32 подключенные станции на каждое радио(?) .. или все же BSS .. тогда макс. 4*32 клиента с каждого диапазона;
2) и таблица безопасности из 64-х ключей (видимо, PMKSA) на MAC (BSS или радио в целом?) .. хотя ACL вроде на 64 mac на каждый BSS .. ф.з., маневры покажут.

В принципе, если не замыкаться на OKC, то армия 2хК обслужит более полусотни точно (а то и больше) фанатов в каждом диапазоне, а т.к. ячейки будут пересекаться (в т.ч. с учетом CCI + вылизанного до блеска "воздуха" в т.ч. в плане airtime utilization), то когда заполнится одна BSS - она, по идее, просто перестанет отвечать на тот же probe request итп. и клиент подцепится к соседней емкости с тем же SSID.

Будем надеяться, что (на всякий случай) аутентификатор 802.1X/EAP, например, rt2860apd из комплекта поставки дров есть и как-то запускается.

PreAuth=1;1;0;0			# Включаем, видимо, pre-authentication IEEE 802.11i/RSN/WPA2 на, например, ra0 и ra1
PMKCachePeriod=10		# TTL записи кэша в минутах (скорее всего, PMKSA caching)

Далее, по идее, все из 802.11i просто включилось на автомате для основной и, например, гостевой AP - распространение preauth - заполняя таблицы с PMKSA на raN с другой стороны via EoIP aka DS и т.к. масштабируем через прозрачный мост с включением в него потенциально сколько угодно EoIP (а не 4-х wdsN), то проще, чтобы для всех:

PreAuthifname=br0;br1		# только надо проверить нотацию

Формально как бы все, счастье уже должно быть если без Radius. PMK (они же в данном случае PSK) на базе SSID и пасса, уходят в прозрачные мосты и слушаются raN с другой стороны, поэтому как бы механизм должен работать но ф.з. наполняются ли PMKSA в реальности без аутентификатора 802.1X/EAP. Вроде все же без EAP не заведется. Формально FSR - уже есть, ура! .. или .. мм .. это похоже на 802.11r-2007.

Вот х.з. на счет необходимости 802.1X/EAP в этом драфте 802.11r .. и вроде 802.11r-2007 не очень сильно поддерживают клиенты, так что идем ниже.

Ограничения таблицы кэшей PMKSA привели к 802.11r-2008 .. ключи разделили и все это стали называть FT и FT-PSK. Да и WPA2-Enterprise надо по-человечески прикрутить.

Похоже без EAP и Radius/Hostapd уже никак. Вызовы к AS идут хитро со стороны выбранной клиентом для будущего роуминга AP в качестве authenticator, к которым мы, видимо, проталкиваем от клиентов через PreAuthifname соответствующий preauth-трафик в котором в т.ч. есть EAP-хэндшейки .. и все нужные части ключей кэшируются в нужных местах.

Видимо, указываем интерфейс, на котором будет EAPOL и, наверное, Radius/Hostapd (роль контроллера) .. м.б. из OPKG:

EAPifname=br0

Чтобы заработала иерархия ключей FT, наверное, указываем где висит наш "Радиус":

RADIUS_Server=192.168.1.1
RADIUS_Port=1812
RADIUS_Key=myradiuskey1

И в зависимости от поинта (свой ип):

own_ip_addr=192.168.1.1

# или:

own_ip_addr=192.168.1.2

# или м.б. универсально как-нибудь:

own_ip_addr=127.0.0.1

Т.е. все пакуем, отправляем и слушаем. Скорее всего, в этом рецепте будет работать и WPA2PSK(!) и WPA2-Enterprise (WPA2-EAP) .. просто определит появление MSK на "контроллере" от которого дальше разойдутся общие части ключей по разным уровням. 802.11r-2008 в теории готов, дальше если только AS шаманить.

У этой темы много "привкусов", поэтому мог накосячить где-то в анализе и с ходу не выйдет.

Вроде как не смотря на то, что здесь можно настроить как угодно на стороне контроллера:

wpa_key_mgmt=WPA-EAP FT-EAP

# или только:

wpa_key_mgmt=FT-PSK

.. Cisco все же рекомендует выделять отдельные емкости для клиентов, которые не поддерживают 802.11r/FT/FT-PSK ввиду определенных несовместимостей (вроде есть такие репорты).

.. в общем, после первоначальных тестов надо бы подумать, как лучше собрать этот конструктор для универсальной схемы "армии двух".

.. так-то вроде настройки ставятся одной левой, нюансы в целом ясны, неизвестно только что выйдет: 2007-й с 802.11i/RSN/WPA2, который, скорее всего, будет работать норм все же ток с WPA2-EAP/802.1X .. или 802.11r-2008 с красивым FT в т.ч. для WPA2PSK независимо по воздуху или DS (хотя скорее Over-the-DS, что гуд, а меж-воздух прикроем EoIP).

.. и если возможностей rt2860apd не хватит в качестве authenticator, то хотелось бы использовать в этой роли в т.ч. Hostapd, т.к. у него в этом плане широкие возможности .. м.б. будет критично для WPA2PSK в FT-PSK (а м.б. и нет) в части генерации R1 из MSK и других опций из серии:

psk_generate_local=1
pmk_r1_push=1

.. хотя м.б. rt2860apd со всем этим справится нормально.

@ndm @Le ecureuil @Padavan Очень, очень ждем настроек, чтобы потестировать сию вандер-фичу во всех кинотеатрах страны (это ведь даже не напряжно со стороны разрабов как бы и вроде и вообще) =)

P.S. На ассист по роумингу голосов много, про эволюцию в рамках WDS, видимо, не раскурили, но это сторона одной медали, спрос есть =)

[arbayten]

@IgaX
похоже, нас не слышат/не понимают/специально издеваются/бажат шоб не отфаерили/сверху спускают вечный баж/анкомпетент, предлагаю забор анлим с рекомендацией обходить стороной как и завещала моргана

[IgaX]

2 минуты назад, arbayten сказал:

с рекомендацией обходить стороной как и завещала моргана

мы хотя бы попытались