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

Начнем с того, что к нам обратился Заказчик с проблемами в сети Wi-Fi, которые можно сформулировать следующим образом:

• прерывания в работе считывающих терминалов, при быстром перемещении время прерываний может достигать нескольких секунд;

• не полное покрытие БЛВС территории объекта;

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

В качестве точек доступа на объекте используются офисные точки доступа ExtremeWireless™ WiNG AP 7532 802.11ac Access Point:

В качестве контроллера ExtremeWireless™ WiNG RFS 4000, текущая версия ПО - 5.9.6.0-007R.

В качестве пользовательских устройств (далее по тексту терминалов) в основном используются Mobile Computer CK3X на Windows Mobile W23.1.6.003, причем подключаются к системе обработки данных терминалы посредством telnet, поверх которого передаются данные.

Терминалы аутентифицируются по MAC адресу, получают адреса по DHCP и "проваливаются" в локальный порт коммутатора в соответствующий VLAN. Не знаю как у вас, но у нас сразу возникли подозрения на возможный mac-address flapping при активном перемещении терминала по территории склада. Стоит отметить, что терминалы перемещаются на погрузчиках, которые временами довольно сильно разгоняются.

По результатам разведки покрытие оказалось в норме, за редким исключением:

Канальная интерференция в диапазоне 2.4 ГГц ожидаемо высокая, а в диапазоне 5ГГц нас поджидал сюрприз, все точки работали на 36 канале:

Или более наглядно:

Ну думаем ясно, причина прерываний налицо и уже представляем себе как будем ее решать. Но это потом, а пока посмотрим, как же ведет себя терминал при перемещении между точками доступа. Для начала посмотрим, что же "умеет" Extreem в "роуминг"?

Пересказывая своими словами мануал получается, что переключением терминалов между точками доступа управляет функция Extreame Roaming Assist, которая "умеет" управлять роумингом двумя способами:

• Legacy Roaming Assistance, который применяется для устройств, не поддерживающих стандарты IEEE 802.11 k/v/r (наш случай). Данная функция дает команду точке доступа отправить в адрес терминала специальный фрейм de-auth, прерывая таким образом соединение. Тем самым сеть как бы подталкивает терминал к выбору точки доступа с лучшим уровнем сигнала путем повторной ассоциации;

• Assisted Roam, вместо отправки фрейма de-auth предлагает выполнить переключение на точку доступа с лучшим уровнем сигнала в рамках реализации стандарта 802.11v. При этом терминалу предоставляется список возможных точек доступа (список точек доступа-кандидатов создается на основе стандарта 802.11k). В зависимости от настроек беспроводного интерфейса терминала, доступно 3 варианта поведения:

  • принять предложение, выбрать точку доступа из списка и ассоциироваться с ней;

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

  • отклонить запрос, действовать на свое усмотрение.

Также контроллер поддерживает функцию Fast Transition в рамках стандарта IEEE 802.11r, позволяющую ускорить процедуру аутентификации. Fast Transition может использоваться при переключении терминала с одной точки доступа на другую в рамках одной сети, при этом поддерживаются оба метода аутентификации: PSK и 802.1Х. Ускорение осуществляется за счет сохранения ключей шифрования на всех точках доступа, то есть терминалу не требуется при роуминге проходить полную процедуру аутентификации.

Для понимания процедуры роуминга рассмотрим выдержки из дампов, терминал перемещается из точки А в точку Б, красной стрелкой указано направление перемещения

В 11:50:02.786 терминал запрашивает аутентификацию у точки Б rx auth-req from 00-10-40-C6-40-72 on radio 0, в 11:50:02.787 точка отвечает auth-rsp to 00-10-40-C6-40-72 on radio 0. status: success.

В 11:50:02.789 точка А понимает, что запустилась процедура роуминга и выдает сообщение WNMP Roam from our MU 00-10-40-C6-40-72.

В 11:50:02.790 на точку Б прилетает запрос rx re-association-req from 00-10-40-C6-40-72 on radio 0 signal-strength is -48dBm, в 11:50:02.791 точка Б отвечает терминалу tx association-rsp success to 00-10-40-C6-40-72 on wlan (wlan5) (ssid:test) with ftie 0, и в 11:50:02.791, рапортует wireless client 00-10-40-C6-40-72 changing state from [Init] to [MAC Auth].

В 11:50:02.793 точка А сообщает об изменении статуса терминала wireless client 00-10-40-C6-40-72 changing state from [Data-Ready] to [Roaming], и практически сразу в 11:50:02.796, точка Б рапортует об изменении статуса wireless client 00-10-40-C6-40-72 changing state from [MAC Auth] to [Data-Ready].

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

Проблема

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

Итак, терминал ассоциирован с точкой А, в 11:57:45.158 терминал принимает решение на ассоциацию с точкой О, установленной на 2 этаже в офисных помещениях, с RSSI = -78dBm:

