-
IT café
Linksys WRT54G/GL/GS router
Új hozzászólás Aktív témák
-
And
veterán
válasz scourge #9763 üzenetére
Ha már ennyit szívtál vele, én a jtag-kábeles megoldást próbálnám a helyedben. Persze ahhoz forrasztgatni kell, de tapasztalatom szerint nem háklis a CFE fajtájára (már ha tudjuk a bootloader default IP-jét), és jóval biztosabb módszer, mint a küzdelem a TFTP-vel. Próbáltam már GL-en ill. G v5-ön, és ugyanazzal a CFE-vel (ami eredetileg talán WAP54-es access point-hoz tartozott) mindkettőn sikerült a művelet. A WRT54G v5 pedig tényleg VxWorks-szel jött gyárilag, de akkoriban még nem létezett a VxWorks killer, ezért csak jtag-gel lehetett DD-WRT-t rávarázsolni.
-
And
veterán
válasz zsolt501 #9780 üzenetére
Na, hogy ne haljak meg tudatlanul, kimértem a GL v1.1-esem fogyasztását a gyári adapterével: átlag negyed amper, csúcsban (Tx-pwr: 70mW) pedig 0,28..0,29A. Gyakorlatilag évek óta folyamatosan működik, a 0,5A terhelhetőségű tápja pedig legfeljebb 40°C hőmérsékletű lehet, kb. kézmeleg.
Mod. #9781: azért azt a 12V-os tápot biztosan stabilizátorok alakítják tovább a belső áramkörök számára, tehát plusz-mínusz pár volt különbség nem hiszem, hogy számítana. Ha viszont 19V-ig elmegy, az meg már erősen nem normális kategória. Az előbb említett 0,25A-es terhelésnél az én adapteremen (a router tápcsatlakozóján) 13,65V körüli feszültség mérhető.[ Szerkesztve ]
-
And
veterán
válasz zsolt501 #9784 üzenetére
A mérésnél szépen megvártam, míg teljesen feléledt. Nincs minden LAN-port használva (nem hinném, hogy ez jelentős mínuszt jelentene), ellenben a wifi teljesítménye a default érték több, mint kétszerese. Az várható, hogy a táp terhelhetőségének csak a töredéke legyen kihasználva, ilyen kütyük adapterét azért nem szokták határra tervezni. A táp üresjárási feszültsége különben 16,2V-os.
-
And
veterán
válasz Palika87 #9790 üzenetére
Két reális lehetőséget látok: 1.) Kültéri antenna (lehet körsugárzó) kihelyezése a tetőre vagy a padléstérbe, a router saját antennáinak eltávolítása után. A csatlakozást meg kell oldani csatlakozó-átmenettel vagy rövid pigtail-kábellel. Megfelelő kivitelben egyik sem okoz észrevehető pluszcsillapítást. 2.) Újabb AP (vagy AP-ként alkalmazott router) telepítése a kültéri lefedettséghez, olyan helyre téve, amelyből a kert jól lefedhető (pl. a már említett padlástér), esetleg az előző javaslathoz hasonlóan külső antennát csatlakoztatva hozzá. Mindkét módszernek van előnye és hátránya: az elsőnél a beltéri jelerősség csökkenhet (de jó esetben mégis megmarad a lefedettség), a második módszer pedig ugyan korrektebb, de nem a legolcsóbb.
Az említett antennacserével is próbálkozhatsz, de én ahhoz (a routert a jelenlegi helyén hagyva) nem sok reményt fűznék, ráadásul a diversity-képesség megmaradásához mindkét antennát le kellene cserélned, ha olyan routered van. -
And
veterán
válasz Palika87 #9792 üzenetére
Fw-cserével egyetlen dolgot tudsz befolyásolni, és az a router kimenőteljesítménye. Ez javíthat valamelyest a klienseken mérhető térerőn, de ez visszafelé sajnos nem igaz, vagyis a router vétele ettől nem javul. Magyarul: egy jó helyre telepített, nagyobb nyereségű antennára cseréléssel az előbbi módszer közelítőleg sem ér fel.
"Több helyen olvastam már h pl tomato-val meg lehet adni h melyik antenna adjon vagy vegyen. Ennek gyakorlatban milyen szerepe van?"
Számunkra gyakorlatilag semmilyen, mert a diversity-működéshez úgyis automatikus kiválasztáson kell hagyni ezt a beállítást, ha meg külső (kültéri) antennát csatlakoztatunk hozzá, amelyből csupán egy darabnak van értelme, akkor nincs haszna a kézi aljzatválasztásnak, mert stabil jelnél a router nem vált antennát. Ennek a lehetőségnek kísérleti jelentősége van. Például abban az esetben lehet értelme, ha olyan adóerősítőt használunk, amely nem támogatja a vételhez a visszafelé irányt, és külön antennákat kell alkalmaznunk az adásra és a vételre.
Hát, ha a telefonod már a kültérre helyezett routert sám látja néhányszor tíz méterről, akkor azzal tényleg nem sok mindent lehet kezdeni. Valószínűleg az a helyzet, hogy a telefon wifi-modulja és/vagy a belső wifi-antennája elég gyenge teljesítőképességű, sajnos ez nem túl ritka eset. Gondolom, hogy a notebook-od azért nem ennyire érzéketlen. -
And
veterán
válasz Kicsirics77 #9886 üzenetére
Nem kevered véletlenül a sima WRT54G-vel? Merthogy -GC-ből nincs 7.0, és sajnos felénk is akad egy téglává varázsolt (eddig rendbehozhatatlannak bizonyult) GC példány. A bootloader-e nem válaszol, a jtag-port (ha egyáltalán az az, ami a nyákon látható) kiosztása pedig kideríthetetlen annál a vacaknál.
#9887: Status / wireless oldal, site survey-gomb (vagy ha nem micro-kiadás, akár a wiviz surwey funkció is szóbajöhet, az folyamatosan mutatja az elérhető AP-ket és klienseket).
#9888: Biztos jó az a program, csakhogy routerrel nem használható. Nekem pl. egyáltalán nincs PC-be épített wifi-klienshardverem, és a külső antennám is a routerre csatlakozik, így kizárólag azzal tudok hálózatot keresni. -
And
veterán
válasz lenbazso #9894 üzenetére
A Client-bridge mód kell neked, ha a másik routerrel azonos címtartományban szeretnél maradni (NAT nélkül). A Repeater-bridge majdnem ugyanez, csak itt van lehetőséged virtuális AP-ket létrehozni, hogy valóban jelismétlőként funkcionáljon a routered. Bridge-módoknál az sem árt, ha a Basic Setup-nál a routered IP-je a 'gazda'-routerrel közös netmaszk alatt van konfigurálva, ugyanabban a tartományban, gateway-nek pedig meg is kell adnod a másik router IP-címét.
Az SSID-nek, a titkosításnak és a megosztott kulcsnak természetesen egyeznie kell a másik routeren beállítottakkal. Ha a link fizikailag létrejött (tényleg: ez rendben?), az úgyis látszódik a routered nyitóoldalán, vagy a Status / Wireless lapján.
Miért kell ezt a kérdést két topikban is feltenni? -
And
veterán
válasz lenbazso #9896 üzenetére
NAT: címfordítás. Ha a gazdarouter (amelyre kapcsolódni szeretnél) a tiéd, és az már amúgy is megosztja a netet, vagyis nem nyilvános IP-című eszközök vannak a LAN / WLAN-oldalán, akkor neked nem kell mégegyszer címeket fordítanod, és maradhatsz azonos címtartományban vele. Viszont ha pl. az a router egy szolgáltatóé, és több klienst szeretnél a routeredre kötni, akkor ugyanúgy szükséges lehet a NAT, mintha egy vezetékes hozzáférést kellene megosztanod.
Az jó, hogy hálózatkeresésnél mutatja, meg csatlakozás gomb megnyomására történik valami, de utána a wireless státusz oldalon mutatja is a routered, hogy a wifi-kapcsolat létrejött (az első router szerepel az kapcsolódó AP listában)? Aztán: van DHCP-szerver a hálózaton? Jó esetben a gazda router az, de megnézted? A routered LAN-IP-je (amelyet csak kézzel tudsz beállítani) ugyanabban a tartományban van? A csatlakozó PC automatikus címkérésre van állítva, és kap is valakitől IP-, netmaszk-, dns- és gateway-címeket? Ha igen, a gateway az első router címe? -
And
veterán
válasz lenbazso #9899 üzenetére
Nem, akkor neked nem kell a NAT, mivel azt a távoli router elvégzi, és te szeretnél egy címtartományban (192.168.1.x) maradni a többi eszközzel, ezért kell a client-bridge.
Meg kellene nézned, hogy az első router milyen tartományban oszt címeket (erre való a DHCP-szerver), de a te routered IP-jét - ahogy írtuk már - ne ebbe a szegmensbe konfiguráld. Ha pl. a DHCP-szerver a 192.168.1.100 - 200-as tartományban oszthat, akkor a te routered ne itt legyen, hanem 192.168.0.x-ben, ahol x<100, és persze a többi fix címtől különbözik. A routered gateway-címe pedig legyen a másik routeré, 192.168.1.1-es.
"A pc automatán van. A gateway az első router ip-je, ezt is kiírja a státusznál."
Mármint a routered írja ezt, vagy a PC-d? A PC gateway- és DNS-címei micsodák? -
And
veterán
-
And
veterán
válasz lenbazso #9929 üzenetére
Nem tudom, én sosem szenvedtem vele, még a csatlakozás gombot sem szoktam nyomogatni (minek?), úgyis megtalálják egymást. A kliens-router gateway-címe az a megosztó AP, a kliensgépek DHCP-kéréseit is az szolgálja ki.
#9931: "Az lehet probléma, hogy az Ap router 192.168.1.100-tól kezdi adni az ip-ket, a kliens routernak meg 192.168.1.2 lett megadva?"
Ez egyáltalán nem baj, sőt: kifejezetten rendben van így. -
And
veterán
válasz lenbazso #9943 üzenetére
"mert automatán a kliens módot állítja be"
Ezért írtam, hogy nem szoktam nyomkodni a 'connect' gombot, már ha ezt érted automata beállítás alatt. Egy perc alatt be lehet anélkül is állítani, és utána nem fog érdekelni, hogy mit csinált 'automatán'. Ha egyszer célszerűbb neked a kliens-híd (azzal ugyanúgy használhatod az összes LAN-portot, akár a WAN-t is ötödiknek), akkor válaszd azt, és ne törődj vele, hogy magától nem úgy konfigurálja be a routert. Márpedig ha az AP, amelyre csatlakozol, már végez címfordítást (mert az a router / gateway), akkor mégegyszer felesleges ugyanezt a kliens-eszköznél is eljátszani. -
And
veterán
válasz lenbazso #9945 üzenetére
Mivel a sima kliens DD-WRT esetén - ahogy Atapi is utalt rá - címfordítást végez, ezért egy másik alhálózatból te hiába kérsz IP-t , a gateway-router (AP) nem is tud címeket adni. Vagy csak maga a kliens-router van a 192.168.2.x tartományban, a rajta lógó gépek nem? A kliens-routernél pedig eleve eltűnik a DHCP-szerver felület, mivel vezetéknélküli kliensként nem tud címeket osztani. Amúgy ha kliens-híddal próbálkozol, a Wireless / Basic Settings oldalon a 'Network configuration' ugye 'bridged'-re van állítva nálad, és nem 'unbridged'-re?
Nálunk van egy gateway-router (AP-módban), DHCP-szerverként, 192.168.0.1 LAN-címmel. Ehhez kapcsolódik két kliens router (pontosabban az egyik kliens-híd, a másik repeater-híd beállítással), azok is fix 192.168.0.x címeket kaptak, a DHCP-tartomány (x: 2..13) felett. A gateway-cím mindkét kliens-routeren 192.168.0.1-ra van állítva (magán a gateway-en 'üres', 0.0.0.0), a Local DNS meg mindenhol 0.0.0.0. Mégis bármelyik kliensre csatlakozik vezetéken, vagy a repeaterre vezeték nélkül egy PC, a gateway-től kap IP-t (mindig ugyanazt, mivel a kiosztás MAC-címhez rendelt), DNS-ként pedig egyből a szolgáltatóét kapják.
#9905 (ha még aktuális): Az SSH-hoz először engedélyezni kell a 'Secure Shell' / 'SSHd' beállítást a Services / Services oldalon. Ha ezt nem teszed meg, az adminisztrációs oldalon az 'SSH management' menüpont szürke marad, így nem tudod bekapcsolni. -
And
veterán
Ez mitől lenne a internet megosztás korlátozása? A belső hálózaton lógó (vagyis a LAN-portokra kötött) PC-k közötti fájlmegosztásnak semmi köze a router 'tűzfalához', NAT-hoz vagy routoláshoz. Pont azért, mert onnan nézve a router csak egy switch. Éppen lehet köze a jelenségnek firmware-hez, bár én sosem tapasztaltam ilyet, és nem kellett semmit 'engedélyezni' dd-wrt-nél a helyi fájlmegosztáshoz. De ha az internetet mindegyik kliensgépről eléred, akkor a netmegosztás nincs korlátozva..
-
And
veterán
"Szereztem egy wrt54g AP-t"
Véletlenül nem WAP54g-re gondoltál? Mert a WRT54G nem csak AP, hanem router, és gyárilag nincs repeater-módja, olyan meg főleg, amelynél AP MAC-addresst kell megadni. A WAP54-et meg épp így kell beállítani, de a manualja szerint csak ugyanilyen AP-vel vagy WRT54G-vel párban működik (utóbbit lehet, hogy csak akkor támogatja, ha azon gyári fw van?). Ha ez lenne a helyzet, és tényleg WAP54-esed van, akkor tolj rá DD-WRT-t - a WAP54g mindegyik hw-verziója támogatott -, azzal meni fog a repeater-mód (virtuális AP-vel). -
And
veterán
Ha belenyúltál, ráadásul wholeflash-törlést is végeztél (feltéve, hogy valóban sikerült), akkor már tényleg nincs más, csak a jtag. Kicsit macerás, én is sok éve csináltam ilyet, aztán két hete újból műteni kellett egy WRT54GL v1.1-est, mert a villogó power-led és az összes LAN-led világít szimptómát produkálta. A megoldás nagyjából ez volt: [link]. A lényeg, hogy nem csupán CFE-írásból, majd tftp-n feltöltésből állt a dolog, hanem akadt még pár másik lényeges apróság. Ezekre kellett figyelni:
- a Skynet Repair kit-tel először egy v1.0-áshoz való CFE-t kellett generálni (vagy ha van korábbi mentésed, az is jó, de anélkül a gyári, matricára felírt MAC-address visszaállításához kényelmesebb a Skynet kit használata),
- szükség volt egy 'üres' nvram-image fájlra is (az útmutatón ott a link hozzá),
- utána kellett ráküldeni az v1.1-hez való CFE-t (hogy miért így, azt pontosan nem tudom),
- a firmware-image fájlok eltérőek lehetnek attól függően, hogy webfelületen vagy épp tftp-n való feltöltésre szánják azokat. Pl. a DD-WRT-nél biztosan ez a helyzet, a "generic" nevűek kellenek a webes módszerhez, de jtag-hez először a "mini_wrt54g" kell, egyébként a tftp-s próbálkozás hibaüzenettel jár.
Nekem a leírt módszerrel sikerült rendbehozni a routert, pedig előtte szintén töröltem már a wholeflash-t. Már kezdtem gyanakodni, hogy nem is biztos, hogy csak szoftverhibás a cucc, de szerencsére az volt (nem az enyém volt, állítólag menet közben hibásodott meg egy viharban). -
And
veterán
válasz adalbert1 #10016 üzenetére
Erre (belső 'szerverek' elérésére az internet felől) való a port forward. Az alkalmazást futtató belsőhálózati gép IP-címére kell továbbítani a WAN felől érkező kéréseket. Ehhez persze feltétel, hogy ezek a szolgáltatások stabil IP-című gépeken legyenek, ezért vagy fix IP-ket osztasz annak / azoknak a gépeknek, vagy legalábbis statikus (MAC-címhez rendelt) DHCP-t alkalmazol. A távoli asztal (RDP) szolgáltatás alapértelmezés szerint a 3389-es, az FTP pedig a 20..21-es TCP-portokat használja (ezeket természetesen át lehet konfigurálni), így ezen portokat kell a megfelelő belső gépek felé forwardolni.
-
And
veterán
válasz adalbert1 #10018 üzenetére
Nincs /gépnév! Csak a dinamikus dns-névre kell hivatkoznod, a router dolga, hogy a port-forward alapján továbbirányítsa a forgalmat a megfelelő gép felé. Ha pl. a router mögött két gépen is FTP-szerver programot futtatsz, és kintről el szeretnéd érni mindkettőt, akkor nyilván csak az egyiken hagyhatod a default portkiosztást, a másikat el át kell állítanod, hogy a szerver egy másik porton figyeljen. Így a két gép ugyanazon szolgáltatására a net felől csak az eltérő portszámokon keresztül tudsz hivatkozni.
-
And
veterán
válasz Oliverda #10021 üzenetére
Ebben a tekintetben tudomásom szerint minden kétantennás b/g-router hasonló: az antennák között váltani tud a szoftver a vételi bithibaarány függvényében (ez a diversity-mód), de ettől még ugyanarra a rádiómodulra kapcsolódnak. Tehát nincs sok értelme 'konfigurálni' az antennákat. Bár szinte minden 3rd-party fw biztosít lehetőséget pl. az adás-vétel irányok szétválasztására a két antennán, de ezzel egy átlagos felhasználó semmilyen előnyhöz nem jut, viszont a diversity-képesség így elvész.
-
And
veterán
válasz Oliverda #10024 üzenetére
Egészen pontosan azt jelenti, hogy mind adás, mind vétel irányára megszabható, hogy melyiket használja a router. Ha nem hagyjuk automatikus kiválasztáson, akkor a diversity eleve működésképtelenné válik, ha meg szétválasztjuk (pl. TX: right, RX: left), akkor elérhetjük, hogy adáskor a másik antennaaljzatot válassza ki a router, mint vételkor. Csakhogy ennek egy tipikus felhasználó számára nincs sok értelme. A topikcímben foglalt routerek meg úgy általában egy rádiómodullal szereltek.
-
And
veterán
válasz sirály12 #10027 üzenetére
Hosszú resettel próbálkoztál, mielőtt JTAG-gel belepiszkáltál volna? Még az eredeti gyári fw volt rajta? A letölthető gyári firmware-image fájlok szerintem inkább webes frissítéshez valók, nem JTAG-hez vagy tftp-hez. Mielőtt hozzákezdtél a kernel felülírásához, csináltál wholeflash-mentést? Az most sokat segítene.
"A jtag kábel sem ismeri már fel."
Ez viszont érdekes, mivel a JTAG sikeressége abszolút független az aktuális flash-tartalomtól, éppen ezért alkalmazható agyhalott (pl. teljesen kitörölt) flash mellett is. Ha a proc- és a flash-típust sem adja vissza a debrick utility, akkor ott már más gond is akad (/noemw-kapcsoló? JTAG-kábelhossz?). Ha nincs hardveres hibája, elvileg helyre lehet hozni. -
And
veterán
válasz jimlaj66 #10057 üzenetére
Ha a backup csupa hexa FF-et ad vissza, az annyit jelent, hogy a bootloader tárterület teljesen törölt. A flash-nél pedig ügyelni kell arra, hogy a CFE-fájl neve pontosan "CFE.BIN" legyen, és ugyanabban a mappában helyezkedjen el, mint a debrick utility futtatható állománya. WRT54GL-ek esetén még hasznos lehet a /noemw ill. /noreset kapcsolók használata is (ha a folyamat el sem indul, vagy szinte rögtön az elején megáll).
-
And
veterán
válasz jimlaj66 #10077 üzenetére
Azért az még édeskevés, hogy nem egy üres állományt kapsz vissza. Próbáltad esetleg összehasonlítani azzal, amit előtte ráflash-eltél? Ha a kettő stimmel, az a jó eredmény. De azt is megoszthatnád, hogy végülis mi volt a gond a korábbi próbálkozásoknál.
Konkrétan miféle cfe.bin-t égettél be a routerbe? Mert ha azt, amelyet Fabriciusz kolléga #10054-es hozzászólásának linkjéből lehet kihalászni, akkor ne azzal az IP-vel próbáld, amit emítettél, mivel abból a letöltött CFE-ből szemre egészen más címet (192.168.1.1) lehet kiolvasni. Egy .1.245 végű IP-vel megáldott CFE évekkel ezelőtt, a VxWorksKiller megjelenése előtt keringett a neten, és eredetileg egy WAP54-es AP-ről mentették. De megpróbálhatod pingelni is az 1.1-es címen a routert, a bootloadernek válaszolnia kell. Az más kérdés, hogy csak az indulás - LAN-ledek kialvása - utáni első néhány másodpercben, vagy tovább is, de ha az első eset igaz, akkor a kernel-image tftp-s feltöltését is az indulás után hamar kell majd elkezdened a megfelelő pillanatban.
#10078: Pedig egy GL-nél úgy kell, csak nem mindegy, melyik verziót teszed fel először, mivel a gyári firmware nem támogatja adott mérethatár (talán 3 MB) feletti fw-image feltöltését. Ezért szokás a cserét a Mini-verzióval (mini_generic) indítani. A DD-WRT keresős router-adatbázisa a WRT54GL-nél is első helyen hozza a 'Mini-Build required for initial flashing via TFTP / WEB' nevű verziókat. -
And
veterán
Én meg a szopást nem értem: számtalan eszközre tettem már DD-WRT-t (ugye egy rakás típusra más nem is megy), és még sosem szívatott meg a feltelepítésekor vagy frissítéskor. Pedig néha wifi-n frissítek, mert az adott router messze van, és nincs ott senki, de olyankor is gond nélkül szokott felmenni .
-
And
veterán
válasz zsolt501 #10088 üzenetére
Igaz, hogy a telepítésről volt szó, de ha számít, eddig egyik verzióval (v23 óta) sem volt gondunk, pedig számtalan GL-re és G v5-re tettük fel. Száz nap feletti uptime-okat produkál, lassulás nélkül (amit aztán általában áramszünet vagy újrakonfigurálás nulláz le), ráadásul külső antennákkal. Te már elég régen és többször írtad, hogy találkoztál ilyen gonddal. Más meg nem. A következtetést mindenki vonja le maga.
-
And
veterán
válasz ksasa67 #10090 üzenetére
Első blikkre hardveres nyűgnek tűnik, de ha szeretnél róla megbizonyosodni, akkor frissíts firmware-t vagy válts DD-WRT-re (más 3rd-party fw erre a típusra se nagyon megy fel). Már az is gyanús lehet, ha egy, a rossz portra csatlakoztatott számítógép LAN-aljzatán nem villan fel a vivő meglétét jelző led. Ha a probléma hardveres eredetű, túl sok mindent nem tudsz vele kezdeni: olyan helyen használhatod (pl. dd-wrt-vel kliensként, azzal a WAN port átkonfigurálható ötödik LAN-portnak), ahol nincs szükség mind a négy LAN-portra, vagy beszerzel hozzá egy filléres switch-et kiegészítésként. Esetleg eladod némi kedvezménnyel, a hibájára tekintettel.
-
And
veterán
válasz R+Tamas #10108 üzenetére
Tényleg marhaság ez a 'tartományon kívüli' IP. Persze kérdés, hogy mit értünk 'tartomány' alatt, a hivatkozott cikk ugyanis DHCP-tartományról ír. Csakhogy egyáltalán nem szükséges a DHCP-által osztható tartományon kívüli címet adni a szervergépnek, ha a router ismeri a statikus (MAC-cím alapján az adott kliensgépnek mindig ugyanazt az IP-címet kiosztó) DHCP-t. Ha nem ismeri, akkor jöhet a fix IP, valóban a DHCP lehetséges címtartományán kívül, de nyilván nem a saját LAN-os netmaszkod által fedett tartományon (a példában 192.168.1.x) túl.
Ja, és a DHCP-tartományon túli (fix IP) kiosztáshoz a routernek semmi köze, tehát azt ne is annak a konfiguráló webfelületén keresd. Ha a statikus DHCP az adott routernél nem járható, akkor csupán annyi a dolgod, hogy a szervergépen a hálózati beállításoknál - természetesen a netmaszkon belül - fix IP-, gateway- és DNS-címeket állítasz be, és erre az IP-re forwardolod a routeren az adott szolgáltatáshoz tartozó porto(ka)t.[ Szerkesztve ]
-
And
veterán
válasz llaszlo #10175 üzenetére
Natívan biztos nem, de amúgy erre a vasra valószínűleg nem is volna érdemes. Soros portot éppen tartalmaz a proc, az a nyákra is ki van hozva, de a használata nem túlságosan felhasználóbarát. Adattárolásra az egyedüli értelmes mod ennél a routercsaládnál az SD-foglalat kiépítés (az ehhez szükséges támogatást több 3rd-party firmware-változat is támogatja), de a sebesség a tapasztalatokból kiindulva azzal sem lesz valami óriási.
-
And
veterán
válasz llaszlo #10192 üzenetére
SD-foglalatot én az Elektrokontha-ban vettem, most is látni vagy ötfélét az online katalógusukban. A panelen lévő (két) soros port alapesetben induláskor diagnosztikai üzeneteket küld, ill. konzolként használható: [link]. Másfajta felhasználásáról például ebben a topikban ötletelnek: [link].
-
And
veterán
válasz TeeJay #10195 üzenetére
Ha valóban 'csak' a WAN-port tojt be, akkor 3rd-party firmware-ekkel minden olyan funkció használható marad, amely a WAN-oldalt nem érinti: kliens, repeater, WDS, ad-hoc.
Repeater (otthonra: NAT nélküli repeater-híd) beállítása dd-wrt v24 esetén, virtuális AP-vel: [link]. -
And
veterán
válasz llaszlo #10198 üzenetére
Próbáld az "sd-mem" ill. az "mmc" keresőkifejezésekkel. Bár utóbbi csak egy releváns találatot ad, még mindig könnyebb így összeszedni a foglalatokat, mint az "sd" keresésre adott 165 találatból (egyébként ez utóbbival is megleled az összeset az 51-75. találatok között).
-
And
veterán
válasz gedikart #10203 üzenetére
Miért is kéne ezeket a bin-fájlban átírni?? E változók mind az nvram-ban (tehát a flash-ben) tárolódnak, így ha módosítás után elmented az értéküket, akkor azok a következő hosszú resetig (nvram törlésig) meg is maradnak. Kikapcsolt állapotban és áramszünet esetén is. Ha nem így lenne, akkor a te routerednél valami csúnya probléma van.
-
And
veterán
-
And
veterán
válasz vargalex #10207 üzenetére
Igazad van! DD-WRT-vel a VLAN-menüben kivettem a WAN-port hozzárendelését a VLAN1-hez. Az enabled-pipát is kivettem a W-oszlopból, így a WAN most nem része egyik VLAN-nak sem. A 4-es LAN-portot viszont bejelöltem VLAN1-be (az 1..3-as portok maradtak VLAN0-ban), és innentől ugyanúgy működik a LAN4-port, mintha az lenne a WAN: szépen lekéri a címet a szolgáltatótól, és megy a netes forgalom, ha erre csatlakoztatom a modemet.
-
And
veterán
válasz Integra #10218 üzenetére
("gyári fw-vel meg lehet oldani, hogy másik router jelét fogjam wifin keresztül és aztán a saját gépeim a saját routeremtől kapják a jelet wifin???"
Mint a másik topikban említettem, a gyári fw-rel nem fog menni. Amúgy ha a saját gépeid felé is vezetéknélküli elérés kell /ami a wifi-sebességet ugye megfelezi/, akkor nem kliens-, hanem valamelyik repeater-mód kell neked.) -
And
veterán
válasz Integra #10220 üzenetére
Félreértettél. Arra utaltam, hogy ha a te routeredből nem kábellel szeretnél csatlakozni a kliens pc-idre, akkor nem jó neked a wireless kliens-mód (mivel az helyileg csak vezetékes elérést biztosít). Ha wifi kliens is szeretnél lenni (a szomszéd routere felé) és egyben wifi-elérést szeretnél adni a saját gépeidnek, akkor kell repeaterként konfigurálnod a routeredet.
-
And
veterán
válasz Integra #10224 üzenetére
Pedig nem túl bonyolult. Ha még nem használtál okos fw-t, akkor kicsit furcsa lehet elsőre, de nem túl nehéz konfigurálni. A dd-wrt-féle repeater bridge lényegében nem más, mint egy kliens (ennek megfelelően kell beállítani a fizikai wlan-interfészt), amelyhez virtuális access pointo(ka)t (VAP-okat) lehet hozzárendelni. VAP létrehozása nélkül lényegében nem is repeaterként, hanem egyszerű kliensként működik. A VAP pedig az a 'virtuális csatoló' amelyre a saját klienseid tudnak csatlakozni, ettől válik jelismétlővé. A két rendszer (fizikai kliens és virtuális AP) beállításai egyébként akár teljesen eltérőek is lehetnek: SSID, titkosítási algoritmus, megosztott kulcs. Egyedül a rádiócsatorna marad ugyanaz, de ez természetes.
-
And
veterán
válasz the_one #10249 üzenetére
Ilyen firmware nincs, és nem is létezhet! A két antenna nem működhet egyszerre. Ez egy rendszeresen visszatérő kérdés, de a válasz az, hogy a diversity mód az antennák átkapcsolásán alapul, vagyis egyetlen adóvevő fokozat van a routerben, ezért a két antennát egyszerűen nem tudod párhuzamosan járatni.
"Ennek ellenére a másik (kikapcsolt antennára) is kapcsolódnak a erősebb jelű kliensek, jóval gyengébb jellel, 1-2 megabit körüli sebességgel, DE STABILAN."
A két antenna közötti elválasztás véges, a félvezetős kapcsoló áthallási csillapítása mindössze huszonvalahány dB értékű, vagyis könnyen elképzelhető, hogy a 'lekapcsolt' antenna felől is érkezhet értelmezhető jel, ha az amúgy megfelelő szintű. Úgyhogy erre nincs megoldás: automata módban a router antennát vált, ha az aktuálison vett jel bithibaaránya nagyon megnő, ha meg kézi kiválasztáson hagyod, valamennyi jel átszűrődhet a passzív ágon keresztül. Két külső (eltérő irányítottságú) antenna kiszolgálásához bizony két AP kell, vagy ha megoldható, akkor egyetlen, nagyobb nyereségű külső körsugárzó is használható, természetesen egy bazinagy antennához képest némi nyereségcsökkenés árán. Biztos lehetne játszani antennaközösítő diplexerekkel, de ez házilag mikrohullámon már nem túl járható út, és akkor is megmaradna a szétosztásból / közösítésből adódó veszteség. -
And
veterán
válasz DeusHun #10251 üzenetére
Ez mitől tud olyat? Csak annyi látszódik az adatlapján, hogy virtuális hálózatokat tud kialakítani 8 SSID-ig (ahogy pl. a dd-wrt v24 is), és ezeket különböző VLAN-be téve el tudja szeparálni egymástól. De éppen úgy csak egyetlen rádiómodult tartalmaz, a két antenna meg éppen ezért valószínűleg ugyanúgy a diversity okán van rajta, mint a WRT54G-routereken. Az összehasonlító tábla szerint az OAP-54 típus tartalmaz egy második WLAN-modult, azt talán lehet ilyen módon használni, de az L-54g-nél ez hiányzik.
#10252: Nincs "legjobb" firmware. Az alap bővítések (amelyektől a router többfunkciós lesz) szinte ugyanazok, de van néhány finomság, amelyet csak az egyik, vagy épp a másik firmware támogat. A Tomato előnye (volt régebben, amíg a másikban ilyen feature nem volt) a grafikus sávszél-megjelenítés csatolónként, meg mindenféle ehhez kapcsolódó statisztika. A DD-WRT meg például ismeri a maximum nyolc virtuális AP-vel kialakított repeater-módot. -
And
veterán
válasz DeusHun #10258 üzenetére
Hogy ti a cégnél úgy használjátok, az nem jelenti azt, hogy hivatalosan képes is ilyesmire , lásd the_one kolléga esetét a #10249-ben.
"A cégnél használjuk úgy, hogy az egyik antennán kapja a jelet és a másikon küldi tovább [..]"
Na épp ez az (mármint hogy minden állomás felé adni és venni is kell, igaz időosztással), ami miatt egyetlen wlan-modullal nem lehet képes ilyen trükkre, márpedig az L-54g-nek csak egy van. (Illetve elméletben úgy igen, hogy mint említettem, kettéosztja a rendelkezésre álló adóteljesítményt, és vételkor is közösíti / illeszti a két antenna jelét. De ilyen trükköt abszolút nem használnak wifi-nél, mivel egyenként minimum 3 dB-lel - de inkább jobban - csökkentené az aljzatokra jutó adóteljesítményt, és ugyanennyivel rontaná a szeparált vételi érzékenységet.) A diversity nem azt jelenti, hogy az AP 'megjegyzi', hogy melyik antennán melyik kliens érhető el normális térerővel, hanem azt, hogy ha az egyiken nincs, hát próbáljuk meg a másikon. Beltéren a visszaverődések miatt ez sokszor sikerrel is jár.
A kulcs nálatok is valószínűleg a már említett diversity kapcsoló chip véges (adatlap szerint 2-3 GHz között tipikusan 23 dB-es) izolációjában, ill. a két antenna ellátási területén amúgy is megévő átfedésben keresendő. Vagyis a router az éppen lekapcsolt aljzatán is vesz jelet a kliensektől, és bár ez a jel erős csillapítást szenved a diversity kapcsolón, nem tűnik el teljesen. Ha már a kapcsolat létrejött, mert a kliens kellően erős jelet produkál, a router diversity-működéssel mindenképp meg fogja találni a leválasztott aljzatra csatlakozó antenna felőli klienseket is, hisz pl. repeater-módban elegendő neki átkapcsolni az antennát (ha az 'erős' jelek között nem találja a klienst). Csakhogy ez nem feature, hanem egy műszaki problémából - a tökéletlen lekapcsolásból - eredő fals működés, amely a csillapítás miatt mindenképp lassulással és az állandó átkapcsolások miatti csomagismétlésekkel jár. -
And
veterán
Természetesen: a NAT-QoS / Port Forwarding menüben a Port from és a Port to mezők értékei különbözőek is lehetnek. Ha kívülről a Port from számú - beállítástól függően - TCP/UDP portra érkezik a kérés, az az IP Address című gép Port to számú portjára lesz küldve, ha az adott forwardot engedélyezed.
Új hozzászólás Aktív témák
● Olvasd el az összefoglalót!
- REZSI csökkentős OLCSÓ Mini Gamer !!!
- TicWatch Pro 2020 okosóra
- Eladó Palit RTX 4070 Dual 12GB GDDR6X videokártya
- Fujitsu Lifebook E546 , 14" Kijelző, I3-6100U, 8GB DDR4, 128GB SSD, WIN 10, Számla, garancia
- Fujitsu Lifebook E544 , 14" Kijelző, I7-4712QM, 16GB DDR3, 128GB SSD, WIN 10, Számla, garancia
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: Ozeki Kft.
Város: Debrecen