[MEGOLDVA] Wifi barangolás, ZTE internet elérés

Wireless

A már majdnem jól működő ZTE-Bladem wifi internet elérésével van gondom.

A 3 szintes családi házba a szuterinben bejövő internetet, szintenként, ap1, ap2, ap3 ossza. Az apk, LAN- on keresztül, vezetékekkel vannak felfűzve. ( internet -> ap1 -> ap2 -> ap3 ) A laptoppal bármelyik apre csatlakozom minden ok, de a telefon wifije csak az ap1 re való connectáláskor tud kimenni a netre.
Ha az ap2 / ap3 – ra csatlakozok akkor csak a belső háló gépeit látom. A ”Fing” gyönyörűen mutatja a hostokat és a paramétereit, a ”RegPon” szépen átkonnektál- barangol az erősebb dedikált wifire, de nem jut ki az internetre, csak az ap1- ről.

Az ap1- ap2- ap3, GW és DNS beállításai hasonlóak, jók, mert a laptoppok szépen kijutnak.
Mit kéne ellenőrizni beállítani a telón, mert Őt gyanusítom e hiba miatt.
- -
üdv: virtualm

( virtualm v | 2012. 10. 30., k – 14:23 )

Leegyszerűsítve, az a kérdés, hogy miként lép ki a netre a wifin keresztül a telefon?

Mi a különbség az egyik router ( ap1 ) és a másik router ( ap2 / ap3 ) között a tekintetben, hogy a laptoppot kiengedi, a telót meg nem?

Ugyanakkor az ap2 és ap3 wifin lekezelte és kiszolgálja a telefont.
--
üdv: virtualm

( virtualm v | 2012. 10. 31., sze – 16:55 )

Az agyrém tovább folytatódik. Az ap2 routerem ( 192.168.1.254 ) reggelre leszakadt az internetről, most már sem a ZTE-Blade, sem a LapTop nem tud rajta keresztül kijutni a netre.

Az ap1 routerem ( SonicWall TZ100 ) egyben tűzfal is, droppolja az alábbi csomagokat:
Header Values:
Bytes captured: 60, Actual Bytes on the wire: 60
Packet Info(Time:2012/10/31 16:15:21.432):
in:X0*(interface), out:--, DROPPED, Drop Code: 50, Module Id: 26, (Ref.Id: _6133_iboemfNvmujdbtuQbdlfu), 0:0)
IP Packet Header
IP Type: IGMP(0x2), Src=[192.168.1.254], Dst=[224.0.0.1]
Value:[0]
Hex and ASCII dump of the packet:
01005e00 0001001d 7efbd052 08004500 001c0000 40000102 *..^.....~..R..E.....@...*
d738c0a8 01fee000 00011164 ee9b0000 00000000 00000000 *.8.........d............*
00000000 00000000 f3a91fe5 *............ *

Az ap2 hirdeti magát és az ap1 droppolja, ami jogos, hogy a LAN felől senki ne hirdesse magát. Na de mi a franc ez az IGMP packet a 224.0.0.1 cím felé?

--
üdv: virtualm

Fent már történt rá utalás, ez egy IGMP General Query. Nem írtad, hogy pontosan milyen típusú ez a Linksys eszközöd, de ha állítható, és valóban nincs rá szükséged, továbbá tényleg nagyon zavar, kikapcsolhatod az IGMP-t. Ha részletesen érdekel a protokoll működése, akkor RFC 3376.

Az meg merőben furcsa lenne, ha az ap1 a saját maga által generált forgalmat nem engedélyezné. Valószínűbbnek tartom, hogy az nem is ismeri az IGMP-t, legalábbis a SonicWall TZ100 adatlapján nem találtam rá utalást.

Összefoglalva: mint láttad, a 192.168.1.254, azaz a Linksys ap2 generálja az IGMP General Queryt, és nem a telefon vagy a laptop. Azaz ha az ap1-re csatlakozol a gépeddel, akkor sincs ilyen forgalom a kliensed felől, mint ahogy eddig sem volt, de az ap2 nevű routered felől igen. Ha nem akarod vagy tudod kikapcsolni az IGMP-t a Linksysen, és zavar a SonicWall logja, akkor gyárts a SonicWallon egy olyan illeszkedő tiltó szabályt, amire nem kapcsolod be a logolást.

