Каталог Поиск 0 Сравнить 0 Закладки 0 Корзина Войти
Каталог
105082, Москва, ул. Фридриха Энгельса, 75с21, БЦ Бауманский ИТКОЛ
Пн - Пт: с 09-00 до 18-00 Сб: с 10-00 до 18-00 Вс: выходной
Страницы: 1
RSS
Андроид-устройства отдают предпочтение 2.4Ghz вместо 5Ghz - и очень медленный 2.4Ghz., UniFi Network
 
Привет,

У нас в офисе в Великобритании open space, примерно 100 метров в длину и 30 метров в ширину. Внутри этого офиса мы предоставляем Wi-Fi примерно 190 устройствам и испытываем серьёзные проблемы с тех пор, как на прошлой неделе перешли с Cisco на Unifi.

1. Многие устройства не подключаются к нашей 5Ghz сети. Даже некоторые новые устройства, например, Nexus 5 (или Macbook Pro, если уж на то пошло), находящиеся в нескольких дюймах от AP, иногда не подключаются к 5Ghz и предпочитают 2.4Ghz.
2. Устройства, подключающиеся к 2.4Ghz сети, часто очень медленные, и иногда теряют так много пакетов, что невозможно даже провести speed test. Так что иногда 2.4Ghz сеть становится нерабочей, но только для некоторых устройств, и проблема, похоже, затрагивает все AP в какой-то момент.

Вот наша конфигурация:
1 x контроллер, работающий на версии 2.4.6 с 9 подключёнными AP. AP - это все новые WAPs AUP-AC, подключённые по одному ethernet кабелю в один HP POE коммутатор со скоростью 1Gb. Мы используем 1 SSID для обеих 2.4Ghz и 5Ghz сетей.

Мы начали с 4 AP меньшего количества, но обнаружили, что когда AP достигают 50+ клиентов, ВСЕ клиенты (на 5 или 2.4) получают ужасную производительность. Поэтому мы добавили ещё несколько AP и установили лимит в 30 клиентов на AP.

Мы начали использовать AUTO настройки для tx power и AUTO channel id для обеих 2.4Ghz и 5Ghz диапазонов и получили ужасную производительность от многих устройств, подключающихся к 2.4Ghz сети (в основном телефоны). В этом случае устройства почти никогда не переключались между AP, независимо от того, где вы ходили по офису. Поэтому мы попробовали вручную установить Channel ID и TX power для 2.4Ghz сети – смотри вложения – *последнее число в метке WAP - это Channel ID для 2.4Ghz*. TX Power для 2.4Ghz сети для большинства AP была установлена в 1dBm, чтобы попытаться уменьшить шум и помехи и помочь устройствам переключаться между AP. Изменение TX power и Channel ID действительно помогло устройствам переключаться, но, похоже, не решило саму проблему сверхмедленной 2.4Ghz производительности.

В течение всего этого, производительность на 5Ghz безупречна.

Поэтому я и спрашиваю:
- Стоит ли мне настраивать 5Ghz сеть по-другому, чтобы больше устройств подключались к ней?
- И есть ли что-то фундаментально не так с моей 2.4Ghz сетью, из-за чего она такая медленная?

Любая помощь ОЧЕНЬ приветствуется, так как я действительно хочу избежать отката к оборудованию Cisco!

Многое спасибо.
 
Прежде чем откатывать изменения, попробуйте сбросить настройки одного из устройств к заводским и посмотрите, решит ли это проблему с перезагрузками. Если да, то сделайте то же самое с остальными.
 
К сожалению, версия 3.1.10 оказалась для меня полным провалом. Мои UAP ACs начали перезагружаться случайным образом и очень часто. С каждым днем становилось все хуже и хуже, пока сегодня AP-шники не начали перезагружаться через несколько минут, потом один за другим. Сейчас пытаюсь откатиться на 3.1.9 🙁
 
Привет! Давно не обновлял, и много работал с поддержкой UniFi, поэтому решил поделиться с комьюнити тем, что у меня пока получилось.

1. Я вручную настроил все идентификаторы каналов на всех точках доступа как для 2, так и для 5 ГГц. Начал с того, что выключил все точки доступа и запустил inSSIDer на ноутбуке, чтобы найти каналы с наименьшими помехами в каждом месте, где я планировал установить точку доступа. Это помогло, потому что автоматические настройки не работают особенно умно в плане идентификаторов каналов, и была перекрытия каналов.

2. Я убрал 4 из 11 установленных точек доступа. Оказалось, что 7 точек доступа с более чем 50 клиентами, подключенными к каждой, обеспечивают гораздо лучший сервис, чем 11 точек с примерно 30 клиентами каждая. У нас плотная среда, и, видимо, дополнительные точки доступа создавали больше помех, чем решали проблемы с пропускной способностью. В этом случае "меньше - лучше".

