Wive-NG Control (мониторинг и управление AP)

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

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

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

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

 

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

Изменено пользователем mbg

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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-адресов опять всё ломает?)

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

 

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

 

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

 

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

 

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

 

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

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

 

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

 

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

 

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

 

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

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

 

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

 

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

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

 

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

мелочи:

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

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

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

nan.png

nan2.png

minus.png

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Для публикации сообщений создайте учётную запись или авторизуйтесь

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

Создать учетную запись

Зарегистрируйте новую учётную запись в нашем сообществе. Это очень просто!


Регистрация нового пользователя

Войти

Уже есть аккаунт? Войти в систему.


Войти
Подписчики 0