[EugeneTV]

А вы не пробовали отключить пару точек вообще? Оставить "радиомост" с йоты на AP на втором этаже на 5ггц, и раздавать инет с нее? Вполне может быть, что мощности HAP-ac на 2.4 достаточно, чтобы закрыть большую часть дома. Тогда весь этот огород с wds, mesh окажется не нужен. В свое время пытался организовать mesh на стройплощадке при помощи трех Омнитиков, ничем хорошим это не кончилось, сеть регулярно ложилась. Что уж там было, я не разбирался, на первый взгляд какой-то бардак с mac-адресами и бриджами, они там то появлялись, то пропадали сами собой. Разбираться не стал, просто переделал схему и все.

 

[Saab95]

6 часов назад, EugeneTV сказал:

А вы не пробовали отключить пару точек вообще? Оставить "радиомост" с йоты на AP на втором этаже на 5ггц, и раздавать инет с нее? Вполне может быть, что мощности HAP-ac на 2.4 достаточно, чтобы закрыть большую часть дома. Тогда весь этот огород с wds, mesh окажется не нужен. В свое время пытался организовать mesh на стройплощадке при помощи трех Омнитиков, ничем хорошим это не кончилось, сеть регулярно ложилась. Что уж там было, я не разбирался, на первый взгляд какой-то бардак с mac-адресами и бриджами, они там то появлялись, то пропадали сами собой. Разбираться не стал, просто переделал схему и все.

 

Правильно. Только у вас схема была не верная. Достаточно было сделать один омнитик главным и настроить его как БС, а остальные как клиенты, например если они перемещались постоянно. Поверх радио прогнать через L3 трафик клиентов в EoIP туннеле, изолировав все друг от друга - проблем бы не знали. Основное же тут это экономия. Хотят обойтись минимальным количеством устройств, вместо сборки полноценных ретрансляторов и т.п. Делали схемы где и по 10 пролетов было до самых дальних раздающих точек, естественно на чистом L2 это не работало - были постоянные отвалы и скорость работы низкая, а вот при работе на L3, где каждый ретранслятор был маршрутизатором, скорость практически не падала при нарастании количества пролетов.

[LostSoul]

16 часов назад, Saab95 сказал:

На малых расстояниях нормально работает Nstreme. При этом не надо задирать мощность сверх меры - получаете переотражения, которые и топят двунаправленный тест. Именно по этой причине нужно использовать узконаправленные антенны типа QRT5 и минимальную мощность. Так же не надо лезть в AC, в режиме N вполне достаточно скоростей для работы.

Я, конечно проверю ваш рецепт при следующем этапе работ у клиента, но для себя уверен что если сравнивать 802.11 40мггц и 802.11ac - 80мггц результат второго будет лучше.

Вот если  можно было открыть на 802.11n ширину хотя 60мгц , тогда возможно да.

Использовать направленные антенны невозможно. Меня и  HAP-ы заставили прятать от жены, с всей возможной смекалкой.

 

 

15 часов назад, NewUse сказал:

раз клиента всё устраивает -- ТС оказался прав

Клиента все устраивало, даже на обычных репиторах TP-Link  в розетку 220. 

Не устраивала только стабильность, и прожив там сутки я понял почему - свет в доме моргает 5-6 раз в сутки. ( с отключением )

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

( ну кроме как если на микроволновке часы сбросились).  А вот дешевые мыльницы подвисали.

 

 

15 часов назад, EugeneTV сказал:

Тогда весь этот огород с wds

У меня нигде нету WDS.  У меня есть AP и station bridge на 5ггц  ( wds везде отключен )

Точку с второго этажа из подвала ловит слишком хреново.

С первого этажа из подвала - более-менее нормально.

 

 

8 часов назад, Saab95 сказал:

L3 трафик клиентов в EoIP т

Хоспаде, любезный Саб!

Скажите, ну чем по вашему прохождение L2 и L3 по радиотрактам может отличатся?

Ведь то что  вы пишите это рецепт из разряда "по колесу стучал? А капот открывал?"

 

 

8 часов назад, Saab95 сказал:

естественно на чистом L2 это не работало

Это говорит только об ошибке в настройке L2.  Подумайте сами.  Какая пакету летящему в эфире разница какие там цифры в поле DST-MAC

 

[LostSoul]

