[edo]

Пока нет. Собирайте их на уровне "шлюза" бриджом и ноу проблем.

на уровне шлюза - вне роутера? да, можно, но как-то нелогично ;)

 

Тем более если будете крутить роуминг который доступен только для ROOT AP и для нормальной миграции с использованием 802.11K/R оно всё должно быть в одной L2 сети без всяких вланов с точки зрения AP

1. root ap - это "основные" ssid? то есть роуминг может быть только на одном ssid? (на двух для двухдиапазонных роутеров)

2. не очень понял насчёт l2 сети.

у меня сейчас wlan завёрнут в vlan (на всех точках в один, разумеется), при этом будут проблемы с 802.11k/r?

[sfstudio]

на уровне шлюза - вне роутера? да, можно, но как-то нелогично ;)

 

Какраз логично. Во первых вы будете видеть сегменты/диапазоны отдельно. Во вторых ресурсов на шлюзе гораздо больше. На АП я им аппаратно натянул тэг. А если я всё это буду делать программно, а если ещё и для провода. Ну и не забывайте. Диапазоны это вообще по сути отдельные АП. Просто в одном корпусе и на один host cpu навешаны.

 

1. root ap - это "основные" ssid? то есть роуминг может быть только на одном ssid? (на двух для двухдиапазонных роутеров)

2. не очень понял насчёт l2 сети.

у меня сейчас wlan завёрнут в vlan (на всех точках в один, разумеется), при этом будут проблемы с 802.11k/r?

 

1. Именно так, поддержка K/R только для первого SSID

2. Да, если over air не отработает будут обязательно, основное требование связность bcast/mcast для br0 (куда обязательно засунут проводный ифэйс) на L2. Если просто трафик с SSID завёрнут проблем нет. А вот если всё раскрасить включая LAN. Но это ИМХО уже клиника. Короче на br0 должны быть IP из одной подсети, и между ними должен без проблем ходить mcast/bcast. Это нужно для работы iappd. Во вланах он ходить не умеет. Т.е. не сможет синкать ключики и всегда будет полная процедура аутентификации вмето простого reassoc.

 

Ради интереса можете сделать nvram_set IAPPDebug 4 && reboot и посмотреть в логах происходит ли общение между AP на тему секьюрити репортов при move notify и прочего.

 

Если клиенты не умеют FT то в обдщем-то пофигу. Можно как угодно разруливать.

[edo]

на АП я им аппаратно натянул тэг. А если я всё это буду делать программно, а если ещё и для провода.

может я что не так понимаю, или вы меня не поняли

 

речь вот про что:

[iT@/]# brctl show
bridge name     bridge id               STP enabled     interfaces
br0             8000.f8f082e2687d       no              eth2
                                                       ra0
brvl1007wl0             8000.f8f082e2687d       no              eth2.1007
                                                       rai0
[iT@/]# brctl delif br0 ra0
[iT@/]# brctl addif brvl1007wl0 ra0
[iT@/]# brctl show
bridge name     bridge id               STP enabled     interfaces
br0             8000.f8f082e2687d       no              eth2
brvl1007wl0             8000.f8f0828e2ac4       no              eth2.1007
                                                       rai0
                                                       ra0

[sfstudio]

Да я понял. Просто рассказываю о крайних случаях. У вас всё Ок.

 

Ну и грю если вы перетащите в один влан оба ифэса радио то аппаратно тэги натягиваться уже не будут (не смотря на логику, т.е. возрастёт нагрузка на cpu). 7621 уже не имеет таких ограничений там скорее всего и сделаю сразу возможность засунуть всё в один влан.

 

А руками можете делать как вам удобно. Для того оно и сделано, а не закрыто как у 90% вендоров. Но я не могу ориентироваться на все возможные комбинации (и не только). И уж тем более тянуть их в морду.

[sfstudio]

Короче не парьтесь, просто загляните в README

#############################################################################################################
CURRENT HOOKS FOR ADVANCED USER LOGIC:

1) /etc/udhcp.d - scripts start after udcpc renew lease
2) /etc/vlan.d - scripts start after vlans configure
3) /etc/ip(6)tables.d - scripts start after netfilter configure
4) /etc/ppp-l2tpsrv/ip-up(down).d - scripts start after client connect(disconnect) to VPN server
5) /etc/ppp/ip-up(down).d - scripts start after router connetc(disconnect) to external VPN server
6) /etc/scripts/wan_up.sh - this script start after WAN up and full services reinit

 

Хук vlan.d по вашу душу и не надо править штатный инит. Скрипты в /etc/vlan.d будут выполнены после конфигурации вланов. Там просто перенесите нужный нтерфейс в нужный VLBR и всё.

 

Специально делал что бы пакеты rwfs юзверей можно было отвязать от моих правок логики, и что бы не ждали пока я каждый подвыверт вытащу в морду, которая и без того перегружена с токи зрения большинства ISP подходивших на КРОС.

[edo]

Ну и грю если вы перетащите в один влан оба ифэса радио то аппаратно тэги натягиваться уже не будут (не смотря на логику, т.е. возрастёт нагрузка на cpu)

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

[sfstudio]

Нет конечно, там копейки, но когда и так навешивают. =) Ну и не забываем что если загрузить по полной оба радио интерфейчас CPU и так будет почти в полке. А в случае бриджа PPE никак не спасёт.

[edo]

в случае бриджа PPE никак не спасёт.

а нужен ли ppe, если nat нет, pptp нет, и т.п.?

[sfstudio]

Ну я и грю что PPE никак не спасёт в случае бриджа ибо не умеет такие операции ускорять. Если бы умел было бы заметно легче cpu т.к. софт бридж тоже не очень быстрая штука.

[edo]

после выключения света роутер предсказуемо забыл настроенное через brctl, нарисовал вот такого уродца чтобы ra0 был в одном в vlan с rai0:

#! /bin/sh

. /etc/scripts/global.sh

VlanWifiLanINIC=`nvram_get 2860 VlanWifiLanINIC`
if [ "$VlanWifiLanINIC" != "" ] && [ "$VlanWifiLanINIC" != "0" ] && [ "$lan_if" = "br0" ]; then
       brctl delif ${lan_if} ${first_wlan_root_if}
       brctl addif brvl${VlanWifiLanINIC}wl0 ${first_wlan_root_if}
fi

[sfstudio]

Блин совсем забыл. Я ж сделал обработку такой ситуации.

 

Например конфиг вида:

VlanWifiLan=100
VlanWifiLanINIC=100
VlanWifiWan=0 100
VlanWifiWanINIC=0 100

 

Приведёт к вот такому результату:

~ # brctl show
bridge name     bridge id               STP enabled     interfaces
br0             8000.f8f082e5d375       no              eth2.1
brvl100wl0              8000.f8f08259408e       no              eth2.1.100
                                                        ra0
                                                        rai0
brvl100wl1              8000.f8f082e03789       no              eth2.2.100
                                                        ra1
                                                        rai1

 

Щас веберу опишу правки по роже что бы можно было из UI такие конфиги наруливать и в финальном релизе 6.7 ветки уже будет из коробки доступно. Соррь... Чёт с этими завалами вылетело всё из головы.

 

[sfstudio]

Добавлено в рожу с 6.7.16, просьба проверить.