[sfstudio]

Кому надо что то там писать Микротику ?

 

Ну вы же меня к пузомеркам отправляли? Ну вот и я вам грю, у вас есть притензии - пишите в микротик.

 

И править драйверы ? ;-).

 

Чего? Я грю правил под наши железки для работы в условиях интерференционного ада. А микротик сами авось осилят.

 

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

 

Я ничего не хочу. Эт вы чего-то хотите. Грю перестаньте махать интырпрайзом. То что вы "продемонстрировали" ошибка софта, возможно конкретной железки (не интересно если что, у меня своего железа навалом).

 

Есть разные устройства по разной цене, применяйте по назначению.

 

Вот и приплыли. Расскажите чем поддержка вашего любимого WPA-Enterptise будет отличаться в вашей железке и моей? А по цене отличия сами найдёте.

 

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

 

P.S. Мораль сей басни такова - независимо от лэйбы ынтырпрайз/супер-пупер/soho/industrial внутри может быть как что-то приличное, так и какаха какой свет не видовал.

[slv700]

А если считаете, что тех часть тут никто не поймёт - ну видимо вы форумом ошиблись

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

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

Я знаю одно Микротик и другие популярные в массах бренды типа ubnt хендовер( он же роуминг) не поддерживают и поэтому имеют кучу проблем , которые совершенно не связаны с большим или малым временем переключения. В Камбиум handover есть ОКС и 802.11r. Совершенно неважно что не все клиенты поддерживают 802.11r. Если таковые есть, то они идут по OKC, что не требует от клиента ничего. Ничего особого в роуминге Камбиум настраивать не надо, включил и работает. И не надо людям думать про реализацию роуминга, ошибках в рейтах и т.п. вы программист - вы и думайте и пишите письма Микротику или Асерос( или Броадком и др) если оно вам надо ;-).

[sfstudio]

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

 

А про что мне почитать темы? На этом форуме, да, я мониторю на постоянной основе раздел wifi. Иногда заглядываю в другие разделы. Для удовлетворения других моих интересов есть другие форумы.

 

Я не хочу вникать в ваше программирование логики хендовера.

 

Ну вот я не хочу вникать в ваши изыскания в других областях.

 

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

 

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

 

Вы - программист, а надо бы быть сначала математиком.

 

Что бы что? Что будем считать?

 

Я знаю одно Микротик и другие популярные в массах бренды типа ubnt хендовер( он же роуминг) не поддерживают и поэтому имеют кучу проблем , которые совершенно не связаны с большим или малым временем переключения. В Камбиум handover есть ОКС и 802.11r. Совершенно неважно что не все клиенты поддерживают 802.11r. Если таковые есть, то они идут по OKC, что не требует от клиента ничего. Ничего особого в роуминге Камбиум настраивать не надо, включил и работает. И не надо людям думать про реализацию роуминга, вы программист - вы и думайте и пишите письма Микротику если оно вам надо ;-)

 

802.11r, which is the IEEE standard for fast roaming, introduces a new concept of roaming where the initial

handshake with the new AP is done even before the client roams to the target AP, which is called Fast

Transition (FT). The initial handshake allows the client and APs to do the Pairwise Transient Key (PTK)

calculation in advance. These PTK keys are applied to the client and AP after the client does the re-association

request or response exchange with the new target AP. The FT key hierarchy is designed to allow clients to

make fast BSS transitions between APs without requiring re-authentication at every AP. 802.11r eliminates

much of the handshaking overhead while roaming, thus reducing the handoff times between APs while

providing security and QoS. This is useful for client devices that have delay-sensitive applications such as

voice and video and is the key requirement for voice over Wi-Fi.

 

Реализация сводиться к тому, что вместо полной процедуры авторизации использутеся процедура с PTK за счёт чего это выглядит как реассоциация без полной фазы. Больше ничего 802.11R на тему роуминга не реализует. Это именно ускорялка.

 

И Opportunistic Key Caching по сути тоже ускорялка только другого момента. И его умеют все (и почти всегда оно по дефолту включено) кто умеет 802.1x.

 

