[SNR]

Эта тема создана для обсуждения системы мониторинга и управления SNR-CPE Control.

В нее следует описывать

-Проблемы, с которыми Вы столкнулись при тестировании

-Необходимый Вам функционал, в настоящее время отсутствующий в системе

 

Для получения SNR-CPE Control в тест, необходимо отправить письмо на wifi@nag.ru , указав организацию, контакт, отвечающий за тест, и дистрибутив с указанием версии, на котором будет осуществляться тестирование.

Edited July 3, 2019 by Mikhail Vanyashkin

[mbg]

на PHP 7 работать не будет?

отвечу сам - работает.

 

Авторизация через ключ планируется?

Edited July 10, 2017 by mbg

[sfstudio]

Ключ???? Или таки сертификат? Гиде авторизация? На роутерах? Ну если вы готовы каждый раз при каждом обновлении следить за актуанльностью сертификатов и перезаливать их то вперёд. Нормальные логин/пароль не менее безопасны в данном случае. Символов 100 сделайте и пущай подбирают.

[mbg]

я про авторизацию WiFi Control на роутерах. у нас коннект к ssh через rsa ключ.

[sfstudio]

Странно ожидать поддержки со стороны мониторилки того, чего из коробки ПО не умеет? У вас ровно 2 варианта:

1) дождаться может быть (я буду настаивать на этом как минимум) исходники мониторилки так же будут полностью открыты и после этого сможете запилить сами

2) предложить правильно оформленный патч для самой Wive-NG заодно попутно решив проблему с хранением ключа в nvram т.к. rwfs сущность по сути "временная" (в смысле что содержимое оного может быть сброшено при обновлении), а потом ждать когда дойдут руки прикрутить это на сторону мониторилки. Что тоже будет не быстро т.к. море работы и без прикручивания новых методов авторизации

[edo]

на PHP 7 работать не будет?

отвечу сам - работает.

мне было лениво менять везде mysql на mysqli (это же надо будет менять и после обновления).

[sfstudio]

В перспективе сделают ферму сборки под актуальные версии дистров и ничего руками править не надо будет ни сразу ни при обновлении. Не всё сразу. Система только только в начальной стадии разработки.

 

Сейчас скорее нужны "идеи" о том, что нужно в неё добавить и т.д. Ну и репорты по багам с максимальной детальностью.

[edo]

по багам (писал на почту, просили продублировать на форум):

1. пакет, зависимости

неплохо бы прописать (для debian) php5 и php5-mysql, libapache2-mod-php5, апач в рекомендуемые (ну или nginx/ещё что по вкусу)

2. установщик

2a. спрашивает логин/пароль к базе, но не прописывает их никуда (надо прописать в два места - в /etc /и в /var/www)

2b. нет initscript для stagger

2c. неплохо бы класть в /etc/apache2/sites-available/ конфиг апача (хотя бы заготовку)

3. удалось ввести в веб-интерфейсе имя хоста некоторые знаки (спецсимволы?), они не отображались

обнаружил по тому, что stagger писал ошибку.

когда исправил (в БД), stagger подхватил изменения только после перезапуска, разве он не должен был перечитать из базы?

 

по фичреквестам:

- при добавлении новых точек в вебинтерфейсе иметь возможность копировать настройки (логин/пароль в первую очередь) и/или указывать диапазон для сканирования, а то не очень удобно по одной точке добавлять;

- сохранять конфиг с точек в базу/восстанавливать (чтобы иметь историю изменений и бэкап последнего на случай входа точки из строя или перепрошивки);

- отображать (или хотя бы писать в базу) и неактивных клиентов (или с рандомизацией mac это никакого смысла уже не имеет?);

- показывать историю клиентов: когда к какой точке был подключен.

 

в принципе, наверное, последний пункт не очень актуален - никто не мешает "вытянуть" эту информацию из БД.

 

непринципиально, но хотелось бы иметь возможность использовать postgres вместо mysql (как я понимаю, никакие продвинутые особенности БД не используются, так что проблем со сменой СУБД не должно быть, а постгрес мне привычнее).

если решитесь на opensource - мог бы и сам сделать.

 

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

[sfstudio]

непринципиально, но хотелось бы иметь возможность использовать postgres вместо mysql (как я понимаю, никакие продвинутые особенности БД не используются, так что проблем со сменой СУБД не должно быть, а постгрес мне привычнее).

если решитесь на opensource - мог бы и сам сделать.

 

Пока мускул, дальше будет видно.

 

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

 

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

 

Логику роуминга нет смысла тянуть в эту систему. Это всего лишь мониторинг/управление. Всё остальное должно быть независимо от неё. Т.е. сеть должна оставаться самодостаточна ИМХО.

 

По остальному Sadler/beutelratte/SNR пусть коментируют %) Я стараюсь по минимуму касаться этого дела. Ну максимум как арбитр.

[edo]

Всё остальное должно быть независимо от неё. Т.е. сеть должна оставаться самодостаточна ИМХО.

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

 

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

 

другое дело, что рандомизация ломает всё нахрен...

[sfstudio]

Вот если вы мне расскажете как я должен увидить клиента не ассоциированного с АП ещё и актуальные данные получить ну кроме как с probe которых вообще может не быть к соседним АП или мак в них подменён будет и т.д. А ещё как обойти проблему с тем что изменение положения клиентского устройства в пространстве может вылиться в дельту в почти 10Дб и т.д. Ну понятно надеюсь?

 

Снифить трафик? Ну ок. Поставим одтельный радиомодуль, цена вырастет втрое т.к. host cpu надо будет поменять т.к. на 7620 вешать не куда, ещё один (а лучше 2 т.к. 2 диапазона) модуля поставить. И т.д. и т.п.

 