Az ap2 WRT610N, fw:dd-wrt, fél éve jól működik.
Az ap3 WRT54GL, fw:Tomato, 10 éve jól működik.
/ a láncolási sorrendet, tipust szerkesztettem /
Sem az ap2-őn, sem az ap3- on keresztül nem enged ki az ap1 ( tűzfala )
ha az ap1 re connectálok akkor kienged, minden eszközzel, ha az ap2-3-ra akkor egyiket sem, pedig ugyanaz a szabály: LAN->WAN , WLAN->WAN

Az IGMP nem zavarna, van még sávszélesség, csak feleslegesen nyüstöli a rendszert meg a szememet. A SonicWall- on kitudom kapcsolni, hogy ezt ne loggolja, de ez nem oldja meg az eredeti problémám.
Köszönöm a segítséged, értékelem a fáradozásod.
--
üdv: virtualm

Rendben, akkor az IGMP-s kérdést megbeszéltük. Nincs sem Tomato, sem DD-WRT a közelemben, de úgy láttam, van egy-két multicastos kapcsoló benne.

"Ha az ap2 / ap3 – ra csatlakozok akkor csak a belső háló gépeit látom"
Ebbe a SonicWall LAN interfésze is beletartozik? Azaz a Linksysek egyikére csatlakozva tudod-e pingelni a SonicWall LAN IP-jét, miközben a többi ap2-re vagy ap3-ra csatlakozó gépről igen?

"Sem az ap2-őn, sem az ap3- on keresztül nem enged ki az ap1 ( tűzfala )"
Tudnál mutatni ezekről a különböző esetekről SonicWall logot? A telefonról indítasz a Fingből IP-re pinget kifelé, például a 8.8.8.8 irányába. Ezt a SonicWall tűzfallogjában látnunk kell, ha valóban ott akad el, amikor a Linksysek egyikére csatlakozol; illetve a SonicWall wifijére csatlakozásnál ha explicite teszel egy ICMP-s megengedő szabályt logolással az ACL elejére - esetleg egész egyszerűen minden csomagot logolsz -, a nyilvánvaló eredmény mellett hasonló logbejegyzés keletkezik, és ezt a két esetet össze tudjuk vetni egymással.

Majd erre a - multicastos - dologra egyszer visszatérnék, de azt hiszem most nem ez a gond.

Igen, pingelhetőek az eszközök. Az ap2- ön lógó 192.168.1.2- ről látok minden eszközt ami a 191.168.1.0 hálózaton lóg. A 192.168.1.2- ről indított LanSurvejor is lát mindenkit, a ZTE- ről indított Fing is.

Megpróblom a ping 8.8.8.8 - at leloggolni, prezentálni.
--
üdv: virtualm

Az ap1 tűzfala a ping 8.8.8.8 - at kiengedte a laptopról, de a választ droppolta:
Packet Info(Time:2012/10/31 22:03:27.256):
in:X1*(interface), out:--, DROPPED, Drop Code: 40, Module Id: 26, (Ref.Id: _4909_txGsIboemfJqQlu), 0:0)
Ethernet Header
Ether Type: IP(0x800), Src=[18:59:33:8b:8e:2f], Dst=[ap1 x:x:x:x:x:x]
IP Packet Header
IP Type: ICMP(0x1), Src=[8.8.8.8], Dst=[192.168.0.11]
ICMP Packet Header
ICMP Type = 0(ECHO_REPLY), ICMP Code = 0(), ICMP Checksum = 9922
Value:[0]
Hex and ASCII dump of the packet:
0017c53e 92051859 338b8e2f 08004500 003c569f 00003201 *...>...Y3../..E..
615f0808 0808c0a8 000b0000 26c22e8d 000d6162 63646566 *a_..........&.....abcdef*
6768696a 6b6c6d6e 6f707172 73747576 77616263 64656667 *ghijklmnopqrstuvwabcdefg*
6869 *hi *
Ez kérés a 192.168.1.66 laptopról indult, az ap1 alól.
Névfeloldás van, a választ miért nyeli le az ap1, nincs ilyen szabályom?

