Több Wifi AP ugyanazon SSID-n

 ( asch | 2018. december 29., szombat - 17:44 )

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.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

É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.

Ú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

De ha nincs olyan csodafreki, ami átmenne?

+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

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.

Egészen addig megy jól, amíg nem próbál meg a kliens roamingolni....
--
"Sose a gép a hülye."

"Simán tudnak működni ugyanazon az ssid-n" amig a sec beallitasok egyeznek!

-
Advanced testing of Golang applications

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

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

É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.

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.

"Otthoni rendszerben simán mehet ugyanaz az SSID. Nálunk (Bp. XV ker. ugyanaz az SSID, mint a monori körzetben."

Ezt most nem biztos hogy értem. Milyen SSID ugyanaz Monoron meg Budapesten? :)

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

Két telephelyen ugyanaz az ssid, tehát ha egyik helyen beállítod, a másikon is menni fog

Jah, persze, ha ugyanaz az SSID meg a security settings akkor simán felmegy több helyen is.

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

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.

Mikrotikben megoldható, hogy levágja a klienst, ha gyenge a jelszint (messze vagy az AP-tól, adott jelszint alatt megtíltja a kapcsolódást). Ekkor ismét szétnéz a kliens és észreveszi, hogy van közelebb erősebb, oda kapcsolódik.

Igen, de miert ismetled meg a kommentem alatt ugyanazt, amit irtam, csak a negativuma nelkul?
Lasd: "egyetlen lehetoseg, hogy alacsony jelerosseg eseten ledobatod, de ez meg a szeleken okoz majd problemat"

Mert nem vettem észre a folyószövegből, annyira említés szintjén volt, hogy még így is keresnem kellett :)
Oké, egyről beszélünk.

"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.

Így már okés! :) A néha néha egy hiba vagy heti 1 napot az AP-kal szívsz nagyon nem ugyanaz :)

"Mindenki hibázhat! Tudja milyenek ezek a rakéták..."

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.

Azigen :D

Ellent mondanék, Unifit használunk mindenhol, és tökéletesen működik. Ennek a controllere kezd már sajnos bloatware lenni, de szerintem egy jó példa arra, hogy lehet javaban jó appot írni.
--
"Sose a gép a hülye."

A szeleken okozzon is problemat...lokje le a retekbe a szar tereros klienst. Ha a juzer ott is fasza wifit akar, tegyen fel megegy cuccot. Vagy menjen kozelebb. Egy szar tereros kliens kinyirja az egesz apt...

Azért a CAPsMAN sokkal több, mint egy központi config, bár abban egyetértünk, hogy a roamingon nem segít.

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.

Unifi sem mindegy melyik. Peldaul UAP-LR egy marhasag, mert csak nagyobb az adasi teljesitmenye, mig UAP-AC-LR-nel jobb az antenna is (nagyobb nyeresegu).

+1
Ott is meg kell nézni hova milyen teljesítményű AP kell.

Az utóbbiból nemrég üzemeltem be egyet az irodánkban. Baromi jó! Igaz csak egy van, de ha nagyobb hálózatot kellene kiépítenem, ilyenekkel oldanám meg tuti.

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."

Ezzel vitatkoznék, simán mehet otthoni routerrel is.

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?

A gyárival, nem is frissítettem. Ami egyébként hanyagság, nézzétek el nekem:

Firmware Version:
3.16.9 Build 150729 Rel.36137n
Hardware Version:
WR1043ND v3 00000000

Erre egyetlen mozdulat az OpenWRT telepítése. Én mindenképpen feltenném (azzal is használom).

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

Hehe, épp most tettem fel. Valamiért nem indult el a LuCi, nincs Wifi, a feleségem meg épp szkájpolni akart, és csak rövid UTP patch kábeleim vannak. Úgyhogy most körülüljük a rútert, mint a tábortüzet. Romantikus.

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 :-)
--

Időnként megfeledkezek róla, hogy ez nem az én kizárólagos játékterem :-). Ritkán kritikus a net megléte, de ez épp ilyen eset volt.