11:57:45.158: tx auth-rsp to 00-10-40-C6-40-72 on radio 0. status: success
11:57:45.187: rx association-req from 00-10-40-C6-40-72 on radio 0 signal-strength is -78dBm
11:57:45.187: assigning wireless client 00-10-40-C6-40-72 to vlan 11
11:57:45.187: tx association-rsp success to 00-10-40-C6-40-72 on wlan (wlan5) (ssid:test)
1:57:45.187: wireless client 00-10-40-C6-40-72 changing state from [Init] to [MAC Auth] 11:57:45.194: wireless client 00-10-40-C6-40-72 changing state from [MAC Auth] to [Data-Ready]

Стоит отметить, что у решения от Extreme имеются механизмы, ограничивающие ассоциацию терминалов с низким RSSI путем настройки assoc-response, однако на момент тестирования они отключены. Логика работы механизма заключается в отбрасывании запросов, приходящих от терминала с RSSI ниже assoc-response rssi-threshold (задается от -40 до -100). Количество отброшенных запросов регулируется параметром no assoc-response deny-threshold (задается от 1 до 12).

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

Далее терминал пытается взаимодействовать с сетью на низких модуляциях и примерно через 10 секунд мучений принимает решение ассоциироваться со следующей точкой доступа B, опять же на крайне низком RSSI = -76dBm:

11:57:55.304: rx re-association-req from 00-10-40-C6-40-72 on radio 0 signal-strength is -76dBm
11:57:55.308: tx association-rsp success to 00-10-40-C6-40-72 on wlan (wlan5) (ssid:test)
11:57:55.311: wireless client 00-10-40-C6-40-72 changing state from [Init] to [MAC Auth] 11:57:55.336: wireless client 00-10-40-C6-40-72 changing state from [MAC Auth] to [Data-Ready]

Еще пару секунд терминал предпринимает ассоциацию со следующей точкой доступа Г, на этот раз выбор точки доступа еще более неудачен RSSI = -80dBm:

11:57:57.793: rx re-association-req from 00-10-40-C6-40-72 on radio 0 signal-strength is -80dBm
11:57:57.796: tx association-rsp success to 00-10-40-C6-40-72 on wlan (wlan5) (ssid:test)
11:57:57.799: wireless client 00-10-40-C6-40-72 changing state from [Init] to [MAC Auth]
11:57:57.806: wireless client 00-10-40-C6-40-72 changing state from [MAC Auth] to [Data-Ready]

В 11:58:14.662 срабатывает функция Roaming-assist, отправляя фрейм deauth от имени точки Г:

11:58:14.662: tx deauthentication [Roaming-assist forced deauth (code:1)] to 00-10-40-C6-40-72
11:58:14.662: wireless client 00-10-40-C6-40-72 changing state from [Data-Ready] to [Roaming]

После чего контроллер игнорирует пакеты от терминала тем самым подталкивая его к поиску новой точки доступа:

