edo Опубликовано 20 июня, 2017 · Жалоба Пока нет. Собирайте их на уровне "шлюза" бриджом и ноу проблем. на уровне шлюза - вне роутера? да, можно, но как-то нелогично ;) Тем более если будете крутить роуминг который доступен только для ROOT AP и для нормальной миграции с использованием 802.11K/R оно всё должно быть в одной L2 сети без всяких вланов с точки зрения AP 1. root ap - это "основные" ssid? то есть роуминг может быть только на одном ssid? (на двух для двухдиапазонных роутеров)2. не очень понял насчёт l2 сети. у меня сейчас wlan завёрнут в vlan (на всех точках в один, разумеется), при этом будут проблемы с 802.11k/r? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sfstudio Опубликовано 20 июня, 2017 · Жалоба на уровне шлюза - вне роутера? да, можно, но как-то нелогично ;) Какраз логично. Во первых вы будете видеть сегменты/диапазоны отдельно. Во вторых ресурсов на шлюзе гораздо больше. На АП я им аппаратно натянул тэг. А если я всё это буду делать программно, а если ещё и для провода. Ну и не забывайте. Диапазоны это вообще по сути отдельные АП. Просто в одном корпусе и на один 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 то в обдщем-то пофигу. Можно как угодно разруливать. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
edo Опубликовано 20 июня, 2017 · Жалоба на АП я им аппаратно натянул тэг. А если я всё это буду делать программно, а если ещё и для провода. может я что не так понимаю, или вы меня не поняли речь вот про что: [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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sfstudio Опубликовано 20 июня, 2017 · Жалоба Да я понял. Просто рассказываю о крайних случаях. У вас всё Ок. Ну и грю если вы перетащите в один влан оба ифэса радио то аппаратно тэги натягиваться уже не будут (не смотря на логику, т.е. возрастёт нагрузка на cpu). 7621 уже не имеет таких ограничений там скорее всего и сделаю сразу возможность засунуть всё в один влан. А руками можете делать как вам удобно. Для того оно и сделано, а не закрыто как у 90% вендоров. Но я не могу ориентироваться на все возможные комбинации (и не только). И уж тем более тянуть их в морду. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sfstudio Опубликовано 20 июня, 2017 · Жалоба Короче не парьтесь, просто загляните в 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 подходивших на КРОС. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
edo Опубликовано 20 июня, 2017 · Жалоба Ну и грю если вы перетащите в один влан оба ифэса радио то аппаратно тэги натягиваться уже не будут (не смотря на логику, т.е. возрастёт нагрузка на cpu) теперь стало понятно. не думаю, что загрузка процессора изменится критично, но подумаю над тем, чтобы объединить vlan уже вне роутера. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sfstudio Опубликовано 20 июня, 2017 · Жалоба Нет конечно, там копейки, но когда и так навешивают. =) Ну и не забываем что если загрузить по полной оба радио интерфейчас CPU и так будет почти в полке. А в случае бриджа PPE никак не спасёт. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
edo Опубликовано 21 июня, 2017 · Жалоба в случае бриджа PPE никак не спасёт. а нужен ли ppe, если nat нет, pptp нет, и т.п.? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sfstudio Опубликовано 21 июня, 2017 · Жалоба Ну я и грю что PPE никак не спасёт в случае бриджа ибо не умеет такие операции ускорять. Если бы умел было бы заметно легче cpu т.к. софт бридж тоже не очень быстрая штука. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
edo Опубликовано 2 августа, 2017 · Жалоба после выключения света роутер предсказуемо забыл настроенное через 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sfstudio Опубликовано 25 ноября, 2017 · Жалоба Блин совсем забыл. Я ж сделал обработку такой ситуации. Например конфиг вида: 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 ветки уже будет из коробки доступно. Соррь... Чёт с этими завалами вылетело всё из головы. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sfstudio Опубликовано 29 ноября, 2017 · Жалоба Добавлено в рожу с 6.7.16, просьба проверить. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...