sfstudio

Просьба всем обновиться на 4.6.14, кроме правки очень многих редко встречающихся багов в т.ч. с контрак был сильно переделан webui и закрыты застарелые косячки с работой nvram, так же добавлена базовая релизация cli (для вывода списка доступных на данный момент команд введите cli после входа по ssh, в будущем список сильно расшириться, так же можно опустить cli и вводить команды без префикса). Добавлен графический сканер эфира и многое другое. Избавился от необходимости ребутов в некоторых случаях и т.д. Задача потестить во всех позах. У меня все тесты проходят от и до, т.е. известных проблем в 4.6.14 на данный момент нет. Жду фидбэка. P.S. Настройки конечно лучше бы сбросить после обновления и настроить руками только то, что надо (т.к. менялись дефолты и мог что-то не учесть).

Справедливости ради BF о котором вы говорите это совсем не тот биамформинг что у рукуса. И железо с поддержкой биамформинг который о котором вы говорите есть давно и с Bfree и с iTxBF и т.д. Тот же RT3662/RT3883 (которые вышли где-то в 2010м году и ни о каком AC не слышали) его умеют. Были даже железки от дырлинк на этих чипах с антеннами с переключаемой поляризацией http://www.netcheif.com/Reviews/DIR-645/PIC/components.png (остальные виденные мной железки на этих чипах не калибровались для поддержки TX BF, однако все были обклеены лэйбами типа все из себя BF суппорт, см например asus n56u). Такой TX BF имеет ряд ограничений в т.ч. для полноценной работы требует что бы клиент умел "ответить" на некоторые вопросы AP касательно BF. У рукуса в том весь и кайф что пофигу что умеет клиент. Более того вендоры не паряться и даже если включают TX BF в дровах, то нет ни калибровок, да и на штырях... Это же не антенная решётка, а разные стримы, т.е. "диаграмма формируется" на каждом штыре, а не за счёт всех штырей... Так что там особо не разгуляешся. Опять таки AC даже Wave2 не делает TxBF обязательной своей частью для сертификации, а значит будет как обычно. Поналепят кучу красивых лэйбов на коробки, а по факту работать оно не будет. Но безусловно могут появиться мелкие вендоры которые смогут заюзать в своих продуктах все возможности чипа в т.ч. в части TxBF и реализовать все требования включая хитрые антенные массивы, главное что логика управления уже заложена чипмэйкерами и им не придётся проходить весь квест который прошёл рукус. Но всё это будет не скоро... P.S. Не думаю что брокады грохнут рукуса, даже более того есть инфа, что не грохнут ;) Так что не спешите их хоронить.

Починил, см гит. До кучи избавился там от необходимости ребута.

Ок. Провею, скорее всего да регрессия. Хотя там уже тоже можно обойтись без ребута. Ребут был нужен когда на goahead был завязан инит. Сейчас его самого будет достаточно перезапустить.

Вы его не туда задаёте, я вам сказал где живут разработчики клиентской части, вот задавайте вопросы им. Если я решу реализовать серверную часть, я воспользуюсь гуглом, почитаю доки в комплекте с сырцами, почитаю сырцы, если не пойму то напишу собсно разработчикам клиента (выше указывал куда) и т.д. и т.п. Сложно понять, что человек собирая автомобиль может понятия не иметь даже о протоколах взаимодействия внутри его бортового ПК. Это свободной стороннее приложение, одно из многих использованных при разработке дистрибутива Wive-NG. И детально раскуривать протоколы и даже понимать как работает его серверная часть (досконально) у меня задачи нет, ибо я не собираюсь реализовывать серверную часть. Инфы в инете на эту тему валом. Как и готовые реализации работают по всему миру. P.S. Вынесу в оффтоп этот флуд.

