Comments 22
Когда вы говорите, что терминал "делает вид", что не видит точку доступа, видит ли он её на самом деле, в смысле - успевает ли он получить от неё beacon frame?
Хороший вопрос) ... на данный момент могу с уверенность сказать, что измерительный комплект точно видит беконы от соседних точек. Успевает ли их увидеть терминал не могу точно сказать, судя по поведению вероятность того что не видит довольно велика. Предлагаете почаще рассылать беконы?
Я давно не работаю в "чистом" IT, работаю в области автоматизированного производства. И когда я только сменил область, очень быстро врубился, что конкретное оборудование ведет себя часто не совсем так или совсем не так, как модельные инструменты. А в случае enterprise WiFi, там есть сотни факторов, которые влияют на поведение.
Так что в конкретном случае (если есть возможность) было бы интереснее узнать, что именно видит терминал. Но если это невозможно, то да, экспериментировать на крайних значениях настроек или в намеренно узких условиях. Например, повысить частоту beacon frame очень сильно. Выяснить, на сколько терминалы вообще способны на band steering (он у вас используется?).
Кладовщики постоянно ездят на погрузчиках? Если так, то - в порядке бреда - можно повесить на погрузчик что-нибудь более приличное, чем windows mobile (не к ночи будь помянут) с поддержкой 802.11[k/v/r/нужное дописать] в режиме client+bridge, а уже к приличному клиенту прикрутить что угодно (TP-Link TL-MR3020) в режиме AP с другим SSID, к которому и будет цепляться ТСД, далеко от погрузчика, соответственно, уходить не стоит. :)
Если кладовщики ходят пешком, то такой вариант, конечно, им не понравится...
Мысль интересная, но в целом то к скорости переключения вопросов нет. Странный выбор точек для ассоциации - вот проблема...
Можно даже по eth/usb прикрутить раз погрузчик и там по идее толстый планшет же
У нас смена оборудования на Android сделало работу WiFi чудным образом идеальным. Любые комбинации настроек точек доступа и оборудования на Windows не давали такого эффекта.
Поменять интегратора
Поменять всех кто разрабатывал этот проект
Продать железо и купить на авито бушку «нормальную»
Я бы так сделал
Видимо придется так и сделать, какую "бушку" посоветуете?
Не знаю, что за "бушка" (б/у?), но сам проект действительно фиговенький. Сканер штрих-кодов - это, по всей видимости, терминал сбора данных, а не сканер, т.к. сканеру сеть не нужна. На терминале приличные люди андройд юзают, а не говно мамонта в виде венды. И приличное приложение не должно постоянно гонять в сеть за данными, т.к. даже очень большой склад будет содержать ну пусть даже 1кк позиций, что при умножении на 12 символов ЕАН13 (да, последний символ там нахрен не сдался) занимает смешные 12 мегабайт, а сжатый пакет и того меньше. Т.е. время синхронизации прилично написанного приложения даже на тормозной 1С с ее багами и глюками не должно быть больше двух секунд, даже если обленившийся программист-алкаш так и не научился работать с сжатием данных. А если научился - и того меньше.
Тут нужен аргумент. Для Заказчика нужен аргумент чтобы всё и вся менять, имею ввиду.
В идеале, Вам бы взять пару этих Windows Mobile терминалов и попробовать воспроизвести ситуацию в схожих условиях, но на другом сетевом оборудовании. Ubiquiti, например.
Если на "другом Wi-Fi" всё будет работать как надо, тогда имеет некоторый смысл продолжить ковыряться с текущим или же, наоборот, донести проблему до Заказчика, мол, смотрите, а на другом сетевом оборудовании всё ок. Пусть дальше думает.
Либо, если и в тестовой среде не будет работать как положено, ну значит всё, можно и не мучаться дальше. WinMobile -> легаси -> в ведро.
БУ - известного всем бренда )) не буду рекламировать
Ну, периодически ловили всякое подобное.. лечится - да, в идеале отпилом нафиг 2.4, а в 5 - ручной настройкой мощности точек в сторону уменьшения (при необходимости с увеличением их количества), а так же вопросом геометрии покрытия , чтоб избежать интересного хода волны (вместо всенаправленных точек вешать направленные/секторальные). Чтобы перекрытие было минимальным и клиент вовсе не видел лишнего - на складах, особенно с металлической мебелью и стеклом, волны порой довольно причудливо себя ведут. За вендора ваших точек ничего не скажу (не знаю), но ловили подобное и на цисках с юнифаями.
И присоединюсь к ораторам выше - пойти в проект поглубже, оптимизировать бизнес-процессы/по чтоб потеря нескольких пакетов не мешала работе. Если конечно есть возможность. Встречалась схема работы вида - ребята подъезжают на зону разгрузки с оператором, там вайфай ловит :) получают сборочный лист на терминал - и погнали. Так склад без покрытия вафая
Здесь тоже оставили только 5 ку, выставили можности и частоты в соответствии с разработанным планом, получили отсутствие проблем с покрытием, с плавностью переключения тоже разобрались, осталась проблема неочевидного выбора терминалом точек для ассоциации. Терминал ассоциируется с удаленными точками доступа на низких rssi при наличии рядом работающих точек доступа.
Я у вас везде на тепловых картах вижу "as measured"
Надеюсь, вы измеряли Сайдкиком, верно?
Делали ли вы измерение поправки на ваш чудо-терминал Mobile Computer CK3X?
Если не делали, то берете одну точку на складе, поднимаете на ней отдельный SSID, ставите рабочую мощность и прогоняете по всем каналам от 36 до 165. Результаты - в таблицу, потом - offset в карту, и думаете...
Возможно, это вас весьма удивит. Картина сети как её видит Sidekick сильно отличается от того, как видит конкретное устройство. Ниже пример, для приличной Зебры поправка средняя -4дБ, а для менее приличного BlackView - 10дБ, а на верхней 5ке уже -14 может быть, а если взять канал 157, то 18дБ разницы.. Смекаете, к чему это ведёт? Кстати, некоторые каналы устройство вообще может не видеть, а вы думаете, почему оно так странно роумится...
На тот момент Сайдкика еще не было, измеряли Comfast CF-912 тот который на реалтековском чипе 8810 если память не изменяет ...
В расчетах использовали калибровочные коэффициенты, которые для нашего чудо терминала (по результатам измерений) составило в 2.4ГГц 0-2дБ, для 5ГГц 5-7дБ в зависимости от частотного канала. Отсюда и диаграммы в статье по уровню -65дБм для 2.4ГГц, -60дБм для 5ГГц.
Разница в 18 дБ конечно впечатляет, но по моему дело всё-таки не в покрытии...Терминал же в итоге цепляется к правильной точке, но перед этим почему-то блуждает по удаленным точкам по замысловатым маршрутам.
Есть мнение, подтвердить которое на данный момент не успел, что терминал не имеет право рассылать probe на DFS каналах и вынужден ждать beacon от точки. Если это так, то вполне вероятно в определенные моменты времени терминал вынужденно засылает probe на разрешенных каналах и ассоциируется с удаленными точками. Что скажете?
Если это так, то можно попытаться сократить время рассылки беконов со 100 до 10мс + в реестре терминала установить "SmeAssocMinRssi"=”-75” тем самым запретив ассоциацию с точками с rssi ниже -75дБм. Как думаете верный путь? Или проще сделать радиоплан без DFS каналов и посмотреть что получится?
Из занимательного, наша версия софта от Extreme (Zebra - Motorola) также не поддерживает 144 канал, видимо это тяжкий удел Зёбры)
я бы не очень доверял обследованию сделанному на комфасте. но, если нет ничего лучшего, то работать можно.
Понял. На всех каналах то замер делали?
Очень сомневаюсь что клиент ждет бикон от точки, и не может послать проб на DFS канале. Если можете подтвердить ссылкой - прошу привести её.
100 биконов в секунду даст ощутимую пассивную нагрузку на сеть, не делайте так никогда. стандартный интервал это хорошо.
Покрутить реестр можно, но нужно глубже понять логику роуминга клиента. Выпишите в таблицу последовательность роуминга по каналам, с какого на какой скачет. Или на тех картах, где вы стрелочки рисуете - каналы покажите.
144 канал многие не любят, он в зоне риска и включается дважды подумавши.
Что я вижу на последней картинке в статье с переключениями терминала в 5 ГГц:
После шага 4 лучший кандидат для ТСД — канал в DFS-диапазоне (60), ТСД выбирает точку с уровнем хуже, но без DFS (40);
Все окружающие ТД — тоже в DFS, поэтому клиент висит до последнего, дожидается, наконец, точку на канале 44 и шестым шагом цепляется к ней;
В нижней части плана пока я не понял поведение клиента, если честно. Но в качестве рабочих гипотез предложил бы следующее:
Исключить каналы DFS (52-144 включительно) из ЧТП. Да, повысит уровень соканальных помех, но я не верю, что у вас одна ТСД жрёт постоянно 50+ мегабит;
Проверить, работает ли 11k в обеих ипостасях должным образом (то есть, в биконах есть репорты, и если клиент просит список соседей — он его получает ненулевым).
Проблемы роуминга сканеров штрих-кодов в Wi-Fi сети на территории склада