Opportunistic Key Caching: With this method, a client device can skip the 802.1x authentication with an access point and only needs to perform the 4 way handshake when roaming to access points that are centrally managed by the same WLC in an LWAPP or other controller-based infrastructure. This means that the client doesn't need to authenticate with access points that it wants to roam to, as long as the client has authenticated successfully to at least one of the access points in the same zone as the access point that handled the previous successful authentication. In this case, the PMK identifier has been cached at a central location, like the WLC (or wireless switch.) With OKC, the client must support this method for it to be used, even if the infrastructure has been configured with OKC enabled.

 

К обеспечению непосредственно миграции клиента (если оный сам не в состоянии инициировать миграцию как это делают нормальные клиенты) это не имеет никакого отношения.

 

Еще раз, расскажите это микротику если это у вас зудит. К обсуждаемой теме сиё вообще отношения не имеет. Я высказываю вам своё веское фи именно на тему, что докатились до уровня Сааба, только у того "надо поставить микротик", а у вас заклинило на слове ынтырпрайз. И вот тут не надо быть математиком, что бы видеть, что для вас наг это тупо торговая площадка (да, тонкий намёк на тонкие обстоятельства), так что либо придерживайтесь темы и технической аргументации без пафосных ынтырпрайзов и странных тестов мегаспециалистами с ляпами уровня сантехника Тюрюмова, или перестаньте уже подпитывать энтропию вселенной за счёт этого форума.

 

вы программист - вы и думайте

 

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

[slv700]

А про что мне почитать темы?

 

ШБД.

[sfstudio]

Конкретнее. У меня нет лишней жизни что бы перечитать всё ваше творчество по такой "узкой" теме как ШБД. Да и не заинтересовали. Что я там увидеть должен? И почему мне должно быть это интересно? Ну всмысле ваши изыскания почему мне должны быть интересны?

[slv700]

Конкретнее. У меня нет лишней жизни что бы перечитать всё ваше творчество по такой "узкой" теме как ШБД. Да и не заинтересовали. Что я там увидеть должен? И почему мне должно быть это интересно? Ну всмысле ваши изыскания почему мне должны быть интересны?

Мне все равно что вам интересно и ни к чему я вас не призываю.Занимайтесь своим делом.

[sfstudio]

Вот я и занимаюсь, не поверите.

[SSD]

Вот я и занимаюсь, не поверите.

Бесполезное занятие, для него признаться в своей неправоте смерти подобно.

[mafijs]

Что касется роуминга в общаге, то он там нужен как зайцу стопсигнал. Неужели Вы думаете,что

бегает по коридору с одного конца коридора в другой конец с открытым лаптопом или планшетом и

разговаривает по скайпу? Эти времена давно прошли, по крайней мере у нас.

Студент сидит в своей комнате и там копается в интернете. Но таким апликациям, как Waze, whatsapp

роуминг по барабану. Переключение даже не заметит.

Далее - точки, конечно разнесены по каналам.

длина коридора 80 метров. К тому же - дом из 4-ёх корпусов как бы, с небольшим смешением относительно друг другу.

Так что одной - двумя точками не накрить этаж.

В добавку - на точке может висеть 8-16 узеров, но это не значит, что они все

одновременно качет. По наблюдениям - обычно 2-3, ну 4 активны одновременно.

Каждой ситуачии свое решение.

Я не крутой специалист, только учусь, немного больше года с микротик занимаюсь.

я могу ошибагся, конечно. Другие пусть сами решет. Я только выложил свой практический опыт.

[Saab95]

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

 

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

[sfstudio]

Saab95 жду от вас коментариев http://forum.nag.ru/forum/index.php?showtopic=122132&view=findpost&p=1329201 И не "правильно", а именно как по вашему пониманию правильно. Сказал правильно - скажи как, а то ведь можно и опять нарваться. Это технический форум, а не кружок начинающих медиумов.

[Saab95]

Конечно там указано не верно. Нужно было 2 микротика использовать, первый для работы в режиме G, второй с режимом N, тогда те устройства, которые N не умеют подключались к другой точке, а кто на N сидели бы только с высокими канальными скоростями.