3. Я вручную установил мощность передачи (TX power) на каждой точке доступа на минимально возможное значение. Это минимизирует помехи между точками доступа и помогает клиентам "забывать" точки доступа по мере перемещения по офису, что улучшает роуминг. У большинства моих точек доступа в поле TX custom установлено значение 3 dBm. Карта покрытия неточна, так что даже не используйте её как ориентир. Установите мощность передачи и посмотрите в inSSIDer, чтобы увидеть, можно ли увидеть точку доступа с разумным RSSI (у меня прыгает между -40 и -60). Снижайте мощность настолько, насколько это возможно.

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

5. Некоторые клиенты, похоже, просто предпочитают 2,4-ГГц диапазон, поэтому я создал 5-ГГц только сеть для этих клиентов. Но в целом это для меня уже не проблема, так как 2,4-ГГц диапазон теперь работает так же хорошо, как и 5-ГГц для большинства операций. Оглядываясь назад, я бы предпочёл сделать свою основную сеть 5-ГГц только и создать отдельную 2,4-ГГц сеть для небольшого количества клиентов, которые не поддерживают 5 ГГц. Я вручную установил своё шифрование на WPA2 Только с AES CCMP только. Видимо, некоторые клиенты не любят иметь возможность выбора. У меня ещё не было клиента, который не поддерживает этот тип безопасности.

6. Некоторые другие вещи, с которыми у меня были смешанные успехи, — это отключить WMM на всех точках доступа и отключить фильтр mcast. Вам придётся это изучить, но это включает в себя редактирование файлов конфигурации:
config.mcast_filter_enabled=false
wireless.X.wmm=disabled
Лучше сначала поговорить со службой поддержки, прежде чем редактировать файлы system.properties, но это определенно вариант, если вам это нужно.

7. Итак, пройдя через все эти шаги, я превратил свою Wi-Fi сеть почти нерабочей до состояния, находящегося в паре шагов от стабильности. Сейчас я вижу, что несколько клиентов в день отключаются случайным образом, и AirPlay зеркалирование экрана на Apple TV несколько раз в день тоже отключается. Пакеты, отправляемые с Wi-Fi устройств, теряются примерно на 0,2% при пинге точки доступа, к которой они подключены.

Я теперь надеюсь, что бета-версия 3.1.10 (установленная прошлой ночью) решит мои проблемы с Apple TV и случайными отключениями, так как changelog показывает некоторые хорошие исправления. И я не уверен, что потерю 0,2% пакетов по Wi-Fi стоит дальше расследовать. Это ведь Wi-Fi!
 
Привет, Мэтт!

Это Ubuntu 12.04.4 LTS.

Пришлось пересоздать контроллер с нуля, чтобы обойти эту проблему. Как оказалось, это не так уж и сложно. Развернул Ubuntu VM, с тем же именем и IP, что и у старого контроллера. Установил 3.1.10 через Apt-get и восстановил конфиг из бэкапа. Контроллер теперь стабилен.
 
На какой операционной системе ты используешь контроллер? Я посмотрел в обсуждении, но не нашел этой информации.
 
