Jump to content
Калькуляторы

sfstudio

VIP
  • Content Count

    5317
  • Joined

  • Last visited

About sfstudio

  • Rank
    Академик
  • Birthday 03/30/1982

Контакты

  • Сайт
    https://wi-cat.ru

Информация

  • Пол
    Мужчина
  • Интересы
    Wireless Network Hardware Development

Город

  • Город
    EKB

Recent Profile Visitors

11650 profile views
  1. Отвечаю. Людям свойственно читать по диагонали и понимать перпендикулярно. 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 Ессно представившись, описав какую компанию представляете т.к. ЧЛ в тест не дадут (как минимум пока). Ну и сделать это стоит уже сейчас. Правда потолочные АП будут чуть позже, но если нужны то стоит это указать отдельно в письме, возможно это сместит приоритеты по запуску новых продуктов.
  2. Значит спроектированы они макаками вот и всё. И дохли они скорее всего далеко не по озвученной выше причине. Как усилки пыхают при возбуде при кривой схемотехнике или даже кривой разводке pcb при банальном откручивании антенн я видел неоднократно. На спектрике в этот момент всплеск на несколько секунд и всё неси на помойку. Но ведь не повод проблемы говножелеза транслировать на всё остальное? Вот и я грю нет.
  3. В данном случае уже всё есть у человека на руках. Тыкает и смотрит устраивает или нет. Смысла моделлить при таком раскладе 0.
  4. У меня пригорает? =) Да вы наверное смеётесь. =) Я для вас выделил что именно не верно. Выделю ещё раз: С вами я вообще ни о чём не спорил даже наоборот. Говорю что усилкам нихрена не будет от слова совсем. И что работать оно вполне себе будет. А исходя из конструкции конкретной антенны в нижней части 5ГГц диапазона вполне даже. Зачем вы спорите с теми, кто с вами не спорит не ясно. Не ну можете продолжать спорить, только не нужно меня с вымышленным спорщиком путать. Попросите его ник сменить. Поясню. В топике задан вопрос: Ответ - запросто вплоть до 5,3ГГц, и никакого выхода из строя усилителей не будет и выше и даже если надуть дури сколько только может эта Cisco 1240, а эффективность будет примерно такой же как и в 2.4 (примерно до 5.3). Остальное к теме отношения не имеет. А сказки о выходах из строя современных FEM устанавливаемых в индор железках применимо к вопросу не более чем сказки, ровно как и то что 2,4ГГц антенна перестала разом излучать в 5ГГц. И вы прекрасно подтверждаете мои слова. Так что что там у кого подгорело ну стоит в другом месте поискать. =)
  5. Ну дык вы посчитайте сколько чего там у вас куда вернётся на антенне расчитанной на работу в середине 2,4ГГц диапазона при использовании её в 5ГГц диапазоне. Ширину полосы и т.д. Я бы ещё бы понял бы если бы речь шла бы об обратной процедуре и то с ооооочень большим натягом... Принцип не читай, не считай неси ересь. Да я понял. =))) Указанная автором антенна это банальный j-коллинеар 1/4L. Можете сами посчитать как он будет работать и в каком диапазоне зная что Ку в 2.4-2.5ГГц по заявлениям 5Дб. Упрощённо можно рассматривать как 1/4 штырь (набор штырей точнее). Относительно 4,88ГГц это будет 1/2 штыри. И такая антенна весьма широкополосная. Можно рассчитывать на почти такой же Ку как в 2.4 вплоть до 5,3ГГц. Так что вот этот откровенный бред: Обособлево применимо к конкретно взятой антенне это просто шедевр. Аффтор может смело юзать оную вплоть до 48 канала без особого геморроя. Насколько удовлетворит результат определит экспериментально. Ничего там с усилками не будет точно, и излучать антенна у него в 5ГГц не перестанет. Короче самый верный ответ был первым. P.S. Хорошо хоть добавить микротик не посоветовал. =) PP.S. Другое дело что эффективнее с точки зрения отношения Ку к габаритам таки такой же коллинеар но посчитанный для 5ГГц диапазона. Но тут уж что есть на руках.
  6. Я просто оставлю это тут https://wi-cat.ru/others/antenna/ Ну что бы спасти от перегревов и выходов из строя. =)))) Мамааааааааа.......
  7. ДК АйТишник

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

    Не думаю а уверен. И запросто одно и то же говно окажется и в самсунге и в яблофонах и в сяомях всяких. Как пример BCM4345x стоял как минимум в трети SGS/большей части HTC/в куче китайских балалаек на QCA/ и внезапно iphone6* и даже macbook`ах. А вот глюкалово в дрове оного из-за которого 80МГц на нём работало на уровне рулетки (чаще не работало вовсе) поправили в итоге только SGS. Яблофон в части радио ничем не отличается от других поделок и очень давно юзает исключительно радиомодули от BCM которые юзает каждый второй смартфонодел или планшетодел, ибо BCM в радиочипах для носимой электрониеи это как риалтэк в свитчах, дешевле не куда и как-то работает. Он вездесущ. Гораздо реже используют QCA wifi, опять же чаще всего лыжи да самсунги. А так поголовно BCM и далеко не всегда путней и почти никогда не обновляемый на уровне даже REGDB не то что дров.   Ага. У них прям любовь.   Только вот в андроиде со стороны приложения уже как версии 3 нельзя получить мак собственного адаптера без рута и передаётся затычка. И приложение нужно ещё поставить заставить и т.д. Другое дело что андроид в отличии от яблока рандомизиует маки засовывая их в da:a1:19 для клиента и 92:68:с3 для wifi direct, и рандомизируются только probe req. В момент подключения оно лезет уже с реальным своим маком. Яблоки рандомизируются хитрее и просто так их не фильтрануть. Но если подключился - то мак уже видно реальный так и сяк. Такая рандомизация не мешает отслеживать перемещения если клиент реально юзает wifi там где бывает. Но вот сильно портит жизнь всяким плюшкам типа band steering, а так же идут под откос всякие smart roam`инги с привентивным определением куда засадить клиента со стороны сети. В общем кому этими рандомизациями жизнь осложнили кроме самих себя не ясно. Правильный ИМХО путь рандомизации был бы новый мак раз в N часов например, причём для всех запросов. Или ещё как-то. Что бы связности вообще не иметь по данным, но в пределах какого-то внятного времени сохранять мак идентичным что бы не ломать вышеописанное. Но увы. Параноя в квадрате отключает мозг на корню. Таков современный мир.
  9. Домашние точки они тоже сильно разные бывают. То что кто-то налепил лэйбу SMB/ENT оно не стало как-то иначе работать. Впрочем и наоборот бывает. Весь вопрос (в 99% случаев) насколько вендор оздачился отладкой ПО.   Чиллиспот эт вообще такой мегакомбайн специализированный для развёртывания хотспотов. Умеет оооочень многое.
  10. Нет у нас это разделение на уровне MBSSID, то что вы хотите это per user. И делалось оно людьми в силу отсуствия возможности на уровне дров изолировать клиентов между собой. У нас такая возможность есть и городить vlan per client нужды по просту нет. Это всё делается на уровне чиллиспота, в т.ч. vlan`ы. Почитайте о нём. Никакой EAP тут близко не нужен. Что бы отсечь всякую муть и заставить шифровать данные в воздухе на доступе используем просто обычный WPA2 PSK с паролем как имя сети (табличку на ресепшн и всё). В WPA3 этой проблемы уже нет т.е. там режим шифруем всё при доступе без пароля (на самом деле он всё равно есть просто клиент о нём не знает). Но до WPA3 на клиентских устройствах ещё далеко. Всё остальное делает чиллиспот, он выдаёт адреса, он же умеет засовывать поклиентно во вланы или заруливать в тот или иной сегмент. Там вариантов умотаться. Но всё это уже задача вашего шлюза. Если вы попытаетесь часть этого функционала вынести на сторону АП то прибьёте себя гвоздями к одному вендору и решению, т.к. в 802.11 нет конкретики по реализации оного, значит сиё не стандартно было есть и будет всегда. И совместимости не ждите. А такого ИМХО нужно избегать, даже если кажется что решение будет удобнее. Чёй-то вдруг? NETBIOS нынче мёртв, что там ещё в офисной сети без связности на L2 работать не будет? На худой конец есть proxyarp что один фиг лучше варианта стык в стык. При этом появляется возможность на уровне FW шлюза фильтрануть всё кроме нужного. На L2 разве что городушки ebtables разводить. Если вы действительно решили городить свой шлюз самостоятельно, то ИМХО стоит начать с расписывания взаимодействия оного и сразу избегать таких моментов, плюс искать и реализовывать решения которые не vendor specific. Т.е. избегать использования привязки к каким-то уникальным плюшкам на уровне АП без которых совсем не обойтись и которые не стандартизированы.   Я вот чаще вижу задачу что юзеры в офисе должны быть связны между собой напрямую, при этом иметь доступ к разному набору сервисов, причём один имеет доступ к одному набору, другой к другому, при этом наборы могут пересекаться. На уровне FW шлюза и данных из радиуса (ессно на доступе тот самый WPA2 Enterprise EAP) это решается на раз, просто в форварде добавляется необходимый набор правил кому и куда разрешить бегать. А вот с L2 начнуться городухи типа софт бриджига с изоляцией на уровне какого-нить ebtables в них. Горы кривых правил, вместо стройного списка в форварде. Не ну каждый кузнец своего счастья конечно. И всякого рода городушки могут работать и местами даже вполне себе. Но попытки навернуть чего-то эдакого не редко стреляют в ногу. Система должна быть стройной, понятной с минимумом оверкила и зависимостей от внешних каких-то факторов, будь то вендорспецифичность функций в АП или просто чужой сервис в облаке.
  11. 1 - будут траблы с IOT поэтому хоть застрелись но им отдельный SSID с банальным WPA2-PSK длиной в символов 30. 2 - авторизация по MAC это вообще дурь которая не даёт вообще ничего 3 - динамические влан я вообще не вижу куда тут врулить. IOT поделили за счёт MBSSID, остальные авторизуюттся EAP в радиус по логину паролю, изолируются засовываются в свой влан и летят до шлюза где уже на L3 индивидуально разруливаются. Ну нет тут места для каких-то динамик вланов с которыми до кучи ещё на шлюзе огребёте когда потребуется разобраться с какой-либо новой проблемой внезапно возникшей на каком-нить хитром клиенте. Усложнение ради усложнения это тупик. И даже в этом случае вам никто не мешает авторизовать клиента средствами AP из радиус по средствам EAP а в индивидуальный влан засунуть на уровне шлюза+chillispot. Но вот надо ли? Тут просто уже на сотне клиентов проводных + столько же беспроводных огребёте вышеописанную Ж с броадкастами если тупо будете линковать вланами проводный и беспроводный сегмент. Так что оно тут вот вообще не нужно, максимум уже выше на уровне шлюза, но радиосегмент не должен иметь связности на L2 с проводным. В радио своего мусора хватает. Насчёт первого можете не сомневаться от вообще уже набили люди шишек. Не повторяйте их приключений. IOT в отдельный MBSSID и дело с концом.
  12. Ну подключились по 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 и влана для него. Доступно сейчас, из коробки, бесплатно, без СМС и мегаконтроллеров.
  13. И при такой схеме уже сейчас нет никаких проблем с реализацией поклиентного шейпинга, изоляции оных и т.д. Нарезка vlan per client или per group тут не очень видно куда впиливается. Если фронтенд чилли поселить на том же шлюзе то вообще никаких проблем хоть влан на клиента хоть влан на группу (и даже без поломки миграции), хоть даже встроенный в него шейпер. Экаунтинг в радиус и ACL там же оно тоже вполне умеет. Лишь бы ресурсов хватало а жрёт оно при полном фарше возможностей мама не горюй, т.е. всяко тащим на шлюз а АП как и написано выше оставляем в роли транспорта с роумингами и прочим. Ещё один плюс такой схемы, что АП в итоге можно любые юзать, хоть те что уже есть у клиента без изменений логики на стороне шлюзосервера вообще. Т.е. нормальное централизованное решение где каждая железка занимается своим делом. Фак конечно уже изрядно протух, но общее представление получить можно http://www.chillispot.org/FAQ.html Более того, почти все коммерческие сервисы авторизации оный умеют. Плюс есть такая заморочка, в некоторых регионах ребята в погонах хотят до кучи net_flow что бы им лили напрямую. Т.е. после чилли ipt_netflow надо и это тоже ресурсы. Я уже не говорю, что требования эти меняются регулярно. Так что софтшлюз на x86 тут must have, а АП и прочее, как вы правильно сказали должно быть просто надёжным транспортом с нужными плюшками.
  14. Ну если вам пофигу что при этом заломается миграция можно вланы нарезать и поклиентно. А шейпит один фиг шлюз, а не АП. Так что радиус говорит шлюзу в какую трубу (например HTB) запихать с какой скоростью и нет проблем. Опять таки причём тут хотспот и EAP ? Если хотспот то endpoint будет например chilli, который умеет в т.ч. поклиетно во вланы заворачивать, бесплатно без SMS. При желании можно на нём и шейпер разрешить и им шейпить, но даже на современном железе это грусть и печаль ибо юзерспэйсное. Грю задачу описываете по человечески со всеми нюансами на wi-cat.ru подскажем как сделать. На уровне хочу странного, ну ой. Тут точно всё подряд никто пилить не будет. Нужно чётко понимать что именно хочется достигнуть, тогда можно работать над решением. Пока каламбур какой-то. И? Как это связано с железом для хотспотов или расширением функционала в том месте где уже есть? Более того, если вы не заметили, то NAG и Wi-CAT немного разные компании. Ну так на секундочку. То что мы работали над софтом и железом линейки SNR-CPE не говорит о том, что мы не движемся дальше. Упираться рогом в LowCost End User CPE с нашей стороны никто не планировал и не планирует от слова совсем.
  15. Вот с новыми и не будет ни у кого. Ибо теперь яблоко по сути wifi не касается. Все проблемы (99% их проблем) это устройства 11-13г (iphone6* и того же времени некоторые макбуки) с радио на вполне конкретном чипе. Пришлось злобный костыль рожать что бы остальным живущим на той же АП жизнь не портить. Если у кого-то имеются проблемы с яблочниками других серий - значит проблема уже не на стороне яблок. Не более ранние, не более поздние яблоки не имеют каких-либо значимых проблем выбивающихся за рамки разночтений "стандарта" 802.11, и вполне могут быть без проблем учтены софтом на стороне АП. Включая некоторые шероховатости с TxBF vs MU-MIMO на последних Xовых. Т.е. их реализация не нарушает требований "стандарта", просто "стандарт" такой блин... Благо всё правиться.