[sfstudio]

Конечно там указано не верно. Нужно было 2 микротика использовать, первый для работы в режиме G, второй с режимом N, тогда те устройства, которые N не умеют подключались к другой точке, а кто на N сидели бы только с высокими канальными скоростями.

 

Опять этот бред. Всё хватит. Ну на кой чёрт вы так дискредитируете тех кто вас (судя по всему) кормит? Цирк с конями.

[slv700]

Что касется роуминга в общаге, то он там нужен как зайцу стопсигнал. Неужели Вы думаете,что

бегает по коридору с одного конца коридора в другой конец с открытым лаптопом или планшетом и

разговаривает по скайпу? Эти времена давно прошли, по крайней мере у нас.

Студент сидит в своей комнате и там копается в интернете. Но таким апликациям, как Waze, whatsapp

роуминг по барабану. Переключение даже не заметит.

Назначение роуминга ( handover) в сети не только в уменьшении времени переключения клиента между точками доступа до <50-150 мс. Для наших практических нужд такое время переключения, действительно, мало кому нужно и в этом задача и не стоит.

Роуминговая сеть -это логически связанные точки доступа, которые обмениваются между собой ( непосредственно друг с другом или через контроллер) информацией о каждом клиенте в сети. Каждая точка доступа роуминговой сети знает ( владеет всей необходимой для подключения клиента информацией) о клиенте как только он первый раз подключился к одной из точек доступа сети. Поэтому при перемещении по сети клиент плавно и быстро переходит от одной точки доступа к другой:

1) Без логического разрыва связи ( дисконекта) клиента от точки доступа

2) Без разрыва связи с сетью в целом - клиент никогда не подключится к другой соседней сети

3) Без повторной аутентификации на каждой точке доступа ( если таковая применяется)

4) Без редиректа на HotSpot портал( если такой применяется).

Эти 4 функции handover реально более важны в корпоративных сетях и сетях публичного доступа, чем низкое время переключения.

В сетях на Микротик и UBNT handover НЕТ.

Это значит что при перемещении клиента по такой сети

1) происходит дисконект клиента от точки доступа ( точка доступа выбрасывает клиента при снижении сигнала RSSI ниже заданного порога)

2) после дисконекта клиент начинает искать новую точку доступа ( сканит эфир), договаривается с точкой доступа о подключении, получает IP адрес и устанавливает связь. Перерыв в связи может занять 1-5 сек, что может быть терпимо ( если это происходит нечасто), но тут важно другое.

2.a) Если клиент после дисконекта видит несколько точек доступа -кандидатов на подключение, то он подключится к той, кто первая ему ответит согласием на подключение. Но такая точка вполне может сразу или через некоторое время ( через несколько секунд по результату флуктуации сигнала) выбросить вновь подключенного клиента по снижению сигнала RSSI ниже заданного порога. В этом случае клиент опять начнет искать новую точку, и очень часто он может найти свою же исходную первую точку доступа, которая его уже дисконектила или другую, которая его сразу или очень скоро опять отбросит. В общем клиент ( даже без движения, например студент сидит в своей комнате) может начать метаться между точками доступа с дисконектами в 1-5 сек, что уже неприемлемо.

2.б) Если клиент после дисконекта видит не только свои ( с тем же SSID), но и чужие точки доступа ( где он хотя бы один раз побывал и устройство запомнило SSID), то он вполне может уйти в соседнюю сеть, отключиться от которой можно только по инициативе клиента и предварительно удалив из клиентского устройства SSID соседней сети из списка запомненных сетей.

Если такая сеть без handover небольшая или имеет невысокую плотность размещения точек доступа ( клиент территориально может находиться в зоне обслуживания до 2-3 точек доступа и чужих точек нет или туда никто никогда не заходит), то данная особенность работы такой сети может вызывать лишь небольшое неудобство. Но если сеть большая корпоративная или HotSpot с плотным размещениеи точек доступа, обслуживающая большое количество клиентов, то данное свойство работы сети БЕЗ поддержки handover сделает сеть полностью неработоспособной.

Идем далее пункт 3.