Готовлюсь к очередному хаосу версии 3.1.10, к сожалению. Обновился прошлой ночью, и вроде бы всё было в порядке, пока сегодня контроллер стал недоступен через веб-интерфейс. Перезагрузка не помогла, пришлось копать глубже и наткнуться на эту ошибку при запуске службы UniFi: <UniFi> ERROR system - [exec] error, rc=255, output=Port 8080 not available. Проверил файл system.properties и обнаружил, что все нижеперечисленные строки были закомментированы:
# unifi.http.port=8080 # device inform
# unifi.https.port=8443 # controller UI / API
# portal.http.port=8880 # portal redirect port for HTTP
# portal.https.port=8843 # portal redirect port for HTTPs
# unifi.db.port=27117 # local-bound port for DB server
Убрал комментарии и перезагрузил контроллер, после чего веб-интерфейс вернулся, но при этом закомментированные разделы как будто бы остались, а потом были добавлены в конец файла. Теперь system.properties выглядит так:
## system.properties
## each unifi instance requires a set of ports:
## unifi.http.port=8080 # device inform
## unifi.https.port=8443 # controller UI / API
## portal.http.port=8880 # portal redirect port for HTTP
## portal.https.port=8843 # portal redirect port for HTTPs
## unifi.db.port=27117 # local-bound port for DB server
## system_ip=a.b.c.d # the IP devices should be talking to for inform
## unifi.db.nojournal=false # disable mongodb journaling
## unifi.db.extraargs # extra mongod args
##
##Wed Mar 19 12:12:48 UTC 2014
debug.device=warndebug.mgmt=warndebug.system=warnis_default=falseportal.http.port=8880 # portal redirect port for HTTPportal.https.port=8843 # portal redirect port for HTTPsunifi.db.port=27117 # local-bound port for DB serverunifi.http.port=8080 # device informunifi.https.port=8443 # controller UI / APIuuid=a3bace2e-5832-40e2-ad82-b7083bb60e1c
Теперь контроллер работает снова, но в server.log вижу кучу таких записей:
[2014-03-19 11:01:52,347] <ssh> WARN event - [event] AP[dc:9f:db:b0:62:8f] was automatically readopted
[2014-03-19 11:01:52,361] <ssh> WARN event - [event] AP[24:a4:3c:10:37:aa] was automatically readopted
[2014-03-19 11:01:52,883] <ssh> WARN event - [event] AP[24:a4:3c:50:06:2f] was automatically readopted
[2014-03-19 11:01:53,037] <ssh> WARN event - [event] AP[24:a4:3c:10:37:98] was automatically readopted
[2014-03-19 11:01:55,145] <ssh> WARN event - [event] AP[24:a4:3c:10:37:62] was automatically readopted
[2014-03-19 11:01:58,195] <ssh> WARN event - [event] AP[24:a4:3c:50:05:fe] was automatically readopted
[2014-03-19 12:05:57,599] <ssh> WARN event - [event] AP[24:a4:3c:50:05:fe] was automatically readopted
[2014-03-19 12:05:59,181] <ssh> WARN event - [event] AP[dc:9f:db:b0:62:8f] was automatically readopted
[2014-03-19 12:06:00,868] <ssh> WARN event - [event] AP[24:a4:3c:10:37:aa] was automatically readopted
[2014-03-19 12:06:02,556] <ssh> WARN event - [event] AP[24:a4:3c:10:37:62] was automatically readopted
[2014-03-19 12:06:02,739] <ssh> WARN event - [event] AP[24:a4:3c:50:06:2f] was automatically readopted
[2014-03-19 12:06:02,869] <ssh> WARN event - [event] AP[24:a4:3c:10:37:68] was automatically readopted

Конфигурация контроллера как-то испортилась ночью, и AP-шки случайно переподключаются. Это меня очень беспокоит.
 
Как и говорил раньше, обновление до версии 3.1.10 оказалось полным провалом, и мои точки доступа начали перезагружаться циклически, причем без видимой причины. В логах не было ни намека на то, почему точки доступа перезагружаются, но это происходило постоянно и выводило всю Wi-Fi сеть из строя на то время, пока я не откатился обратно к версии 3.1.9. Мне сказали, что мне нужно обновить систему до 3.1.10 еще раз, но на этот раз нужно сбросить точки доступа к заводским настройкам, а затем обновить их до версии 3.1.10. Я попробовал этот подход в лабораторной среде, и он оказался довольно успешным (хотя и без нагрузки), так что завтра вечером собираюсь попробовать сделать так в рабочей среде и посмотрим, что получится.
 
@johnJ

Ты получил доступ к бета-тестированию.
 
Привет, ребята!

Да, могу запустить в тестовой среде (и запускаю). Но мне нужен бета-инсталлятор для 3.1.10. Пока что я качаю его из репозитория на своем Linux-контроллере, но тестовая среда будет на моем Mac, так что нужна ссылка на скачивание, пожалуйста.
 
Я бы сказал, что 95% проблем, с которыми я сталкивался, решаются сбросом UAP до заводских настроек и последующим перепровижинингом. Именно поэтому я и предложил это. Возможно ли временно получить доступ к версии 3.1.10RC на другом компьютере, обновить пару запасных устройств на тестовой стенде и посмотреть, решит ли это проблему? Просто интересно, есть ли постоянная проблема, которую нужно исправить, или что-то зависает во время обновления, и это нужно будет решить.

Не могли бы вы прислать мне в личку номер тикета, чтобы я посмотрел его для вас?
 
Привет, Мэтт.

К сожалению, у меня не было выбора. Мне пришлось что-то сделать, чтобы вернуть работающий Wi-Fi, поэтому я откатился. Я только что завершил откат. К счастью, у меня было 4 запасных AP от версии 3.1.9, поэтому я взял их, сбросил их до заводских настроек и установил их на замену 4 устройств 3.1.10. Это обеспечило работающий Wi-Fi на последние 2 часа дня. Затем я вернулся к 3.1.9 снапшоту контроллера и переразвернул все AP.

Я отправил Рональду кучу логов, чтобы он посмотрел, показывающие случайные перезагрузки и отключение клиентов десятками после 3.1.10. Есть ли шанс, что кто-нибудь сможет посмотреть на них для меня? Я немного в тупике, так как у меня нет ни малейшего представления, что я буду делать, чтобы решить мои проблемы, особенно учитывая, что 3.1.10 был полным провалом, но кажется, что это единственный путь вперед.
Страницы: 1
Читают тему (гостей: 1)