Az ap2 alól indított ping 8.8.8.8 válasza is hasonló:
Packet Info(Time:2012/10/31 22:21:53.720):
in:X1*(interface), out:--, DROPPED, Drop Code: 40, Module Id: 26, (Ref.Id: _4909_txGsIboemfJqQlu), 0:0)
Ethernet Header
Ether Type: IP(0x800), Src=[18:59:33:8b:8e:2f], Dst=[ap1 x:x:x:x:x:x]
IP Packet Header
IP Type: ICMP(0x1), Src=[8.8.8.8], Dst=[192.168.0.11]
ICMP Packet Header
ICMP Type = 0(ECHO_REPLY), ICMP Code = 0(), ICMP Checksum = 4655
Value:[0]
Hex and ASCII dump of the packet:
0017c53e 92051859 338b8e2f 08004500 003c2ce9 00003201 *...>...Y3../..E..<,...2.*
8b150808 0808c0a8 000b0000 122f4318 00156162 63646566 *............./C...abcdef*
6768696a 6b6c6d6e 6f707172 73747576 77616263 64656667 *ghijklmnopqrstuvwabcdefg*
6869 *hi *

Lehet, hogy rosszul értelmezem a dolgot, de úgy látom mintha eltévedne a válasz, mert az ap1 tűzfal WAN portja Dst=[192.168.0.11] van megcímezve, holott nem Ő volt a forrás, nem Ő volt a kérő.

( A T-Home miatt a 192.168.0.11 - ről NAT-ol az ap1 a 192.168.1.0 tarományba, de azt hiszem, hogy ez most mellékes. )
--
üdv: virtualm

"úgy látom mintha eltévedne a válasz, mert az ap1 tűzfal WAN portja Dst=[192.168.0.11] van megcímezve"
A Cisco szempontjából a címzett a 192.168.0.11 a SonicWall WAN "in:X1*(interface)" interfésze, mivel a LAN felől a WAN felé tartó forgalomra source NAT-ot alkalmaztál a router WAN IP címével. A SonicWall a NAT táblája alapján a válaszcsomag célcímét a LAN interfészén visszafordítja az eredeti címre. Feltéve, hogy az ICMP Echo Reply be van engedve a tűzfalon. Nálad úgy tűnik, nincs. Két választás kínálkozik: vagy beengeded, vagy a tesztelést mondjuk TCP/80-on folytatod (pl.: 195.228.252.138). Persze bármilyen olyan forgalomtípus jó a teszteléshez, ami a laptoppal nézve gond nélkül megy.

Megjegyzés: a SonicWall MAC címét felesleges kitakarni, mivel nem szenzitív adat, valamint az Ethernet frame-ben amúgy is ott van.

"Az ap1 tűzfalon engedélyeztem a Multicast, IGMP csomagokat."
Azt mondtuk, hogy az IGMP témát egyelőre félretesszük, ha majd megy a telefonos forgalom, utána visszatérhetünk rá. Mindamellett téged az ap2 által kibocsátott IGMP forgalom zavart, tehát inkább ott kellene letiltanod, semmint az ap1-en engedélyezned, mert így a Linksys mellett már valószínűleg a SonicWall is küldeni fogja.

"Hogyan kéne folytatnom a tesztelést?"
Először arról, hogy hozzávetőlegesen milyen esetek lehetségesek a Linksysekre kapcsolódó telefon nem működő kommunikációjával kapcsolatban. Nagyjából, és néhol elnagyolva:
a) a telefon nem látja a LAN-t L2-ben: kizárva, mert a LAN-on lévő gépeket látja
b) a telefon nem látja a LAN-t L3-ban: kizárva, mert a LAN-on lévő gépeket látja
c) a telefon nem ismeri a SonicWall LAN IP-jét (default gateway): függőben
d) a telefon nem ismeri a SonicWall LAN interfészének MAC címét (ARP): ha jól vettem ki a fentiekből, akkor a ZTE-ről pingelhető a SonicWall LAN
e) a SonicWall-hoz nem ér el a telefontól az IP forgalom: kizárt a d) miatt
f) a SonicWall tűzfala megtiltja, hogy a telefon IP-jéről az internet felé forgalom továbbítódjon (firewall): függőben, nincs tűzfallog
g) a telefon nem tud DNS nevet feloldani, de az IP-re indított forgalom megy (DNS): függőben
h) a telefonról az internet felé indított forgalom kilép a SonicWall WAN oldalán, de rossz IP-vel (NAT): függőben
i) a SonicWall tűzfala megtiltja a kapcsolat visszirányát (firewall): függőben, nincs tűzfallog
j) a SonicWall eldobja a visszirányú forgalmat ismeretlen session miatt (NAT): függőben
k) a SonicWall eldobja a visszirányú forgalmat ismeretlen cél MAC cím miatt (ARP): függőben
l) a SonicWall rossz interfész felé küldi a válaszcsomagot: függőben
m) a SonicWall felől visszaindul a csomag, de a telefonhoz nem érkezik meg: függőben