Сеть без handover может иметь только открытый доступ, или WPA-PSK c одинаковым ключом. В сети без handover доступ WPA EAP с Радиус аутентификацией каждый раз при смене клиента точки доступа будет требоваться повторная аутентификация. В принципе если ключ EAP запоминается в устройстве, то повторная аутентификация на Радиус может и занимает продолжительное время ( что может быть некритично), но по крайней мере не требует от клиента каждый раз при смене точки доступа вводить логин/ пароль. Но вот если логин/пароль клиент вводит на странице авторизации HotSpot портала , то тогда это уже совсем другая история . Каждый раз при смене точки доступа клиент будет редиректиться на HotSpot портал ( что уже неприемлемо), а если еще при этом ему нужно каждый раз вводить логин/пароль, то это значит решение вообще нерабочее.

Микротик для решения п.3 и п. 4 проблемы работы сети без handover, в частности для реализации доступа через Radius, предлагает свое решение ( которое можно назвать "костылем").

1)Все точки доступа имеют открытый доступ

2) Аутентификацию с взаимодействием с Радиус осуществляют не точки доступа , а централизованно - контроллер CapsMan в режиме HotSpot Gateway. Контроллер запоминает каждого клиента при входе в сеть и поэтому при смене точки доступа ( с открытым доступом) не направляет его на повторную аутентификацию Radius. Решение в принципе рабочее ( если не обращать внимание на нерешенные проблемы с п.1 и п.2), но есть ключевое НО.

Микротик реализует устаревший и уже нигде не используемый доступ MS-PAP, MS-CHAP, который мгновенно взламывается, что делает монетизацию услуг сети на Микротике невозможной. Современный стандартный защищенный доступ WPA-Enterprise ( в частности необходимый EAP PEAP/TTLS ) Микротик не поддерживает . На данный момент у МТ есть только EAP TLS, что для обсуждаемых задач не подходит.

Что касается UBNT , то у них есть WPA-Enterprise, но handover нет. Раньше был на старых моделях Zero handoff, но ущербный и поэтому нерабочий, сейчас на новых продуктах поддержки роуминга нет.

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

Поэтому точки доступа без поддержки роуминга (handover) не могут быть класса SME ( Enterprise), у которых масштабируемость является обязательной. А строительство относительно больших сетей на дешевых домашних точках доступа (SOHO) имеет ряд перечиленных выше недостатков, которые на определенном этапе роста сети (размере сети) становятся неразрешимыми проблемами, что делает сеть неработоспособной.

[sfstudio]

1) Без логического разрыва связи ( дисконекта) клиента от точки доступа

 

Разрыв происходил и будет происходить, хватит врать. Что бы стэйты не дропались на нормальных клиентах и соединения у приложений не дохли необходимо и достаточно (если клтент не совсем косой) что бы при миграции адрес на интерфейсе не менялся, это достигается либо статик привязкой ip либо привязкой к хэшу на уровне dhcp, либо привязкой login/password к ip на уровне связки radius+dhcp.

 

2) Без разрыва связи с сетью в целом - клиент никогда не подключится к другой соседней сети

 

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

 

3) Без повторной аутентификации на каждой точке доступа ( если таковая применяется)

 

Читайте маны они рулез. Аутентификация есть всегда. Будет она по укороченной процедуре 802.11R/OKC или по полной вопрос 1999й.

 

4) Без редиректа на HotSpot портал( если такой применяется).

 

Вообще к роумингу с боку и обеспечивается ровно тем же что и в п1.

 

Итого из 4х фраз соврали 3жды. Подмена понятий и лапша на уши это тоже враньё. Буду просить вам выписать RO что бы было время почитать и подумать.

[sfstudio]

Эти 4 функции handover реально более важны в корпоративных сетях и сетях публичного доступа, чем низкое время переключения.

В сетях на Микротик и UBNT handover НЕТ.

 

Чего нет? Насколько я помню микротик и ubnt юзает стыренный dnsmasq как dns и dhcp сервер, а там одним из первых была реализована привязка IP к хэшу. Т.е. п 1-4 решаются штатно из коробки, при желании можно и внешний dhcp сервер приюзать.

 