Minek a router-re LuCi? Ha ráfér, legyen rajta mc, ha nem, esetleg egy nano, ha az sem, szerkeszd a konfig file-t azon a host-on, ahonnan ssh-zol rá. Amúgy az enyémen sincs webes felület, kell a fenének.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Nem kell, de anélkül meg el kell olvasni a doksit, hogy hogy kellene beállítani. Most csináltam volna először. Arra meg nem volt idő. Maradt a drót.

Meglepően beszédesek a konfig file-ok OpenWrt/LEDE alatt. Egy alapbeállítást hamar össze lehet hozni minimális doksi olvasással.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Attól tartok ha megtalálom a régi WRTGL-emet, arra már nem fér rá a LUCI, úgyhogy el fog jönni ennek is az ideje...

Arra a GL-re örülhetsz ha GUI mentes openwrt felfér, de lehet hogy az se, kínosan régi az már.

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

Biztosan nem fog. Nekem már jópár éve pihen egy dobozban szegényem. Megszolgálta az árát az biztos. Nem nagyon tudnék olyat kitalálni, amire használhatnám.

30 mbit környékén van a plafon, amit képes 100% kihajtott CPU mellett vinni. Ezt mára meghaladta az átlagos internet kapcsolat sebessége.
--

Ma összeraktam, éppen arról netezek. Egy darabig jó lesz emeleti access pointnak. Én ilyen igénytelen állat vagyok :-)

Egyébként az a tervem, hogy a belső serial portjára forrasztok egy ATMega csippet, és azzal tolom az automatizálást.

Azon lesz GUI?
--

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

"Minek a router-re LuCi?"

Benne van a standard build-ben erre az eszközre. Egyébként meg elég jól használható.

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

Snapshot-ból szoktam saját csomagkészlettel, konfiggal LuCi nélkül image-et készíteni. Nekem az ssh meg a konfig file-ok elegendőek.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

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

Mondjuk ebben van igazságod.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

"Hehe, épp most tettem fel. Valamiért nem indult el a LuCi"

Ez roppant érdekes, el kéne indulnia. Pontosan melyik image file -t tetted fel és hogyan?

--
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-ar71xx-generic-tl-wr1043nd-v3-squashfs-factory.bin

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/openwrt-18.06.1-ar71xx-generic-tl-wr1043nd-v3-squashfs-factory.bin
(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

az az archivált régi wiki, ahogy felül is írja. Ez sokkal frissebbnek tűnik
https://openwrt.org/toh/tp-link/tl-wr1043nd

Hopp, ezt benéztem. Köszi! Ha legközelebb arra járok felteszek egy ilyen rendes release-t rá.

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

Miért nem? Nekem fostalicska AP-kkal és fostalicska kliensekkel az ugyanaz az SSID, csak a csatornák széttolva amennyire csak lehet, simán működött több helyen is.

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."

Bocsánat, de nem megy át, mert nem az SSID azonosítja a kapcsolódott klienst, hanem a BSSID, ami minden AP-n más. Szóval nem történik meg az, amit most megálmodtál.

--
https://iotguru.live

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

"ha a kliens driver szar."
Én még nem láttam jó kliens drivert :)

Nagyszerű, de annyira nem szokott szar lenni, hogy másik BSSID AP-ra kapcsolódik és úgy próbál vele beszélni, ahol az előzővel abbahagyta, mert ugyanaz az SSID...

--
https://iotguru.live

Nem is állítottam ilyet.

Akkor esetleg jelezd, hogy nem a szál kontextusára válaszolsz.

--
https://iotguru.live

"A roaming megtörténik és az is megtörténik, hogy időnként ide-oda kapcsolódik, ha a kliens driver szar."
Én erre reagáltam. Te írtad és ahogy látom ebbe a szálba írtam vagy valamit rosszul látok?

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."

A drivernek ez a része az eszközhöz tartozik, vagy általános és minden eszközre alkalmas? Tehát kvázi a Linux része, vagy minden driverben benne kellene hogy legyen?