És most arról, hogy mit kellene tenni:
Körülbelül a fenti lista alapján végigkövetni egy csomag útját, és az egyes tapasztalatok alapján kizárni az ezzel összefüggő hibaokokat. Az előző hozzászólásodban csak a működő laptop forgalmát nézted - ráadásul az ICMP meg is akadt az i) esetnél -, de a telefon által generált forgalommal még nem vetetted össze, pedig ez lenne a cél. A laptop működik, a telefon nem. A laptop forgalma látszik a tűzfalon - bár nincs a kimenő forgalom logolva, csak a visszajövő -, és a telefonnal mi látszik?

Több helyen tudod követni a kommunikációt, Linksys MAC address tábla, SonicWall MAC address tábla, ARP cache tábla, ha jól látom, van Connections Monitor, Packet Monitor (capture) is, ez utóbbit már leírtad egy előző topikban.

Köszi a további útmutatást, amint időm engedi dolgozom a feladatokon. Sajna el kell mennem itthonról, de alkalmasint beszámolok egy- egy függőben maradt lépés eredményéről.

"a) a telefon nem látja a LAN-t L2-ben: kizárva, mert a LAN-on lévő gépeket látja" ezt kifejtenéd hosszabban mert lehet, hogy félre értettünk valamit, én biztosan, legalábbis így nem értem.

b) majd az "a)" szerint értelmezem

c) de igen, a telefon a Fing- es scan után látja a gateway: 192.168.1.1 ( ap1 - SonicWall - tűzfal ) és a DNS : 208.67.222.222 - jól látja, de még sincs név feloldás.

d) A ZTE minden eszköznek megolvasta a mac addresset, pingelés: függőben

e) úgy láttam, hogy a ZTE forgalma kijut a WAN- ra, de a vissza irány droppolva van, loggolás: függőben

f) ?

g) a telefon nem tud DNS nevet feloldani, de az IP-re indított forgalom megy (DNS): ez így igaz

h) ?

i,j,k,l ) : függőben, de gyanítom, hogy így van

m) ?

--
üdv: virtualm

Az ap1 tűzfalon beállítottam, hogy mindent loggoljon, a displayre le tudom majd szűrni, akár külön is, az ICMP csomagokat.

Amit nagyon nem értek, hogy kívülről elérem az ap2- őn és az ap3- on lógó eszközöket, de belülről meg nem tudok kimenni a laptoppal és a telefonnal, pedig a tűzfalon nincs erre tilalom, igaz, hogy a bejutásra van külön szabály, de kifelé mehetne mindenki.
--
üdv: virtualm

( virtualm v | 2012. 11. 01., cs – 14:17 )

Hoppá, ha a telefon az ap1- re connectál és onnan indítom a Fing- scant akkor nem látja az ap2 és ap3 routereket.

Ha az ap2 vagy ap3- ról indítom akkor lát mindenkit.

Jól gondolom, hogy valójában az ap1 nem látja valamiért "rendesen" a másik két routert és a miatt halnak el a válaszok?
--
üdv: virtualm

"Az apk, LAN- on keresztül, vezetékekkel vannak felfűzve. ( internet -> ap1 -> ap2 -> ap3 )"

 
  


L1, L2, L3: kábeles eszközök a megfelelő számú eszközre csatlakoztatva
W1, W2, W3: wireless kliensek a megfelelő számú eszközre csatlakoztatva
T: ZTE Blade telefon


Cisco EPC3925
  (WAN, x.x.x.x/x)
  (LAN, 192.168.0.11/24)
    │
    │ SonicWall TZ100, ap1
    └── (WAN, X1, 192.168.0.11/24, NAT outside)
        (LAN-WLAN bridge, X0, 192.168.1.1/24, NAT inside)
           ├── (WLAN)
           │      └── W1 (192.168.1.x/24)
           └── (LAN)
                 │└── L1 (192.168.1.x/24)
                 │
                 │  Linksys WRT610N, DD-WRT, ap2
                 │    (WAN, nem használt)
                 │    (LAN-WLAN bridge, 192.168.1.254/24)
                 │      ├── (WLAN)
                 │      │      └── W2 (192.168.1.x/24)
                 └──────┴── (LAN)
                              │└── L2 (192.168.1.x/24)
                              │
                              │  Linksys WRT54GL, Tomato, ap3
                              │    (WAN, nem használt)
                              │    (LAN-WLAN bridge, 192.168.1.x/24)
                              │      ├── (WLAN)
                              │      │      └── W3 (192.168.1.x/24)
                              └──────┴── (LAN)
                                           └─── L3 (192.168.1.x/24)




   ?
   └───  T (192.168.1.x/24)

