modnyman

Во первых думаю не по этой причине данные протоколы до сих пор отсутствуют в ros. Во вторых уязвимости закрывают ведь со временем... Но вряд-ли это побудит добавить в прошивку поддержку данных протоколов. Так что не смотря на неудачный момент для пожелания, актуальность вопроса не снизится со временем. Разве не так?

Ещё пожелания принимаются? Что насчёт всяких 802.11r и 802.11k для полноценного роуминга?

Предложения и пожелания? Передайте пусть с тикетом 2017102922000739 разберутся. Пол года переписывались, когда дело дошло до "зайти на мою железку и посмотреть точно по моей инструкции" как воспроизвести проблему - они включили игнор мод.

Смогли. Все и так на радиусе и работает норм. Но! Монтажникам ведь надо иногда зайти на антенну у которой например пропала связь с бс, дабы продиагностировать... Я описал ситуацию в случае когда скомпрометирован данный пароль, или пароль для юзера локального с правами полиси.   В ссш сессии можно генерировать ответ и наблюдать его визуально. Всё-таки не ежедневная процедура. За несколько лет мне пришлось прибегнуть к ней 1 раз, при увольнении сотрудника... А по поводу учёта вообще - можно добавить строку кода и писать в файл результат. Я больше данную фичу использую для апдейта прошивок массового или для обновления конфига.

Долбится по адресам соответствующим критерию [/ip neighbor find]. Естественно можете более конкретизировать. Про ключи - ну, это вам немного теории лучше покурить. Там все не хитро, обычные rsa или dsa ключи. Позволяют авторизоваться без ввода пароля. Сгенерировать дело не хитрое, например в путти ген.

Как тогда выявлять перегрузку интерфейса? И не только перегрузку, а степень плачевности ситуации? "а вот на прием таким образом регулировать скорость не выйдет" ну, на этот случай fixed downlink теперь есть

"очень и очень большим" - можно в более конкретных значениях для pcq? И всётаки, какой в этом смысл если есть буфер драйвера? Да и какбы не имеет смысла накапливать пакеты в том числе слабых клиентов, так как весь их шедуленный трафик сожрет кучу эфирного времени и усугубит перегрузку, тогда как дроп - заставит поумерить аппетиты. И кстати всегда мучал вопрос - каков размер буфера драйвера? Не могу инфу нигде найти внятную. Да и кстати, суммарный то размер очереди не такой уж малый, 250 килобайт. А потоки в свою очередь не накапливают много пакетов.

@Timax Дело не хитрое Так как трафик везде у меня выходит даже с wlan c тегами, маркирую юникаст трафик вот так: /interface bridge filter add action=mark-packet chain=forward mac-protocol=vlan new-packet-mark=unicast out-interface=wlan1 packet-type=other-host vlan-encap=ip ВАЖНО: метод маркировки может отличаться, если точка является ещё и маршрутизатором - лучше брать трафик уже меченый под шейпер, если не шейпится тут - просто маркируйте в манглах весь айпи трафик. Дальше делаю дерево с родителем wlan интерфейсом: /queue tree add name=wlan1-tree parent=wlan1 /queue type add kind=pcq name=wireless-downlink pcq-classifier=dst-address pcq-dst-address6-mask=64 pcq-limit=10KiB pcq-src-address6-mask=64 pcq-total-limit=250KiB add kind=pfifo name=pfifo-downlink pfifo-limit=10 /queue tree add name=unicast packet-mark=unicast parent=wlan1-tree queue=wireless-downlink add name=non-unicast packet-mark=no-mark parent=wlan1-tree queue=pfifo-downlink Весь не маркированный трафик - не юникаст. Арпы там всякие, мультикасты... Нече ему делать в очереди с писикью классификатором. К вопросу почему такая короткая очередь: Хотелось бы узнать вообще мнение людей знакомых с теорией очередей, или просто знающих... Какую лучше длину очереди делать? Я брал общий размер из расчета на примерно 10 милисекунд при полной канальной утилизации, потом немного снизил и округлил. Длина на один поток взята минимальной, так как вообще не вижу смысла в этом месте шедулить трафик. Ведь за этой очередью следует очередь драйвера из которой осуществляется доступ к среде, агрегация кадров, смена порядка пакетов по 802.1p... Соответственно всё что задержалось в моем дереве - это перегрузка интерфейса, причем уже случившаяся. И тут возникает ещё аргумент не городить длинную очередь. Пакеты пойманные в дроп мы сможем отмониторить, и явно понять уровень перегрузки и построить график. Ну а дальше дело мониторинга. Всё что нам нужно есть в мибах кроме процента отброшенных пакетов. Но у нас есть oid-ы для общего числа пакетов и для числа дропов. По снятым значениям в заббиксе создаем ещё одно вычисляемое, где второе делим на первое и умножаем на 100. Ну и рисуем графики: Левый, левая шкала, зеленый график - дельта нагрузки в мегабитах. Левый, правая шкала, красный график - кол-во абонентов онлайн. Правый, левай шкала, желты график - дельта нагрузки в пакетах. Правый, плавая шкала, красный график - процент дропов - что есть в любом случае перегрузка. На слабо нагруженных базах дропов к слову нет вообще. Если увеличить длину очереди - не сказал бы что это особо увеличит скорость (хотя отчасти увеличит). Но пропадет информативность и время для "маневра", чтоб отреагировать на данную проблему. Да и вообще, я к этому решению довольно долго приходил, но пришлось прийти. Потому что бесит в микротике что невозможно понять когда иссякает емкость, не понять есть ли запас. Не понять когда абонент жалуется на скорость - не на базовой станции ли это? Срань полнейшая, почему из коробки это нельзя было сделать? Очень жажду любой критики и советов.

