Több Wifi AP ugyanazon SSID-n

Wireless

Sziasztok!

Kétszintes házba telepítenék szintenként WiFi access pointot, mert a födémen elég gyengén szivárog át a légi közlekedésű net. Működik, de lassú.

A kérdésem az, hogy ha ugyanarra az SSID-ra teszem a két AP-t, akkor lesz-e abból problémám, hogy nem tudhatom biztosan, hogy melyik AP-vel beszélget a gépem, és néha a rosszra csatlakozik, és ettől lassú lesz például?

Tehát szükséges lesz-e két külön SSID-t bekonfolnom (ami egyébként nem túl bonya), vagy jó megoldás, ha ugyanaz a kettő?

Otthoni "wifi router" szintű kütyüben gondolkodom, természetesen beállítom a kütyüket úgy, hogy ne adjanak DHCP-t, hanem csak AP-ként működjenek. Plusz beállítom, hogy ne ugyanazon fizikai csatornán legyenek, meg a szomszédéval se ütközzön nagyon.

Szerk.: a megoldás végül az lett, hogy külön SSID-n fut a két szint. Nem ideális megoldás, de a kommentvihart végigolvasva úgy döntöttem, hogy se a pénzt, se az erőfeszítést nem éri meg nekem most a tisztességes megoldás. Az AP-k máshol selejtezett WiFi routerek lettek OpenWRT-vel. Ingyen volt, és jól működnek. Néha bekapcsolás után kézzel be kell állítani, hogy a megfelelőhöz csatlakozzon, de csak 1 eszköz van, amin mindkét háló konfigolva van, a többi fixen szinthez kötődik egyelőre.

( KicsiBocs | 2018. 12. 29., szo – 17:03 )

Érdemes egymástól eltérő (távoli) csatornára konfigurálni az AP-kat. Az SSID maradhat ugyanaz, csak érdemes külön csatornákra beállítani az AP-kat. Sőt a környékbelei Wi-Fi-ket is érdemes (és kell is) leellenőrizni, hogy mely (frekvencia) csatornákat használják. Milyen típusú AP-k?

Jelenleg van egy TP-Link TL-WR1043ND típusú routerem AP-nak bekonfolva. Ez kvázi ingyen volt.

Eddig nincs vele bajom, csak annyi volt, hogy a BGN-ből az N-t ki kellett kapcsolnom, mert úgy rettenetes lassú volt. De lehet, hogy ez kliens oldali probléma volt, sokat nem gondolkodtam rajta, örülök hogy most működik.

Ha nem tudok még egyet ingyen szerezni, akkor venni fogok valamit. Mit ajánlanál?

Alapvetően olyan kütyükre utazok, amikhez van közösségi firmware image. A régi WRTGL-emet is a mai napig használom ilyennel, jó lenne itt is ennyi évre venni a vasat.

( Gyuszk v | 2018. 12. 29., szo – 17:56 )

Úgy nyilatkozom mint aki cégben és otthon is rengeteg energiát fektetett hasonló helyzetek megoldására. Az otthoni eszközök nem alkalmasak arra hogy "olcsón jót" kapj. Két vicces de annál idegesítőbb hibát is könnyen tapasztalhatsz:
- az eszköz felmegy az erősebbik routerre, majd hiába jársz-kelsz a lakásban vele, nem engedi el és vált az erősebbre, ha a meglevő még működik (és az user experience lehet hogy szar lesz, de ő még azt hiszi maradhat)
- az eszköz ide-oda ugrál a két AP között (én mindkettővel találkoztam).

Ha különböző SSID-eket állítasz be akkor meg kézzel kell klattyogtatni attól függően hogy melyik a jobb (pl. telefont vagy laptopot várhatóan fent és lent is használni akarsz).

Nekem is TL-1043ND van, még úgy sem túl erősen lövi át a falakat hogy a háromból két antennája nagyméretűre lett cserélve.

Én azt javaslom hogy vásárolj olyan routert aminek kifejezetten erős antennái vannak, és próbáld meg azzal megoldani. Internetes vásárlást 14 napig indoklás nélkül visszaadhatsz, ha nem jött be, visszaadod és kérsz egy másikat vagy visszakéred a pénzt.

Ami valószínűleg tényleg stabil kapcsolatot (de fele teljesítményt) fog adni az a repeater. Gondolom nem kell minden egyes eszközön többszáz mbites kapcsolat, a telefonok, tabletek felhasználói élménye simán megfelelő 40-50 mbittől felfelé.

Egyéb tanács: mivel emeletek közti kapcsolatról van szó így rögtön felejtsd el az 5ghz-et, mert a 2,4-es sokkal jobban átmegy a falakon.

--
arch,ubuntu,windows,libreelec,omnirom,microg
zbook/elitebook/rpi3/motog4_athene

Az 5 vs 2.4 kapcsán ezt így nem jelenteném ki.
Ha sok más 2.4-es hálózat van a szomszédoktól, akkor azokkal is konfliktus van és lassulás. 5GHz-en sokkal több csatorna van és szokkal nagyobb sebesség érhető el. Az, hogy nem ér el falakon át olyan messzire, akár előny is lehet, mert a harmadik szomszéd hálózata már nem ér el hozzád.

Sajnos valóban nem támogatják az eszközök az automatikus váltást, ígyis úgyis kb manuálisan kell váltani. Pécén talán van rá szoftver, ami figyelheti a hálózatokat, de maga a figyelés is lassítja a kapcsolatot. Mobileszközöknél meg kb így járás.

Kézzel váltogatni szerintem nem feltétlen gond, ritkán fogom használat közben felvinni-levinni a kütyüket.

De tényleg legésszerűbb volna olyan frekire átállni, ami talán átmegy a födémen, és nem kellene semmi trükk hozzá. A gyári szoftverben csak 11bg és 11bgn mixedből lehet választani, illetve be tudom állítani a csatorna számát 1 és 13 között. Hogy derül ki, hogy milyen frekin van ez, és be lehet állítani valahogy 2.4-re?

Meggondolom a tanácsaidat, de lehet, hogy mégis maradok az olcsó gagyi eszközökkel való megoldásnál, mert nem akarok sokat költeni.