A felrajzolt struktúra tökéletes!
A ZTE connektálhat mind három ap- re ( barangolhat ) de csak az ap1- ről jut ki az interNET- re, csak ott kap választ. Ő az ap1- ben dedikált része a WLAN csoportnak.

Az ap2- ap3- ról indított kérései kimennek, de nem kap választ.
A LapTop- om ugyanígy, válasz nélkül marad.( bocs, de mennem kell, majd jövök )
--
üdv: virtualm

Kezdek egy kicsit belegabalyodni, hogy ki mit mikor lát.

Légy szíves nézd meg a fenti ábrát, és ha valami nem stimmel, szólj.

Eszköztípust tekintve két eset van: számítógép és telefon (T).
A csatlakozás módját nézve két eset van: vezetékes módon csatlakoztatva (L) és wifin (W).
A csatlakozás helyét tekintve három lehetőség van: ap1 (SonicWall), ap2 (WRT610N) és ap3 (WRT54GL).

A topikban eddig elhangzott állapotok a következők:

1.)
"A laptoppal bármelyik apre csatlakozom minden ok, de a telefon wifije csak az ap1 re való connectáláskor tud kimenni a netre."
Tehát a kezdeti állapot szerint nem ment a T2->internet és T3->internet, de jó volt az összes többi Lx->internet, Wx->internet, valamint a T1->internet.

2.)
"Az ap2 routerem ( 192.168.1.254 ) reggelre leszakadt az internetről, most már sem a ZTE-Blade, sem a LapTop nem tud rajta keresztül kijutni a netre."
Tehát ezek nem mennek? L2->internet, W2(T2)->internet; L3->internet, W3(T3)->internet
Viszont jó a W1(T1)->internet, és az L1->internet?

3.)
"ha a telefon az ap1- re connectál és onnan indítom a Fing- scant akkor nem látja az ap2 és ap3 routereket."
Akkor jelenleg ezek a viszonylatok nem mennek: T1->AP2, T1->L2, T1->W2; T1->AP3, T1->L3, T1->W3?
A 2.) pont fennáll ezzel egyidőben? Azaz a Linsysek és a SonicWall között látszólag teljesen megszakadt a kapcsolat mindkét irányban kezdeményezett kapcsolatnál? Erre a legegyszerűbb magyarázat az ap1-ap2 kábel szakadása, vagy a SonicWall bridge nem működése lenne.

1);2);3) igazak.
Nem, sajnos nem ilyen egyszerű a helyzet. A kérések kijutnak a netre, ap2 és ap3- on keresztül is de a válaszokat a csudálatos kis ap1 droppolja.

Egy elvi kérdés:
Ha a Telefon csatlakozik az ap3 wifijére, aminek a wifije WLAN brigged a LAN- al akkor a csomag a LAN- on keresztül mint lan eszköz csomagja utazik és koppan az ap1- en aki szigorúan figyeli a LAN és WLAN csoport tagságot a dedikált mac addresse alapján, nem lehet itt ellent mondás és a válasz csomag eltévedése, hogy nem engedi olyan helyre ami nincs?

Az ap1 ( SonicWall ) rettenetesen bonyolult módon ( 1500 oldal UM ) setupolható, de jól debuggolható, igaz, hogy az sem egy kattintás, időigényes, de megoldható hogy felkutassam a csomagutat, ha tudom, hogy mit és hol keressek. Na itt vannak hiányosságaim.
--
üdv: virtualm

Mindegy, hogy a telefon melyik AP-ra csatlakozik, a SonicWall-hoz a csomag a telefon saját MAC címével és IP-jével ér el.

"szigorúan figyeli a LAN és WLAN csoport tagságot a dedikált mac addresse alapján"
És a telefon MAC címe mindkét csoporthoz hozzá van adva?

"hogy az Ő laptopjával kapcsolódjon le az ap1- ről és csatlakozzon az ap3- ra [...] és azt látom, hogy az ap1 ki sem engedi a kérését"
Ha a laptop az ap1-en is wifivel volt fent, és az ap3-ra is így csatlakozott, akkor a helyzet az előző esethez hasonló, két eltérő fizikai interfészen (zónából?) jönne ugyanaz a MAC és IP. Fel van véve mindkét listába?