И ещё тут был замес в соседней теме про бесшовное переключение.

Так вот отчитываюсь про HAP AC .

Разница между вариантами CAPs Manager и просто 2 штуки HAP AC с одинаковыми настройками WiFi  - ЕСТЬ.

( dhcp общий и единый, но разные AP в одном L2-vlan , соединены кабелем )
Мой телефон LG Nexus 5 в случае двух точек доступа с идентичными настройками между ними НЕ ПЕРЕКЛЮЧАЕТСЯ. 

В случае CAPs переключается как только условия слышимости второй точки становятся лучше.

 

Но так же правда и в том, что клиента который переключатся не желает сам микротик не скидывает.

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

То есть не отличает тупой клиент отказы авторизации от отказа по низкому уровню сигнала.

 

[NewUse]

это всё уже обсуждали в теме snr,  и там разработчик на этот случай костылей понавешал...

[sfstudio]

Цитата

В случае CAPs переключается как только условия слышимости второй точки становятся лучше.

Опять 25. Ну расписывал же уже и про фоновые сканирования и по критерии (дельта и min rssi и т.д.)... LG Nexus 5 начинает пытаться мигрировать если дельта уровней между АП 15Дб при -80 RSSI. Приберите уровни на своих АП что бы в зоне перехода обеспечить RSSI с точки зрения клиента в ~-80, при наличии рядом АП c RSSI > -65 и он радостно начнёт у вас пытаться переключиться при условии одинаковых SSID (а некоторым клиентам надо ещё что бы и канал совпадал, иначе только пинок, потому всегда рекомендую если нужно выше ёмкость то строятся дублирующие 20МГц сети с непрерывным покрытием, если речь о 2.4). Да и ещё клиент не должен спать, т.е. абы какой трафик должен бежать. Либо придётся все PSM на AP отключить (кстати как там при ваших CAP с PSM, не тут ли ваше заблуждение зарыто). Многие клиенты во сне будут висеть до последнего на той АП на которой зацеплен. Благо при правильно реализованном планировщике в дровах и работе с PSM они и не мешают, можно их не трогать или килять с ооооочень большой задержкой или с оооочень низким уровнем надеясь что они к тому времени сами проснуться и переключатся.

 

Для квалкомовских дров могу подсказать что и где покрутить что бы даже говнотелефоны с их радио (если вендор не залез руками в build конфиги дров) начал мигрировать даже при очень плотном размещении АП независимо от вендора или того, что на них наконфигурено. =))) Только рут нужен. Всё руки не дойдут расписать, может на днях сделаю (ждите в спец разделе =))).

[NewUse]

3 минуты назад, sfstudio сказал:

Для квалкомовских дров могу подсказать что и где покрутить что бы даже говнотелефоны с их радио (если вендор не залез руками в build конфиги дров) начал мигрировать даже при очень плотном размещении АП независимо от вендора или того, что на них наконфигурено. =))) Всё руки не дойдут расписать, может на днях сделаю (ждите в спец разделе =))).

Было бы круто, а ещё если без рута (ну можно же мне помечтать) :)

 

[sfstudio]

Без рута никак. Нужно править конфиг драйвера. У квалкома в дровах с 2014г везде реализован относительно вменяемый хэндовер (жаль только band preffered нет). Однако дефолты для него такие зачастую стоят что крайне редко можно видеть нормальную миграцию на них дажев 5ГГц, а в 2.4 так и подавно.

 

Там вся логика SME/MLME и т.д. и т.п. живёт как и у нас прямо в драйвере. И миграция осуществляется драйвером. При этом в старших версиях есть поддержка RRM и FT (правда без правок суппликанта FT тоже работать не будет, но эт не суть важно). Суппликант только уже по факту ставят в известность что терь живём на другой АП. Т.е. никаких LinkBeat не будет при перемещении внутри одного SSID. Главное мигрировать раньше чем по голове дадут (именно с этим у них проблемы), и переключиться на новую АП быстрее чем оборвуться соединения приложений по таймауту.

 

В старших версиях наличие MDIE (при включенном 802.11R) со стороны АП дополнительно говорит драйверу, что надо мигрировать только внутри сеть ап с одинаковым MBSSID+MDIE при этом не говорить системе, что линк рвался даже если время перемещения было зело не маленьким (без него надо таки успевать "перепрыгнуть"). Вот и вся мегапрозрачность. =))

 