Ez mind 2,4 ghz-es lesz, mert a routered nem tud 5öt. A csatornát úgy válaszd meg, hogy a környezetedben fellelhető AP-ktől minél messzebb legyen (pl. laptoppal fel tudod mérni a terepet: https://sourceforge.net/projects/linssid/ ), illetve ha két routert húzol fel akkor ők is legyenek egymástól távol, hogy kevesebb legyen az interferencia.

--
arch,ubuntu,windows,libreelec,omnirom,microg
zbook/elitebook/rpi3/motog4_athene

+1 az "otthoni eszközök nem alkalmasak" Nalam az volt a rendszeresen, hogy kozelebb mentem a masik eszkozhoz, es konkretan percekig semmi net nem volt az eszkozon, vakarozott a device, aztan nagy kegyesen atvaltott. Mindezt, ugy, hogy a ket wifi AC onmagaban is lefedte a haz nagy reszet, biztonsag kedveert tettem be kettot, hogy a spejz hatuljaban meg a kert vegeben is tuti legyen jel. Azota megy a router ket nagy antennaval es jonapot, tokeletesen mukodik (kiveve a kert veget), a wifi extenderrel csak a baj volt.

-
Advanced testing of Golang applications

( azbest | 2018. 12. 29., szo – 18:11 )

Simán tudnak működni ugyanazon az ssid-n, az eszközök meg oda mennek fel, ahová épp akarnak. Nem kell ugyanazon a fizikai csatornán lenniük. Persze, ha nem használjátok párhuzamosan sokan, akkor lehet nem számít, de egyébként a csatorna terheltsége lassíthatja a másik eszközre kapcsolódókat is.

A szomszédokkal való békesség jegyében lehet az 5GHz-es hálózat használata előny. Kevésbé is látszik át a falon. Ez akár előny is lehet, mert esélyesebb, hogy átvált. Az is lehet, hogyy jobb, ha nem emeled, hanem inkább csökkented a jel erősségét, hogy ne érjen el gyengén a másik szintre. De persze a váltás miatt például szakadhat voip vagy hasonlók. Persze ettől még jó, ha van 2.4-es is beállítva, ide érdemes különböző ssid-t megadni, mármint hogy lásd, hogy 2.4 vagy 5ös hálózatra akarsz csatlakozni valamelyik eszközöddel.

Ahol a közös ssid ellenére fixen meg akarod adni, hogy melyikre kapcsolódjon, ott a bssid megadásával fixálhatod le. Péládul ha van helyhez kötött wifis eszközöd, oda felveheted a közelebbit így.

Egyébként érdemes lehet például egy telefonnal körbejárni, amin wifi elemző alkalmazás fut és megnézni, hogy adott elhelyezés, beállítások mellett milyen térerőt kap, a bssid alapján akkor is tudhatod melyik ezközt látod. Plusz a szomszédokkal való rádiós konfliktust is látod. Így esélyesebb, hogy a megfelelő csatornákat és beállításokat megtalálod.

( fsanyee | 2018. 12. 29., szo – 18:58 )

szuleimnel ugyanaz az ssid, ugyanaz a channel. a T dlink kutyuje + tplink 741n (dhcp off, lan porton dlinkre kotve), nincs vele gond.

( sigellef | 2018. 12. 29., szo – 19:21 )

2 vagy több egyforma SSID csak akkor jó, ha a másik ugyanolyan SSID-jű hálózat véletlenül sem látszik a másik lefedettségi területéről.
Azért sem jó a 2 egyforma SSID, mert lehet, te magad sem fogod tudni, hogy most épp melyikre csatlakozik az eszközöd. Meg egy csomó egyéb kütyü is össze tud zavarodni az ilyentől.
Ha dróttal viszed a hálót másik routerhez, akkor jó, ha a 2 wifi spektruma nem fedi egymást. Ha repeater megoldást használod, akkor viszont egyeznie kell a csatornáknak, de az SSID akkor is különböző kell legyen.

-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.
/usr/lib/libasound.so --gágágágá --lilaliba

( mauzi v | 2018. 12. 29., szo – 21:05 )

Én Unifi-jal nyomom, amiben már valamennyi 802.11r támogatás is van, és azt kell mondanom, hogy határozottan pocsékul működik az, amikor a kliens dönti el, hova is csatlakozzon, valamint mikor is kellene elengednie az éppen aktuális AP-t és átállnia a másikra. Amíg az nem jelent komolyabb problémát, használj eltérő SSID-t. Tisztább és szárazabb érzés.

Azonos SSID-vel néha egészen meglepő AP-kra akar csatlakozni (ami a ház másik felében van, 5 főfalon keresztül) vagy éppen oda-vissza pattog különböző AP-k között, néha akár azért is, mert valaki elsétál a helyiségben, és róla hirtelen másképp verődnek vissza a jelek. Néha egy fix ponton tartózkodva (íróasztalnál ülve) is körbe-körbe jár több AP között. Hiába a "fast roaming" és az egyszerűsített handshake, minden egyes átállás mérhető szakadást okoz, amit HTTP forgalomban talán nem veszel észre, de interaktív, valós idejű kommunikációnál (SSH, RDP, pláne UDP alapúnál - VoIP, RTSP) elég rossz kaland.

Ez persze attól is függ, hogy a kliens mennyire okosan implementálja a fast roamingot... de a tapasztalat a meglévő eszközökkel az, hogy messze vagyunk még...

Épp akartam javasolni, hogy Unifi tökéletes erre a célra. A Unifi-s eszközök egységesen kezelhetőek és ha Unify-s switch-et használ, netán POE-s, akkor 10 perc a konfig.
Ahogy te írtad: " Tisztább és szárazabb érzés." :D

Minden "olcsó" router csak egy probléma kupac lenne.

( agostonl | 2018. 12. 29., szo – 19:53 )

Otthoni rendszerben simán mehet ugyanaz az SSID. Nálunk (Bp. XV ker. ugyanaz az SSID, mint a monori körzetben.
Mindkét helyen megy a Wi-fi kérdés nélkül.

Régen minden más volt... ma meg minden a régi.

( answ | 2018. 12. 29., szo – 22:12 )

Semmilyen consumer vagy felprofinak mondott (Ubiquiti, Mikrotik) eszkozzel nem lehet ezt jol (!) megoldani. Ugyanis ezeknel az eszkozoknel a kliens dontesere lehet csak szamitani, igy minden ettol a szinte biztosan rossz dontestol fugg (egyetlen lehetoseg, hogy alacsony jelerosseg eseten ledobatod, de ez meg a szeleken okoz majd problemat). De ugye szegeny ember vizzel foz, igy a kovetkezot szoktam alkalmazni: felveszel Mikrotikeken egy azonos SSID-s halozatot es csinalsz mindegyiken egy-egy virtualis AP-t is kulonbozo SSID-vel. Peldaul "otthon", "otthon-foldszint", "otthon-emelet". Igy alapbol mondjuk csatlakozol az "otthon"-ra, de ha a marha kliens tul sticky, akkor at tudsz allni barmikor manualisan is a megfelelo AP-re. A parasztvakito capsmannel nem kell torodnod, nem segit semmit a roamingon, csak a kozponti beallitason, ami ilyen kis szamu AP-nel nem problema.

"Semmilyen consumer vagy felprofinak mondott (Ubiquiti, Mikrotik) eszkozzel nem lehet ezt jol (!) megoldani."
Ez olyan, hogy nem lehet mindenkinek prémium kategóriás autója! Mindennek vannak különböző szintjei. Tehát nem tud minden cég Cisco-t venni. Egy átlagos kis és közép méretű vállalkozás nem igazán engedheti meg magának ezt a méretű kiadást. A MikroTik CAPsMan nekem is csalódást okozott, de az Ubiquiti Unifi szériás eszközei meglepően barátságosan viselkedtek. Mellesleg nem kell eldugni az AP-kat egy irodában, mert beleolvadnak a környezetbe. Tapasztalatból mondom,ha jól be van lőve,akkor az AP-k között szépen megy a "vándorlás", ahogy sétálok az irodában.
Én továbbra is úgy látom,hogy neki a Unifi szériás eszközök megoldások tökéletesek lennének.

Felreertes ne essek: otthon nalam is Unifi, Mikrotik, sot meg felso kategorias Asus is van. Irodakba, hotelekbe, ettermekbe is telepitunk Mikrotik router/Unifi AP kombokat. Mukodik, de sose teljes az orom, mindig talalkozni olyannal, hogy ha klienst manualisan disassocialom, akkor utana ujracsatlakozaskor sokkal jobb a kapcsolat. Raadasul otthoni kornyezetben (2-3 AP kozel egymashoz) tapasztalatom szerint ez sokkal gyakrabban jelentkezik.

Először is igen remek TOPIC! Köszönet mindenkinek, aki energiát fektetett az álláspontja kifejtésére.

Másrészt szeretném felmelegíteni a témát, mert miután végigolvastam az összes hozzászólást nem alakult ki bennem világos kép.

A problémám ugyan az, mint asch -nak: Kettő viszonylag kis kiterjedésű területbe belerondít egy wifi által áthatolhatatlan vasbeton.
Mind a két terület be van UTP -vel kábelezve, és szeretném, ha úgy le tudnám fedni kettő darab AccessPoint -tal.
Szeretném ha a kliensek roamingolnának, lehetőleg minél zökkenőmentesebben.

Ha lehet Wifi vezérlő nélkül, vagy eszközbe épített vezérlővel oldanám meg, mert ezért nem szeretnék erre egy külön gépet tartani.

Arra gondoltam, hogy a lehető legkisebbre lecsökkentem a jelszintet, így biztos, hogy a helységhez rendelt AP -hez fog fordulni a kliens. (Jól gondolom?)

Az a kérdésem, milyen eszközöket vegyek? Persze a költség is számít, de nem az a legfontosabb!

Kérek valakit, akinek van tapasztalata, segítsen.

Előre is köszönöm!

"It took six days for the god creating this world and see how many bugs it contains! "

Mikrotik cAP AC lehet az egyik jelölt. Mikrotik esetén próbáltam a wireless access list-ben a minimális csatlakozási jelszintet. Ez bár nem tökéletes megoldás, mert egy erősebb adóval / jobb antennával rendelkező eszköz képes fent maradni, de esetedben ahol elég nagy az elnyomás, jó lehet. Főleg 5 GHz-es sáv esetén. Továbbá az előbb írt szélsőséges eszközök esetén végülis MAC-enként lehet finomhangolni a vételi jelszint minimumot.

Ubiquity ha van kontrollered, akkor állítólag megbeszéli, melyik AP hallja jobban az adott eszközt és a másik lerúgja magáról. De ezt nem próbáltam még.

Mikrotik esetén a CAPsMAN-t is kipróbálhatod, egyesek szerint az Ubiquity-hoz hasonlóan szintén lerúgja arról az AP-ról az eszközt, amelyik gyengébben veszi. Ezt sem tudom megerősíteni, de talán más megteszi.

Az AP-k tök jól elvannak kontroller nélkül is. Pl. az egyik szálloda évekig anélkül használta és nem volt panasz. Ez max a roaming miatt kell, terhelés eloszláshoz, stb. Amit megkapsz standard wifi eszközökkel, azt az unifi is tudja kontroller nélkül, sőt jobban.

Az AC LR pedig nem egy xar cucc. Az LR alapból jó, nagy nagy adó, érzékeny vevő.

Kedves HUPtársak!
Elnézést, hogy még mindig ezt a topicot lovagolom, de itt minden előzmény megtalálható.

Történt:

  • Beszerzésre került 2db Ubiquiti UniFi Long Range Access Point /UAP-AC-LR/. Egy UTP LAN -on mindkettő.
  • Be lett üzemelve: Először az egyik, minden alapbeállítás, Channel → AUTO, MESH funkció engedélyezve. Majd a második is konfiguráció másolásával (Ilyet tud a kezelőszoftver).

Kérdés:
Az rendben van, hogy az automatikus channel kiválasztásánál mindkettő ugyan azt a channel -t választja? Állítsam át kézzel?

Nem vagyok róla meggyőződve, hogy roamingol

"It took six days for the god creating this world and see how many bugs it contains! "

Ha LAN-on kötődik a hálózatra, akkor ne legyen ugyanazon a csatornán, mert úgy zavarják/lassítják egymást.

A MESH meg akkor kell, ha jelismétlő(k) vannak. (Ha két gép ugyanahhoz a jelismétlőhöz kötődik, akkor a 2 gép közötti kommunikáció nem megy a routerhez, hanem a jelismétlőn megy csak át)

Ha meg több AP-nek is ugyanaz az SSID-je, az meg önszívatáson kívül semmire sem jó. (Fogalmad se lesz róla, hogy mi mihez kötődik)

-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.

Ha a területek lefedésében van közös terület, valami mesh megoldásra lesz szükséged, hogy a klienst átadogassák az AP-k egymás között.
Sosem volt ilyenem otthon, úgyhogy nem segíthetek, mit vegyél, de ez lesz a drágább megoldás.

Ha nincs közös terület, könnyebb a dolgod, mert úgyis leszakad a kliens, mire a másik területére ér, így csak ugyanaz az SSID,security kell az AP-knek, de arra figyelj, hogy külön csatornán legyenek, ne vágjanak egymás szavába. Itt AP bármi lehet, ami elbír a kliensmennyiséggel.

Szerintem is mesh (az eredeti post, amihez hasonló a problem, épp átfedésről szól). Én d-linket (COVR-1200) használok. A kezdeti szívás után, amikor is megtanultam a d-linkes terminológiát :-D, eléggé stabilan megy. És nem utolsó sorban "nem egy ökör ára". A meshek között pláne nem. A 3 AP-s kiszerelés egy jobb Asus árában van.

Valószínűleg nem fogom beletenni azt a pénzt, de kiváncsiságból érdekelne, hogy profi eszközzel hogy lehet megoldani, és az hogy működik?

A rendszer nyomonköveti a klienst (az APk ledumálják, hogy ki milyen erősen látja a forgalmát), és ő mondja meg hogy mihez kell csatlakozni? Van erre valami protokoll a rendszer és a kliens között is?

Peldaul felmerik a szomszedossagi viszonyokat, ahhoz allitjak a jelerossegeket. Szeleken nem dobjak le a klienst (iranyt ismerik). Beamformingot es band steeringet alkalmaznak. 802.11k,r,v-vel segitik a barangolast.
Peldaul 802.11k eseten:
1 Access point determines that client is moving away from it.
2. Informs client to prepare to switch to a new access point.
3. Client requests list of nearby access points
4. Access point gives site report
5. Client moves to best access point based on report

Letezik olyan megoldas is, amikor egy BSSID-vel latszik az egesz rendszer es kliens nem is tud a roamingrol. Ezt manapsag mar ritkan alkalmazzak es csak kis kliensszamnal, de meg a leggagyibb kliensekkel is mukodik.

( szollosiimre | 2018. 12. 30., v – 09:28 )

Nem lesz problémád. A windows-os notebookon érdemes ellenőrizni a wifi drivert. A windows driver nem roamingol rendesen.

A "wifi routert" ne használj AP-ként. Nekem volt, hogy időnként megbolondult. AP módoz AP módban működő eszköz kell. Dedikált eszköz. Az unifi javasolt termék.

Windowst nem használ senki, úgyhogy nem lesz vele gond. Ha meg a feleségem mégis vesz és szar lesz, akkor legalább cukkolhatom vele :-P.

Amíg nem lesz vele bajom, addig használni fogom amim van, csak akkor cserélem le, ha tönkremegy, vagy találok neki új helyet (elpasszolom ismerősnek, stb). Azért is jó ez, mert van rajta USB és printert is tervezek rákötni. De ha cserélem, akkor majd Unifit veszek.

"Windowst nem használ senki, úgyhogy nem lesz vele gond. Ha meg a feleségem mégis vesz és szar lesz, akkor legalább cukkolhatom vele :-P."

tetszik ez a mentalitás :D

"all submitted complaints will be forwarded to /dev/null for further investigation"
"ez ilyen hippi kommunás felfogás, ahogy Stallman sámán módjára dobol a nagy hasán, hogy GNU, free software, free as free beer."

( mark7 | 2018. 12. 30., v – 11:42 )

Veterán hozzászólásához nem enged válaszolni, ez miért van?

asch
'TL-1043ND típusú routerem AP-nak bekonfolva'
Milyen firmwaren csináltad?

Volt kijelölve maintenance window a change-re, és rollback plan ha beüt a gebasz? /s

Komolyra fordítva: a wifi elérhetősége lassan már otthon is olyan kritikus, h. nem biztos az ember olyan bátran nekiáll észnélkül rútert apgrédelgetni. Főleg ha a család többi része ferdeszemmel nézi miért kell állandóan basztatni azt a rohadt rútert? Az update eredménye ugyanis általában nem kézzelfogható: a fész eddig is működött, ezután is működik ugyanúgy, akkor meg minek ez az egész barkácsolás?
Nagyobb az otthoni wifire a helyes működés SLA-ja, mint a corporate hálókon :-)
--

Az nem, de Web UI igen :)