Я не силён в обёртках микротиковских нахлобученных поверх iptables/netfilter с целью вендорлока юзверя. В нормальном не обфусцированном linux используем расширения нетфильтра xt_limit/xt_connlimit/etc для ограничения чего-либо по неоходимости. Ваш микротик развернёт это всё до тех же линуксовых xt_*, но вот парсить этот бедлам что вы привели - эт увольте. Мне вывод iptables -L -v -n покажите, тады скажу оно нет. А как дополнительно защитить тот или иной сервис тут надо смотреть по месту. Иногда даже icmp echo может стать проблемой и его тоже желательно бы лимитировать эдак 10p/s. ssh и прочие желательно лимитировать как минимум по числу сессий с одного ip тем же connlimit, и т.д. и т.п. Всё индивидуально. Причём такая фильтрация в ядре будет заметно быстрее чем фильтрация на уровне приложения, т.к. будут исключены бесполезные переключения контекста kernel<=>userspace, но тоже не всегда. Основной посыл такой - на INPUT должно быть запрещено всё что явно не разрешено или не является ответом на наши же запросы (RELATED/ESTABLISHED), все остальные лимиты индивидуально.

Нет, это совсем на другом уровне ограничение, и при нахождании дыры в приложении слушающем порт в этой самой логике ограничения отымеют на раз-два. А защититься можно именно что используя DROP в фаерволе по умолчанию разрешая только то что нужно и вводя ограничения на уровне FW. Привет мир *nix (а именно linux) торчащий и в вашем микротике. Ну и плюс если ограничивать на уровне сервиса, то совершение (D)DOS атаки остаётся возможным (например устроить SYN FLOOD HTTP или даже SSTP серверу) т.к. данные долетят до сокета приложения этот сервис обслуживается не зависимо от введённых вами ограничений. В случае с правильно настроенным фаерволом (например в случае с syn flood нужен rate limit на SYN/RST) такая ситуация исключена ибо данные дропнуться ещё в ядре задолго до. А вот это уже надо смотреть как реализовано, запросто это и будет фильтр в нетфильтре. Но вы как бы об этом не знаете, ибо вас туда (к логике) не пущают. Выше пример почему запросто могут привести. Вот уж точно хорошее.=))) Аргумент так аргумент. Я бы это назвал вариант "для тупых". Но если для вас это признак "хорошести" - ок. Могу только порадоваться. Возможность настройки чего-либо некомпетентным человеком не является признаком "хорошести" или "плохости". Тут скорее вопрос к компетенции человека который лезет крутить, а не к инструменту. Я вот не могу нарисовать карандашом портрет, а художник может. Это разве делает карандаш плохим инструментом? Вот то то и оно. Потому настаиваю в очедной раз на аргументации с вашей стороны. Напомню, что предупреждение вы уже получили. Так что рекомендую придерживаться технического ключа и технической же терминологии. Ещё раз грю. На потери в icmp насрать - там полезных данных нет за редким исключением. Даже более того вредно скрывать дропы icmp, почему - догадайтесь сами. Всё остальное контроллиться по схемам выше, что на реальной сети, что внутри туннеля, и нет никакой нужды на уровне самого туннеля городить огород. Вот именно из-за поддержки всех современных алгоритмов шифрования с возможностью быстро прикрутить хоть чёрта лысого + возможность пролезть куда угодно (даже в спутниковый one way канал когда запрос через наземку,а ответ наоборот) без костылей его и юзают. Плюс там где нужна кросплатформенность. А чем лучше прекрасно расписано на их сайте и на тонне ресурсов. В т.ч. и чем хуже. А вот где sstp приюзано я ХЗ. Вот вообще ни разу не встречал его применения на практике. =))) Не надо мне приписывать то чего я не говорил. Навалом приложений которые работают по протоколам без поддержки какого-либо шифрования. Однако запросто могут использоваться для передачи конфиденциальной информации, и вот тут и нужен шифрованный транспорт. Опять таки это доп гарантия от ситуации когда протокол используемый приложением был скомпроментирован и найден косяк позволяющий декодировать трафик. Это касается тех сфер куда с микротиками не пускают, так что расслабьтесь, вам оно действительно в 99% случаев не надо.