11:58:15.201: ignoring 802.3 data frame from 00-10-40-C6-40-72 wlan_idx:0, radio:0x147eda
11:58:15.217: ignoring 802.3 frame of unexpected eth_type 0x5500 from client 00-10-40-C6-40-72
11:58:15.250: ignoring 802.3 data frame from 00-10-40-C6-40-72: (wlan_idx:0, radio:0x147eda
11:58:15.251: ignoring 802.3 data frame from 00-10-40-C6-40-72: (wlan_idx:0, radio:0x147eda
11:58:15.251: ignoring 802.3 data frame from 00-10-40-C6-40-72: (wlan_idx:0, radio:0x147eda

После такого "жесткого обращения" терминал "внезапно осознает", что рядом есть точка доступа с "нормальным" уровнем -47dBm и подключается к ней:

11:58:15.200: rx association-req from 00-10-40-C6-40-72 on radio 0 signal-strength is -47dBm
11:58:15.200: tx association-rsp success to 00-10-40-C6-40-72 on wlan (wlan5) (ssid:test)
11:58:15.248: wireless client 00-10-40-C6-40-72 changing state from [MAC Auth] to [Data-Ready]

Таким образом около 30 секунд в период между 11:57:45.158 - 11:58:15.248 терминал "кушает кактусы" теряет пакеты и продолжает "кушать кактусы".

Фильтруем дамп по сообщениям ассоциации видим неутешительную картину, терминал предпочитает подключаться к интерфейсам точек radio 0 диапазона 2.4 ГГц с низким RSSI:

11:50:02.790: mgmt:rx re-association-reqon radio 0 signal-strength is -48dBm
11:51:05.645: mgmt:rx re-association-reqon radio 0 signal-strength is -61dBm
11:53:50.404: mgmt:rx re-association-reqon radio 0 signal-strength is -45dBm
11:54:31.164: mgmt:rx re-association-reqon radio 0 signal-strength is -67dBm
11:54:36.562: mgmt:rx re-association-reqon radio 0 signal-strength is -84dBm
11:57:45.187: mgmt:rx association-reqon radio 0 signal-strength is -78dBm
11:57:55.304: mgmt:rx re-association-reqon radio 0 signal-strength is -76dBm
11:57:57.793: mgmt:rx re-association-reqon radio 0 signal-strength is -80dBm
11:58:15.200: mgmt:rx association-reqon radio 0 signal-strength is -47dBm
11:58:21.564: mgmt:rx re-association-reqon radio 0 signal-strength is -82dBm
11:58:21.575: mgmt:rx re-association-reqon radio 0 signal-strength is -82dBm
11:58:23.999: mgmt:rx re-association-reqon radio 0 signal-strength is -85dBm
11:58:24.46: mgmt:rx re-association-reqon radio 0 signal-strength is -87dBm
11:58:25.850: mgmt:rx re-association-reqon radio 0 signal-strength is -78dBm
11:58:26.926: mgmt:rx re-association-reqon radio 0 signal-strength is -72dBm
11:58:57.18: mgmt:rx association-reqon radio 0 signal-strength is -73dBm
11:59:19.758: mgmt:rx association-reqon radio 0 signal-strength is -73dBm
12:00:03.967: mgmt:rx re-association-reqon radio 0 signal-strength is -65dBm
12:00:37.73: mgmt:rx association-reqon radio 0 signal-strength is -77dBm
12:00:48.226: mgmt:rx re-association-reqon radio 0 signal-strength is -68dBm

Попытка решения проблемы путем оптимизации терминала

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

12:17:34.302: mgmt:rx re-association-req on radio 1 signal-strength is -53dBm
12:17:53.276: mgmt:rx re-association-reqon radio 1 signal-strength is -64dBm
12:18:21.704: mgmt:rx re-association-reqon radio 1 signal-strength is -61dBm
12:19:02.359: mgmt:rx re-association-reqon radio 1 signal-strength is -66dBm
12:19:09.512: mgmt:rx re-association-reqon radio 1 signal-strength is -66dBm
12:19:27.287: mgmt:rx re-association-reqon radio 1 signal-strength is -70dBm
12:20:05.132: mgmt:rx re-association-reqon radio 1 signal-strength is -52dBm
12:20:58.205: mgmt:rx re-association-reqon radio 1 signal-strength is -55dBm
12:21:31.387: mgmt:rx re-association-reqon radio 0 signal-strength is -42dBm
12:21:39.654: mgmt:rx re-association-reqon radio 0 signal-strength is -53dBm

Терминал стал подключаться к интерфейсам radio 1 диапазона 5 ГГц, а также значительно более удачно стал выбирать точки доступа для ассоциации.

Просим Заказчика накатить патч на оставшиеся терминалы и уходим разрабатывать радиоплан и рекомендации ...

Радиоплан и рекомендации

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

Разработан и имплементирован частотно-территориальный план:

Это позволило уменьшить канальную интерференцию:

Так же Заказчику рекомендовали в реестре терминала внести следующие правки:

HKEY_LOCAL_MACHINE\Comm\TIWLN1\Parms (radio driver path)
“DynamicScanThreshold”=”0”; # отключение динамического роуминга
“RoamLowRssiThreshold”=”-70”; # установка порога переключения
“RoamRssiDeltaThreshold”=”7”; # установка дельты порога

Со стороны беспроводной сети Заказчик по нашей рекомендации установил пограничные параметры roam-assist:

roaming-assist-policy RASST
detection-threshold -65
handoff-threshold -72

Рекомендацию завернуть трафик в туннель и тем самым исключить вероятность mac-address flapping Заказчик не успел выполнить.

Однако несмотря на оптимизацию сети потери пакетов и обрывы продолжаются. Выезжаем на объект, включаем дамп, садимся на погрузчик смотрим что происходит:

Если сравнить с предыдущей картинкой видно, что "длинных пингов стало меньше" (фиолетовые вертикальные черты), среднее время отклика снизилось с 16 до 2, по ощущениям, переключение стало более плавным. Однако за время поездки потерялось 15 пакетов, при том, что терминал успел передать 736 пакетов.

Между 3 и 4 шагом терминал проехал мимо 4 точек доступа, не попытавшись ассоциироваться.

При этом на коммутаторах доступа, к которым подключены точки доступа, фиксируются следующие сообщения:

[37]:MAC address flapping started on port. The rate of unknown unicast packets was limited to 50% of the port bandwidth.(Interface=GigabitEthernet0/0/25)
[38]:MAC address flapping started on port. The rate of unknown unicast packets was limited to 50% of the port bandwidth.(Interface=GigabitEthernet0/0/6)
[39]:MAC address flapping started on port. The rate of unknown unicast packets was limited to 50% of the port bandwidth.(Interface=GigabitEthernet0/0/2)

Включаем туннелирование трафика, получаем:

Сообщения о MAC address flapping ожидаемо ушли, при этом по ощущениям переключения стали происходить еще быстрее. За аналогичное время поездки терминал успел передать 2094 пакета и потерять по таймауту 6 пакетов.

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

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