Legutóbb (pár éve) az enyémre talán ezt tettem fel:
http://victek.is-a-geek.com/virtual/tomatok26/status-index.html

de az is lehet, hogy ezt:
http://tomato.groov.pl/?page_id=31

Ehhez már erősebb router kell:
https://advancedtomato.com/demo/status-overview.asp#status-home.asp

DD-WRT is volt rajta valamikor:
https://router-firmware-test.gamma.nu/DD-WRT/index.html

Gargoyle is egy rövid ideig, valami ősrégi verziójú OpenWRT:
https://router-firmware-test.gamma.nu/Gargoyle/index.html

Hát kinek mi jön be :) Én általában text editor / konfigfile / vim / ssh vonalon érzem magam jól szintén, de egy közepesen komoly openwrt setupot (mondjuk static dhcp table, sima wifi+ethernet, külön VLAN-ban guest AP-k + az egyik ethernet port, dynamic dns, openvpn, port forward, társai) nem feltétlenül kezdeném el kitanulni az openwrt uci/konfigfájl témáit, mert összekattogtatva a webfelületen áttekinthetőbbnek, érthetőbbnek látom (persze ha beleraknék egy kis időt, nyilván megtanulhatnám, csak nem érzek benne return value-t).

--
arch,ubuntu,windows,libreelec,omnirom,microg
zbook/elitebook/rpi3/motog4_athene