П2 лежит исключительно на совести клиента. Точнее на совести того кто логику писал клиентскую.

П3 не решается впринципе в том виде как описали (без повторной аутентификации, она всегда будет везде, но где-то шустрее с использованием 802.11R или OKC, где-то медленнее) и на проблему не влияет.

 

Единственное с чем у мокротика и ubnt жопа при принудительном пересаживании клиентов, это крайне куцая логика хэндофа с всего с одним параметром (kick rrssi) потому имеем косяк с, как вы выразились, броуновским движением клиентов.

 

Это значит что при перемещении клиента по такой сети

1) происходит дисконект клиента от точки доступа ( точка доступа выбрасывает клиента при снижении сигнала RSSI ниже заданного порога)

 

Если клиент не умеет сам мигрировать (а большинство не умеют исключение интелы под виндой нормально мигрируют и в новых ведроидах 6-7 абы как но допилили поддержку роминга при -75 не дожидаясь пока АП по голове даст) не умеет то со стороны АП вы кроме как выкинуть его ничего и не сможете. Хоть нтырпрайзное хоть не интырпрайзное решение.

 

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

 

2) после дисконекта клиент начинает искать новую точку доступа ( сканит эфир),

 

Фоновое сканирование? Не не слышал? Да и RRM позволяет рассказать о топологии сети и о соседях, только клиенты кладут на это болт.

 

договаривается с точкой доступа о подключении, получает IP адрес и устанавливает связь.

 

Договаривается и подключается с полной фазой авторизации ~150мс, это именно то, что может сократить 802.11R и иже с ними. Нормальный клиент при миграции между точек с одинаковым SSID не запрашивает IP занова, IP уже есть, он шлёт запрос на продление лизы и только, он физически для DHPC сервера остался на месте и ессно получит вожделенный ответ, более того этот механизм никак не мешает передаче данных параллельно процедуре.

 

Перерыв в связи может занять 1-5 сек, что может быть терпимо ( если это происходит нечасто), но тут важно другое.

 

Может составлять, а может и не составлять и зависит это на 90% от клиента и настройки DHCP сервера. А что тут важно, так это то что кто-то трындит.

 

2.a) Если клиент после дисконекта видит несколько точек доступа -кандидатов на подключение, то он подключится к той, кто первая ему ответит согласием на подключение.

 

Да ну? Ну т.е. вы считаете что клиент никак не выбирает АП? Вот опять враньё. Именно клиент и решает куда он будет коннектиться, и это в 90% случаев будет не первая ответившая, а выбранная по уровню исходя из данных фонового или не фонового сканирования.

 

Но такая точка вполне может сразу или через некоторое время ( через несколько секунд по результату флуктуации сигнала) выбросить вновь подключенного клиента по снижению сигнала RSSI ниже заданного порога. В этом случае клиент опять начнет искать новую точку, и очень часто он может найти свою же исходную первую точку доступа, которая его уже дисконектила или другую, которая его сразу или очень скоро опять отбросит. В общем клиент ( даже без движения, например студент сидит в своей комнате) может начать метаться между точками доступа с дисконектами в 1-5 сек, что уже неприемлемо.

 

Ещё раз грю, это проблема исключительно куцей логики хэндофа у микротика. У нас например нет такой проблемы. И к ЫНТЫРПРАЙЗУ это отношения не имеет абсолютно. Это буквально несколько десяток строк кода в драйвере радио.

 

2.б) Если клиент после дисконекта видит не только свои ( с тем же SSID), но и чужие точки доступа ( где он хотя бы один раз побывал и устройство запомнило SSID), то он вполне может уйти в соседнюю сеть, отключиться от которой можно только по инициативе клиента и предварительно удалив из клиентского устройства SSID соседней сети из списка запомненных сетей.

 

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

 

Весь дальнейший бред увы нет сил коментировать, черезчур много букав. Враньё о связи хэндовер с поддержкой WPA enterprise и т.д.

 

И вообще вы похоже как "математик" и великий "теоретик" никогда не видели логику ни АП ни клиента т.е. как по факту реализуется то вокруг чего вы фантазируете.

 