А можно всётаки выдержку из документации с внятным описанием различий?

@x-rayd в чем различие между ап энд клиент и просто клиент?

@x-rayd Разъясните мне значения обоих параметров данной опции, возможно я изменю на ваш вариант)

Омнитик, 30 радиоклиентов. Прошивка обновлена 24 числа. Видно что процент дропов на интерфейсе упал. Более детально воскресенье: раньше на такой нагрузке было до 2 процентов дропов. /interface wireless set [ find default-name=wlan1 ] adaptive-noise-immunity=client-mode ampdu-priorities=0,1,2,3,6,7 area=******** band=5ghz-a/n \ channel-width=20/40mhz-Ce default-authentication=no default-forwarding=no disabled=no frequency=5680 frequency-mode=superchannel \ guard-interval=long hw-retries=3 keepalive-frames=disabled mode=ap-bridge multicast-helper=full nv2-cell-radius=10 nv2-preshared-key=******** \ nv2-qos=frame-priority nv2-queue-count=8 nv2-security=enabled radio-name=******** scan-list=5100-5850 ssid=******** tdma-period-size=auto \ wireless-protocol=nv2

Во первых как она передавать то будет, когда эфир занят? Это уже в любом случае коллизия, даже если они не рядом. Но!... Вы видимо не внимательны. Вопрос именно про nv2 и при подключении к одной AP. Я как бы почти уверен, что мешать не будут. Но хотелось бы мнение со стороны услышать.

Прошел месяц - следов их присутствия на оборудовании вообще нет. Кстати, подскажите кто-нибудь, если 2 антенны подключенные к одной базовой станции работающей в nv2 расположить на одной мачте - будут ли у них возникать проблемы с качеством приема и передачи сигнала? Если да, то по каким причинам?

на базе по парочке или одному, чисто по этому получилось четко выявить как это проявялется база как правило sa5 nv2 то есть даже AC не используется. работает в n. если сигнал лучше примерно -55, то проблем то и нету. при сигналах ниже, во время работы "живой" сети и предположительно на перегрузках возникают "фризы" периодом скачет ласт эктив до одной секунды и проваливается в минимум модуляция от базы к клиенту. проверено в разных локациях (регионах). списать на шум не получится. меняется антенна на обычный лайт - проблемы нет. причем коли это N режим - проблема либо хардварная (что мало вероятно) либо в драйвере чипа микротиковском. много где видел на форумах в том числе микротиковском, что жалуются на ацшки, но нигде не видел никакой конкретики. Что-то плохо, а что конкретно? Здесь тоже не ответили когда писал примерно той зимой. Вообще не нашел информации о наблюдениях проблем в виде показателей сигнала модуляций или перегрузок интерфейсов. Пришлось отрисовать заббиксом всё что рисовалось, вплоть временного графика процента дропов на очереди на интерфейсе. Картина стала совсем очевидной. Ну и началась долгая переписка, мол вот смотрите сюда и сюда, вот проблема, вот так проявляется.