Ez a MAC szűrés a SonicWall LAN-ján és WLAN-ján okozhatna csomageldobást. De azt nem magyarázza, hogy ha egyszer kiengedett valamit, akkor azt a kapcsolatot miért nem engedi vissza. (Ennél már csak interfészhez vagy zónához rendelt statikus ARP jutna eszembe, de ezt zárójelbe is teszem, remélem nincs ilyen.)

Picit helyesbítek: a mac azonosítás a rádiós oldalon van, W0 interface, az IP cím azonosítás a LAN csoportnál van, X0 interface. Igaz, hogy a W0 és X0 brigged, egy subnetbe ( 192.168.1.0/24 )van fogva és valóban az eszköz ( telefon és laptop ) azonosítva kijut ap1- en keresztül, tehát visszafelé is jónak kéne lennie.

Ezt az ARP listát megnézem, gyanús emlékem szerint interfacehez van rendelve. És akkor mi van ha igen?
--
üdv: virtualm

Lehet hogy megérkeztünk. Előrebocsátom, hogy nem ismerem a SonicWallt és a lelkületét.

Az lenne az ésszerű, hogy ha statikus ARP van, akkor az a bridge interfészre legyen beállítva, ha ilyet lehet. (A bridgetag L2 interfészekre a statikus MAC lenne logikus.)

Próbaként vedd ki ezt a statikus ARP-t, mert lehet, hogy a SonicWall elfogadja az IP-t és a MAC-et forrásként másik interfész felől is, viszont célként mindenképpen a megadott interfészre küldi a csomagot.

OK, megnézem, hogy mit tehetek ez ügyben, de csak holnap délután este tudom tesztelni illetve az eredményt publikálni, addig olvasok.

Próbaképpen felvettem a telefont másik ip címre a másik interfacere, ha ott kezd communikálni lehet, hogy elfogadja, majd holnap meglátom.
--
üdv: virtualm

Beraktam a telefont és a laptoppot az Anti-Spoof objektumok listájábaba, a két féle IP cím használat miatt.

Érdekesség, hogy a DHCP server beállíthatóan csak az X0- interfacere oszt címet, pedig eddig a wifis cuccok akik címet is kaptak a W0 interfacen vannak dedikálva. Hümm, ezt sem értem, na majd meglátjuk mire mentem evvel a gányolással.
--
üdv: virtualm

"Lehet hogy megérkeztünk" - igen, valószínű, hogy megérkeztünk. Két napig, a szabadidőmben olvastam és gyomláltam, flush- eletem, purge- áltam az ap1 ( SonicWall ) beállításait, mire az első funkcionális tesztek jók, pozítívak lettek. Még nem tudtam teljeskörű vizsgálatot végezni, de majd holnap azt is megejtem és beszámolok róla.

A tanácsodat követve az ARP táblát kitakarítottam, ami ebben az OOP- ben nem volt egyszerű, a Statikus DHCP beállítást, dinamikusra raktam, a végeredményt tekintve, a gyors teszt alapján jónak tűnik. Holnap ezt megismétlem a LapTop paramétereivel is, remélve, hogy az is ugyanígy működni fog. ( @stra írtam üzit )
--
üdv: virtualm

( W3ber | 2012. 11. 01., cs – 16:15 )

Most mind 3 Router és AP egyben,és sorba vannak kötve?
Masquerade?megy?

Mivel látszólag mindenki a 192.168.1.0/24-ben van, nem valószínű, hogy a Linksysek routerként funkcionálnának, valószínűleg a LAN switchen keresztül vannak sorba kötve. Masquerade, azaz source NAT véleményem szerint csak a SonicWallon (ap1) - és a Ciscon - van. De várjuk meg a topiknyitó válaszát.

Várjuk várjuk:)
Ap2,AP3 ba mindent kigyomlálnék.
Ugye mivel routerek Tomato és DD-wrt.Bár én openwrt-vel csinálnám.Sonicwall
Így ránézésre én routing problémára tippelnék.Ap2,és AP3 nak gwnek a AP1 kéne megadva lenni.Dns szint úgy.Sonicwall osztaná ipket és kész.:)
Sőt ha wan portokat használna akkor külön ,külön adna staticus ipket és akkor nem lenne gond.
Az se világos DHCP kiszolgáló milyen tartományt oszt.
1.Tesztkör APk látják e egymást megy e pingelés egymásra,netre,neveket feloldja e.