Ez driver és OS függő.

Aki vágja ezeket a dolgokat, pls elaborate! :-)

Én Intelt ismerem, ott Windows alatt teljesen driver függő. Konkrétan benne állíthatod.

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."

"802.11r/k/v és társai annyit javít a helyzeten, hogy a BSSID változásakor rövidebb a handshake"
Azért k és v ennél jóval többről szól, pont hogy a roaming-ot befolyásolhatod.
https://support.apple.com/bg-bg/HT202628

Családi házban 50+ wifis kliens? Mit akarsz te demonstrálni?

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-director2.0/topics/concept/wireless-ssid-bssid-essid.html
De van cisco is, vagy amit szeretnél.
--
"Sose a gép a hülye."

+1 "Vagyis van, ezt hívják "slendriánul" simán SSID-nek. Vagy még másképp, akkor lesz az SSID-ből "extended", ha több eszköz szórja."

É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

Igen ez nagyon jól leírja a logikai felépítést. Hol látsz ebben ellentmondást?

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

Akkor szerintem nézz meg egy beacon-t..

Hogyan tudnád egyáltalán listázni a hálózatokat?

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

Akkor hova kell?
--
"Sose a gép a hülye."

Mondjuk kezdésnek érdemes megolvasnod az ANQP protokollt és az alkalmazását.

--
https://iotguru.live

https://en.wikipedia.org/wiki/Advanced_Message_Queuing_Protocol
https://wiki.wireshark.org/AMQP
Erről beszélsz?
"AMQP is a binary, application layer protocol..."
A 802.11 meg layer2... Olyan messze van tőle, mint Makó Jeruzsálemtől.
--
"Sose a gép a hülye."

Nem AMQP, hanem ANQP, vagyis Access Network Query Protocol, ami a 802.11u specifikáció része. Látom nagyon mélyen benne vagy a témában... akarsz még mélyebbre süllyedni? Kezd a dolog fekete lovag szindrómába átcsapni. :/

--
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-phpapp01/95/cracking-wpa2-psk-in-the-cloud-3-728.jpg?cb=1304614211
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-and-response-frame.html
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-lan-wlan/116493-technote-technology-00.html
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."

Valójában ma már nem kell kinevezni, ezt tudják már AP módban is végezni (igen még Unifi is).

Igaz, de most lényegtelen. :)
--
"Sose a gép a hülye."

Aham, rámásznak, mindent logol és satöbbi... figyelj, én itt kiszállok, különben a végtelenségig tudnád folytatni a faszságok összehordását. Olvass szabványokat, jót fog tenni.

--
https://iotguru.live

Nem tudsz veszíteni. :)
Vagyis ez hülyeség, mert nem szerencsejáték, hanem tények és érvek.
--
"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."

Nem beszel ugy mint az elozovel. Ezt senki nem allitotta. Ujra kell associalnia. Meg Ubiquiti AirOS-ben sem kotelezo kitolteni a lock to MAC mezot.

Idéznék a szál elejérő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"

--
https://iotguru.live

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.

Nagyszerű. Akkor visszagörgetsz a fában a harmadik hozzászólásig, ahol az idézett dolog le van írva vagy adjak hozzá permalink-et? Aztán meg beszéld meg a szerzővel ugyanezt...

--
https://iotguru.live

Azt már nem látja senki :)
De igazad van, oda kellett volna írnom.

Üzbegaztán

:D


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

klasszikus!
--

Ha fixálod a BSSID-t, akkor soha a büdös életbe nem fog másik AP-hoz kapcsolódni a kliens, hiába szórja ugyanazt a nevű hálózatot, ergo tök felesleges a két vagy több AP. A BSSID gyakorlatilag az AP MAC címe.
--
"Sose a gép a hülye."

Nemtom, nekem 1 ping sem esett ki, direkt rohangáltam le-fel az emeleteken.

É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.

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...

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!"..

WDS???
Az nem az eredeti kérdésben felvetett probléma megoldására való.

"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!"..

Sub, nem gondoltam, hogy ide popcorn kell.