Android WiFi manager

Android

Adott:

- 100+ darab Androidos tablet. (ha jól rémlik, van köztük 4.4, 5.x, 6.x)
- root nincs! Külső szállító által adott, garanciális készülékek!
- 45+ darab különböző SSID, közös prefix-szel (cegnev-xxxx)
- WPA2-RADIUS, PEAP, MSCHAPv2

Az volna a feladat, hogy a júzer beírja valahova a júzernév/password párosát, akkor képes legyen csatlakozni az összes, céges SSID-hez. (Ne kelljen az összes SSID-hez egyenként beállítani.)

Ismer valaki valami célszerű appot?

Amiket idáig találtam, ezeken véreztek el:
- root kellett volna hozzá
- nem tud WPA2-RADIUS-t, csak PSK-t (csak jelszó mező van, stb.)

  • 937 megtekintés

( Nyosigomboc v | 2017. 02. 16., cs – 12:23 )

Szerintem forditva ultok a pacin. Ezt tipikusan a wifi oldalarol kell megoldani ennel a mennyisegnel, egyetlen SSID-vel, es az access pointok kozti atadassal. Nem vagyok halozatos, nemtom ezt pontosan hogy szoktak megvalositani, de hasznaltam mar ilyet.

--
A strange game. The only winning move is not to play. How about a nice game of chess? - Wargames

+1. A megvalósítás annyi, hogy minden AP-nek ugyanaz a neve (SSID). Innentől kezdve a kliens oldali eszközök automatikusan csatlakoznak az AP-khez, az okosabb fajta még automatikusan vált is ha a jelerősség gyengévé válik és van jobb jelerősségü AP a közelben. És ez mindössze 1 darab wifi hálózat felkonfigurálást jelenti az androidos eszközön.

Mivel itt mindenhol ugyanaz a user:pass, ezért az égvilágon semmi értelme a 45 darab különböző SSID-nak.

A topicnyitónak:
szerintem ilyen appot nem nagyon fogsz találni ez annyira specifikus igény. Inkább a fenti vonalon indulnék el a helyedben.

> +1. A megvalósítás annyi, hogy minden AP-nek ugyanaz a neve (SSID). Innentől kezdve a kliens
> oldali eszközök automatikusan csatlakoznak az AP-khez, az okosabb fajta még automatikusan vált
> is ha a jelerősség gyengévé válik és van jobb jelerősségü AP a közelben.

Próbáltuk, teljességgel használhatatlan. A kliensek össze-vissza ugrálnak az AP-k között.

1000+ felhasználó van, az eszközök nagy része BYOD, ahol nem tudunk "okos" klienst telepíteni, ami képes a "roamingot" normálisan lekezelni. A gyári Windows zeroconf és hasonszűrőek pedig nagyjából úgy működnek jelerősség-detektálás szempontjából, mint egy randomgenerátor.

Az irodámban van egy AP, aminek - minden máshoz képest vagy 15dB-el jobb a jel-zaj aránya, ehhez képest az aszalomra fixen lerakott notebook körbe-körbe jár mindenféle azonos ESSID-jű AP-re, olyanokra is, amik két emelettel odébb vannak. És, ez attól is függ, hogy éppen tömeg van-e a folyosón a büfé előtt, mert a visszaverődő jeleket az is befolyásolja.

A másik pedig, hogy mivel kis alapterületen sok ember lehet (oktatótermek) ezért muszáj egzakt módon (ESSID-vel) definiálni a hozzáférési pontot, különben - az egy helyen elérhető sok hálózat miatt - vígan lehet, hogy egy AP-re akár 60 kliens is felmászik, miközben a nem sokkal mellette lévőn öten vannak.

Nem vagyok halozatos, nemtom ezt pontosan hogy szoktak megvalositani, de hasznaltam mar ilyet.

Ezt normáliséknál úgy szokták megvalósítani, hogy lwap-okat használnak + 1-2-x controllert.
Az lwap-ok becsattannak a kontroller(ek)hez, és az megmondja a tutit.
Mivel nála összefut minden adat, így a kontrollernek az antennák térbeli elhelyezkedéséről is van egyfajta fogalma.
feltételezve 3 dimenziót + abból , hogy melyik AP mekkora erősséggel halja melyiket, már lehet egy kb/sacc fogalma arról, hogy ezek térben hol vannak egymáshoz képest.
még ha egy kliens is beleüti az egészbe a dolgát, azt is meg tudja saccolni elég egyszerűen, hogy az hol van térben, és ha úgy látja, hogy bár most ap1-re van beregisztrálva, de jobb lenne neki ap2-n (terheléselosztás, térbeli közelség, jobb snr érték, etwas miatt), akkor ap1 ledobja, és úgy keveri a lapokat, hogy ap2-re akarjon beregisztrálni majd legközelebb a kliens.

A 802.11 szabványokba nem nagyon tervezték bele a roaming-ot.

Mielőtt lett volna WLC-nk a 2-vel ezelőtti munkahelyemen, én úgy oldottam meg, hogy X ssid forgalmát az AP egy x vlan-ra bridgelte rá, Y ssid-t meg y vlan-ra.
Volt egy admin vlan, csak azon keresztül lehett az AP-kat konfig, log, login szintjén elérni.
Ill az x, y, stb vlan-ok meg a központi routerben voltak routeolva, így ha a kliens maga döntött úgy, hogy eldobja a csatlakozást ap1-el, és helyette átregisztrál ap2-re, akkor is mindegy volt neki, mert volt érvényes dhcp lease, a routerben ip helper engedélyezve volt a vlanra, a dhcp szerverben meg még ott volt neki az érvényes lease, az átregisztárlás l2 szinten gyak egy dhcp renew volt.
--Amolyan f99-es, beljebbhúzott-dőlt-megjegyzés: A 802.1X auth szintjén meg nem szórakoztunk PSK-val. Mindenkinek saját regisztrált usernév + pw, peap, mschapv2 és csókolom. Bármelyik windwosos buta kliens kezelte jól. Linuxok kezelik jól. Makkosix kezeli jól.
(Tegyük hozzá: Eduroam hálózatról (is) volt szó, így egyetemi campuson fontos volt, hogy a mindenféle egységsugarú egyetemista számára is zuportálható megoldás legyen.) --
Kb. mintha két ugyanabba a vlanba tartozó switchportod lenne, és kihúznád az egyikből a kanócot, és átdugnád a másikba.
Persze ez is remekül működött, de szinte kőbaltának éreztem a WLC-s megoldáshoz képest.
Őszintén szólva én ezen a területen Cisco hívő voltam, de nagyon sok helyen láttam, ahol valahogy az Aruba remekül bemarketingelte magát, és inkább az ő termékeiket kezdték használni. Valószínűleg tartom, hogy az extra mgmt szoftverek terén a Cisco erősen mellélőtt az árakkal.
(Pl. halványan rémlik olyasmi is, hogy adsz neki pár png-t a floorplan-nal, meg rápöttyintesz, hogy na kb. X ap ott van rajta, akkor ő heat-map szerűen tudott neked lefedettségi térképet rajzolni a kliensektől begyűjtött snr és egyéb adatok alapján, meg mindenféle engineer-candy feature-je volt.)

( gyu v | 2017. 02. 16., cs – 16:14 )

sub
<troll>
Ez a topik, legalább akkora szakmai inkompetenciáról árulkodik a kérdezőt illetően, mint http://hup.hu/node/152076
Ha valaki válaszra nyom, lécci, a jakós-popkornos képet tegye ide alá! ;-)
</troll>