Более того несёте ахинею о сетях без хэндовера рассказываете сказки о чудодейственном хэндовере заставляющем кривых клиентов без раеализации нормальной миграции с их стороны где нет вообще логики привязки к SSID при выборе AP кандидата, а выбор идёт только по уровню и есть ли данные для авторизации (насрать что там внутри WPA2 PSK или хервкрутиновый протокол). И т.д.

 

Вы может и хороший математик, и продавац (что на техническом форуме минус да ещё и правила нарушает), но слабо себе представляете о чём говорите + подменяете понятия и врёте напрополую.

 

Думаю месяцок профилактического RO вам будет полезен. Может перестаните из раза в раз свои сказки в виде портянок по теме и без пихать куда не просят.

[slv700]

Разрыв происходил и будет происходить

Коню ясно, что переход клиентами между точками доступа невозможен без разрыва соединения по радио ( РHY )от одной точки доступа и подключения по радио к другой. Речь идет именно о логическом разрыве соединения, объединяющими в себе все состояния, финальное из которых - сообщение клиенту что он подключился к такой точке доступа.

И присваивание IP адреса -это один из этапов процесса перехода, состояние разрыва соединения клиента не зависит от того какой адрес старый или новый выдал DHCP или вообще он статический или нет. При handover адрес клиенту не назначается, но если адрес не назначается ( например какой то привязкой IP клиенту), то это не значит что это handover и не означает что нет логического разрыва связи.

ЗЫ

Особенно улыбнуло привязка логина/пароля, например при wpa доступе к IP адресу.

 

Аутентификация есть всегда.

Ну хорошо, чтобы вы не цеплялись к формулировкам, приписывали мне то, что я не говорил, а потом с этим ( типа враньем) боролись, я скажу более точно:

При handover не проводится полная повторная аутентификация. Она проводится по сокращенной процедуре, в которой исключается 4 Way-handshaking , в частности при EAP - обмена ключами с Радиус сервером ( занимающей по времени от 400 мс).

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

Это может произойти только в случае логического ( полного по прохождением всем стейтов) дисконекта от точки доступа. В роуминговой сети этого никогда не произойдет независимо от логики, заложенной у клиента. Более того в 802.11r/к будет выбираться более подходящая точка доступа ( по алгоритму 802.11k) из числа точек доступа своей сети.

 

То что я изложил в 4 пунктах - это так работает на практике сеть без поддержки handover, в частности на Микротике. Кто там виноват, драйвер ли Микротика, ошибка в программе, драйвер китайского клиента- не имеет значения. Может и можно что там костылями поправить и улучшить ( что многие и пытаются сделать), но ничего этого не надо. Надо просто использовать правильное оборудование со стандартной 802.11* реализацией handover и WPA-Enterprise. Тогда это все нормально работает на практике.

 

ЗЫ

Вы сударь, программист-кулибин/самоделкин. У вас в команде разработчиков SNR есть вообще знающий предметную область руководитель проекта ( назовите его математик или архитектор или постановщик задач) , который ставит программистам задачу и направляет в нужное русло ваши буйные фантазии? Если Вы и есть тот руководитель, то результат вашего творчества в виде продукта коммерческого качества рискует никогда не быть полученным.

[sfstudio]

Коню ясно, что переход клиентами между точками доступа невозможен без разрыва соединения по радио ( РHY )от одной точки доступа и подключения по радио к другой. Речь идет именно о логическом разрыве соединения, объединяющими в себе все состояния, финальное из которых - сообщение клиенту что он подключился к такой точке доступа.

 

Это что за поток сознания?

 

И присваивание IP адреса -это один из этапов процесса перехода, состояние разрыва соединения клиента не зависит от того какой адрес старый или новый выдал DHCP или вообще он статический или нет.

 

Зависит drop state таблицы соединений на клиентах, и если адрес изменился то таблица состояний соединений на клиенте невалидна - привет реконнекту всех пользовательских приложений. Адрес остался тот же - стэйты остались на месте, приложения если не отвалились по таймауту продолжать работать, будет лишь перепосыл данных на уровне TCP или в случае с UDP на уровне приложения если это необходимо.

 

