Перейти к содержимому
Калькуляторы

sfstudio

VIP
 Просмотреть профиль  Активность

  • Публикации

    5319

  • Зарегистрирован

  • Посещение

 Тип публикации 

Сообщения, опубликованные пользователем sfstudio

  1. Опубликовано · Жалоба на ответ

    В 23.05.2020 в 13:04, mar7 сказал:

    и надо ли для создания роуминга для 3-х устройств включать на них wds?

    Нет. Соединяете АП между собой проводом (организуете DS) и вперёд.

     

    DS (опорная сеть) может быть организована как проводом, так и радиокостылями типа WDS и APCLI. Провод предпочтительней. 

     

    Как именно будет организована DS для роуминга пофигу по большому счёту. Разве что не забываем, что опорка по радио это лишние задержки, потери, подземные стуки и возможность положить всю вашу сеть на лопатки любому пионеру с "шумелкой" из-за угла.

     

  2. Опубликовано · Жалоба на ответ

    Спец... Уже пол инета ржот. Аж мне линканули в чатике. =)))

    MAT работает только между клиентским интерфейсом и bridge куда собраны клиентский интерфейс + любой другой. Т.е. работает только в режиме ApCLi. Нет APCLI и клиентского интерфейса - нет и MAT (NAT2.5).

     

    Но что бы не нести ахинею надо понимать зачем он этот самый MAT вообще нужен. =))

     

    WDS с MAT и его отсутствием и наличием никак не связан. Как и нет никакого MAT и в случае с DS по проводу.

     

    Читайте вопрос alibek внимательно. И учите матчасть...

     

    P.S. В общем всё что нужно знать о спецах NAG... Профнепригодность во весь рост.

     

    В 27.05.2020 в 11:54, alibek сказал:

    То есть без включенного WDS точка доступа будет подменять MAC клиента на свой?

    Нет и ещё раз нет. Подмена будет только в случае если одна из железок работает в режиме клиент + мост в LAN + AP. Т.е. apcli (репиттером оный называют не редко). Для чего нужен думаю сами догадаетесь. У вас подготовка по выше будет.

  3. Опубликовано · Жалоба на ответ

    Отвечаю. Людям свойственно читать по диагонали и понимать перпендикулярно.

    FT от частоты вообще не зависит.
    RRM призван как раз решить проблему когда железки на разных частотах отдавая список соседей клиенту по запросу и исключая полное сканирование. которое в 5ГГц может и 7 секунд длиться.

    Тут мухи с котлетами у человека попутались.

    Если клиенты не умеют RRM (что частое явление) то при АП на разных каналах запросто можно поиметь переключение по вплоть до 7 сек. Если умеют то скан не нужен вовсе т.к. список соседей и каналов на которых они работают будет получен по RRM от текущей АП, останется по ним быстренько пробежаться пробами даже не отключаясь полностью от текущей и вауля.

    Т.е. тут выбор в зависимости от задачи. Или надо обеспечить максимально бесшовную миграцию для большинства клиентов или обеспечить выше ёмкость. Отсюда и пляшем.

    Нормальные клиенты особенно умеющие RRM не будут болеть головой ни в том ни в том кейзе. Разница будет как раз на ненорамльных.

    Какую схему применять (можно и обе сразу грамотно спланировав сеть) решаем исходя из задачи.

     

    SSID общие на 2.4/5 лучше не юзать, ибо либо все свалимся в 2.4 (большинство мобильников о band preffered и MBO слыхом не слыхивали) либо придётся юзать BandSteering что на части клиентов приведёт к проблемам с миграцией. Полезно уронить дурь в 2.4ГГц в пол дабы склонить к выбору клиентом 5ГГц без членовредительства типа стирингов. Но  и тут ессно есть побочка,  т.к. упадёт SNR на клиентах.

     

    Зонирование и т.д. это отдельная огромная тема. Может будет времени побольше распишу на пальцах в статье. Пока у нас завал т.к. старт серии сразу 6ти железяк от нескольких поставщиков. В т.ч. хитого FE дуала (см ФБ). 

    P.S. Все вопросы можно  задать у нас на ресурсе https://wi-cat.ru тут бываю только когда кто-то напишет мне на мыло. Даже уведомлений отсюда не вижу ;) Анонсы по новом нашему железу будут вот вот там же, частично тема раскрыта в моём уютном ФБбложике https://www.facebook.com/WirelessCatLLC Так что если кто-то хочет задать вопрос, поспорить или просто зайти в гости - welcome по адресам выше.

    PP.S. Простой пример. Очень часто великой ёмкости не требуется, ибо работает 10ток клиентов на площади аля спортзал. =) А вот рвущийся голос на говнотрубах аля сяоми народ бесит. Т.к. сяоми нихрена не умеет (ни FT ни RRM) единственным выходом что бы помочь ему абы как мигрировать это запихать всё на один канал и грамотно разместить АП дабы переключение (триггер у них падение уровня до -75 на стороне клиента) происходило там где надо и гарантированно.

    PP.SS. Достаточно много клиентов нынче умеют BTM (часть WNM). Все новые гигабитные устройства под управлением Wive-NG-HQ от Wi-Cat и партнёров умеют управляемый BTM. По сути BTM позволяет форсировать процедуру выбора кандидатов для миграции и саму миграцию, т.е. служит вместо триггера в виде падения RSSI. АП буквально может мягко попросить клиента мигрировать нафиг с нё, а не давать по голове через KickOut или не ждать пока сам клиент отвалиться. Около 70% даже какашечных клиентских устройств, последних оет выпуска, BTM умеет из коробки. Мы продолжаем совершенствование механизмов миграции в той части что зависит от АП в нашем ПО и железках... К SNR это отношения не имеет. Они сами с усами нонче. =) Так что welcome на https://wi-cat.ru

     

    PPP.SSS. =) Записаться в очередь для получения в тест сэмплов можно написав на info@wi-cat.ru Ессно представившись, описав какую компанию представляете т.к. ЧЛ в тест не дадут (как минимум пока). Ну и сделать это стоит уже сейчас. Правда потолочные АП будут чуть позже, но если нужны то стоит это указать отдельно в письме, возможно это сместит приоритеты по запуску новых продуктов.

  4. Опубликовано · Жалоба на ответ

    Значит спроектированы они макаками вот и всё. И дохли они скорее всего далеко не по озвученной выше причине. Как усилки пыхают при возбуде при кривой схемотехнике или даже кривой разводке pcb при банальном откручивании антенн я видел неоднократно. На спектрике в этот момент всплеск на несколько секунд и всё неси на помойку.

     

    Но ведь не повод проблемы говножелеза транслировать на всё остальное? Вот и я грю нет.

  5. Опубликовано · Жалоба на ответ

    11 часов назад, Error_404 сказал:

    ну вы же живете в современном мире

    воспользуйтесь программкой MMANA-GAL

    можно посчитать и диаграммы направленности и эффективность антены.

    В данном случае уже всё есть у человека на руках. Тыкает и смотрит устраивает или нет. Смысла моделлить при таком раскладе 0.

  6. Опубликовано · Жалоба на ответ

    1 час назад, sol сказал:

    Уважаемый sfstudio! Что так у Вас пригорает?!?

    У меня пригорает? =) Да вы наверное смеётесь. =)

     

    1 час назад, sol сказал:

    Что не верно

    Я для вас выделил что именно не верно. Выделю ещё раз:

    В 01.03.2019 в 18:01, Saab95 сказал:

    На частоте 5ггц антенна 2.4ггц практически ничего не сможет излучать в эфир

    С вами я вообще ни о чём не спорил даже наоборот. Говорю что усилкам нихрена не будет от слова совсем. И что работать оно вполне себе будет. А исходя из конструкции конкретной антенны в нижней части 5ГГц диапазона вполне даже.

     

    Зачем вы спорите с теми, кто с вами не спорит не ясно. Не ну можете продолжать спорить, только не нужно меня с вымышленным спорщиком путать. Попросите его ник сменить.

     

     

    1 час назад, sol сказал:

    Не проясните для меня несколько неясных моментов?

     

    Поясню. 

     

    В топике задан вопрос:

    В 01.03.2019 в 10:11, Duplex сказал:

    Возможно ли использовать антенны для сетей 2.4 Ггц в сетях 5 ГГц?
    Имеются антенны "AIR-ANT1728 2.4GHz, 5.2dBi" и АР Cisco 1240. Хотелось бы использовать сеть 5 ГГц, т.к. вокруг только сети 2.4

    Ответ - запросто вплоть до 5,3ГГц, и никакого выхода из строя усилителей не будет и выше и даже если надуть дури сколько только может эта Cisco 1240, а эффективность  будет примерно такой же как и в 2.4 (примерно до 5.3). Остальное к теме отношения не имеет.

     

    А сказки о выходах из строя современных FEM устанавливаемых в индор железках применимо к вопросу не более чем сказки, ровно как и то что 2,4ГГц антенна перестала разом излучать в 5ГГц. И вы прекрасно подтверждаете мои слова.

     

    Так что что там у кого подгорело ну стоит в другом месте поискать. =)

  7. Опубликовано · Жалоба на ответ

    Ну дык вы посчитайте сколько чего там у вас куда вернётся на антенне расчитанной на работу в середине 2,4ГГц диапазона при использовании её в 5ГГц диапазоне.

    Ширину полосы и т.д. 

     

    Я бы ещё бы понял бы если бы речь шла бы об обратной процедуре и то с ооооочень большим натягом...

     

    Принцип не читай, не считай неси ересь. Да я понял. =)))

     

    Указанная автором антенна это банальный j-коллинеар 1/4L. Можете сами посчитать как он будет работать и в каком диапазоне зная что Ку в 2.4-2.5ГГц по заявлениям 5Дб.

     

    Упрощённо можно рассматривать как 1/4 штырь (набор штырей точнее). Относительно 4,88ГГц это будет 1/2 штыри. И такая антенна весьма широкополосная. Можно рассчитывать на почти такой же Ку как в 2.4 вплоть до 5,3ГГц. 

     

    Так что вот этот откровенный бред:

    В 01.03.2019 в 18:01, Saab95 сказал:

    На частоте 5ггц антенна 2.4ггц практически ничего не сможет излучать в эфир

    Обособлево применимо к конкретно взятой антенне это просто шедевр.

     

    Аффтор может смело юзать оную вплоть до 48 канала без особого геморроя. Насколько удовлетворит результат определит экспериментально. Ничего там с усилками не будет точно, и излучать антенна у него в 5ГГц не перестанет.

     

    Короче самый верный ответ был первым.

     

    P.S. Хорошо хоть добавить микротик не посоветовал. =)

    PP.S. Другое дело что эффективнее с точки зрения отношения Ку к габаритам таки такой же коллинеар но посчитанный для 5ГГц диапазона. Но тут уж что есть на руках.

     

  9. Опубликовано · Жалоба на ответ

    11 часов назад, MobileOneWiFi сказал:

    Wi-Fi модули у китаефонов как правило не свои, там все трекалось, все нонеймы, т.к. унутри стандартные чипы старших товарищей

    Как уже говорилось там может быть всё что угодно. Исключение это свежие MTK где всё вообще в одном чипе. Все остальные лепят что подешевше есть на рынке. А подешевше это BCM в упаковках от кого попало.

     

    Тоже самое в планшетах и STB, там поголовно AMPAK с BCM внутри.

  10. Опубликовано · Жалоба на ответ

    11 часов назад, LostSoul сказал:

    Неужели думаете от айфона или самсунга в ксаоми чип ставят? :-)

     

    Не думаю а уверен. И запросто одно и то же говно окажется и в самсунге и в яблофонах и в сяомях всяких. 

     

    Как пример BCM4345x стоял как минимум в трети SGS/большей части HTC/в куче китайских балалаек на QCA/ и внезапно iphone6* и даже macbook`ах.

     

    А вот глюкалово в дрове оного из-за которого 80МГц на нём работало на уровне рулетки (чаще не работало вовсе) поправили в итоге только SGS.

     

    Яблофон в части радио ничем не отличается от других поделок и очень давно юзает исключительно радиомодули от BCM которые юзает каждый второй смартфонодел или планшетодел, ибо BCM в радиочипах для носимой электрониеи это как риалтэк в свитчах, дешевле не куда и как-то работает. Он вездесущ.

     

    Гораздо реже используют QCA wifi, опять же чаще всего лыжи да самсунги. А так поголовно BCM и далеко не всегда путней и почти никогда не обновляемый на уровне даже REGDB не то что дров.

     

    11 часов назад, MobileOneWiFi сказал:

    Последняя строка например - реальный Гнусмас, а модуль - Мурата

    Ага. У них прям любовь.

     

     

     

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

    Можно встроить функционал например чтобы приложение раз в минуту просыпалось, сканировала видимые маки установленных вайфай точек и отправляла инфу на сервер и засыпало.

    Только вот в андроиде со стороны приложения уже как версии 3 нельзя получить мак собственного адаптера без рута и передаётся затычка. И приложение нужно ещё поставить заставить и т.д.

     

    Другое дело что андроид в отличии от яблока рандомизиует маки засовывая их в da:a1:19 для клиента и 92:68:с3 для wifi direct, и рандомизируются только probe req. В момент подключения оно лезет уже с реальным своим маком.

     

    Яблоки рандомизируются хитрее и просто так их не фильтрануть. Но если подключился - то мак уже видно реальный так и сяк.

     

    Такая рандомизация не мешает отслеживать перемещения если клиент реально юзает wifi там где бывает. Но вот сильно портит жизнь всяким плюшкам типа band steering, а так же идут под откос всякие smart roam`инги с привентивным определением куда засадить клиента со стороны сети.

     

    В общем кому этими рандомизациями жизнь осложнили кроме самих себя не ясно.

     

    Правильный ИМХО путь рандомизации был бы новый мак раз в N часов например, причём для всех запросов. Или ещё как-то. Что бы связности вообще не иметь по данным, но в пределах какого-то внятного времени сохранять мак идентичным что бы не ломать вышеописанное.

     

    Но увы. Параноя в квадрате отключает мозг на корню. Таков современный мир.

  11. Опубликовано · Жалоба на ответ

    2 часа назад, alibek сказал:

    В перспективе такой точкой доступа может быть даже обычная домашняя точка доступа.

     

    Домашние точки они тоже сильно разные бывают. То что кто-то налепил лэйбу SMB/ENT оно не стало как-то иначе работать. Впрочем и наоборот бывает. Весь вопрос (в 99% случаев) насколько вендор оздачился отладкой ПО.

     

    2 часа назад, alibek сказал:

    Не знал, нужно будет поизучать.

    Чиллиспот эт вообще такой мегакомбайн специализированный для развёртывания хотспотов. Умеет оооочень многое.

  12. Опубликовано · Жалоба на ответ

    13 минут назад, alibek сказал:

    Так это же и есть dynamic vlan assignment.

     

    Нет у нас это разделение на уровне MBSSID, то что вы хотите это per user. И делалось оно людьми в силу отсуствия возможности на уровне дров изолировать клиентов между собой. У нас такая возможность есть и городить vlan per client нужды по просту нет.

     

    13 минут назад, alibek сказал:

    У меня пока нет проработанного решения, но есть смутно сформулированные хотелки — клиент подключается к публичному хотспоту, вводил свой логин-пароль и попадает не на обычный хотспот с общей для всех авторизацией, а в свою домашнюю или офисную локальную сеть. Тут через L3 не решить, нужен именно L2.

    Это всё делается на уровне чиллиспота, в т.ч. vlan`ы. Почитайте о нём. Никакой EAP тут близко не нужен.

     

    Что бы отсечь всякую муть и заставить шифровать данные в воздухе на доступе используем просто обычный WPA2 PSK с паролем как имя сети (табличку на ресепшн и всё). В WPA3 этой проблемы уже нет т.е. там режим шифруем всё при доступе без пароля (на самом деле он всё равно есть просто клиент о нём не знает). Но до WPA3 на клиентских устройствах ещё далеко.

     

    Всё остальное делает чиллиспот, он выдаёт адреса, он же умеет засовывать поклиентно во вланы или заруливать в тот или иной сегмент. Там вариантов умотаться. Но всё это уже задача вашего шлюза. Если вы попытаетесь часть этого функционала вынести на сторону АП то прибьёте себя гвоздями к одному вендору и решению, т.к. в 802.11 нет конкретики по реализации оного, значит сиё не стандартно было есть и будет всегда. И совместимости не ждите. А такого ИМХО нужно избегать, даже если кажется что решение будет удобнее.

     

    13 минут назад, alibek сказал:

    нужен именно L2.

    Чёй-то вдруг? NETBIOS нынче мёртв, что там ещё в офисной сети без связности на L2 работать не будет? На худой конец есть proxyarp что один фиг лучше варианта стык в стык. При этом появляется возможность на уровне FW шлюза фильтрануть всё кроме нужного. На L2 разве что городушки ebtables разводить.

     

    Если вы действительно решили городить свой шлюз самостоятельно, то ИМХО стоит начать с расписывания взаимодействия оного и сразу избегать таких моментов, плюс искать и реализовывать решения которые не vendor specific. Т.е. избегать использования привязки к каким-то уникальным плюшкам на уровне АП без которых совсем не обойтись и которые не стандартизированы.

     

     

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

     

    На уровне FW шлюза и данных из радиуса (ессно на доступе тот самый WPA2 Enterprise EAP) это решается на раз, просто в форварде добавляется необходимый набор правил кому и куда разрешить бегать. А вот с L2 начнуться городухи типа софт бриджига с изоляцией на уровне какого-нить ebtables в них. Горы кривых правил, вместо стройного списка в форварде.

     

    Не ну каждый кузнец своего счастья конечно. И всякого рода городушки могут работать и местами даже вполне себе. Но попытки навернуть чего-то эдакого не редко стреляют в ногу.

     

    Система должна быть стройной, понятной с минимумом оверкила и зависимостей от внешних каких-то факторов, будь то вендорспецифичность функций в АП или просто чужой сервис в облаке.

     

  13. Опубликовано · Жалоба на ответ

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

    На мой взгляд RADIUS с поддержкой динамических VLAN (с авторизацией клиента по MAC, логину-паролю или сертификату) будет намного удобнее.

    1 - будут траблы с IOT поэтому хоть застрелись но им отдельный SSID с банальным WPA2-PSK длиной в символов 30.
    2 - авторизация по MAC это вообще дурь которая не даёт вообще ничего
    3 - динамические влан я вообще не вижу куда тут врулить. IOT поделили за счёт MBSSID, остальные авторизуюттся EAP в радиус по логину паролю, изолируются засовываются в свой влан и летят до шлюза где уже на L3 индивидуально разруливаются. Ну нет тут места для каких-то динамик вланов с которыми до кучи ещё на шлюзе огребёте когда потребуется разобраться с какой-либо новой проблемой внезапно возникшей на каком-нить хитром клиенте. Усложнение ради усложнения это тупик. И даже в этом случае вам никто не мешает авторизовать клиента средствами AP из радиус по средствам EAP а в индивидуальный влан засунуть на уровне шлюза+chillispot. Но вот надо ли?

     

    Тут просто уже на сотне клиентов проводных + столько же беспроводных огребёте вышеописанную Ж с броадкастами если тупо будете линковать вланами проводный и беспроводный сегмент. Так что оно тут вот вообще не нужно, максимум уже выше на уровне шлюза, но радиосегмент не должен иметь связности на L2 с проводным. В радио своего мусора хватает.

     

    Насчёт первого можете не сомневаться от вообще уже набили люди шишек. Не повторяйте их приключений. IOT в отдельный MBSSID и дело с концом.

  14. Опубликовано · Жалоба на ответ

    Ну подключились по EAP в радиусе на шлюзе мы видим как минимум MAC, user/pass, а так же шлюз и IP выдаёт. Кидаем роут  (или разрешаем в FORWARD на шлзе) для этого клиента в нужную подсеть в офис или подсеть датчиков - профит. Тут же прям можеми пошейпить.

     

    Проводный сегмент с беспроводным в одну плоскую сеть всё равно делать чревато тем что радио будет заниматься большую часть времени рассылкой броадкаста (а оно на самом низком рэйте летит). Т.е. беспроводный сегмент от проводного один фиг должен быть развязан на L3. А дальше куда пускать и даже какой адрес выдать и в какую подсеть роут кинуть, фаером форвард разрешить уже решает шлюз на основании данных с радиуса (в который ходит AP за авторизацией)  которому известны как минимум mac/ip/user/pass. Всё остальное это сугубо логика шлюза.

     

    А вот проблема тут другая. IOT ни о каких EAP на доступе чаще всего не знает. И посему проще сделать 2й MBSSID для IOT с обычным WPA2+PSK с длинным паролем и весь MBSSID запихать в нужный VLAN (делается из рожи на раз). А вот EAP и прочие прелести оставить на 1м MBSSID завёрнутым в другой влан например.

     

    Вот вообще не вижу никаких проблем со схемой выделенного SSID для IOT и влана для него. Доступно сейчас, из коробки, бесплатно, без СМС и мегаконтроллеров.

  15. Опубликовано · Жалоба на ответ

    14 часов назад, alibek сказал:

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

    И при такой схеме уже сейчас нет никаких проблем с реализацией поклиентного шейпинга, изоляции оных и т.д. Нарезка vlan per client или per group тут не очень видно куда впиливается. Если фронтенд чилли поселить на том же шлюзе то вообще никаких проблем хоть влан на клиента хоть влан на группу (и даже без поломки миграции), хоть даже встроенный в него шейпер. Экаунтинг в радиус и ACL там же оно тоже вполне умеет.

     

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

     

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

     

    Фак конечно уже изрядно протух, но общее представление получить можно http://www.chillispot.org/FAQ.html Более того, почти все коммерческие сервисы авторизации оный умеют.

     

    Плюс есть такая заморочка, в некоторых регионах ребята в погонах хотят до кучи net_flow что бы им лили напрямую. Т.е. после чилли ipt_netflow надо и это тоже ресурсы. 

     

    Я уже не говорю, что требования эти меняются регулярно. Так что софтшлюз на x86 тут must have, а АП и прочее, как вы правильно сказали должно быть просто надёжным транспортом с нужными плюшками.

  16. Опубликовано · Жалоба на ответ

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

    беспроводной клиент подключается к WiFi, точка авторизует его по RADIUS, RADIUS сообщает точке, в какой vlan его засунуть и на какой скорости. Такое есть?

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

     

    Опять таки причём тут хотспот и EAP ? Если хотспот то endpoint будет например chilli, который умеет в т.ч. поклиетно во вланы заворачивать, бесплатно без SMS. При желании можно на нём и шейпер разрешить и им шейпить, но даже на современном железе это грусть и печаль ибо юзерспэйсное.

     

    Грю задачу описываете по человечески со всеми нюансами на wi-cat.ru подскажем как сделать. На уровне хочу странного, ну ой. Тут точно всё подряд никто пилить не будет. Нужно чётко понимать что именно хочется достигнуть, тогда можно работать над решением. Пока каламбур какой-то.

     

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

    Я как-то встречал высказывание, что это конечная абонентская железка под конкретную задачу, универсального устройства никто делать не будет.

    И? Как это связано с железом для хотспотов или расширением функционала в том месте где уже есть?

     

    Более того, если вы не заметили, то NAG и Wi-CAT немного разные компании. Ну так на секундочку. То что мы работали над софтом и железом линейки SNR-CPE не говорит о том, что мы не движемся дальше. Упираться рогом в LowCost End User CPE с нашей стороны никто не планировал и не планирует от слова совсем.

  17. Опубликовано · Жалоба на ответ

    3 часа назад, jffulcrum сказал:

    про совместимость с гейфонами - сказали что нет проблем даже с последними Х

    Вот с новыми и не будет ни у кого. Ибо теперь яблоко по сути wifi не касается. Все проблемы (99% их проблем) это устройства 11-13г (iphone6* и того же времени некоторые макбуки) с радио на вполне конкретном чипе. Пришлось злобный костыль рожать что бы остальным живущим на той же АП жизнь не портить.

     

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

     

    Включая некоторые шероховатости с TxBF vs MU-MIMO на последних Xовых. Т.е. их реализация не нарушает требований "стандарта", просто "стандарт" такой блин... Благо всё правиться.

     

  18. Опубликовано · Жалоба на ответ

    1 час назад, NewUse сказал:

    спросите у разработчика @sfstudio https://forum.nag.ru/index.php?/profile/30112-sfstudio/

    Плз. всё сюда https://wi-cat.ru/forums/ или на крайняк на support[at]wi-cat.ru по форумам ходить сейчас времени 0,0 да и лички по форумам я либо почти везде повырубал, либо тупо не заглядываю.

     

    Если ну уж прям напрямую хочется то sfstudio[at]wi-cat.ru но лучше через офиц каналы выше, тогда запросы точно не потеряются.

     

    2 часа назад, NewUse сказал:

    динамикВлан хостапд умеет с незапамятных времён

    Я вам грил уже раз 5ть. Нет у нас никаких хостапд. Не юзаем мы оные, всё делает драйвер. =) И к WRT мы никакого отношения не имеем тоже. =)))

  19. Опубликовано · Жалоба на ответ

    3 часа назад, alibek сказал:

    Но нет уличных моделей и скорее всего никогда не будет нормальной поддержки EAP с плюшками.

    Чего конкретно нет-то? Опишите на wi-cat.ru каких плюшек не хватает. И причём тут хотспот и EAP. Распишите схему - будет понятно.

     

    Экаунтинг в новом софте под новое железо есть. В старое натянуть можно но геморно и не окупиться.

     

    В общем распишите у нас в разделе "функционал" - возьмём на заметку. На эту тему вообще случайно нарвался. Так что если что-то хотите увидеть в Wive описывайте у нас ибо собирать хотелки со всей сети точно никто не будет.

     

    Более того, запросто может получиться так, что искомое вами уже давно есть, только в UI не вытащено и болтается в ToDo где-нить в полузабытом состоянии ибо оказалось никому не нужно. Опишите свои чаяния - будет повод освежить.

     

    Убивают меня люди которые лучше разработчиков знают что будет, а чего не будет. Я сам ещё не определился, а клиенты уже в курсе. =))))) Не гадайте, задавайте вопросы с конкретикой куда и как надо. Задачи вида то, не знаю, что, пока не куда, но может куда-то лет через 100 пригодиться ессно брать в работу сломя голову никто не будет. В сутках всего 24 часа и цели реализовать всё и вся, но абы как и что бы было не стоит. Либо решаем конкретные задачи и делаем это хорошо, либо нечего и 5ю точку мучать. Вот такой подход. Будет спрос и понятные кейзы - бум думать и готовить решение.

     

    P.S. Кстати, интересующиеся теперь могут потыкать демоуй https://wi-cat.ru/wive-ng/gui-emulator-wive-ng/ . Собирается прям вот напрямую из GIT прям той же ветки с которой собираются реальные образы. Пока не без шероховатостей (демка всмысле), допилимс.

     

    2 часа назад, NewUse сказал:

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

    Можете написать нам на info[at]wi-cat.ru с примерными объёмами и т.д. Кооперацию никто не отменял, ради 10шт ессно увы стартовать не вижу смысла. А с сотни уже можно начинать разговаривать. Как бы будет заявок в нужном количестве - возьмём в работу. Технически всё реально сделать в сжатые сроки с учётом хоть крайнего севера (ессно ценник в зависимости), хоть подводного монтажа. =)

  22. Опубликовано · Жалоба на ответ

    2 часа назад, DAF сказал:

    /sys clock time-zone-name

    Это ответ на что? Вопроса я тут вижу 2:

    1) как он автоматом зону определяет

    2) как отрубить sntp дабы остальные могли с ним синкаться

     

    На какой из вопросов это является ответом? Вроде мануал тут все в состоянии прочитать на тему как зону сменить. Или вы реально считаете, что LostSoul не в курсе? Зачем отвечать на что-то своё?

  23. Опубликовано · Жалоба на ответ

    Это не ко мне вопрос что в микротике реализовано.

     

    В wive использован busybox ntpd, он прекрасно ходит по ntp и в т.ч. до цисок (проверено), sntp он не умеет. Этот же демон юзают буквально все CPE (с теми же огрничениям), видимо кроме микротика.

     

    Тут вопрос микротику нужно задавать как разрешить ntp без всяких S и будет счастье.

  24. Опубликовано · Жалоба на ответ

    Тут интересы скорее всего смежные (аля повод ещё жахнуть в зомбовизор), возможно родственные (гениальный ФУЙХ45 может ЦОДы какие строит, или "мегавендором" перекрашивающим китай владеет).

     

    Вариантов дофига.

    13 минут назад, nemo_lynx сказал:

    У меня вообще складывается всё более стойкое убеждение, что Б4 собираются компенсировать себе расходы на яровую этим вот законом.

    Одно другому не мешает.

    13 минут назад, nemo_lynx сказал:

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

    А чего не сразу так? 

    Скрытый текст

     

     

    Только лучше сразу учесть, что для малого телекома нынче только так:

    Скрытый текст

     

     

  25. Опубликовано · Жалоба на ответ

    Кстати, народ тут ржал с 9тков яиц и прочего. Я вот сегодня купил кусок мяса в вакууме (брал постоянно раньше никогда такого не видел). После отделения жира (спрятанного в аккуратно замотанный шмат мяса получил соотношение ну где-то 1/3 жир/мясо. =)))  И визуально это был лучший вариант из доступного в магазине. Чую где-то тут НДС компенсировали. =) Жировая налоговая оптимизация так сказать.

     

    Оскал капитализма в ключе состязания за баблище. =) Ну что тут ещё сказать-то. =)

    shash.jpg