Просто попали мне тут в руки аккуратные срезы android wireless sdk  от аферос/квалком начиная с 2011г и по конец 2016г. Сижу изучаю потихоньку время от времени.

 

P.S. Не ленилились бы вендоры это дело в уй выносить и вообще бы, как минимум с квалкомами, на тему миграции проблем бы особых бы и не было. А по хорошему гугл должен бы добавить всё это дело в уй, и озадачить остальных, что теперь реализация этого дела обязательна для всех. Но это фантастика. Ну и band preffered нужно нормальную реализацию так, с парой крутилок. И корпорасты были бы счастливы.

[NewUse]

Ну в гугл можно постучаться, они достаточно лояльные, но ждать имплементации придётся х.з. сколько....

 

 

[sfstudio]

В гугл на эти темы стучат уже скоро как 5ть лет. =)) Воз и ныне там. См их списки рассылки. Иначе не пришлось бы чипмэйкерам на уровне дров всем этим заниматься. Всё можно было бы реализовать на уровне суппликанта и их connection/wifi manager`а (или как оно теперь там называется)... Но увы.

[LostSoul]

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

он радостно начнёт у вас пытаться переключиться при условии одинаковых SSID

При абсолютно одинаковых уровнях и расположении точек НЕ ПЕРЕКЛЮЧАЛСЯ с одним SSID.

-79 было по моему от соседнего этажа, но продолжал висеть на нем.

Спящего режима не было так как смотрел обновляющуюся вебморду основного микротика.

Включил через CAPS - запрыгало.

 

[sfstudio]

Ещё раз. Если капс ваш сбивает нафиг клиента пинком по тому же tx error или ещё по какому критерию тут заслуги нет от слова совсем. Разговор идёт о нормальной миграции без подбитых глаз. Вот что бы её обеспечить нужно соблюсти несколько условий дабы клиент решил мигрировать и сделал это без проблем.

 

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

 

P.S. Я посмотрел что такое ваш capsman v2. И что такое это CAP. Внутри по сути туннели от wireless интерфейсов до "центра", где они завязаны в бридж + управлялка. На кой чёрт туннелировать это дело в плоской L2 сети где не нужно даже изоляции (да и вланы никто не отменял) я ХЗ. Но видимо у микротиков есть какие-то проблемы с этим делом. А может просто от нефиг делать. Никакого экспорта интерфейсов и логики MLME на сторону центра там и не пахнет. Так что не интересно. =)

 

 

PP.SS. А вот реальная выборка по поведению клиентов (абсолютно разношёрстных) в офисе тыц. Логи могу предоставить, правда лень блин маки выкусывать. Хотя не принципиально. Под честное слово. =) Специально (ну если интересно) лог, за завтрашний день могу прислать куда скажете. Проанализируете сами, если сможете.
 

 

[andryas]

11 минут назад, sfstudio сказал:

На кой чёрт туннелировать это дело в плоской L2 сети где не нужно даже изоляции (да и вланы никто не отменял) я ХЗ.

 

Сеть может быть не плоской.

[sfstudio]

Да правда чтоль? Я мужики-то и не знают.  Но вопрос задан был именно как "на кой чёрт туннелировать всё в даже в плоской сети". Другого вариванта в обсуждаемом случае не предложено.

[LostSoul]

33 минуты назад, sfstudio сказал:

Проанализируете сами, если сможете.

Благодарю, но мне даж свое анализировать некогда.

Я просто "веду наблюдение" по ходу работы.

Как я уже сказал, CAPs ничего не сбивает.

Но сам нексус не мигрирует.  Уж не знаю чего ему там не доложили.

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

Делать livecd с линуксом лень.

 

 

[andryas]

34 минуты назад, sfstudio сказал:

Да правда чтоль? Я мужики-то и не знают.  Но вопрос задан был именно как "на кой чёрт туннелировать всё в даже в плоской сети"

 

Видимо, для унификации.

[sfstudio]

Ну прально чё. Ресурсы проца же лишние. Давайте будем унифицировать. А для унификации этих туннелей поверх ещё какой-нить туннель натянем и т.д. Фтопку.

 

Как и обещал начал писать на тему как приручить миграцию в квалкоме, первый параметр описал, щас поедем дальше. ТЫЦ

 

[sfstudio]

В общих чертах готово. Владельцы квалкомов могут начинать развлекаться. =)

[Saab95]

22 часа назад, sfstudio сказал:

Да правда чтоль? Я мужики-то и не знают.  Но вопрос задан был именно как "на кой чёрт туннелировать всё в даже в плоской сети". Другого вариванта в обсуждаемом случае не предложено.

Представьте у вас 10 точек, на каждой 10 клиентов, суммарно 100 абонентов.

 

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

 

В 14.11.2017 в 01:12, LostSoul сказал:

Я, конечно проверю ваш рецепт при следующем этапе работ у клиента, но для себя уверен что если сравнивать 802.11 40мггц и 802.11ac - 80мггц результат второго будет лучше.

Вот если  можно было открыть на 802.11n ширину хотя 60мгц , тогда возможно да.

Микротик умеет управлять канальными скоростями N, а вот скоростями AC пока никак не научится. Именно по этой причине на мосту можно зажать канальные скорости на том уровне, где нормально работает. А низкие отключить. В режиме AC можно только сверху подрезать. А в условиях полосы 80мгц, внутренних переотражений - работает плохо. Проверялось и не раз.

 

60мгц можно на микротике но на внешних радиокартах.

[sfstudio]

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

 

То что мокротик не умеет по сей день просто не анонсить B в IECAP эт гораздо большая проблема чем посчитать маску рэйтов для анонсов AC.

 

Перед тем как писать, нужно хоть слегка быть в теме.

[LostSoul]

56 минут назад, Saab95 сказал:

60мгц можно на микротике но на внешних радиокартах.

ну и как назвать продукцию которая при наличии 80мггц радиоинтерфейса не может его в N использовать?

 

[sfstudio]

А кто может 80МГц в N? 80МГц bonding это AC. Откуда взялись 60МГц для меня вообще загадка. В N/AN макс это 40МГц. Просто этот первооткрываетель, как обычно не въезжает в то, что пишет. Ибо как это работает не представляет.

 

Может товарищ курнул не того и путает с 60ГГц этих самых 802.11ad ? =) Но тут загадка. Мокротиководы всегда меня поражали фантазиями.

[LostSoul]

Как 2x40 нельзя как-то активировать?

ну вдруг

работают же как-то "репиторы в розетку".

и у них прием и передача вроде на разных каналах

 

[sfstudio]

Чего куда активировать? 802.11N имеет wide channel = 40MHz (причём это уже "bonding"). ТЧК. Репитеры работают крайне тупо. Это AP+Client (у нас оно честно зовётся ApCLI). Часть времени принимаем и буферизируем, часть передаём. Если радиомодуль один - то привет использование одного канала и двойная утилизация эфира - падение скорости вдвое на каждом хопе (в лучшем случае). Что вас смущает-то?

 

И что значит разные каналы когда 2.4ГГц в 40МГц нет ниодного канала не пересекающегося по факту по спектру (ищите, приводил спектрограмму). Из 5Ггц в 2.4ГГц - ок. Внутри 1-2 поддиапазонов 5ГГц (при наличии 2х модулей) ок. В 2.4ГГц лучший вариант откуда взяли - туда и насрали (слово выбрано верно, ибо утилизация эфира значительно растёт из-за дублей разнесённых во времени).

 

И с всякими мешами (включая бэтмена) будет та же жопа.

 

Ещё раз рекомендую, ну хоть базово осиливать принципы работы того, с чем сталкиваетесь... Ну гугл же есть блин...

[LostSoul]

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

Ещё раз рекомендую, ну хоть базово осиливать принципы работы того, с чем сталкиваетесь... Ну гугл же есть блин...

Боюсь коллега, что это ваш кругозор существенно ограничен тем что вы ковыряете.

Если бы вы с всяким gnu radio работали более плотно, то не удивлялись бы вопросам про возможность запустить 2 виртуальных канала по 40 на одном передатчике.

 

А у меня однако не только базовые принципы но и 20-летний опыт развертывания и использования. И понимания ( в общих существенных моментах ) как оно работает.

То что не ковырял мелочи реализации, не значит что есть какое-то непонимание базы.

 

Да, чипмейеры что-то иногда делают не наиболее предсказуемым и логичным образом, а через гланды.

Тогда мои предположения о конкретной реализации определенной фишки могут оказаться ошибочны.

Но не более того.