Как получить информацию о wi-fi подключении по сети с android-устройства?
Здравствуйте, коллеги!
Стоит задача непрерывно контролировать сигнал вайфай-сети на устройстве под управлением Android.
Который день мучаю железку. Пытаюсь мониторить ее с помощью PRTG. Может кто-нибудь сталкивался, можно ли по SNMP получить информацию об уровне сигнала? Пытался найти соответствующий OID, но увы не могу найти. Если такового нет, есть ли альтернативные способы помимо SNMP? UPD: написание своей программы рассматриваю как последний из вариантов, все же почти уверен что такие уже есть, наверняка ведь кто-то сталкивался, задача актуальная...
P.S. Знаю, что вышла PRTG Probe for Android, но она не устраивает, т.к. минимальная частота снятия показаний там - 1 минута, мне же необходимо чаще.
P.P.S. В PRTG Probe for Android в свойствах сенсора Wi-Fi нет толком никаких данных, увы, чтобы добавить аналогичный. Клонирование тоже запрещено.
Проблема, похоже, не решится до тех пор, пока кто-нибудь не напишет нормальный конфигурируемый агент под Андроид :( По поводу 30с - это вообще проблема системы мониторинга. Я сам собирался написать такую штуку, но потом, по разным причинам, решил проблему иначе - прямым сбором данных на девайсе. Так что, видимо, либо ждать появления добровольцев, либо самому закатать рукава... и - вперед в светлое будущее :)
ясненько, есть статья на английском, в ней описана похожая задача, использовали некое приложение WaveLAN NIC под управлением FreeBSD + беспроводной адаптер ... Считывали уровень сигнала и соотношение сигнал/шум. Я пока на стадии изучения, но может вам пригодится. Статья называется: RADAR: An In-Building RF-based User Location and Tracking System, можно найти через sci-hub.org
@yetiman Мне кажется, мы говорим о несколько разных вещах. Проблема автора вопроса в том, что ему мужно конкретно подключить девайс к системе мониторинга по SMTP (вероятно, чтоб отследить проблемы с WiFi). Вы же, видимо, хотите получать RSSI для локализации девайса в помещении. Если я прав, то нужно отметить две вещи.
Первая: само по себе получение данных на Андроиде (как и на любой другой ОС) - задача тривиальная. Инфу выдает драйвер через стандартное API.
Второе соображение печальнее и заключается в том, что тема локализации в помещении через WiFi RSSI - баян. На этом поприще перепробовали все мыслимое и немыслимое - от банальной трилатерации и поиска патернов в heatmaps, и до скрещивания RSSI с интеграцией данных от гироскопа, вспомогательных IR/US/RFID маячков и распознавания образов в сигнале с камеры (ключевое слово sensorfusion). Этим активно занимались не только авторы статьи, но еще пару сотен исследовательских и коммерческих проектов разной степени серьезности, и все уперлись в то, что через WiFi получить практически пригодные результаты с приемлемыми затратами нереально. Это связано со спецификой распространения сигнала на этих частотах. (Уже на 433 МГц получаются на порядки более стабильные результаты, причем, на порядки проще и дешевле.)
Tему прожевали и выплюнули уже лет пять как. Сейчас она интересна разве что для каких-нибудь лабораторных работ для студентов или занимательных рассуждений о еще одной попытке скрестить фильтр Калмана с триангуляцией на основе какой-нибудь заковыристой модели распространения радиоволн... короче: практическая польза стремится к нулю.
@pi314 Речь, наверное, шла об SNMP, а не SMTP ? Но не суть ... Вы правы, мне необходимо решить задачу локализации.
Приятно встретить человека, которому эта тема знакома. Мне встретилась еще одна статья с анализом технологий локализации на основе различных беспроводных устройств (IR/RFID/Wi-Fi/Bluetooth) и с классификацией по различным свойства, в том числе и по стоимости, точности и погрешности, и я не согласился бы с вами, если взять в расчет, что выводы из этой статьи правильные.
Вот сама название статьи: "Survey of Wireless Indoor Positioning Techniques and Systems", в ней есть таблица со сравнительными характеристиками и по тексту - графики.
По сути, пользу даже от Wi-Fi все же получают и недорого и с достаточно высокой точностью ... Самые дешевые технологии на основе Wi-Fi + RSS позволяют локализовать устройства с точностью до 1-2 метров.
Собственно, лично мой интерес в том, как все-таки от Wi-Fi адаптера программно получить данные об RSSI ...
По сути вопроса, если речь про Андроид, то там все просто, как угол дома - там за это дело отвечает WifiManager, конкретнее см. константу EXTRA_NEW_RSSI. Т.к. для локализации нужен уровень сигнала нескольких AP, нужно периодически выполнять скан и собирать RSSI всех видимых (известных) AP. Хотя, в принципе, можно подойти к вопросу и с обратной стороны - брать RSSI на стороне AP (как конкретно - зависит от ОС AP). Теоретическая разр. способность RSSI в dBm - 1 байт, а какая будет битность реально, сильно зависит от конкретного железа и драйвера. По опыту: среднестатистические производители относятся к этому делу без фанатизма, ибо для отображения нескольких "столбиков" (хороший-плохой "прием") особая точность не требуется. Этот момент, кстати - один из безчисленных подводных камушков, о которые спотыкаются, как только от академической статейки нужно перейти к конкретной реализации :)
Далее по теме... не стоит безоговорочно доверять эпитетам типа "дешевые технологии". Дело в том, что авторы обзоров берут их, как и цифры типа 1-2 метра, из рекламных проспектов производителей, которые, в свою очередь, выводят их из теоретических формул. А на практике все выглядит несколько печальнее. Если из списка в статье выделить только WiFi-технологии, то победитель, бесспорно, Ekahau, с их заявленными "1м", "90% в радиусе 2м" и "низкой стоимостью". Я имел непосредственное удовольствие использовать эту приблуду (наряду с другими прочими из списка) в конкретных проектах и знаю истинную цену таким заявлениям.
На практике хорошо, если positioning engine может в 90% случаев определить положение с точностью "до комнаты", а в оставшихся 10% - "до этажа". Стоимость 1 транспондера у них 95-190€ плюс грубо столько же за лицензию на трекинг 1 транспондера. И это - без учета стоимости AP (которых нужно много и которые должны быть размещены на местности определенным образом), зарядных станций, ИК-маячков, интеграции и эксплуатации этого чуда... которая, кстати, работает ровно до того момента, как где-нибудь поднимут дополнительные AP, передвинут мебель или станут чаще/реже закрывать массивные двери или опускать жалюзи. Тогда нужно заново калибровать модель. По поводу "высокой надежности" могу только добавить, что когда в сети начинают пропадать UDP пакеты (а такое случается в реальных сетях даже при штатной нагрузке), система косячит так, что мама не горюй. Вот такая вот "точная, дешевая и надежная" технология :)
Коллега @pi314 прав. Действительно, в моей кейсе задача стоит именно в подключении к системе мониторинга по SNMP (хех, тоже до этого как-то несколько раз опечатывался (-: ).
К сожалению, на данный момент вопрос так и не решен. Все упирается в частоту опросов. Пробовал разные продукты (всех сейчас уж и не упомнить) - везде минимальный период опроса в районе 30-60 секунд. В упор не могу понять, с чем может быть связано такое ограничение снизу - зачем? Может у вас, коллеги будут какие-то мысли на этот счет...?
Нормальный агент под андроид у меня, к сожалению, написать вряд ли получится ввиду отсутствия нужных компетенций и времени :( Но если кто-то заинтересован в этой теме, готов конечно же оказать любую посильную помощь. И, судя по всему, не один я готов - проблема-то актуальна!
@dimoncomeon Собственно, ограничение вытекает из сути SNMP и систем мониторинга, не предназначенных для "непрерывного" снятия данных. Вообще-то для отслеживания проблем в быстротекущих процессах существует механизм trap-ов. По идее, агент может собирать данные и анализировать их локально, и только в случае обнаружения проблемы (например, при выявлении тренда в среднеквадратичном отклонении) посылать соотв. trap. Если он будет их тупо слать каждую секунду (и если таких агентов будет много), это создаст нехилый спам в сети. С другой стороны, если система мониторинга будет слать get раз в секунду, это может задидосить сам девайс. Ну, и наконец, при большом количестве девайсов, которые нужно опрашивать, проблемы возникнут уже у планировщика запросов, не говоря о том, что такое количество данных еще нужно где-то хранить (например, в БД). Вот почему подавляющее большинство систем мониторинга и агентов заточены под потоки данных максимум раз в 30-60 с.
Ну хранение в БД и загрузка сети - это какие-то потенциально решаемые проблемы. Не верится что разработчики мыслят на несколько шагов вперед и таким образом проявляют заботу об админах...
К тому же можно (и даже нужно!!!) снимать информацию локально и какими-то частями ее потом выгружать, хоть пусть даже и раз в час.
Средний