Просто не надо мыть фрукты перед тем как тянуть в рот и никаких проблем с мокрыми руками? Ну т.е. больничка вас не смущает? =))) Опять хорошие шифрования и сильные антенны? В очередной раз призываю говоря "хорошее" аргументировать, чем же оно хорошо по каким параметрам и делать это абсолютно чётко на техническом языке со ссылками на техническую информацию. Ну либо можете переместиться на какой-нить не технический ресурс, где ваши "хороший", "слабый", "сильный" и прочие эпитеты будут уместны и без аргументации. TCP ходящий поверх туннеля сам гарантирует перезапрос в случае дропа. А доставку и перезапросы по UDP контроллируют end user apps. Контроль дотавки и перепосылка на уровне самого туннеля суть бесполезно по этим самым причинам. Единственная полуправда. Никто не мешает юзать нестандартные порты и для l2tp/pptp, не долго вытащить крутилку, главное делать это с обоих сторон. Но ессно винда отпадает, но на нормальных осях при желании делается в лёт. Хито устаревший? Вот OpenVPN вполне активно развивается. А вот архитектурное уродство заворачивания туннеля в tcp точно отмерло у нормальных людей. Ибо тонна лишней логики (udp проще в разы чем tcp и по сути достаточно простая надстройка над ip), причём на каждом хопе = доп точки отказа. Вот поэтому СПИД и прочая муть шагает по планете. Ибо обычно просто не предохраняются.