Ezen Wiki oldal alapján: https://oldwiki.archive.openwrt.org/toh/tp-link/tl-wr1043nd ezen fejezetben: Installation on HW rev.3 azt írta, hogy valamiért a trunk buildet javasolja: trunk version for v3 openwrt-ar71xx-generic-tl-wr1043nd-v3-squashfs-factory.bin https://downloads.openwrt.org/snapshots/trunk/ar71xx/generic/openwrt-ar…

A gyári FW webes felületén az upgrade menűponton keresztül feltöltöttem és megvártam, hogy újrainduljon.

Újraindulás után failsafe módba vittem a gombjával, a WAN porton beléptem SSH-val és a biztonság kedvéért nyomtam rá egy factory reset-et a firstboot paranccsal.

Ezután LAN porton beléptem SSH-val, és megnéztem mi van fenn. Nem volt fenn a luci csomag. És az opkg nem tudott telepíteni semmit, mert a libustream-openssl csomag sem volt fenn. Ezért csináltam egy Java programot (:-), ami http-n elérhetővé tette az openwrt letöltő oldalainak tartalmát, átírtam az opkg konfigot és azon keresztül telepítettem a lucit és a libustream-openssl-t. Ezután már megy az opkg és van LuCi felület is.

Ennyi volt a történet. Ezenkívül még ezeket tettem fel, hogy USB-n Arduino-t tudjak távvezérelni: kmod-usb-serial kmod-usb-serial-acm socat ezen leírás szerint működik is: https://blog.g3rt.nl/arduino-serial-over-tcp-openwrt.html

Valószínűleg az a baj hogy trunk -ot tettél fel (azt hiszem az egy daily build, amiben bármilyen napi taknyolás benne lehet).

Sajnos az openwrt/lede dokumentációja eléggé változatos minőségű, néha jobb ha az ember megnézi a legyártott image fájlokat és az alapján dönt. Én a mikrotik -emre simán fel tudtam rakni úgy hogy a doksik szerint egyáltalán nem volt kész, de a gyakorlatban igen.

Ezt tedd fel: https://downloads.openwrt.org/releases/18.06.1/targets/ar71xx/generic/o…
(de figyelj mert ez a gyári firmware-ről való átállásra szolgál!)

--
arch,ubuntu,windows,libreelec,omnirom,microg
zbook/elitebook/rpi3/motog4_athene

( hnsz2002 v | 2018. 12. 30., v – 11:50 )

Ne csináld, nem lesz jó.
Legyen más a neve, és kész.
--
"Sose a gép a hülye."

Mert a kliens akkor roamingolni fog, vagyis próbál, és amikor átmegy arra az AP-ra, amelyikre nem csatlakoztál, akkor néz mint borjú az új kapura, hogy miért nincs hitelesítve... Majd mire észhez tér, és eltimeoutol, és nulláról felépíti a kapcsolatot és az autentikációt, addig az lesz, hogy látszólag van jel, aztán mégsem megy egy bit forgalom se. És ha olyan helyen vagy, ahol kb. azonos erősségű a két AP, és a kliens pattog ide-oda, az egy használhatatlan wifit eredményez.
--
"Sose a gép a hülye."

Tökéletesen megtörténik, mert a kliens oldali roaming abból áll, hogy az egyazon ESSID-hez tartozó több BSSID közül próbálja "jól" kiválasztani, hogy melyikhez csatlakozzon. A jel-zaj viszonyok változásának köszönhetően pattog oda-vissza az egyes BSSID-k között. Eközben a júzer csak annyit lát, hogy ő csatlakozott egy ESSID-hez, a jelerősség össze-vissza ugrál, a ping meg hol van, hol nem van.

A 802.11r/k/v és társai annyit javít a helyzeten, hogy a BSSID változásakor rövidebb a handshake, gyorsabban felépül újra a kapcsolat, kevesebb a csomagvesztés, de a kliens gyakorlatban pont ugyanolyan szar döntéseket hoz, mint nélküle. Na jó, lehet, hogy 20%-kal kevésbbé szar döntéseket.

Bármikor szívesen demonstrálom neked egy 50+ AP-s hálózatban, akár Unifi-vel akár anélkül, akár 802.11r-rel, akár anélkül. Attól függ, hogy melyik helyiségben vagy és éppen milyen a mozgolódás az egyes helyiségekben, akár 8-10 (saját) AP is látszik egyszerre, +/- 20dB-es jel-zaj ugrabugrálással.

A roaming megtörténik és az is megtörténik, hogy időnként ide-oda kapcsolódik, ha a kliens driver szar.

Az nem történik meg, hogy a kliens átmegy egy másik AP-re, azt gondolván, hogy ugyanaz az SSID és ott authentikáció nélkül próbál forgalmazni, én ugyanis erre reagáltam: "és amikor átmegy arra az AP-ra, amelyikre nem csatlakoztál, akkor néz mint borjú az új kapura, hogy miért nincs hitelesítve"

--
https://iotguru.live

De, szokott. Sőt, olyat is lehet, hogy AP oldalról kéred meg a klienst, hogy legyen szíves másik AP-ra kapcsolódni.... Load balance. Hogy ne az legyen, hogy egyik AP-n van 50 kliens, másikon 2, aminek bár hiába erősebb a jele, az 50 kliens miatt annyira kicsi lesz a használható sebesség, hogy a másik, egyébként gyengébb AP-val jobban jár csóri kliens.
Ezzel az a probléma, hogy ennek még kisebb a támogatása mind AP, mind kliens oldalról, de ettől még létezik. Viszont az, hogy a kliens sétál egy bazi nagy wifivel lefedett területen, és átmegy egyikről a másikra, teljesen mindennapi.
--
"Sose a gép a hülye."

Teljes autentikáció nem történik, layer2-n szól a kliens az új AP-nak, hogy hello itt vagyok, a régitől meg elköszön. A hello miatt az új AP elkéri a kliens aktuális kulcsát, ha nincs meg neki, és magasabb szinten ez kb úgy néz ki, hogy az egyik packeted még az egyik AP-nak megy, a másik meg már az újnak. Nincs teljes, nulláról felépített autentikáció, nincs link szakadás, nincs ip cím újrakérés meg semmi ilyesmi.
Nagyon leegyszerűsítve így néz ki.
--
"Sose a gép a hülye."

A kliens SSID-hoz kapcsolódik, a BSSID egy alacsonyabb szintű dolog, nyilván tudja a kliens, hogy épp kivel beszél. De ha másik BSSID szórja ugyanazt az SSID-t, az a kliens számára azt jelenti, hogy ugyanaz a hálózat, tehát ha úgy gondolja (bármi miatt), akkor átmegy, hiszen ez a roamingnak a lényege, hogy minden AP tudja (vagy legalább is el tudja kérni a kontollertől) bármelyik kliens aktuális kulcsát, és minden megy szakadás nélkül tovább.
--
"Sose a gép a hülye."

"A kliens SSID-hoz kapcsolódik, a BSSID egy alacsonyabb szintű dolog, nyilván tudja a kliens, hogy épp kivel beszél."

Bocsánat, de lófaszt. A kliens a BSSID-hez kapcsolódik, az SSID nem is jön szóba, ha tudod a BSSID-t és az alapján kapcsolódsz. Az SSID a humán workflow miatt van mindössze, hogy ember számára is értelmezhető név látszódjon.

"De ha másik BSSID szórja ugyanazt az SSID-t, az a kliens számára azt jelenti, hogy ugyanaz a hálózat, tehát ha úgy gondolja (bármi miatt), akkor átmegy, hiszen ez a roamingnak a lényege, hogy minden AP tudja (vagy legalább is el tudja kérni a kontollertől) bármelyik kliens aktuális kulcsát, és minden megy szakadás nélkül tovább."

A roaming úgy működik, hogy a kliens ESSID alapján tudja, hogy melyik BSSID tartozik ugyanahhoz a hálózathoz.

--
https://iotguru.live

+1
az SSID egy sima display sztring (van valamekkora max. hossz limitje), a BSSID meg konkrétan a wifi hálózat egyedi MAC címe, 6 bájton!

Lefordítom laikus nyelvre:
a világon milliószám létezik "Linksys" meg "Tp-link" SSID-jű wifi, ez alapján nem is lehetne 2 azonos nevű között különbséget tenni. De a háttérben mindegyiknek saját egyedi BSSID-je IS van.
--

