Jump to content

ezin

Пользователи
  • Posts

    11
  • Joined

  • Last visited

About ezin

  • Rank
    Абитуриент
    Абитуриент

Контакты

  • ICQ
    Array
  1. еще небольшой полет мыли: для того, чтоб выводить информацию в логфайл, надо задать некий ключик: типа -log. помимо этого, надо еще выводить информацию на экран, для этого задать ключик -stdput. вообще, потом то, что лезет на стдаут,можно переправить в интересующий файлик. еще вспомнились мне пайпы из унихов: пусть например офрмат выводящейся информации стандартизирован, и никак его изменить нельзя(зато просто в программной реализации) тогда можно сделать что-то типа такого: админакова {всякие ключи -stdout}| grep {лалала}|awk 'print $2' >>1.txt т.о. в результате того, что акова выдает на экран, вытягиваем строку с "лалала", в kоторой вытягиваем 2 параметр, и его пишем в файл. вот. еще надо сделать дополнительный лог файл, в который заносятся все изменения, которые производятся над точками. бо, можно доавтоматиться, что связь с удаленной точкой потеряется, а причина останется невыясненой. тут-то этот лог и подскажет, чтож за конфигурация туда была залита. вот!
  2. на мой взгляд, предложенный вариант, конечно интересен, но сложность комплекса слишком сильно возрастет, при этом он потеряет свою потенциальную гибкость. например, один из проблемных моментов - сбор статистики. -mon_interval n это значит, что монитор должен висеть постоянно в памяти. не думаю, что это хорошая идея. speed - не очень понятный параметр, такого в точке нет. думаю, для решения проблем, надо внести некую модульнусть. т.е. не один исполняемый файл, а несколько. каждый на свою задачу. также сделать набор командных файлов. а теперь поподробнее. собирать статистику, естесна, надо в течение длительного времени. для этого предлагаю использовать виндовый шедулер(а лучше - команду at - она задает выполнение задачи в опредленное время). т.о. админский комплекс не дудет постоянно висеть в памяти. далее, лог-файл получается слишком сложный по структуре. думаю, его надо оформить например в таком виде: metric*метрика|mac|мак*time|21.12.06-17:21*итд а потом уже необходимую информацию парсить, например с помощью awk(mawk), и делать файл, готовый для экспорта в excel. метрика - это некая константа, который пользователь хочет, чтоб присутствовал в логфайле(она например, может быть привязана к точке, к способу предачи информации и пр.) вообще, лучше даже сделать что-то типа параметра, который определяет, в каком виде будет формироваться лог-файл print("лалала $datetime /t $local_RSSI /t $noise_level") что касаемо измерения скорости: надо реализовать несколько способов(надо иметь какой-нить IP на другой стороне линка) 1. пинг например, запустить 10 пакетов и взять среднее время отклика. негож тем, что не нагрузит должным образом канал. гож, что достаточно на той стороне хотяб рабочей точки 2. шара естесна, надо знать имя шары, и копировать, засекая время(с помощью командного файла) 3. фтп - тоже не особо сложно. 4. генератор трафика а потом результат выводить в лог файл, где будет сказано, время, IP или шара и пр. всем этим должна заниматься уже другая программа(пусть обзывается тестскорость), а не админверсия она должна уметь и пинговать, и копировать заданные файлы на шары, копировать с шар. качать по фтп. засекать время, определять скорость, и выдавать в лог файл требуемую информацию 4 ерализуется, например, при помощи драйверов winpcap. протсо кидает в сеть широковещательный трафик и всё т.о. управляющий командный файл будет выглядеть например так: -запуск тестскорость -запустить аковаадмин с задачей по сбору параметров и сбросу в файл -at перезапустить себя(управляющий командный файл) через полчаса для сканирования канала вайфая -запуск тестскорость -запустить аковаадмин с параметром установки канала на удаленной точке -запустить аковаадмин с параметром установки канала на местной точке -запустить аковаадмин с задачей по сбору параметров и сбросу в файл(здесь сделать метрикой номер канала) -запуск тестскорость -завернуть цикл по проверке списка тестируемых каналов т.о. получится параметричская задача, обработав данные, получим качество связи на каналах. у меня интересный эффект наблюдается: так вышло, что в одном месте несколько антенн собралось от нескольких точек, и они ДИКО влияют друг на друга, даже если линки на разных каналах(надо рстаскивать антенны). вопрос: как выявить такое сочетания каналов, при котором наименьшее влияние линков друг на друга будет. реализовывать все это в аковадмине нереально. зато такая узкаялокальная задача просто реализуется с помощью самописных командных файлов(кстати, можно пользовать и перл, и пхп, да хоть и свой паскаль). это я все к чему. а к тому, что надо делать модульнуюструктуру. т.о. акова знимается только драйвером, а коллектив предлагает на основе этого драйвера кучу решений. это мне напоминает тот же winpcap. наверняка многие сталкивались с этой штукой. по сути - это драйвер сетевой карты + библиотека функций управления сетевой кантой. многие производители не изобретают велосипеда, а просто просят юзера поставить этот драйвер себе, а сами реализуют уже конкретую задачу. мне, например, попадались сниферы, анализаторы трафика, генераторы трафика, утилита управления компексовым свичем. вот в чем сила - в модульности полагаю, и в случае с аковойадмин надо поступить аналогичным образом фуф. фантазёр;)
  3. как-как, как консольная софтина, которая умеет подключаться к точке, и заливать ей телнетовские команды, и выдавать телнетовские ответы на эти команды(типа стандартного ввода - вывода). чтоб такую вещь можно было использовать в своих скриптах. вот такой вот офтоп!
  4. когда, гришь, новая версия увидит свет, ы? ЗЫ а что там с админ версией? уже оочень хоца её поюзать.
  5. да-да, именно так всё и имелось ввиду! :) а когда очередной релиз, ы?
  6. -еще было бы классно, еслиб была кнопка, которая позволяет сохранять текущую конфигурацию АР в файл. и вторая кнопка - чтение конфигурации из файла. -и былобы хорошо, еслиб строка телнета имела историю ввода. бо, порой приходится повторять команды. -ну, а если совсем зафантазироваться, то чтоб работал еще и автоввод команд, когда по сочетанию первых букв становится ясно, что за команда. а еще, когда, не ясно, чтоб выпадал список с предлагаемыми вариантами(типа как в bash). -если пытаться закрыть прогрмму при работающей вкладке RSII, то она предлагает поначалу остановить сканирование. думаю, можно остановку сканирования в автомат поставить. -если работаешь с несколькими точками, и начинаешь перегружать несколько точек сразу(включая ближайшую к тебе), то все программы впоследствие коннектятся к той точке, которая в поле IP addres. - после подключения к точке пусть в поле IP addres остается ИП этой точки, а не иной. бо, порой вводит в заблуждение. - ну, и при выборе любой из вкладок программы было бы не плохо видеть, с какой точкой работаешь(её IP и ssid). пока всё :)
  7. поле для IP адреса в правом нижнем углу слишком мелкое. я полностью не влезаю :)
  8. продолжая тему инициатив, могу проедложить, чтоб помимо стандартного ввода можно былоб поиметь не менее стандартный вывод. желательно в некой универсальной форме, удобной для дальнейшего разбора параметров. во как!
  9. эта мысль у меня созрела, когда я в телнете пытался найти сочетание ssid, broadcast. на поверку оказалось, что и команда имеет несколько иной вид, и параметр этой команды обратный представлению в программе. а так бы все сразу стало понятно, в какую сторону копать
  10. благодарности автору за творение - вещь! моменты: -почему-то не хочет включаться(выключаться) режим SSID Broadcast(2100 2.00 и BB2_180). приходится телнетом. -былоб не плохо, еслиб был реализован режим телнет строки, в которой в реальном времени при нажимании какх нибудь кнопок, выборов из списков и т.д., появлялся телнет аналог команд. а также все это аккуратно складывать в какойнить файлик логов. - не очень удобно, если пытаешь конектиться к каой-либо точке, и какой-либо параметр ввел не правильно, то в выпадающем списке вылезает последний удачный IP с логином и паролем, хотелось бы, чтоб оставались хоть и неудачные данные, чтоб можно было их отредактировать, а не бомбить снова.
  11. предлагаю на реализацию следующую идею: пусть у нас существует некая сеть, построенная на длинках. требуется оптимальным образом подобрать для такой сети параметры для связывающихся между собой точек досупа. способ реализации например такой(нарисую только про каналы): задаем список АП. задаем связи между ними. показываем, где находится наша машина, относительно этих точек(ну, чтоб софт сначала менял параметры на наиболее отдаленных линках, а потом более близких). пусть пользователь имеет возможность установить время сканирования одного линка между АП. потом следующий диапаон и т.д. также требуется установить кол-во проходов сканирования. вообщем, фантазия разыгралась такой хренью можно вообще все вокруг положить, а потом вспоминать акову;) к сожалению, не знаю, но подозреваю, что в длинковых штуках нет автоматического режима отката при неудачных настройках. типа, на дельней точке поставил суперГ, а на блиней - нет. в итоге, пусть вся трасса легла. точки постояли, подождали, не получили некоего подтверждения от пользователя и вернулись в некое предыдущее рабочее состояние. вот так!