1) микротик это и есть самый что ни на есть кастрированный, обфусцированный linux на стероидах 2) проблема описанная выше встречается на каналах с потерями ,ассиметричных каналах и т.д. почти постоянно, для этого в ядре Linux целая стопка планировщиков TCP есть для разных случаев 3) никакие размеры буфера на это практически не повлияют, более того планировщики работают на каждом hop`е и где и как они настроены и какие одному богу известно (в udp контролем перегрузок и прочими сущностями занимаются, ну если вообще занимаюся, только конечные точки, вот тут важно что бы буферов по дороге хватило и не только). А если по пути у оператора или выше ещё и полисер работает... 4) tcp slow start after drop/idle и т.д. в общем случае проблемой не является, это нормальное поведение, но для туннелей это приговор на всяких мобильных сетях. Для решения этой проблемы (как правильно заметили) в l2tp заюзали транспорт по udp, в pptp заюзали транспорт по gre. OVPN так же умеет транспорт по UDP. А tcp там скорее ради пролазанья через всякие proxyфикаторы и иже с ними (было когда-то очень актуально).

Нормальный пример для тех кто понимает о чём речь и как это дело устроено. А как платить напрягает... Ужаасссс просто. Открытую сеть оставлять низя в любом случае. А будет login/passw или просто passw разницы ноль. Можно логин вообще игнорить. Это чисто вопросы настройки того же радиуса. Я то внимательный, но ИМХО строить сеть везде и прибивать гвоздями клиента к местоположению абсурд. Схема с 802.1x решает проблему и клиент сможет свободно мигрировать по AP. А все ограниченя на подключение/отключение доп и не доп устройсв будут жить на уровне биллинга, как у нормальных хоть проводных, хоть беспроводных операторов и сделано. Чукча тут только вы. То что аффтор на стене в 9м классе нацарапал вам интересно? Вроде давно сказано что открытая сеть: 1) не пролазиет по законодательству в РФ 2) кретину понятно что небезопасно. Т.е. давно озвучено, что в таком ключе нет смысла продолжать разговор. А идиоты с калолинукс одинаково небезопасны если они клиенты и уже имеют доступ. Однако это история из совсем другой области.

Да хоть 5ть логинов на клиента отдать. Хоть один логин на 5ть девасов с запоминанием маков. С запоминанием маков может выйти фэйл. У телефонов и планшетов на чипах от MTK со слетевшим "nvram" (что у них очень частое явление), каждое засыпание/просыпание/ребут мак будет новый. я так и представляю, заехала компания в номер и давай делиться логинами/паролями с соседями и разорили гостинницу. Тут скорее задача оперативно при вселении дать доступ, при выселении забрать + ограничить зону обслуживания (например слать REJECT на ASSOC REQ с клиентов с низкими уровнями) что бы зонировать и отбить желание халявщиков из жилых домов пытающихся юзать гостинничный wifi дома (как с кафешками часто бывает).

Чего? Причём тут L2TP ? Я о L2TP тут просто пример как авторизации через радиус. В wifi для авторизации централизованной есть 802.1x и AP прекрасно ходят до радиуса и авторизуют без всяких туннелей. Что мешает разрешить 2-5 коннектов на один логин пароль в радиус хоть с 802.1х на АП, хоть при использовании чилли? Нет, ну можно и гланды автогеном вырезать конечно... И что вы будете делать когда на эту кастрированную АП упадут соседи о смартами (из соседних номеров), а у поселенца в этом номере уже ничего работать не будет? Будете руками маки прописывать что бы внепланово его разрешть? =))) Вот и задавайте ограничение в биллинге в зависимости хоть звёзд на небе, можно сразу и канал под юзверя нарезать в зависимости от звёзд и прочего. Причём тут нешифрованная сеть? Вам именно что и предлагают WPA Enterprise с 802.1x MSCHAPv2 авторизацией (умеют все современные клиенты). А рулить микробиллингом каким-нить. Всё централизовано, сколько надо и какие надо лимиты из единой рожи биллинга.

В случае с радиус авторизацией через 802.1x просто тупо запрещается более одного соединения по паре логин/пароль. При этом клиент может прекрасно логиниться на любой AP в любом номере. Ровно та же система что у провайдеров PPTP/L2TP/PPPOE. Роуминг тоже пожалуйста. Не вижу проблем тут, ну кроме как развернуть какой-нить микробиллинг или нарисовать свой с тупой рожей для работников на ресепшн. Железо? Да хоть SNR-CPE-W4N revM если однобэнд или SNR-CPE-MD1 если хочется дуал и эфир загажен. Всё что нужно включая роуминг вполне себе умеет. Если впадлу заморачиваться с биллингом, отчётностью для органов и прочим - приюзываем один из сервисов авторизации (SNR-CPE поддерживает из коробки SAIWiFi/Wifisystem, ну или любой другой сервис использующий chillispot). Хочется продавать wifi (ну жлобство неискоренимо, а заморачиваться ой как не хочется) - есть сервис MyWiFi от webmoney (тоже есть профиль для работы с ним из коробки). Пошейпить (базово что бы решить проблему монопольного засёра канала одним из клиентов) можно на том же железе. Как и порезать по числу сессий что бы не влетать в лимит аплинка да и поумерить пыл торрентоводов.

Бросьте кости, они вам точно скажут хватит или нет. =)

Изучайте законодательство - узнаете много нового. Ну если о РФ речь идёт. А в чём проблема? Сервисов авторизации с отчётностью и СМС как гогна. Хоть тот же wifisystem.

Я ХЗ что вы взяли в руки. Наверное стоит после этого руки-то помыть. =)))

Хосподи. Ну обычный биллинг (хоть самоходно-наколенный) с радиусом и 802.1x на точке и клиенте (клиенты ныне штатно умеют это дело по радио). Тупо как пример http://forum.nag.ru/forum/index.php?showtopic=110269 P.S. Даааа... Админы уже не те... А ещё поди день сисадмина отмечают. =))) Чуть нет инбоксового и привет. Ок. Через пару недель будет. Не шучу. Рожу допишем и вперёд. =)

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

Constantin и прально делают. Только надо ещё рожу вкрутить что бы администратор включал WiFi только когда номер заселён ибо нефиг срать в эфир без дела. Ну и уровни придушить. А железо под такую задачу без роумингов и прочего можно чуть ли не любое юзать, лишь бы не дохло само по себе и не висло. Вот только на шлюзе надо бы всё это пошейпить равномерно что бы весь канал не выгребал какой-нить самый умный гость.

Книга называется радиофак в ближайшем институте.

Щито? Куда какие поляризации выведены? Spatial Stream никак с поляризацией не связаны, они могут быть как в одной поляризации (чаще всего на всех домашних роутерах анетнны в одной поляризации) так и в разных. Spatial Strean не равнозначны. К примеру все CONTROL MESSAGES бегают только в первом Spatial Stream (за исключением варианта с MU-MIMO там хитрее). Что касается работы >= 2TxR AP с xT1R клиентами разжовывал досконально недавно. Поиск по форуму по слову STBC. Абсолютно не верное мнение. Просто медленный клиент будет больше времени в эфире отъедать на приём/передачу того же объёма инфы что и быстрый на высоких модуляциях, а время у АП ограничего, и за раз оно только одного клиента обслужить может, т.е. пока обслуживает одного - остальные курят, и чем медленнее этот самый тормоз - тем дольше курят пока его обслуживают (для решения этой проблемы придумали Airtime Fairness, тоже разжовывал). Железки которые дропают PHY MODE и TX RATE до самого тормозного из клиентов вымерли в далёком 2000м году. У меня вот сейчас прямо на AP висят несколько легаси клиентов only G и несколько N клиентов. Так же ничто не мешает на втором радиомодуле сосуществовать A/AN/AC клиентам одновременно, и для каждого используется своя модуляция. Впрочем как и Rate для каждого выбран индивидуально. Будет в схеме STBC (если клиент умеет). MIMO это стек плюшек, часть из которых работает и в такой конфигурации. Опять же поиск рулит. Ему грят AP 3T3R, клиент 1T1R. Где тут 2T2R (MIMO 2x2) я в упор не вижу. Если клиент умеет STBC (а его сейчас умеют почти все) то AP будет использовать все 3 стрима в STBC режиме повышая тем самым надёжность передачи. Скорость всё равно будет ограничена тем что клиент умеет только 1 Spatial Stream на RX. И ограничена будет только на этом клиенте. А чего не 6ть? =) 6T6R железки вполне есть. =) P.S. dronis3 ну хоть чуток матчасть подтяните. Как бы стыдно в 2016г подобную ахинею писать даже для старшеклассника который пару роутеров домашних настроил.

Для PPPOE на Ethernet сетях MTU по хорошему должен быть 1492 (8 байт занимает инкапсуляция, а масимальный размер для Ethernet 1500). Если стоит авто то логика такая. PPPOE сервер в LCP посылает (в момент соединения) нужное значение MTU, клиент проверяет что бы оно было не больше WAN MTU - 8 (в случае с PPPOE) и выставляет у себя. Если сервер оператора ничего не присылает то используется по дефолту 1492. Уменьшение размера MTU косвенно влияет на вероятность порчи данных по пути от вас до сервера PPPOE и наоборот. Чем меньше размер - тем меньше вероятность что пакет побьётся, но это же приводит к увеличению накладных расходов на инкапсуляцию. В данном случае влияет ещё и на то как быстро свитч ласты склеивает. Я бы вообще бы вам советовал избегать провайдеров которые в 2016г используют на доступе ppp based туннели, любые. Хоть PPPOE (меньшее из зол), хоть L2TP/PPTP. Я к тому что помогло бы и то и то. Т.к. похоже "полное обесточивание" порта домового свитча приводит к его временному очухиванию. А сделть это можно либо выдрав кабель из WAN либо отключив питание роутера. Софт ребут совсем полностью не отрубает порт только временно снимается питание с ресивера/трансмиттера во встроенном свитче. Так же я бы проверил бы кабель от вас до свитча. Если кабель дерьмо или черезчур длинный то на говносвитчах запросто может быть ситуация когда линк поднимается и всё вроде бы работает, но прут ошибки включая порчу данных. При этом подключение напрямую к ПК зачастую решает проблему, в силу просто более дубовых ресиверов/трансмиттеров в сетевых картах. Тут надо разбираться индивидуально. То что уменьшение MTU приводит к положительным результатам + в логе маты на битое поле protocol с мусором в нём чётко грит, что проблема где-то по пути и именно не отвал, а порча данных. Полудохлые свитчи и/или дерьмовый кабель + дерьмовый свитч к примеру. Могут быть и другие чудеса. Но они не на вашей стороне.

И да. Зачем врубили шейпер? Оно к проблеме конечно отношения не имеет. Но нафиг оно вам дома надо я не в курсе, а учитывая что при включении шейпера сразу теряем NAT offload в любом его виде и сотку дуплекса при наличии VPN особенно по WiFi оно уже не прожуёт. Дома больше чем Codel нафиг не надо.

Да не за что. Причём у вас в логе чётко видно что железка "перезванивает". Но видимо временами данные выше вообще перестают ходить. А раз говорите физическое отключение кабеля помогает, то могу предположить что проблема на домовом свитче.

Судя по Protocol-Reject for unsupported protocol и тому что код протокола либо 0xffff либо просто от балды проблема в том что по пути между вами и PPPOE сервером оператора портятся пакеты. Это может быть кривой свитч к примеру. Выдержка из официального фака на эту тему: https://ppp.samba.org/FAQ.html Единственное что со своей стороне вы можете сделать это попробовать уменьшть MTU в настройках VPN. Но это не решение проблемы. Оператор должен разобраться где происходит порча данных на его сети. Запросто это может быть проблема домового свитча (например поджаренный грозой свитч запросто может себя так вести).