-
IT café
Linksys WRT54G/GL/GS router
Új hozzászólás Aktív témák
-
And
veterán
"most már legalább tudom, hogy a statikus ipket a dinamikus tartományon kívülre kell tenni."
Hát, úgy illene.
"aztán remélem, hogy ez a firmware rendesen megmutatja a statikus tartományt is."
Hogy mit csinál: megmutatja, de mit is? Mit kell a 'statikus tartományon' mutogatni? Az van, oszt' kész . Ami a DHCP-szerver számára foglalt (általa kiosztható) tartományon kívül, és az alhálózati maszk által nem kizárt címtartományban van, az használható statikus IP-nek egy alhálózatban (mod.: a 0 és 255 végű címektől most tekintsünk el).
"bár lehet, hogy az kavart be, hogy a dinamikuson belülre tettem a statikust is."
De miért úgy? Az nem firmware-függő, hogy ilyet nem kellene tenni, az sem, hogy nem konfigurálunk kettő vagy több DHCP-szervert és az sem, hogy nem osztjuk ki kétszer ugyanazt az IP-t egy alhálózatban..[ Szerkesztve ]
-
And
veterán
"eddig egy smc volt, ott a dhcp tartományán belül adtam statikust (lehet helytelenül), és működött."
Addig valószínűleg nincs gond, amíg a DHCP-szerver által osztható tartomány elég nagy, sorban oszt címeket a szerver, és te a tartomány tetejére teszel egy statikus IP-t, mert valószínűleg sosem lesz átfedés. De ha a kiosztható címtartomány kicsi, akkor simán előfordulhat, hogy előbb-utóbb mindet megkapja egy-egy kliens, aztán címütközés lesz, ha a fix IP-vel rendelkező eszköz is megjelenik a hálózaton.
"pl, hogy jól írtam be a mac addrest, vagy hogy mondjuk megváltoztassam. de mivel nem írt ki semmit, ez nem ment."
Ja igen, leesett, hogy mire gondolsz . Emlékszem, nálad valami furcsa okból kifolyólag nem látszódott a statikus DHCP-tábla. Mondjuk én ilyennel sosem találkoztam, de megnyugtatlak, hogy a statikus tartomány továbbra sem fog látszódni, csak az a kvázi-statikus címeket tartalmazó tábla, amely a MAC-addresshez kötött címeket tartalmazza. Utóbbiak ugyanis nem fix címek a szó eredeti értelmében, hiszen azokat nem te állítod be a gépeken, hanem továbbra is a DHCP-szerver osztja ki, csak mindig ugyanúgy. Tehát ezeket a címeket igenis a DHCP-szerver címtartományába kell tenni, és nem azon kívül, de ettől még nem fix IP-k. -
And
veterán
válasz KicsiPo #8758 üzenetére
Gondolom a wireless repeater-módot kiválasztottad . A manual mindenesetre azt írja a WAP54G repeater-ről: "This feature only works with the Linksys Wireless-G Router (model number: WRT54G) or another Wireless-G Access Point (model number: WAP54G)."
Remélhetően azért nem kizárólag WRT54G-vel működik.. Ha végképp nem megy, és hajlandó vagy rá, telepíthetsz rá 3rd-party firmware-t (pl. DD-WRT-vel kompatibilis), azzal eszközfüggetlenül képes lesz repeaterként működni. -
And
veterán
-
And
veterán
válasz Bandus99 #8792 üzenetére
"Mindket antenna RX es TX, vagy egyik RX masik TX ?"
Teljesen mindegy, mert amit felvázoltál, nem működhet egyik esetben sem. (Gyári és bármely 3rd-party firmware alapmódja az első, de utóbbiak közül némelyikkel rávehető a másikfajta működésre is a router.) Egy kivétel mégis akad: ha kizárólag egyetlen wifi-klienssel szeretnél kapcsolódni, és többel sohasem. Ugyanis addig, ameddig router az egyik antennájával jelet vesz a kliensgépektől, tojik arra, hogy mi történik a másik antennán, és azt szépen le is kapcsolja, mivel az egyetlen belső vevőfokozatra csak egy antenna kapcsolódhat. Csak akkor vált át a másikra, ha az aktuálisan kiválasztottról érkező jel minősége (bithibaaránya) nagyon megnő. Ezért mondjuk egy szem wifi-s notebookkal szabadon garázdálkodhatsz a saját kettéosztott birodalmadban , de ha két kliens akarná a két külön területet egyszerre használni, na az már nem működne. Erős jelszintnél valamennyire esetleg, mivel a 'lekapcsolt' antennák felé a csillapítás nem végtelen, de azért kellően nagy (az ilyen 'nem üzemszerű' működés csomagütközések, sok kliens esetén jelentős lassulás melegágya volna). A két antenna célja egyszerűen nem az, hogy a lefedettséget így növelje. A diversity működéshez - amiért kitalálták - pedig kifejezetten szükséges, hogy az antennák egyforma karakterisztikájúak legyenek, és az egymástól való távolságuk csak a hullámhossz (ami 2,4GHz-en kb. 12cm) nagyságrendjébe essen. -
And
veterán
válasz Bandus99 #8796 üzenetére
A routertől elvihető akár mindkét antenna, de az egyik is elegendő. Nyíltabb helyre, például magasabbra téve az antennát valószínűleg eleve kisebb lesz a helyi térerőingadozás, amelyet az átkapcsolással kompenzálni lehet. Természetesen nem hátrány a két antenna sem, de ez az árakat ismerve nem túl kifizetődő mutatvány.
"A masik kerdesem a gyarilag fent levo antennanak mekkora a teljesitmenye?"
A routereken szokásosan dipólok vannak, 2 dBi körüli nyereséggel, ez alól a -GL sem kivétel. Ezért a jelszint növekedése névlegesen 6 dB lehet, mindkét irányban (a router és a kliensek vétele is javul). Hogy ez mennyit számít, az nagyon függ a tereptől: ahol pont ennyi hiányzik, ott biztosan javul a kapcsolat minősége, de a jelszint ennél sokkal jobban is változhat a routertől való távolság és a pozíció függvényében. Azt is figyelembe kell venni, hogy hiába nagyobb a külső antenna alapnyeresége, a kábelezés csillapítása is jelentős lehet (pl. 6m hosszban H155 típusú koax 3dB-t csillapít). -
And
veterán
válasz Jégkokó #8826 üzenetére
Pontosan milyen típus és milyen firmware van rajta? Mert ha utóbbi még gyári, akkor azon nem fogsz tuningolni egy dekát se. Ha viszont 3rd-party fw van rajta, beléphetsz telneten vagy ssh-n is, csak úgy kicsit nehezebb lesz meglelni a szükséges nvram-változót, amit a művelethez módosítani kell (a "20mhz" helyett gondolom 20mW-ot akartál írni). Egyébként attól, hogy megnöveled a router teljesítményét, a te vételed javulhat ugyan (nem sokat), de a te kliensed jelét semmivel sem fogja jobban venni a tuningolt router, mint korábban.
-
And
veterán
válasz Jégkokó #8829 üzenetére
Hát ha nem éred el, akkor az nem egyszerű mutatvány. Mindenesetre a 20/40 MHz-es beállítás (csatorna sávszél) csakis a szabványonkívüli 108 Mbps-es "Super-G" vagy a 802.11n szabványú eszközök esetén létezik, utóbbinál is jellemzően csak az 5 GHz-es sávban. Sima 802.11b/g/a routereknél nincs ilyen.
-
And
veterán
válasz gyurczy #8860 üzenetére
A WRT54G v3-as már elég régi ugyan, de a hardvere kevésbé limitált. A v7-es csak feleakkora ram-ot és flash tárat tartalmaz, mint a v5.0 előtti hardververziók (utóbbiaknál még 16MB / 4MB volt a méret). Ráadásul a v7-es (pontosabban a v7.0) abszolút nem támogat 'okos' firmware-eket, a v3 viszont igen, ha ez szempont.
-
And
veterán
A gyári firmware sajnos nem támogatja a statikus DHCP-t (ami elég súlyos hiányosság, de ez van), úgyhogy kénytelen leszel feltenni bármilyen 3rd-party szoftvert, ha ilyet szeretnél. Vagy maradsz a full statikus, gépeken beállított egyéni IP-knél, de az nagyon kényelmetlen, én is inkább az első megoldást favorizálom.
#8882: Szerintem ezt ne az access restrictions menüben keresd, mivel az a netelérésre vonatkozik. A megoldás általában - ha nem akarjuk vagy nem tudjuk megoldani a hozzáférést, beállítást az összes kliens gépen - az, hogy az egyes fizikai portokat és esetleg a WLAN-oldalt is eltérő virtuális LAN-okhoz (VLAN) társítjuk, és az átjárást ezek között megtiltjuk. Hogy Tomato-nál ezt hogyan kell, azt nem tudom, de itt egy DD-WRT-s leírás erről: [link]. Lehet, hogy a parancsoros (telnet, ssh) módszer lényegében nem különbözik a kétféle firmware esetén, persze erre nem esküszöm meg . -
And
veterán
Mit is szeretnél pontosan? Milyen vezetéknélküli hálózati listából kellene a gépeknek eltűnniük? Az SSID broadcast-nek nincs köze ahhoz, hogy a vezetéknélküli kliens PC-k "látszódnak"-e vagy sem. Szóval itt valami nagyon nem tiszta. Ha kikapcsolod az SSID-szórást a routeren, akkor a wifi-kliensek egyszerű lekéréssel nem fogják látni az AP-t vagy wireless routert az elérhető vezetéknélküli hálózatok listájában. De attól még ha a router konfigurációs felületét nézed, a gépek ott lesznek, mint kliensek, hiszen azok . De lehet, hogy valamit nagyon félreértek.. A MAC-szűrést sem értem, hogy jön ide.
-
And
veterán
Még mindig nem tiszta: gép (PC) = kliens. Tehát az SSID-szórás letiltásával nem a wifi-kliens számítógépet rejted el a többi gép elől, hanem a routert (vagyis a router rádiós hozzáférését), éppen a kliensek elől.
"Laikus nyelvre lefordítva: átmentem a szomszédhoz és ott a saját gépem nem volt látható, viszont a két öcsémé igen, tehát a szomszéd némi rosszindulattal akár kapcsolódni is tudott volna."
Fogalmi keveredés áll fenn: milyen eszközről volt "látható" a két öcséd gépe? Egy újabb wifi-kliensről, a router menüjéből, vagy a windows-os fájlmegosztással tudtad tallózni a két gép megosztott mappáit? Nagyon nem világos, de abban továbbra is biztos lehetsz, hogy ennek semmi köze az SSID-broadcast engedélyezéséhez vagy tiltásához.
A MAC-szűrés pedig nem azt jelenti, amit az a bizonyos 'hozzáértő' valaki mondott neked. Annak az a lényege, hogy a routeren beállítható, hogy csak bizonyos kliensek tudjanak vezeték nélkül kapcsolódni, mégpedig azok, amelyeknek ismert a MAC-címe (mivel a MAC-cím elvileg, minden hálózati csatolónál, wifi-kliensnél egyedi).
Az SSID-szórás tiltása mellesleg egyáltalán nem jelenti azt, hogy nem lehet kapcsolódni, hiszen rejtett SSID-jű routerre vagy AP-re is fel lehet csatlakozni, ha egyébként tudjuk az SSID-t, vagy azt a kliens szoftverében már egyszer be lett állítva (és azzal el lett tárolva), pl. valamilyen ismert hálózat profiljában. A MAC-szűrés pedig véd ugyan valamelyest az illetéktelen használat ellen, de megfelelő eszközzel (hardverrel és szoftverrel) nagyon egyszerűen kijátszható.
(Amúgy meg gyógyulást !)
Mod. #8900-ra: Ha az "új jelszó" alatt új előre megosztott kulcsot értesz, amelyet a routeren kívül a klienseken is mindig újra beállítasz a kapcsolathoz, arra azt mondom: felesleges. Egyszer kell beállítani egy jó (értsd: kellően hosszú és kitalálhatatlan, az sem baj, ha fejben földi halandó számára megjegyezhetetlen) megosztott kulcsot a routeren és a wifi-kliensgépeken, hozzá egy valamirevaló kódolási algoritmust választani, minimum WPA(PSK)-AES-t (vagy WPA2-PSK-t), és meg van oldva. Itt a PSK jelenti a megosztott kulcsú titkosítást, vagyis azt, hogy általában kézzel kell bepötyögni a kulcsot minden érintett állomáson, a routeren és a PC-ken is. Innentől kezdve teljesen mindegy, hogy mi az SSID-d, azt változtatgatni is felesleges, hiszen az önmagában nem jelent kulcsot a vezetéknélküli hálózatodhoz, csak annak az elnevezését jelenti. A MAC-szűrés pedig a fent említett kódolási eljárásokat változtatva szinte teljesen értelmét veszti. Csak az tud kapcsolódni, aki ismeri a megosztott kulcsot, teljesen mindegy, hogy tudja-e az SSID-t, vagy alkalmazol-e MAC-szűrést. Egy hosszú és értelmetlen kulcs ma még WPA-AES és WPA2 esetén gyakorlatilag törhetetlen.[ Szerkesztve ]
-
And
veterán
Tehát azt mondod, hogy a szomszéd gépéről (?) lekérve az elérhető hálózatok listáját, azon rajta van a te hálózatod neve is (vagyis az SSID-d)? Mert a számítógépek nem lehetnek ám rajta, fogalmilag sem. Ha ez a helyzet, akkor tiltsd le az SSID-broadcast funkciót, és ne felejtsd el elmenteni utána a beállításokat a router webfelületén.
"De ha csak én tudom akkor más biztos nem fog kapcsolódni."
Ez így ebben a formában nem teljesen igaz. Oké, egy szimpla felhasználó nem fogja kihalászni a forgalomból, de ehhez nem kell túl nagy önképzés, és simán megtehető. Méghozzá kódolatlanul, hiszen az SSID az alkalmazott kulcsolástól függetlenül mindig sima szövegként rohangál az éterben pl. akkor, amikor a kliensek felkapcsolódnak a rejtett SSID-jű routerre.
Mindegy, mert mint írtam, az SSID elrejtése meg a MAC-szűrés egyszerűen bohóckodás, ha a hálózatunkat védeni akarjuk. Kulcsold le (na jó, ne WEP-pel ), és utána akár világgá is kürtölheted az SSID-t..
#8903: Ilyeneket ne . Igenis, van védelem a 'profik' ellen, mint említettem. A mai legerősebb titkosítási eljárások megtörése (hosszú kulcs esetén) nem profizmus kérdése, hanem lehetetlenség.
"Hiába van kikapcsolva az SSID broadcast, a router és gépek közötti forgalomból is el lehet lopni a jelszót, sajnos."
Ez meg simán nem igaz. A jelszó természetesen 'nincs benne' a rádiós forgalomban. Addig rendben, hogy a WEP törése nem túl bonyolult, de azért az sem 'vérpistikés' szintet takar ám, és én sem a WEP-ről írtam azt, amit.
Mod. #8906:
"Nekem a WPA-PSK van beállítva hálózat hitelesítésnek és TKIP adattitkosításnak."
Ha a TKIP kulcsolást AES-re cseréled, és baromi hosszú a kulcsod, ma még biztonságban érezheted magad. A TKIP már sebezhető (persze ez sem csak úgy hipp-hopp, hogy lefuttatom a cracktkip.exe-t , és löki a kulcsot, ahhoz azért kicsit több kell), de az AES nem.[ Szerkesztve ]
-
And
veterán
válasz Atom Maki #8910 üzenetére
Természetesen nem. Szép is lenne, ha a kulcs a forgalomban lenne . Úgy képzeld el, mint mondjuk egy jelszóval védett zip- vagy rar-fájlt: a kulcs ahhoz kell, hogy a rejtjelezett adat a titkosított fájlból kihámozható legyen. Enkódoláskor megadták a kulcsot, és a kicsomagoláshoz is kell, de ettől fizikailag még semmilyen formában nincs benne a fájlban. A kulcsot az en/dekódoló algoritmus használja, amely anélkül képtelen az eredeti bitmintát (vagyis adatot) visszanyerni. (A WEP utáni /WPA, WPA2/ wifi-kulcsoló eljárások ráadásul a tényleges titkosítókulcsot időnként változtatják, ezt az időtartamot lehet beállítani a routeren a pár hsz-szel korábban említett key renewal interval paraméterrel. Vagyis a tényleges titkosítás nem az általunk megadott előre megosztott kulccsal történik.)
#8909: Ennek nem lehet az az oka, hogy azokon a gépeken a kapcsolódási profil valamilyen formában el lett mentve? Egyes kliensekhez olyan wifi-kezelőrogramot adnak, ami akkor is mutatja a (már korábban beállított, tehát ismert) hálózatot, amikor az rejtett. A Windows-ét nem ismerem, mert sose használtam. A kliensekhez általában sokkal értelmesebb szoftvereket adnak, mint a Win beépített verziója, így inkább azokra szoktam bízni a wifi-hálózatkezelést. Tehát: a wifi-router időnként lead egy broadcast-csomagot, ez a beacon. Ez minden routerre és AP-re igaz, default ismétlési periódusa 100ms. Ez tartalmazza az SSID-t is, ha az nincs tiltva. De ha tiltva is van, a csomagban akkor is van még egy csomó hasznos adat: [link]. Mint minden 802.11 adatcsomagban, ebben is benne van a küldő állomás (a router) MAC-addresse. Vagyis ha a kliens ezt veszi, és a kezelőszoftverben el van mentve az ismert kapcsolatok profilja, akkor könnyen össze tudja társítani a profilban tárolt SSID-t a már korábbról is ismert MAC-címmel. Én így képzelem.. Ha egy olyan gépről keresel wifi-hálózatokat, amely 'tiszta', korábban nem volt beállítva benne ez a kapcsolat, akkor nem találja meg (vagy megtalálja ugyan, de SSID-t nem mutat, csak MAC-címet, ilyen például az Intel-gyártmányú belső wifi-kártyákhoz adott kezelőszoftver is). Tehát lehet, hogy az SSID-szórás ténylegesen tiltott, és nem is történik meg, de a szofver kicsit 'átver' téged. -
And
veterán
Akkor vagy kihagytad a teljes nvram-törlést, vagy hardveres nyűgje van. Több alkalommal is tettem fel már DD-WRT micro-t v5.0-ás hardverre, és sosem volt vele baj, évek óta működik egy kollégámnál. (Azért többször, merthogy néha önerőből sikerült összekuszálnom, és gyorsabbnak bizonyult úgy rendbehozni.) Igaz, a kor lehetőségeinek megfelelően még jtag-kábellel telepítettem, és akkoriban v23-as verzió volt az aktuális.
-
And
veterán
válasz GS_Laja #8927 üzenetére
Próbáltad újraindítani a routert?
A lease time meg ugye kétértelmű dolog: az egyik, hogy a szolgáltató mennyi időre adja neked a címeket, ha azokat DHCP-n kapod tőle. Namost erre gyakorlatilag nulla ráhatásod van, legfeljebb mutathatja a router, hogy mennyi még az újításig hátralévő idő, ill. újra tudod kérni, ahogy írtad. A másik a saját belsőhálózatod DHCP-szervere a routeren, ha azt engedélyezted, és a gép(ek) automatikus címkérésre van(nak) állítva. Ez viszont nem nagyon szokott gondot okozni, mert ha lejár, a kliensek egyszerűen újra kérnek maguknak címet, és kész. Statikus (MAC-addresshez fixen kötött) DHCP-nél ráadásul mindig ugyanazt kapják, így az nem lehet probléma.[ Szerkesztve ]
-
And
veterán
válasz GS_Laja #8930 üzenetére
Amikor így elmegy a neted (ill. később is érdekes, amikor rendbe jön), meg tudod pingelni a szolgáltatód első gateway-ének IP-jét, amit WAN-oldalon kapsz? Használsz a WAN felé MAC-klónozást? Ki az ISP, a T-online? Egyáltalán: router nélkül, közvetlen PC-modem kapcsolatnál is előjön ez a hiba, vagy csak routerrel?
-
And
veterán
válasz GS_Laja #8932 üzenetére
Engem az Axelero / T szívatott éveken keresztül hasonló jelenséggel. Ugyanígy kellett egy 'renew' gombot nyomni, és helyrejött, csakhogy nem 18 óránként, hanem rosszabb napokon 5-10 percenként, de volt, hogy 'csak' pár óránként, néha pedig napokig ment szakadás nélkül. Ezt három különféle gyármányú és típusú routerrel, mindenféle firmware-rel eljátszotta. A műszakiak sosem értették, miért panaszkodom, mert szerintük a kapcsolat 'hetek óta', folyamatosan élt. Egyszer még kábelmodemet is cseréltek, de eredménytelenül. Aztán egyszer kikapcsoltam a MAC-klónozást (ami T-nél sem kell), és láss csodát: a szakadások megszűntek. A tényleges okot azóta is homály fedi, gondolom az ISP is csak nézne ki a fejéből, ha megtudná, mi volt a megoldás.. Mindenesetre már a legelső gateway sem válaszolt a ping-re, amikor kimaradt a net.
-
And
veterán
Igen, a wigwam-os port teszt is épp a NAT miatt nem működik, ha nincs beállított port-forward, DMZ vagy UPNP. A Skype meg külön világ, nem feltétlenül állandó porto(ka)t használ (a rendszergazdák kedvence, elég körülményes tiltani, az én munkahelyemen sem sikerült teljesen ).
-
And
veterán
"Ez rendesen kezeli a Tvnerwork (25/10) md5 chap?"
A vonatkozó topik szerint igen, ebben a kérdésben h_143570 kolléga a szakértő. Egyébként egy rakás fajta 3rd-party firmware-rel kompatibilis. Megnézni? Hát, mondjuk működik-e , esetleg kérj rá egy nap próbát. AP-ként pedig minden wifi-router használható, konkrétan attól wifi-s, hogy tartalmaz egy AP-t is. -
And
veterán
válasz GS_Laja #8978 üzenetére
Még annyit megtehetsz, hogy megpróbálod elérni a kábelmodemed webfelületét (ez mondjuk korábban is eszembe juthatott volna), ha olyan típus, és tudod az IP-jét. A szimpla ping is árulkodó lehet. Mivel a modem a routered WAN-portjához közvetlenül kapcsolódik, ha eléred, hivatkozhatsz arra, hogy a routerrel nem lehet gond. A LAN-oldalon gondolom nincs probléma, és a többi gép / eszköz a helyi hálózatban akkor is elérhető, amikor nincs neted.
#8980: Ebből épp az következne, hogy korántsem biztos, hogy a router a ludas. Nálam is széttárta a karját az ISP, hogy náluk 'minden rendben', csakhogy a netszakadás routertől és firmware-től függetlenül jelentkezett. -
And
veterán
válasz GS_Laja #9087 üzenetére
(Nehezen tudom elképzelni, hogy a Tomato, vagy bármely más 3rd-party firmware "tönkre tegye" a routert. Már attól eltekintve, hogy ha netán a flash-elés közben akadna valami bibi, de az egy teljesen másik eset. Jtag-kábel nélkül a gyári fw visszaállítása után valószínűleg az sem derül ki, hogy valaha másik oprendszer volt rátelepítve, de még azzal sem holtbiztos.)
[ Szerkesztve ]
-
And
veterán
1.) Ha még az eredeti gyári firmware van a routeren, akkor semmit nem tudsz tenni. A teljesítmény növeléséhez valamelyik 3rd-party fw-t kell feltelepítened.
2.) A router teljesítményének növelése semmit sem javít magának a routernek a vételi képességein. Vagyis a tuningolt router ugyanolyan térerővel veszi majd a kliensek jelét, mint korábban. Az antennacsere viszont 'mindkét irányban' hatásos (még akkor is, ha az adóteljesítményhez nem nyúlsz), ettől minden résztvevő vételi jele javulhat. -
And
veterán
válasz csabszli11 #9276 üzenetére
Először is tisztázni kellene, hogy tényleg a hibás fw-e a hiba oka. Ha bekapcsolás és boot-olás után a power led abbahagyja a villogást, akkor valószínűleg nincs baja a szofvernek, de ha még percek múlva is folytatja, akkor gyanakodhatsz. Talán tftp-vel is gyógyítható, de nagyon el kell találni azt a pár mp-es időtartamot (boot wait), amely lehetőséget biztosít erre, ha egyáltalán engedélyezve van. Ha a bootloader is sérült vagy hiányzik, a tftp-s feltöltés nem fog sikerülni, ekkor marad a jtag-kábeles módszer.
-
And
veterán
válasz csabszli11 #9279 üzenetére
Korántsem biztos, hogy ez szoftverhiba, lehet, hogy egyszerűen más címre van konfigurálva. Ping-re válaszol? Be van kapcsolva a dhcp-szervere, azaz automatikus címkérésre állított, LAN-ra csatlakozó pc-k kapnak tőle IP- és egyéb címeket? Ha igen, akkor a pc alapértelmezett átjáró / gateway címén sem lehet elérni a routert?
-
And
veterán
Eggyel is működik, de úgy a router diversity-képessége elvész. Annak a hiánya pedig valamelyest ronthat a beltéri lefedettségen, főleg ha pl. sokat mozogsz egy mobil kliensgéppel. De lehet, hogy észre se vennéd a különbséget.
Mellesleg a hardveraprón is látni olyan hirdetést, amelyben valaki routerekről, wifi-kártyákról származó alapantennákat árul. Bár a leírása csak RP-SMA csatlakozós példányokról szól, a WRT54G-sorozat cserélhető antennás verzióin meg RP-TNC-k vannak, talán érdemes megpróbálni.. -
And
veterán
A -GL működhet így, de csak külső, 3rd-party firmware-rel, gyárival nem. A -G v7 viszont nem okosítható, az mindenképp csak AP-ként funkcionálhat. Egyébként sem kell ehhez konkrétan bridge-mód, hagyományos AP <-> kliens(híd) kapcsolattal is megvalósítható. Tehát ha a két routert meg tudod cserélni, és a GL-en hajlandó vagy fw-t cserélni, akkor: modem -> WRT54G v7 (AP) -> WRT54GL (kliens-híd).
-
And
veterán
Igen, de ettől nem szabad csodákat várni. A változás nem lehet annyira jelentős, a gyári beállítás 2..3-szorosa (az eredetinél 3..7 dB-lel nagyobb teljesítmény) még kijöhet ugyan belőle, de ez mindig csak egy irányban hat, vagyis a router vételi képességein semmit sem javít.
-
And
veterán
Mivel a -G v7 egy AP, és nem is lehet más, ezért kizárólag kliens-módban csatlakozhatunk rá wifi-n, máshogyan nem. A -GL-t is ezért kell kliensnek átvarázsolni, vagy ha utóbbit is vezeték nélkül szeretnéd elérni, akkor repeater-bridge-nek kell konfigurálni (utóbbi mód pl. DD-WRT-nél egy kliens és 1..8 lehetséges virtuális AP együttese).
-
And
veterán
Nem tudom, mire ajánlották a firmware-frissítést, de az egyik verziónál sem természetes (és emlékeim szerint nem is közismert), hogy nem menti el a beállításokat. Melyik volt rajta a mostani próbálkozás előtt, még a gyári? Ping-re válaszol? A power led villogása egyébként a hibás verziójú vagy elrontott / megszakított fw-frissítés tipikus utóhatása, vagyis a router nem tud boot-olni. Kétféle módszer van a javítására: az egyik a tftp-s feltöltés (ha korábban engedélyezve volt a 'boot wait' opció), erről e topikban is sokat írtak, pl.: #2125. Ha a tftp-s módszer nem válik be, akkor marad a jtag-kábeles feltöltés, ehhez viszont minimum forrasztani kell egy keveset (tüskesor a router nyákjára), meg egy szimpla és rövid kábelt kell hozzá készíteni. Erről, és a hozzávaló segédprogramokról több infó itt: [link].
elfelelytett: jujj -
And
veterán
-
And
veterán
válasz Kicsirics77 #9488 üzenetére
A WRT54G v7.0-ra sajnos nincs alternatív fw. A hardver erősen kiherélt, 2MB-os flash-tárral, ráadásul a többi verziótól eltérő Atheros chipsettel.
#9489: Természetesen lehet firmware probléma is a hiba forrása, de ez egyáltalán nem biztos. Mondjuk nem használnék egy közel két éves RC-buildet, ha egyszer van végleges DD-WRT v24 is (sőt SP1, ill. pre-SP2). Ez a stabilitás kérdés szvsz. jórészt hitvita. Nálam hónapokig képes egyhuzamban járni a WRT54GL egy DD-WRT-vel (általában konfig-változtatás vagy rövid áramkimaradás az újraindulás oka, nem pedig valamilyen bug / hiba), másoknál meg ugyanez a helyzet a Tomato-val. Egyébként Tomato-ban is van lehetőség a TX-power emelésére, de a 150mW valószínűleg erős túlzás, lehet, hogy a hardver sem tud annyit. Meg azt is vedd figyelembe, hogy ha a WRT54G-d hardververziója 5-ös vagy annál nagyobb, akkor nem fogod tudni ráinstallálni Tomato-t. Ezekre a flash-méret miatt szinte kizárólag a DD-WRT Micro tehető fel. -
And
veterán
Ha már rajtavan a DD-WRT Micro, akkor ezentúl csak az új verziójának megfelelő binárist kell ráfrissítened. DD-WRT főoldal, majd Router Database. Ide szépen beírod a típust, a WRT54G-t, majd rákattintasz a neked megfelelő hw-verzióra, a 7.2-re. Erre feljön egy ablak a választható verziókkal és build-ekkel. Itt ízlés szerint kiválaszthatod az utolsó stabil (v24 sp1 b10020), vagy béta (v24 pre-sp2 b13064) verziót, és letöldöd belőle a Micro Generic (pontosabban: dd-wrt.v24_micro_generic.bin) nevű binárist. Ezt betallózod a router fw-frissítő oldalán felteszed, örülsz .
-
And
veterán
válasz ludsimon #9539 üzenetére
(Igen, szoktam olvasni). Mit is írhatnék erre? Akkora teljesítmény kell használni, amekkora a biztos kapcsolathoz elegendő. Remélem, elég diplomatikus voltam . Nincs olyan, hogy 2km-rel odébb eltűnik a jel, persze nem mindegy, mekkora antenna kell a vételéhez.
Ja, és ahogy a kliens+szoftver (NetStumbler, inSSIDer, akármi) nem pontos mérőműszer, úgy a routerek sem pontos szignálgenerátorok, hogy percízen lehessen vezérelni a teljesítményüket. Azaz pl. a névleges adóteljesítmény négyszerezése a router webfelületén nem jelent automatikusan 6 dB-lel nagyobb indikált vételi szintet a kliensen, én legalábbis úgy vettem észre. -
And
veterán
A passzív jtag-kábel nagyon érzékeny a távolságra. Nem véletlenül írják, hogy a lehető legrövidebb kábelezéssel kell megoldani: itt pl. max. 15 említenek: [link]. Egyébként is felsoroltál négy lehetséges okot, amelyet a debrick utility írt ki, és ebből három rögtön kizárható: az első kettő, ill. ha egyszer csatlakoztatott kábellel úgymond 'normális' chip-ID-t kaptál (ellenőrizd mégegyszer, hogy név szerint kiírja-e a flash típusát, nem csak egy ismeretlen számot), akkor az utolsót is. Szóval próbáld rövid kábellel!
[ Szerkesztve ]
-
And
veterán
válasz Edebácsi #9613 üzenetére
"akárhogyis guglizok mindenhol csak azt látom hogy a gyári fw-en kivul nem lehet ratenni semmit."
Azért, mert ez pontosan így van. A v7-es (pontosabban v7.0-s) WRT54G-re nincs alternatíva. Egyéb 'térerőnövelő' beállítást sem tudsz piszkálni rajta, mert nem létezik. Csodák sajnos nincsenek, de sok függ a kliensek érzékenységétől is. Azért a szomszéd szoba még nem szokott gondot okozni ezeknek a routereknek.
#9612: A DD-WRT fórumán pár éve láttam olyan kezdeményezést, hogy elkezdték összeszedni a kompatibilis eszközökhöz való bootloadereket. De emlékeim szerint mikor sok éve egy WRT54G v5-öst (néha kényszerűségből WRT54GL-t is) kezelgettem jtag-gel, ahhoz sem a saját CFE-jét kellett használni, hanem valami totál más típusét. Ha minden igaz, egy WAP54G-é volt, ami még csak nem is router, csak egy sima AP, mégis meg lehetett vele ejteni a műveletet. -
And
veterán
válasz proradeon #9651 üzenetére
Én ezt igazán nem varrnám a Linksys / Tomato nyakába, pedig nem is azt a fw-t használom. Hogy az ISP-nél mennyi időtartamra szól lease time, azt szerinted befolyásolja a router vagy az azon futó oprendszer? Nálam is 12-24 órára oszt címet a T, de egyáltalán nem szoktam észrevenni, hogy a lejáratkor megszakadna a net (igaz, jó darabig ugyanazt az IP-t kapom meg ismét).
-
And
veterán
válasz proradeon #9653 üzenetére
Jó, akkor maradjunk annyiban, hogy nem nagyon emlékszem arra, hogy ebben a topikban visszatérő probléma lenne a DHCP lease lejáratakor bekövetkező szakadás, legyen szó bármelyik alternatív vagy épp gyári firmware-ről. Szóval ha össze lehetne kötni ezt a gondot a Tomato-val, vagy a megoldását valamilyen iptables-varázslással, annak azért csak több nyoma volna itt. Vagy ez valami konkrét hardvertípushoz köthető bug?
-
And
veterán
válasz h_143570 #9659 üzenetére
Ezzel egyetértek, de a kolléga maga említette, hogy az előző routerrel nem vette észre a szakadást, én pedig a T-ről tudom, hogy jó esetben adja vissza ugyanazt a címet, a Chello-ról nincs ilyen infóm (#9662: most már van).
#9660: én is használok fájlcserélőt, és nem szoktam észrevenni szakadást, pedig naponta minimum egyszer biztos lejár a lease time. -
And
veterán
Azt látom, hogy az 'eredeti' HairyDairyMaid-féle EJTAG Debrick Utility v4.5 verziója nem kezeli a GS v7.0-ás verzió processzorát (ami a Wikipedia szerint: Broadcom BCM5354 KFBG). Egy módosított verzió, az EJTAG Debrick Utility v2.0-Tornado-MOD (a futtatható állomány neve itt tjtag.exe) vagy e feletti verziók viszont igen, méghozzá a chipset mindkét (Rev1, Rev2) verzióját: [link]. Szóval azzal kellene próbálkoznod, főleg akkor, ha a jelenlegi debrick util-od nem ismeri fel név szerint a procit / flash-t. De erre mintha annak idején a #9611-ben rá is kérdeztem volna .
A CFE nem lehet hibás, ha egyszer el sem jut odáig a debrick util, hogy bármit is kezdjen vele. Amúgy ha sima webalapú frissítés közben szállt el, és nem CFE / wholeflash jtag-es visszaírásakor, akkor nem túl valószínű, hogy maga a bootloader is sérült volna.
#9674: A kettő közül egyértelműen a GL nyerő. Az összes G2-verzió csak 2 MB flash-sel rendelkezik, a RAM mérete pedig 8 vagy 16 MB. Ráadásul az utolsó kiadás (v1.5) egyik alternatív fw által sem támogatott, a két régebbi (v1.0 és v1.3) viszont igen. A GL-nél nincsenek ilyen 'fogyatékosságok', lásd az #1-es hozzászólás Wiki-s linkjét. -
And
veterán
"hát én ehez nagyon nem értek"
Ehhez képest már próbálkoztál a jtag-gel . Namost én azt javasoltam, hogy próbáld ki a módosított jtag util-t, hátha azzal szerencséd lesz. Mintha többektől is azt olvastam volna a dd-wrt fórumán, hogy a leggyakrabban használt ('hairydairimaid'-féle) segédprogram a késői GS-verziókhoz nem stimmel. A módosítotthoz pedig megadtam a linket. Ha pedig az beválik, akkor édesmindegy, hogy a CFE-d sérült-e vagy nem, mert jtag-gel mindenképp helyreállítható a firmware image (akár a teljes, akár egyes részei, CFE / kernel).[ Szerkesztve ]
-
And
veterán
válasz tejeskifly #9704 üzenetére
Nagyjából teljesen mindegy. A WRT54GL összesen kétféle verziót ért meg, és nincs igazán különbség a hardveres adottságaik ill. a firmware-támogatottságuk között. Egyébként csodálnám, ha új beszerzése esetén v1.0-s kiadásba botlanál..
-
And
veterán
A WRT54GC nem igazán barátja az alternatív fw-eknek. 1 MB-os flash-tárral szerelt, szinte esélytelen. Én még a gyári firmware-t sem tudtam visszatenni egy olyan példányra, amely mellett frissítés közben lehalt a PC (jtag-port sincs rajta, vagy ha mégis, arról nulla infó található a neten). A Wiki is csak olyan sikeres módosítást említ, amelyben nem konkrétan a GC érintett, hanem egy ugyanolyan chipsettel (Marvell ARM914) szerelt másik, nem Linksys routertípus.
Mod: ".. mivel ez a G-nek valami egyszerűsített változata."
Ilyen alapon az egész WRT54-család sem más, mint az alap WRT54G módosított (felturbózott vagy épp lebutított) változata. Pedig a GC-nek sajnos nem sok köze van a G-hez: teljesen más lapkakészlet, a végletekig kiherélve, minimális RAM-mal és a v2-es hardvertől kezdve egyetlen, fixen szerelt antennával.[ Szerkesztve ]
Új hozzászólás Aktív témák
● Olvasd el az összefoglalót!
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen
Cég: Alpha Laptopszerviz Kft.
Város: Pécs