A BSSID a gyakorlatban MAC címe az AP-nak. Annyira egyedi, mint egy MAC cím...De alapvetően a kliens nem ez alapján keres hálózatot, hacsak nem fixáltad direkt egyre, hogy az adott SSID-t keresse és fixen ahhoz a BSSID-hoz kapcsolódjon.
Ha pedig nem fixáltad, akkor pedig igenis az van, hogy ha van egy Linksys nevű hálózat, amihez elmentettél egy jelszót, akkor otthon is, az irodába is, Üzbegisztánban is, ha fog látni egy ilyen SSID-t, rá fog próbálni a nála elmentett PSK-val.
--
"Sose a gép a hülye."

Próbálhatod magyarázni, de az SSID pusztán humán olvasatra van. Ami alapján a kliens-szerver beszélget, az a BSSID és az ESSID. A BSSID-hez kapcsolódik és az ESSID alapján tudja, hogy melyik BSSID-k vannak egy hálózatban, azok között van roaming.

Szóval nem fordul elő olyan, hogy átmegy egy azonos nevű SSID-t hirdető AP-re és ott próbál vele beszélgetni, mint az előző AP-vel abbahagyta, csak mert azonos az SSID... más a BSSID és ebből tudja a kliens, hogy újra kezet kell fogniuk... szóval nem lesz olyan, hogy "átmegy arra az AP-ra, amelyikre nem csatlakoztál, akkor néz mint borjú az új kapura, hogy miért nincs hitelesítve".

--
https://iotguru.live

Hát, javaslom hogy olvasgass egy kicsit a wirelessről akkor még...
Az ESS a BSS-ek összessége, és amit mi csak egyszerűen SSID-nak hívunk, az valójában az ESSID. Van jelentősége, ez alapján scannel a kliens, ez alapján választ egy olyan BSSID-t, ami ezt az ESSID-t szórja, és vele kezd el beszélgetni, neki címezve a keretet. Hány kliensen adtál te meg ESSID-t userként? Egyet se, mert nincs. Vagyis van, ezt hívják "slendriánul" simán SSID-nek. Vagy még másképp, akkor lesz a "sima" SSID-ből "extended", ha több eszköz szórja.
Itt van például egy juniper-es link: https://www.juniper.net/documentation/en_US/junos-space-apps/network-di…
De van cisco is, vagy amit szeretnél.
--
"Sose a gép a hülye."

Érdekes, a szabvány szerint nem ugyanaz... :/

3.53 extended service area (ESA): The area within which members of an extended service set (ESS) may
communicate. An ESA is larger than or equal to a basic service area (BSA) and may involve several basic
service sets (BSSs) in overlapping, disjointed, or both configurations.

3.54 extended service set (ESS): A set of one or more interconnected basic service sets (BSSs) that appears
as a single BSS to the logical link control (LLC) layer at any station (STA) associated with one of those
BSSs.

3.137 station service (SS): The set of services that support transport of medium access control (MAC)
service data units (MSDUs) between stations (STAs) within a basic service set (BSS).

...

5.2.3.1 Extended service set (ESS): The large coverage network

The DS and BSSs allow IEEE Std 802.11 to create a wireless network of arbitrary size and complexity.
IEEE Std 802.11 refers to this type of network as the ESS network. An ESS is the union of the BSSs
connected by a DS. The ESS does not include the DS.

The key concept is that the ESS network appears the same to an LLC layer as an IBSS network. STAs within
an ESS may communicate and mobile STAs may move from one BSS to another (within the same ESS)
transparently to LLC.

Nothing is assumed by IEEE Std 802.11 about the relative physical locations of the BSSs in Figure 5-3.
All of the following are possible:

a) The BSSs may partially overlap. This is commonly used to arrange contiguous coverage within a
physical volume.
b) The BSSs could be physically disjoint. Logically there is no limit to the distance between BSSs.
c) The BSSs may be physically collocated. This may be done to provide redundancy.
d) One (or more) IBSS or ESS networks may be physically present in the same space as one (or more)
ESS networks. This may arise for a number of reasons. Some examples are when an ad hoc network
is operating in a location that also has an ESS network, when physically overlapping IEEE 802.11
networks have been set up by different organizations, and when two or more different access and
security policies are needed in the same location.

--
https://iotguru.live

Ott, hogy az SS azonosítója - az SSID - és az ESS azonosítója - az ESSID - nem ugyanaz. Az egyik service set azonosító, a másik meg station service azonosító. Az, hogy kényelemből vagy lustaságból ugyanazt adod meg mind a kettőnek vagy azt hiszed valamelyikről, hogy azonos a másikkal, attól még nem ugyanaz a kettő. Szabvány szerint legalábbis.

Szerintem erre te is rá tudsz jönni, hogy ez irgalmatlanul nagy faszság: "Vagy még másképp, akkor lesz az SSID-ből "extended", ha több eszköz szórja."

--
https://iotguru.live

Ez csak logikai megnevezés különbség, fizikailag ugyanaz a kettő a menedzsment frame-ekben. A kliens eszköznek fogalma sincs (nem is lehet erről), hiszen beaconban egy érték szerepel. Nevezheted azt SSID-nek vagy ESSID-nek.

Mondok egy elég sz*r autós hasonlatot:
- Ebben az autóban akkor nincs ASR?
- Ebben ESP van.
- De akkor most van ASR vagy nincs?
- Ebben az autóban ESP van, ez látja el az ASR feladatát.
(ez a párbeszéd valóban megtörtént)

"Ez csak logikai megnevezés különbség, fizikailag ugyanaz a kettő a menedzsment frame-ekben."

Igen, lehet ugyanaz az SSID és az ESSID _értéke_, de attól még teljesen más a kettő, nem logikai megnevezés különbség, hanem alapvetően teljesen más a célja és a funkciója a kettőnek, nem ugyanaz a kettő a management frame-ben, pláne azért, mert a management frame-ben csak BSS ID van.

A kliens pedig tud mind a kettőről, lévén más célja van ezeknek és pláne azért, mert _lehet_ és _van_ is eltérő értékük... mert be tudsz tenni különböző SSID-t hirdető AP-ket egy ESSID alá.

Baszki, olvassátok már el azt a nyomorult szabványt, különösen az roaming és ESS részét, aztán legalább nem írtok folyton faszságokat a témában... :/

--
https://iotguru.live

Nincs más célja. Egy hálózatot azonosít, ez alapján keres a kliens BSS-eket. És ha ez egy olyan SSID, amit több BSS is szór, akkor hívják ESSID-nak. Nincs a beacon keretben külön SSID és ESSID mező.
https://mrncciew.com/2014/10/08/802-11-mgmt-beacon-frame/
--
"Sose a gép a hülye."

"És ha ez egy olyan SSID, amit több BSS is szór, akkor hívják ESSID-nak."

Nem. Nem hívják annak, teljesen más a terminológia, olvasd már el a szabvány definíciós részét, ha már a többit nem olvastad el. :/

"Nincs a beacon keretben külön SSID és ESSID mező."

Mert oda nem kell ESSID, azért. :/

--
https://iotguru.live

OK, ezt benéztem. De rákerestem erre is.
Nos, az egész ott bukik el a kiindulási szituációban, hogy HA támogatott (AP és kliens oldalon egyaránt). Márpedig az otthoni eszközök nem roamingra készültek, így jó eséllyel nem támogatják. De még ha tudja és támogatja is az eszköz, amíg nincs olyan környezetben (nevezzük ESSID-nak), addig nem biztos, hogy aktív ez a funkció.
Bár most 10 percnél többet nem szántam erre, de nem tartom valószínűnek (sem energiatakarékossági, sem biztonsági okokból), hogy a kliens minden egyes AP-t, akit csak talál, megszórjon ANQP-vel, hogy megtudja, hogy amúgy a nem egyező SSID-hoz hátha mégis olyan "ESSID" tartozik az ANQP szerint, ami neki jó, és majd ezért felkonnektál egy olyan SSID-ra, ami neki abszolút soha nem volt konfigolva. Főleg, mert ez technikailag sem lehetséges.
--
"Sose a gép a hülye."

"Márpedig az otthoni eszközök nem roamingra készültek, így jó eséllyel nem támogatják."

