Нет. C RouterOS та же проблема — сниффить probe-запросы на устройстве не получается, в прошивку вендор изменения вряд ли включит. У Cisco проприетарный протокол общения с контроллером (NMSP), тоже шифрованный, так что добро пожаловать купить CMX. Есть обходное решение, но я его не скажу :)
Некоторые другие вендоры, например Ruckus, Huawei и Cambium имеют средства отправки probe-пакетов во внешнюю систему, но на это ни стандарта ни общего протокола не существует. В результате на рынке присутствует несколько систем аналитики, все закрытые и разного качества.
Есть реализации закрытых систем, использующих сбор probe-пакетов на роутерах с OpenWrt (там это делается тривиально), к тому же это на порядок дешевле по железу.
Опенсорса нет и вряд ли он скоро появится.
Wi-Fi устройства передают в эфир свой МАС адрес нешифрованным, и принять его можно обычной мыльницей за 1500р с openwrt (нет, Cisco AIR-CAP3800 брать не обязательно).
GSM сигнал просто так не принять, а если и получится — там всё шифровано, даже IMEI не достать.
Здесь нет ничего, кроме штатного и давно известного функционала Cisco MSE (Cisco CMX). Кстати, генерируемые этими системами отчёты — «вещь в себе», они жестко зашиты и их почти невозможно кастомизировать. Да, у CMX есть некоторое API, но лучше бы его вообще не было — через него ничего толком достать не удаётся, и слепить собственную аналитику просто не получится.
Каждый день у человека будет новый рандомный МАС в probe-запросах и один и тот же настоящий — если он попробует подключиться к местному Wi-Fi. Но-его надо убедить подключиться.
Эксперименты показали, что рандомные адреса генерятся не только для неиспользуемых блоков ОUI, но и для вполне себе валидных блоков чужих (или собственных) вендоров. У того же эппла в базе больше 500 блоков OUI.
Для меня все восторги по поводу letsencrypt заканчиваются на необходимости поддерживать SSL не только на веб фронтах. Вы удивитесь, но в мире есть не только nginx и апач! Есть tomcat, винда с iis, exchange, микротики, разношерстное телекоммуникационное оборудование, iLo серваков, админки СХД и куча других сервисов и железок, куда сертификат можно поставить только вручную.
Я к тому, что скорее всего там не просто формула, где добавляются dB в FSPL, а мегабайты аналитического кода со сложной математикой, которые они там развивают уже лет 10 как.
Я не очень верю в применимость BLE. Это всё требует создания и установки приложения, а кто из абонентов его будет ставить в проходных местах вроде ТРЦ? Остается узкая ниша складов, где работники ходят с корпоративными устройствами.
Не думаю, что FSPL — корректная модель. У той же Cisco в Prime вы рисуете карту, расставляете «стены» из разных материалов, учитываете материал межэтажных перекрытий и так далее. А дальше MSE, получая сырые данные от контроллера (МАС точки и клиента, уровни сигнала и шума), упорно занимается расчетами и другой хитрой математикой. Не даром там внутри полно кода, написанного на матлабе(!), можете сами разобрать и посмотреть.
А по-другому перенаправление с HTTPS сайта на авторизацию и не может работать. Это не метро плохое, это у всех вендоров captive portal так. Технология такая.
Некоторые другие вендоры, например Ruckus, Huawei и Cambium имеют средства отправки probe-пакетов во внешнюю систему, но на это ни стандарта ни общего протокола не существует. В результате на рынке присутствует несколько систем аналитики, все закрытые и разного качества.
Есть реализации закрытых систем, использующих сбор probe-пакетов на роутерах с OpenWrt (там это делается тривиально), к тому же это на порядок дешевле по железу.
Опенсорса нет и вряд ли он скоро появится.
GSM сигнал просто так не принять, а если и получится — там всё шифровано, даже IMEI не достать.
Спасибо.