Na most tegyük tisztába amit írtál.

Alapvetően - elképzelhető egyéb trükkös megoldás is, most ettől tekintsünk el - kétféle topológia lehet: a teljes hálózat bridge-elt, egy L2 hálózat, vagy pedig részben vagy teljesen route-olt, L3.

Ha WAN portokat használna a két Linksysen, akkor az első esetben mindegyiken WAN-LAN-WLAN bridge kell, ha pedig a második eset van, akkor a Linksys WAN hálózata (192.168.0.0/24) nem lehet azonos a LAN ill. WLAN interfészén lévő hálózattal, márpedig írta, hogy a LAN v. WLAN oldalon lévő eszköz is ebbe a tartományba tartozik, és látja a teljes 192.168.0.0/24-et.

"Ap2,és AP3 nak gwnek a AP1 kéne megadva lenni"
Az AP-ként használt routerek LAN IP-je, és a gateway-e érdektelen a kliensek elérése szempontjából. Ha meg router, akkor az AP2-nél természetes, az AP3-nál meg topológiafüggő, hogy AP1 vagy AP2.

"Ap2,AP3 ba mindent kigyomlálnék."
Azért feleslegesen ne gyomláljunk, ugyanis az eredeti felállás szerint már legalább fél éve mindennel működött ez a topológia, csak most az új telefonnal nem. (Más kérdés, hogy azóta úgy tűnik, rosszabb lett a helyzet.).

A SonicWall-os linket nem teljesen értem, ha jól tippelek, a "Virtual Access Point" célja alapvetően a több SSID kezelése, de mivel háromszintes az épület, valószínűleg a SonicWall rádiós teljesítménye nem elégséges, két szinttel feljebb mindegy hogy hány SSID-t nem látna. Ezért használ még két AP-t. Ezen viszont a VAP nem segít.

Egyelőre nem tudjuk, hogy hol a hiba, de ha a SonicWall a visszajövő forgalmat dobja el ("A válaszok az ap1- ben droppolódnak."), akkor kifelé rendben átment a telefonon és az AP-kon, visszafelé meg nem csak a telefonra tartva nem ért el hozzájuk, ergo a csomagvesztésben jelen tudásunk szerint nincs szerepük.

A laptop és a telefon "hasonlóan" viselkedik, az ap2 és ap3 ra connektálva nem kap választ mert az ap1 droppolja. Ez van most.

Az őrület az, hogy 2 nappal ezelőtt a LapTop, úgy mond kijutott, kapott válaszokat, jól barangolt az ap1-2-3 között. Most csak az ap1- re connektált készülékek kapnak választ, az ap2- ap3- ra connektált felé nincs válasz. Tudom, hogy nevetséges, de reggelre meg, a laptop kérése ugyanúgy válasz nélkül maradt mint a telefoné.

Tudtommal rajtam kívül senki nem bizerálgatja az otthoni kis hálózatom beállításait, de "mindig a férj tudja meg utoljára" tartja a mondás.
--
üdv: virtualm

"a ZTE statikus dhcp címet kapja rendesen, bárhonnan kéri, ( .211 )"
"Ő az ap1- ben dedikált része a WLAN csoportnak."
"A válaszok az ap1- ben droppolódnak."
Ez azt jelenti, hogy a telefon és a SonicWall közötti kapcsolat jó, a SonicWall elfogadja a LAN és a WLAN felől is, kiengedi, de a választ eldobja. Ez tűzfal vagy NAT problémára utalna.

Most jön a jolly-joker kérdés: a SonicWall újraindítása után is ugyanez a helyzet?

Akkor most az ap1 ( SonocWall- t ) távolról újraindítottam, majd megkértem a feleségem, hogy az Ő laptopjával kapcsolódjon le az ap1- ről és csatlakozzon az ap3- ra ( mert helyileg arra tud és a a hálózat vége )ezt loggoltam és azt látom, hogy az ap1 ki sem engedi a kérését, tehát ez egy új infó.

Mivel távol vagyok nem igazán tudom most érdemben folytatni a hibakeresést, csak agyalok az eddigieken.
--
üdv: virtualm

( virtualm v | 2012. 11. 02., p – 04:43 )