Ha nem támogatják, akkor bizony nincs roaming... de akkor se próbál beszélni azonos SSID-t hirdető AP-vel, mert a kommunikációban nem jön szóba az SSID.

"Bár most 10 percnél többet nem szántam erre, de nem tartom valószínűnek [...]"

Nagyszerű, szerintem szánj rá kicsit többet tíz percnél, hátha megokosodsz a témában és akkor rájössz, hogy nem azon múlik, hogy mit tartasz valószínűnek, hanem azon, hogy mi a szabvány a kérdést tekintve. És akkor végre nem írsz számodra valószínűnek tűnő hülyeségeket a témában...

--
https://iotguru.live

Az AP szórja a beacon kereteit, amit a kliens megkap, és folyamatosan figyel. Pontosan tudja, hogy milyen SSID-hoz van éppen kapcsolódva. Ha úgy dönt bármi miatt, hogy másikra akar átmenni, bármi miatt, akkor jön képbe a roaming. Ha a kliens roaming képes, ezt meg fogja tenni.
--
"Sose a gép a hülye."

"mert be tudsz tenni különböző SSID-t hirdető AP-ket egy ESSID alá."
Igen. És akkor lesz mindegyiken egy háló, amit te ESSID-nak hívsz, meg meglesz mindegyiknek a sajátja, amit SSID-nak. Ebben sincs semmi különös.
AP1 - AP1 SSID, COMMON SSID
AP2 - AP2 SSID, COMMON SSID
AP3 - AP3 SSID, COMMON SSID
Ekkor minden AP két külön beacont fog szórni az éterbe, az egyik az AP1 SSID, a másik a COMMON SSID. A BSSID meg akár lehet ugyanaz a MAC cím is (nincs jelentősége, lehet kézzel megadott, vagy virtuális is, vagy ha két rádió van az eszközben, és úgy konfigolod, hogy az egyik az egyiket, a másik a másikat szórja, akkor az megint más)

Az AP1-2-3 mindegyiknek a sajátja, a COMMON meg szépen roamingolható. De amikor te roamingoldsz a COMMON-on, a kliens nem az az AP1-2-3 SSID-ra csatlakozik, hanem a COMMON-ra.

--
"Sose a gép a hülye."

A kliens a BSSID-re csatlakozik, ha ugyanaz, akkor ugyanaz, ha nem ugyanaz, akkor feltűnik a kliensnek. Felejtsd már el a szöveges SSID-t, mint kapcsolódást, sehol nincs benne a kommunikációs protokollokban címzésre az SSID, ez egy humán által olvasható név, annyi a szerepe, hogy egy listából választani tudj. Ha tudod a BSSID-t, akkor nem is kell a kapcsolódáshoz.

--
https://iotguru.live

Megint rábasztál többszörösen.
Olyan szinten benne van az SSID a kommunikációban, hogy konkrétan a WPA handshare része, és teljesen más ugyanazon PSK-val a három/négyfázisú kétfogás más-más SSID esetén. http://image.slidesharecdn.com/crackingwpa2-pskinthecloud-110505163725-…
Továbbá, ha az általad leírt dolog igaz lenne, akkor semmi értelme nem lenne a rejtett hálózatnak (abba most ne menjünk bele, hogy amúgy se nagyon van...), hiszen SSID nélkül lehetne kapcsolódni.
Harmad részt, ha egy AP több SSID-t is szór ugyanazon BSSID-val, és te nem adod meg, hogy melyik SSID-ra akarsz kapcsolódni, honnan a bánatból tudja, hogy te melyikre szeretnél? Végigpróbálja mindet?
--
"Sose a gép a hülye."

"Megint rábasztál többszörösen."

Persze, többszörösen is.

"Olyan szinten benne van az SSID a kommunikációban, hogy konkrétan a WPA handshare része"

A handshake nem kommunikáció, hanem handshake... tudod, olyan ez, mint amikor kapcsolódsz név alapján egy szerverhez, akkor is történnek névfeloldások, a kommunikációnál pedig már indifferens, hogy mi volt a szerver neve. :/

"Továbbá, ha az általad leírt dolog igaz lenne, akkor semmi értelme nem lenne a rejtett hálózatnak (abba most ne menjünk bele, hogy amúgy se nagyon van...), hiszen SSID nélkül lehetne kapcsolódni."

Lehet is, megadhatsz csak BSSID-t is.

"Harmad részt, ha egy AP több SSID-t is szór ugyanazon BSSID-val, és te nem adod meg, hogy melyik SSID-ra akarsz kapcsolódni, honnan a bánatból tudja, hogy te melyikre szeretnél? Végigpróbálja mindet?"

Úgy, hogy az csak a handshake-nek része, aztán pedig BSSID alapon beszélgetsz...

Baszki, komolyan kérem, hogy ülj le, szánj rá néhány órát és olvasd el a szabványokat a témában. Akkor nem próbálnál így találgatni, hogy szerinted hogy működik a dolog.

--
https://iotguru.live

Mit értesz kommunikáció alatt? Mert most layer2-ről beszélünk, márpedig ott bármilyen keret kommunikáció, ha egy kérdésre vagy csomagra érkezik válasz. Semmilyen felsőbb rétegről, még IP-ről se beszélünk.
"a kommunikációnál pedig már indifferens, hogy mi volt a szerver neve. :/"
Erre is rábasztál. Szerintem pl. az apache honnan tudja, hogy melyik virtualhostot kéred tőle? Úgy, hogy benne van a kérésbe. Fingja nincs arról, hogy milyen DNS-t kértél le.
"Lehet is, megadhatsz csak BSSID-t is."
Nem válaszoltál a kérdésre, hogy honnan tudja az AP, hogy melyik SSID-ra akartál kapcsolódni? Továbbá megnézted a WPA handshake-et, hogy hogy néz ki?
"Úgy, hogy az csak a handshake-nek része, aztán pedig BSSID alapon beszélgetsz..."
De ha nem megy le a handshake, akkor nem beszélgetsz senkivel! Tudod mi van akkor? Auth failed. Bocs, de ezt a magas labdát nem hagyhattam ki.

Ha jól látom, fejlesztő vagy... Remélem nem valami network stacket fejlesztesz az IoT eszközeidben, mert ott irgalmatlan bajok lehetnek. Továbbá remélem, hogy semmilyen hálózatot nem üzemeltetsz, és soha nem is fogsz.
Tipikus példája vagy annak a fejlesztőnek, aki azt gondolja, hogy ha fejlesztő, akkor ő tökéletesen ért a hálózatokhoz, minden technikai dologhoz, az üzemeltetéshez, perfekt a linuxba meg minden egyéb. Sajna rengeteg ilyen ember után vettem már rendszereket, és takarítottam a szart, amit a hozzá nem értés szült oda az évek alatt. Továbbá képtelen vagy beismerni, hogy valamit nem tudsz, nem érted, vagy rosszul tudod, nem tudod elviselni, ha mások kijavítanak. Nem irigylem a környezetedben lévőket.
Én itt befejeztem veled a kommunikációt. Csak annyit kérek, nézz egy wiresharkot amikor a kliensed konnektál, roamingol. Nem kell leírni az eredményt. Csak nézd meg magadnak, otthon, a sarokban, amikor senki nem lát.
--
"Sose a gép a hülye."

"Mert most layer2-ről beszélünk, márpedig ott bármilyen keret kommunikáció, ha egy kérdésre vagy csomagra érkezik válasz. [...] Erre is rábasztál. Szerintem pl. az apache honnan tudja, hogy melyik virtualhostot kéred tőle?"

Akkor most layer 2 vagy nem layer 2? :)

"De ha nem megy le a handshake, akkor nem beszélgetsz senkivel!"

Így van. És?

"Remélem nem valami network stacket fejlesztesz az IoT eszközeidben, mert ott irgalmatlan bajok lehetnek."

Igen. A kettőnk között az a különbség, hogy én például olvasok doksit és szabványokat. Onnan tudom, hogy pusztán BSSID-vel tudok kapcsolódni és ilyenkor sokkal gyorsabb lesz a kapcsolódás, mert nincs tökölődés a scanning-el és azzal, hogy éppen milyen BSSID-k vannak az SSID mögött. És innen tudom, hogy a beacon interval időn belül mehet a modem sleep, amivel energiát tudok megspórolni. És így mennek a cuccaim egy darab 18650 celláról 2-3-4 hónapot. Lehet, hogy én kicsit jobban beleástam magam a 802.11 hálózatokba...