Не будут клиенты лучше распределены чем сейчас. Работать нужно со стороны клиентов. А для взаимодействия между АП есть iapp. Проблема не в этом.

 

P.S. Более того это оффтоп, и поверьте из всей портянки вероятно полезных вещей с точки зрения пользователя, увы по факту полезны меньше 1%, остальное разве что для муркетинга можно использовать, ибо применимость околонулевая.

 

другое дело, что рандомизация ломает всё нахрен...

 

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

 

P.S. Лишний раз пинать дурного клиента нельлзя. Метания по пинку клиента туда-сюда гораздо хуже проблем на стороне этого клиента. Баланс и разумность должны соблюдаться. Любая технология должна укладываться в рамки разумного, иначе тупо не взлетит т.к. будет больше приносить проблем чем решать. Предсказуемость так же не на последнем месте.

[edo]

А ещё как обойти проблему с тем что изменение положения клиентского устройства в пространстве может вылиться в дельту в почти 10Дб и т.д.

это как раз легко - если новая точка видит на 15-20Дб лучше, то перекидываем, нет - не трогаем. и я же не зря написал, что перекидывать не сразу, а только если ситуация сохраняется некоторое время (телефон лежит на столе, прицепившись к точке в соседней комнате)

 

остальные аргументы принимаются, ну не получается - так не получается.

[edo]

Это не самая большая проблема, даже её можно с некоторыми изысками обойти

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

[sfstudio]

это как раз легко - если новая точка видит на 15-20Дб лучше, то перекидываем, нет - не трогаем. и я же не зря написал, что перекидывать не сразу, а только если ситуация сохраняется некоторое время (телефон лежит на столе, прицепившись к точке в соседней комнате)

 

Склько сколько? 15-20 дельта? Ну т.е. у вас АП на 1000 квадратов 2шт стоят? =) Более того. Заивисимость от канала и т.д. и т.п. Опять таки как ведёт AGC с его стороны кто знает? Факторов сильно больше чем вам кажется. Так что...

 

Не выйдет корректно сравнить даже имея данные и сделать по ним вывод в лоб. Пройдено уже. Нет ну можно сделать эдакую таблицу автокалибровок сети, поставить в центре (а лучше на квадракоптере) источник эталонного сигнала, и т.д. Ну поняли к чему веду... Проблема не на стороне AP. Увы.

 

Это не самая большая проблема, даже её можно с некоторыми изысками обойти

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

 

Ну я не буду раскрывать подобные идеи ибо есть шанс что через некоторое время возможно придётся заняться реализацией. =))) Но подскажу, ключевое слово "интервалы". Но прошу не развивать дальше тему. ;)

 

P.S. Всё, завязали с оффтопом. Откровенно лень, да и некогда чистить потом будет... Надо окно назад в лоджии вставить. А то 2 часа ночи, соседи там поди у виска крутят как я тут с алюминиевым профилем скачу и матерюсь. =)))

[edo]

Склько сколько? 15-20 дельта?

ну ладно, с 20Дб я погорячился, но речь именно про то, чтобы исправлять крайние случаи (а в том, что они случаются, я убедился собственными глазами)

 

ладно, я смирился с тем, что этого не будет )))

[sfstudio]

Такое бывает когда клиенты спят. Но тут в любом случае пока он спит он не услышит сигнала. А только проснувшись получит его повторно из логики обработки class2/3 error. Потому я от этого отказался, и пытаюсь будить и только потом килять. Но просыпаются по запросу от АП далеко не все.

 

Но это лучший вариант.

[edo]

мелочи:

на страничке "AP List" для точек без 5GHz пишется NaN на число клиентов, оно же и Total портит.

если два раза ткнуть по точке, выбрать закладку Clients, то уровень пишется вроде -52.-50, в соседней колонке пробел перед запятой (а не после)

баг с минусом после десятичной точки есть и на закладке "Clients List"

[edo]

Были ли выпущены с тех пор новые версии с новыми фичами?

[sfstudio]

Как бы интересный вопрос. Собирались перед НГ сформировать новые пакеты и допилить шероховатости (т.к. многое было переделано/доделано + расширен функционал именно в части управления) и перевести наконец софт в стадию публичного альфа релиза.

 

Ноо...

 

А но заключается в том, что мы сейчас на стадии реструктуризации всей работы с компанией НАГ. Дальнейшая судьба Wive-NG-Control пока не обсуждалась. Возможно компания НАГ решит развивать её самостоятельно.

 

Wive-NG в любом случае остаётся за нами и продолжит своё развитие в том или ином виде. Будет ли развитие в ключе компании НАГ или кого-то ещё сейчас зависит исключительно от того примут ли они наше предложение или нет. Так что таймаут до конца месяца. Дальше будет видно.

 

Следите за новостями. ;)

[sfstudio]

Полный комплект исходников передан компании НАГ. Надеюсь они примут верное решение и переведут проект в статус OSS.

[ima]

Контроллер можно сейчас где скачать?

[sfstudio]

Пишите на wifi@nag.ru

[edo]

Хотелось бы узнать (от представителей nag?) каков сейчас статус проекта

[Kirill Vasilyev]

Добрый день

Проект в работе. Актуальную версию ПО можно скачать с нашего файл-сервера http://data.nag.ru/SNR WiFi/Wive-Control/

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

Если у вас есть пожелания по работе или по функционалу Wive-NG Control вы можете озвучить их тут или на наш почтовый адрес wifi@nag.ru 

[vik44]

Можно  где-нить прочитать полный список того, что может данная система - на фтп с исо как-то очень тускло ...

Интересует есть ли централизованное управление кластером из АР (и что оно в себя включает) и мониторинг по отказам АР с информированием о проблемах - например, на почту...