При handover адрес клиенту не назначается, но если адрес не назначается ( например какой то привязкой IP клиенту), то это не значит что это handover и не означает что нет логического разрыва связи.

 

Перестаньте изобретать собственные диалекты. Что значит логический разрыв связи? Соединения приложений не порвутся? Вот я вам рассказываю что для этого надо. Надо что бы за время миграции таймауту не истекли в таблице стэйтов, надо что бы IP оставался тот же при миграции на клиентах, надо что бы клиент не дропал просто по link beat таблицу стэйтов у себя.

 

ЗЫ

Особенно улыбнуло привязка логина/пароля, например при wpa доступе к IP адресу.

 

Сами придумали сами поулыбались. Нет никаких проблем на уровне радиуса+dhcp привязать логин с паролем к IP и запретить более одного коннекта с пары. На точках ессно будет для этого настроен 802.1x.

 

Ну хорошо, чтобы вы не цеплялись к формулировкам, приписывали мне то, что я не говорил, а потом с этим ( типа враньем) боролись, я скажу более точно:

При handover не проводится полная повторная аутентификация. Она проводится по сокращенной процедуре, в которой исключается 4 Way-handshaking , в частности при EAP - обмена ключами с Радиус сервером ( занимающей по времени от 400 мс).

 

Ну вот видите, нет радиуса - нет проблем и время миграции 150мс. С радиусом надо городить кэши и прочее. =) Хотя 802.11R позволяет ускорить и схему без радиуса точно так же сокращая процедуру (можете глянуть код если зело интересно, он у меня открыт).

 

 

Это может произойти только в случае логического ( полного по прохождением всем стейтов) дисконекта от точки доступа. В роуминговой сети этого никогда не произойдет независимо от логики, заложенной у клиента. Более того в 802.11r/к будет выбираться более подходящая точка доступа ( по алгоритму 802.11k) из числа точек доступа своей сети.

 

Что опять за бред. Какие стэйты логического дисконнекта? Вы марсианен? С какого перепуга кривой клиент будет по разному себя вести в зависимости от AP ? Не будет. А 802.11k вообще 1,5 колеки поддерживают, и даже топовые нексусы на 7мом ведроиде игнорируют репорты о соседях.

 

В сотый раз подтверждаете что всё зависит от реализации на клиенте, сами же. Насрать что там думает АП если клиент решил спрыгнуть. ТЧК.

 

Вы сударь, программист-кулибин/самоделкин.

 

А не охренели вы сударь?

 

У вас в команде разработчиков SNR есть вообще знающий предметную область руководитель проекта ( назовите его математик или архитектор или постановщик задач) , который ставит программистам задачу и направляет в нужное русло ваши буйные фантазии? Если Вы и есть тот руководитель, то результат вашего творчества в виде продукта коммерческого качества рискует никогда не быть полученным.

 

Да вы что? Давайте вы будете свои буйные фантазии на мой счёт где-нить с девочками обсуждать, а не на техническом форуме? Как и фантазии насчёт SNR?

 

Я конечно сдержусь на этот раз что бы не послать вас в пешее эротическое путешествие, но поверьте не вам рассуждать на подобные темы. Фантазёр математик-продавец да ещё и врун будет учить меня как и что делать... Цирк с конями.

[Saab95]

Опять этот бред. Всё хватит. Ну на кой чёрт вы так дискредитируете тех кто вас (судя по всему) кормит? Цирк с конями.

 

Вообще это самое простое и доступное средство, которое можно купить в любом магазине и получить пожизненное обновление прошивок.

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

[sfstudio]

Мыло тоже можно купить в любом магазине и совместимо оно будет до упора =)))

 

Какое отношение ваш высер к теме вопроса и к убогости rate_alg из-за чего вы предлагаете дублировать железо для 2х режимов OFDM N/G имеет? Впочем как и то, что какашки обычно доступны в любом магазине? Как и не уловил связи поддрежки ПО для протухшего железа с решаемой проблемой?

 