"Csak annyit kérek, nézz egy wiresharkot amikor a kliensed konnektál, roamingol. Nem kell leírni az eredményt. Csak nézd meg magadnak, otthon, a sarokban, amikor senki nem lát."

Viszont kívánom... szerintem kettőnk közül nekem több WiFi-s eszközöm van, amelyek végletekig kihasználják a lehetőségeket, de várom a gyakorlati példáidat. :)

"Továbbá képtelen vagy beismerni, hogy valamit nem tudsz, nem érted, vagy rosszul tudod, nem tudod elviselni, ha mások kijavítanak."

Próbáld ki egyszer a tükröt, lehet meg fogsz lepődni.

--
https://iotguru.live

Te keverted ide az alkalmazást az előző hozzászólásodban.

"Így van. És?"
Ahhoz hogy lemenjen a WPA handshake, kell az SSID. De egyébként magához az association request frame-hez is, akármilyen titkosítást, vagy titkosítás nélküli hálózathoz kapcsolódsz.
http://www.rfwireless-world.com/Terminology/WLAN-association-request-an…
Tehát újra megdőlt az, hogy az SSID nem kell semmire, csak egy string a usernek.

"Onnan tudom, hogy pusztán BSSID-vel tudok kapcsolódni"
Mindig BSSID-val kapcsolódsz, hiszen azzal tudod az AP-t megcímzezni. Semmi újat nem mondtál. Vagy megadsz a kliensnek egy konkrétat, akihez konnektál, vagy scannelsz, és a megadott SSID mögötti BSSID-kból választ egyet. De az SSID minden esetben kell, ott van a body-ban. De ezt írtam már pár hozzászólással ezelőtt.

Energiatakarékosság: oké, ezzel se mondtál semmit újat, vagy ellent.

"Lehet, hogy én kicsit jobban beleástam magam a 802.11 hálózatokba..."
Lehet, viszont vagy baromira nem érted, és/vagy nem tudod leírni, vagy sikerült a saját értelmezésed szerint implementációt csinálni az eszközeidre, amivel egyrészt eléred, hogy a saját eszközeid csak saját magukkal fognak tudni kommunikálni, másrészt ha mondjuk implementáltál egy saját WPA-nak tűnő valamit, és az implementációdból ügyesen kihagytad az SSID-t, mint az egyik input változó a kulcsgeneráláshoz, akkor sikerült egy jóval gyengébb és sérülékenyebb verziót implementálni, ami totálisan hamis biztonságérzetet ad. Köszi, hogy gyarapítod az IoT botnetet, és ezúton üdvözlök mindenkit, aki IoT cuccokat vesz marékszámra otthonra.
--
"Sose a gép a hülye."

"Ahhoz hogy lemenjen a WPA handshake, kell az SSID."

Nem kell. Ha nincs, és általában nincs, mert kevéssé biztonságos, akkor ANonce/SNonce alapon megy. Jajj, megint mondtam egy újdonságot, amire meg kell keresned az első találatot. Ajánlgattad a Wireshark-ot, szerintem nézz meg egy handshake-et, lehet, hogy meg fogsz lepődni.

"Tehát újra megdőlt az, hogy az SSID nem kell semmire, csak egy string a usernek."

Pedig az csak az. Mutass már egy konkrét Wireshark protokoll elemzést kérlek. :)

"akkor sikerült egy jóval gyengébb és sérülékenyebb verziót implementálni, ami totálisan hamis biztonságérzetet"

Nyilván, sérülékenyebb... ülj le egy csendes sarokba és olvass szabványt, rád fér. :D

--
https://iotguru.live

"ANonce/SNonce alapon"
Úr isten, miről beszélsz? Mert milyen "alapon" van még?
Nem ez alapon, ez a handshake. Az ANonce és SNonce kiszámolásához, megkonstruálásához kell az SSID.
https://www.ins1gn1a.com/understanding-wpa-psk-cracking/

Az, hogy nálad nem, az már a te hiányosságod.

De itt tényleg befejeztem, mert ennek semmi értelme.
--
"Sose a gép a hülye."

"Nem ez alapon, ez a handshake. Az ANonce és SNonce kiszámolásához, megkonstruálásához kell az SSID."

Az ANonce egy random szám, nem kell hozzá az SSID... minek küldje az AP a STA felé, ha mind a kettő ki tudná számolni?

A PMK jön létre az SSID-ből és a passhphrase-ből mind a két oldalon külön-külön, de ezt nem küldik sehova, viszont mivel egy viszonylag költséges hash függvény hozza létre, ezért elég egyetlen egyszer létrehozni, aztán letárolni, ezért nem kell a kapcsolódáshoz SSID és ezért nem megy át SSID a kapcsolódáskor. Nézz utána legyél szíves a 4-way handshake működésének, mert komoly hiányosságaid vannak ezen a téren, konkrétan faszságokat beszélsz, saját magad által linkelt ábrán nem tudsz értelmezni, baszod, de folyamatosan képes vagy lehülyézni mindenkit...

"Az, hogy nálad nem, az már a te hiányosságod."

Ahja, az összes implementáció szar, mert nem úgy működik, ahogy te a szabvány ismeretének hiányában elképzelted... fekete lovag szindrómád van, kérlek alássan. :)

--
https://iotguru.live

"Hát, javaslom hogy olvasgass egy kicsit a wirelessről akkor még..."

Látom sikerült megtalálnod az első oldalt, amit a Google feldob... :D

"Az ESS a BSS-ek összessége, és amit mi csak egyszerűen SSID-nak hívunk, az valójában az ESSID."

Hát nem egészen... az a helyzet, hogy faszságot írtál, beleálltál. Szar ügy, nehéz kimászni belőle... de kérlek mutass már példát arra, hogy egy kliens felmászik egy másik AP-re és úgy forgalmaz, mintha az előzővel beszélne, csak azért, mert azonosak az SSID-k. Mert a BSSID alapú kommunikáció miatt ez technikailag nem lehetséges, de kíváncsi vagyok a példádra.

--
https://iotguru.live

Oké, és te miért nem találtad meg akkor googleban? Egyébként duckduckgoval keresek, és a negyedik volt, mindegy. Terelsz.
Amikor BSSID-t vált, azt hívják roamingnak.
duckduckgo első találat: https://www.cisco.com/c/en/us/support/docs/wireless-mobility/wireless-l…
Részletes leírás, wireshark-os packet capture képekkel.
Amúgy nincs baj azzal, ha rosszul tudod, vagy nem tudod, csak akkor ismerd be....
--
"Sose a gép a hülye."

"Amikor BSSID-t vált, azt hívják roamingnak."

Kezdetek óta ezt mondom.

Innen indultunk: "amikor átmegy arra az AP-ra, amelyikre nem csatlakoztál, akkor néz mint borjú az új kapura, hogy miért nincs hitelesítve" és "A kliens SSID-hoz kapcsolódik"

Átmegy a másik AP-re és mivel annak más a BSSID-je, ezért nem néz, mint borjú az új kapura, hanem tudja, hogy nincs hitelesítve. És nem SSID-hez kapcsolódik, hanem BSSID-hez. Ezeket mind te írtad.

--
https://iotguru.live

Megadsz egy SSID-t, az alapján megnézi a kliens, hogy milyen BSSID-k szórják. Ha meg van neki adva egy konkrét arra csatlakozik, és nem is fog másikra átmenni. Egyébként választ egyet, valamilyen algoritmus alapján. Ha később egy másikra át akar menni - bármi miatt, akkor csak egy gyors handshake zajlik le, amelyben jelzi mindkét AP fele, hogy ő most innentől a másikhoz fog beszélni. Ez a roaming. Ha ez nem megy, akkor csak teljes lecsatlakozás (ip release, link down, disconnect), majd újracsatlakozás (connect, wpa handshake, link up, dhcp kérés, offer, accept) tud működni, ami jóval nagyobb forgalom, több packet, link és ezáltal minden kapcsolat megszakadása. De ha ugyanaz az SSID, akkor ezt csak akkor fogja megtenni, amikor timeoutol a handshare, és rájön, hogy a roaming nem jött össze (és ez idő), vagy amíg az AP egy deauth kerettel el nem hajtja a búsba.
--
"Sose a gép a hülye."