A történések jobb nyomkövetéséhez be kellene üzemelni egy logservert, ami lenyelné az ap1 syslogd ( :512 ) által küldött logokat. Van egy állandóan futó, ( kissé terhelt ) xp_32 vagy alkalom szerűen futtatnám a ws2k8 alapú HomeServer 2011_x64 - et.

Tudtok erre ajánlani valami egyszerű de nagyszerű free logserver programot? ( ne 30- 90 naposat )
--
üdv: virtualm

Hello!

Tiszteletem stra :)

Ha megengedtek egy pár megjegyzést, igaz csak futólag olvastam végig a dolgokat, de szerintem már elvesztek a kevert részletekben:
- minek ennyi AP, megfelelő tuninggal át tudod lőni a födémeket még G-s módban is, kivéve ha nem ólómból építkeztek.
- ezzel nagymértékben egyszerűbb lesz a hálózatod
- DD-WRT forever
- DD-WRT-hez van log lehetőség
- Használj dinamikus ARP-ot, bizz ebben nem ettől fogják törni a rendszered...
- Megfelelő WPA2-PSK kulcs használata

Sose bonyolítsd túl azt amit nem szükséges...a lehető legkevesebb eszközzel oldd meg, az a kihívás, és nem utolsó sorban olcsóbb megoldás is.

TomSoft

A javaslatok mindig jól jönnek (jobb későn mint soha).
- minek ennyi ap ?
Ha tuningolt rádióval fel is küzdöm a jeleket, akkor meg switchet kellene használnom a LAN- on lógó eszközök miatt. Ahogy belaktuk a házat ( 10 év alatt ) úgy alakult hozzá az eszközállomány és a struktúra. E közben szolgáltató váltás is lett, ami még tovább növelte a bonyodalmakat. Tudod, a "nemzetközi helyzet fokozódik" !

Eddigi, néhány routeres és háromszor annyi fw- es tapasztalatom alapján, azt tudom mondani, hogy eddig mindegyik routerrel, firmware- rel volt valami bajom, valami hiányérzetem, kínom. Ezek a kinlódások rákényszerítettek az olvasásra, a fórumozásra és így ismertem meg néhány tiszteletre méltó, segítőkész szakembert is. Mindez nem történt volna meg ha jól találom ki, megveszem, bedugom és működik. Az egy olcsó és múlandó sikerélmény lett volna, de ez így bevésődik, ismétlődik, variálódik és ettől válik a számomra élménnyé, amit jó újra megélni, csak egy kicsit másképp.

Amúgy teljesen igazad van, én is az egyszerűsítés híve vagyok. Úgy vettem észre, hogy az infomrmatikában, az olcsó húsnak mindig híg a leve.
--
üdv: virtualm

Mint ahogy mindenben, nem csak az informatikában: "A legolcsóbb a legdrágább..."

Ha megfogadsz egy tanácsot, sose vegyél olcsó eszközt, inkább ha nincs pénzed most a drágára várj, és tedd rá félre! Sok bosszúságtól fogod megkímálni magad, és nem utolsó sorban meg fogod majd látni, hogy ez lesz az olcsóbb!!!

( virtualm v | 2012. 11. 05., h – 20:04 )

Megtörtént a teljeskörű, funkcionális vizsgálat ami pozitítv eredménnyel zárult. @stra útmutatása alapján az ap1 ( SonicWall ) statikus ARP bejegyzését és függőségeit megszüntettem, így a ZTE kérésének válasz csomagjai visszataláltak a kérést indítóhoz, tehát a probléma[MEGOLDVA]

Ami egy kicsit elvileg zavar, az a LapTop esete, amit ugyanúgy meghagytam statikus bejegyzésűnek, nem nyúltam semelyik beállításához és az is "megjavult" , olyan lett mint a ZTE leszakadása előtt volt. Jól barangolt az ap1-2-3 között. Azt gyanítom, hogy nem a statikus / dinamikus beállításon múlt a dolog, hanem egy ismeretlen hiba miatt jött létre ez az állapot. A router Red Hat linux alapú, a router fejlesztői az DHCP és ARP managment felületre raktak Purge és Flush gombokat, na ezek használata oldotta meg a problémát. Azt, hogy belül mi zajlott a purgálás során igazán nem tudom, de ez a két linuxos click jót tett velem az biztos.

@stra, mégegyszer köszönöm hogy irányt mutattál a tévelygős utamon.

--
üdv: virtualm