Прекращайте оффтопить. Есть по теме что сказать - welcome. Нет - пройдите мимо.

[SNR]

Уважаемые Коллеги,

 

Предлагаю Вам прекратить балаган, в противном случае последуют санкции.

 

slv700

Вам настоятельно рекомендую

1. Исключить из своих выкладок искажение инфорации о технический составляющей оборудования (а именно - приукрашивание достижений продвигаемого Вами бренда и наговор на все остальные)

2. Добавить в своих высказываниях побольше уважения к компании, форумом которой Вы бесплатно пользуетесь в собственных коммерческих интересах (я имею в виду НАГ и бренд SNR)

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

[sfstudio]

То что я изложил в 4 пунктах - это так работает на практике сеть без поддержки handover, в частности на Микротике. Кто там виноват, драйвер ли Микротика, ошибка в программе, драйвер китайского клиента- не имеет значения. Может и можно что там костылями поправить и улучшить ( что многие и пытаются сделать), но ничего этого не надо. Надо просто использовать правильное оборудование со стандартной 802.11* реализацией handover и WPA-Enterprise. Тогда это все нормально работает на практике.

 

Реальность она такая жестокая и непредсказуемая. Можно заставлять клиентов подбирать правильное энд-юзер оборудование (коего кот наплакал и цена в потолок), а можно зная как дела обстоят на практике учесть по максимуму в своей логике поведение клиентов. Тем более, что никто не запрещает использовать разную логику, для разных клиентов, что и сделано. Учитывая что вне корпоративных сетей (тема про общагу) подход с покупкой энд юзеру правильного оборудования обречён.

 

Что бы всё это работало нормально на практике, wifi альянс должен приять волевое решение и при сертификации требовать поддержки всего что заложенно в стандарт и именно так как заложенно, при этом гарантируя совместимость реализаций. На практике этого никогда не происходит. Кроме совсем базовых вещей (тех что вообще требуются для передачи данных включая шифрование, а всё остальное уж как повезёт и что и кто и как реализует, встречаются клиенты которые даже SGI не умеют, не то что какие-то плюшки).

[slv700]

Уважаемые Коллеги,

 

Предлагаю Вам прекратить балаган, в противном случае последуют санкции.

 

slv700

Вам настоятельно рекомендую

1. Исключить из своих выкладок искажение инфорации о технический составляющей оборудования (а именно - приукрашивание достижений продвигаемого Вами бренда и наговор на все остальные)

2. Добавить в своих высказываниях побольше уважения к компании, форумом которой Вы бесплатно пользуетесь в собственных коммерческих интересах (я имею в виду НАГ и бренд SNR)

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

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

Будучи сам руководителем известного ( в узких кругах :-) и коммерчески успешного проекта по разработке и отечественному производству устройств ШБД искренне желаю разработчикам SNR успеха и удачи!

Буду рад, если мои замечания по работе вайфай ( я лично работаю в этой теме с 1997 года) будут полезны вам и другим людям.

[sfstudio]

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

 

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

 

Я хоть и миролюбивый человек, но...

 

P.S. Если вы у нас такой великий руководитель - welcome работать на моё место. Думаю NAG ради процветания проекта обязательно вас наймёт. =))

 

Буду рад, если мои замечания по работе вайфай будут полезны вам и другим людям.

 

Нет у вас никаких замечаний. Кроме того что нашли багу с rate_alg в микротике, о которой (судя по желанию Сааба налепить по 2 девайса для G/N вместо одного) давно известно.

 

И глаза вы никому не раскрыли рассказав что микротик не умеет ничего из WPA кроме PSK.

 

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

[Negator]

Мы давно и успешно работаем в общагах. правда покрупнее.

Wi-Fi предоставлять не собираемся, смысла нет.

Основная проблема общажников - раздача интернета с одного аккаунта на весь блок(что еще неплохо), а то и на несколько вокруг.

Вам нужно

1. Договориться с администрацией общежития, возможно найти одного двух работников которые будут работать за бесплатный интернет.

Основная их работа - подключения и проверка левых кабелей в соседние комнаты.

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

 

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