Nagyszerű, akkor az szerinted se fordul elő, amit leírtál: "és amikor átmegy arra az AP-ra, amelyikre nem csatlakoztál, akkor néz mint borjú az új kapura, hogy miért nincs hitelesítve", ugye?

És továbbra is az a helyzet, hogy roaming esetén ESS megléte szükséges, nem az SSID neve fogja össze ezt, különben egy ugyanolyan nevű SSID-t szóró AP-t indítva magadra tudnád húzni a klienseket, de nem tudod, mert nem az SSID számít. De ez le van írva a szabványban, amit esetleg el kellene olvasnod.

--
https://iotguru.live

De, handshake után átmegy a másik ugyanolyan SSID-t szóró AP-ra.
"különben egy ugyanolyan nevű SSID-t szóró AP-t indítva magadra tudnád húzni a klienseket"
Így van. Pontosan erről szólnak a rouge AP-k. Leteszel egy ugyanolyan SSID-val sugárzó AP-t, felcsavarod a teljesítményt, és az összes kliens rajtad lesz.
--
"Sose a gép a hülye."

"De, handshake után átmegy a másik ugyanolyan SSID-t szóró AP-ra."

Nagyszerű. Csak te nem ezt írtad, te azt írtad, hogy "és amikor átmegy arra az AP-ra, amelyikre nem csatlakoztál, akkor néz mint borjú az új kapura, hogy miért nincs hitelesítve". De ilyen nem fordul elő.

"Így van. Pontosan erről szólnak a rouge AP-k."

Nem, nem erről szólnak. Azok nyílt hálózatok esetén működnek így, vagyis nem tartoznak bele az ESS-be, így az ESA-ba sem és ebből következően nem lesz roaming sem. Baszki, olvasd el a szabványt. Legalább lesz pár óra nyugtunk addig is.

--
https://iotguru.live

Nem csak nyílt, bármilyen WPA vagy 802.1x esetén működik. Ha összeraksz egy 802.1x szervert, amit úgy konfigurálsz, hogy minden autentikációs kérést elfogad, és mindent logol, akkor szépen rád másznak a kliensek, mindenki boldogan csatlakozik hozzád, és akár a jelszavuk is meglehet (de mondjuk a felhasználónevük biztosan), és ha ezt még úgy csinálod, hogy mindeközben ténylegesen elérik mondjuk a netet, lehet, hogy a kutya nem fogja észrevenni.... Ezért van minden AP-ba, a unifitől megkezdve a cisco-ig és a juniperig rouge detect funkció, ami azt jelenti, hogy kinevezel AP-kat, akiknek az a feladatuk, hogy hallgatózzanak, hogy milyen BSSID-k szórják az ő SSID-jukat, és ha van olyan, amit nem ismernek, akkor megy a riasztás.
--
"Sose a gép a hülye."

Nézd, tényeket és érveket eddig én hoztam, például a szabványból is idézve. Te meg összehordtál mindenféle faszságot, összekeverve mindenfélét. Már így is több időm ment el erre, mint amennyit érdemes lett volna erre rászánnom. Talán mások tanulnak belőle, ha már te nem tudsz...

--
https://iotguru.live

Amit a szabványból idéztél, az az egyetlen dolog, semmilyen ellentmondás nem mond azzal, amit én mondtam. Egyéb tényt nem láttam tőled. Nem kevertem össze semmit, te vagy az, aki abba az egy mondatomba kapaszkodott, mint egy szalmaszál, amit nem egészen pontosan írtam le először, majd jöttél mindenféle hülyeséggel, hogy csak open hálózatban tud működni a rouge ap, meg hogy nem roamingol a kliens, ha lát egy ugyanolyan SSID-t sugárzó BSSID-t, meg ehhez hasonló dolgok. Mutass már egy bármilyen screenshotot, leírást, packet sniffinget, ahol az általad leírt "jelenség" látható.
--
"Sose a gép a hülye."

Szerintem nem így van, de ebben nem vagyok biztos. Jól tudja, hogy nincs hitelesítve hiszen másik BSSID-re csatlakozott, ezért újra kezdi a handshaket. Ez tud lerövidülni fast roaming támogatással (802.11r). De ehhez látni kellene a frame-eket, a nélkül nem merek semmit állítani. Egyébként nagyobb probléma, ha 1 SSID van, de valamelyik AP lecsatlakozott a fizikai hálózatról. Ezért jó stratégia, ha az eszköz ilyenkor inkább nem sugározza az SSID-t, mert pofára ejti a klienst. Például Unifi tudja ezt.

És váltott is AP-t? Mert nem biztos, hogy vált, ha a jelszint nem megy egy adott minőség/sebesség alá. Egyébként a ping ilyen szempontból nem az igazi, lehet azzal is látni a problémát, de lehet hogy pont "megúszod", mert 1mp alatt meg tud történni egy komplett reautentikáció is.
Indíts egy netrádiót, vagy valami live streamet, vagy voipot, az folyamatos adatforgalom, és úgy mozogj a géppel, hogy az egyik tuti erősebb legyen mint a másik. Akkor látnod kell a jelenséget.
--
"Sose a gép a hülye."

+1 RTP-t kell nézni, de mivel a fő stratégia a "nem váltok, míg nincs elég hiba", ezért ezen sem fog látványosan jelentkezni a hiba (hacsak nem nagy sávszélességű videokonferenciát használsz), a következőt javaslom:
ellenőrizd hogy a BSSID-t változik-e egyáltalán! Ha nem változik, akkor futtass speedtestet a különböző helyeken, utána próbáld meg ugyanezt úgy, hogy lekapcsolod a wlan-t, majd visszakapcsolod a kliens eszközön (minden mért helyen). Látványos különbségre számíthatsz..

Lehet, hogy kliens/AP-ja valogatja, hogyan viselkedik, de OpenWRT + T-Home fele Huawei router faszan mukodik.
Itthon ilyen megoldas van es egy pillanat alatt atvalt a masik AP-ra, amint erosebb jelet kap tole.
Kapcsolatok tobbsegevel semmi gond: Kodi video stream, SSH, stb, eszre sem veszed a valtast. VoIP is okes, de baromi ritkan van az, hogy hivas kozben lepcsozni kelljen.

+1 nekem is. Csatorna kiosztasra kellett csak figyelni.
Amugy nem tudom mennyit szamit, hogy ugyanaz az SSID van megadva, hiszen ettol meg 2 kulon AP-nak latja. Annyiban egyszerusiti a helyzetet, hogy nem kell 2 kulon authot kezelni, ugyanaz az SSID + jelszo es csak egyszer kell a kliensnek megtanitani.

Ennel igenyesebb megoldas tudtommal mesh halozat kialakitasa, egyre tobb consumer AP is kezdi tamogatni, szoval lehet hogy csak egy kattintas az egesz.

( fairlane | 2018. 12. 31., h – 12:06 )

VoIP kapcsolattal próbáld, azok a legérzékenyebbek a váltásra.
Én pl.: a Viberrel teszteltem, van ingyenes teszt hívószámuk (+883510001196512).

(szerk: rossz szálra ment a válasz)
--------------------------------
...úgyis jönnek...

( Huncraft v | 2018. 12. 31., h – 21:04 )

Nekem erre 2 OpenWRT-s routerem van WDS-be kapcsolva..
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

"Kétszintes házba telepítenék szintenként WiFi access pointot, mert a födémen elég gyengén szivárog át a légi közlekedésű net. Működik, de lassú."
Nálam ez azt jelenti, hogy 1 wifi AP-val is megy a kapcsolat, csak mivel gyenge a jel, így a kérdező 2 AP-val (szintenként eggyel) akarja inkább megoldani a jel erősségét. Ehhez vagy 2 külön hálózatot üzemeltet (AP-nként eggyet), vagy 1 hálózatot "nyújt" meg több AP-n keresztül. Erre viszont a WDS tökéletesen megfelel szerintem (1 master, 1 vagy több slave)
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

( veyron007 | 2019. 01. 03., cs – 18:42 )

Sub, nem gondoltam, hogy ide popcorn kell.