Hirdetés
-
IT café
TP-Link WR1043ND - N450 router
Új hozzászólás Aktív témák
-
-
petakpa1
őstag
Legelső próbálkozásom pontosan úgy történt, hogy Te 1. és 2. lépéseidbeli beállításokat végrehajtottam, majd ez után nyomtam csak rá a Save&Apply-ra, de már ez sem volt sikeres. Ezután kezdtem el lépésenkánt végrehajtani, és ekkor derült ki, hogy te 2. ás 4. lépésedet simán végrehajtja, de az elsőt nem.
Mivel konzolból sikerült megcsinálni az volt a hiba amit Alex eleve is gyanított: a Luci rollback funkciója valahogyan összeakad az 1. lépés Mentés és alkalmazásával.
@ Alex még1x köszi a kitartó segítséget!
"... Feltalálom a hidegfúziót oszt reszeltek az amcsiknak...":)))
-
petakpa1
őstag
válasz
petakpa1
#71418
üzenetére
Úgy tűnik igen
Reboot után is megmaradt WAN port untagged állapotban VLAN1 soron és ip neigh parancsi is lefutott, azaz 192.168.0.101 ip cím bérlete permanent.Megint jól megközdöttem openwrt konfiggal, de végül sikerült. Nagyon köszönöm mindenkinek a segítséget, elsősorban Vargalex Mesternek természetesen!
"... Feltalálom a hidegfúziót oszt reszeltek az amcsiknak...":)))
-
petakpa1
őstag
válasz
vargalex
#71417
üzenetére
Köszi Alex!!!
Az alábbi 3 parancs konzolból való kiadásával úgy tűnik sikerült
.Mikor ezt követően böngészőből beléptem Luciba, már WAN port is untagged volt
Így néz ki most Switch menü:
Továbbá WAN portba (azaz mostmár 5. LAN portomba) dugott laptop is rendben látja a belső hálómon lévő eszközöket, pont ami a cél volt.Kérdésem az lenne, hogy ez a mostani beállítás az eszköz (1043ND) újraindítása után is megmarad?
Ezt azért kérdezem, mert fenti 3 restart parancs miatt a Local Startupban szereplő ip neigh replace 192.168.0.101 lladdr aa:bb:cc:dd:ee: nud permanent dev br-lan parancs szerintem most érvényét vesztette, de ez nekem mindenképp kell ahhoz, hogy a 101-es ip címen lévő PC-mre mindenkor működjön a WOL.Célom az lenne tehát, hogy WAN port router reboot után is LAN portként szolgáljon, és a fenti ip neigh parancs is minden rebbot után érvvényben legyen.
Mindjárt kipróbálok egy reboot-ot me meglátjuk mi történik?
"... Feltalálom a hidegfúziót oszt reszeltek az amcsiknak...":)))
-
petakpa1
őstag
Sziasztok!
Én úgy gondolom LAN-on FIX ip címe van az eszköznek, íme a LAN interfacem beállításai:
DHCP-n nem is kaphatna az eszköz IP címet, mert Vodafone HGW-ben le van tiltva a DHCP server, csak ezen az eszközön fut DHCP server a LAN-omban.@ Alex
Megpróbálnám Putty-on keresztül konzolból akkor a VLAN1-en off-ról untagged-re állítani WAN portot, de ehhez kellene egy kis segítség még. Pontosan milyen parancsokat kellene konzolba bevinnem.
Ha konzolból sikerül, akkor gondolom tényleg az általad tippelt Luci rollback funkcióval van a bibi...@ gduck:
Legelső nekifutásra valóban abban a sorrendben próbáltzam amit Te írsz, de az első lépésedet nem hajtotta végre. Ezt követően a Te 2. és 4. lépésedet mentéssel együtt sikeresn végrehajtottam. Most jönne a te 1. lépsed de az nem megy se a Te sorrendedben, se úgy, hogy előbb a Te 2. és 4. lépésed már végre van hajtva.Igazából az általad javasolt 1. lépést (VLAN1 soron WAN port off-ról untagged-re kapcsolása) nem tudom elmenteni és alkalmazni Save&Apply funckióval
. "... Feltalálom a hidegfúziót oszt reszeltek az amcsiknak...":)))
-
petakpa1
őstag
Jó reggelt mindenkinek, és köszi, hogy próbáltok segíteni.
@ Alex
Sajnos VLAN1 sorban CPU tagged-ről untagged-re állítása sem sikerül. Amikor Save&Apply-ra nyomog lefut a 90 sec-es konfiguráció, majd ismét a Failed to confirm apply within 90s, waiting for rollback üzenetet kapom. Luci ablaka lefagy böngészőben, de új tabon megnyitva Lucit ismét bejön és visszajutok oda, hogy világoskék Unsaved changes: 2 felirat van jobb felső sarokban. Érdekes, hogyha az új Luci ablakban kilépek Logouttal, majd vossza akkor jobb felülről eltűnik a két függűben lévő, Apply-ra váró módosítás.@ gduck
Ugyanazt csinálom mint Te
VLAN2 soron WAN port OFF-ra rakva majd törölve is
Interface-ek közül WAn és WAN6 már törölve
Ezek sikeresek is
Csak az a lépés van hátra, hogy VLAN1 soron próbálnám WAN portot átkapcsolni off-ről untagged-re akkor azt Save&Apply-al már nem engedi menteni.System vagy Kernel logban nem lehetne megnézni, hogy mi hibázik? Melyikben kellene keresnem?
Csinálnék egy reboot-ot, majd amikor minden biztosan elindult (várnék mondjuk 5 percet) belépnék Luciba és a Switch menüpontban átállítanám WAN portot OFF-ról untagged-re, majd Save&Apply. Nyilván nem lenne sikeres, de ezt követően megnézném a logot, hátha látszik valami.+ 1 ötlet még:
LAN Interface nekem jelenleg így néz ki:
Ez így rendben van? Switch menüpontban VLAN funkcionalitás engedélyezve van még jelenleg, annak letiltását még nem próbáltam.[ Szerkesztve ]
"... Feltalálom a hidegfúziót oszt reszeltek az amcsiknak...":)))
-
petakpa1
őstag
Kezdem elölről:
0) Eszköz reboot. Reboot után így néz ki a Switch menü:
1) Most átállítom WAN portot untagged-re, majd alul a Zöld Save gombra nyomok, ekkor ezt kapom:
3) Nem nyomok Save & Apply-ra, hanem putty-al belépek konzolon és kiadom a z Alex által fentebb javasolt parancsokat:login as: root
root@192.168.0.2's password:
BusyBox v1.30.1 () built-in shell (ash)
_______ ________ __
| |.-----.-----.-----.| | | |.----.| |_
| - || _ | -__| || | | || _|| _|
|_______|| __|_____|__|__||________||__| |____|
|__| W I R E L E S S F R E E D O M
-----------------------------------------------------
OpenWrt 19.07.10, r11427-9ce6aa9d8d
-----------------------------------------------------
root@TL-WR1043ND:~# uci commit
root@TL-WR1043ND:~# /etc/init.d/network restart
'radio0' is disabled
root@TL-WR1043ND:~#De sajnos semmi, mintha ez a parancs nem alkalmazná (Apply) az elmentet (Save) beállításokat. Továbbra is off-ban van ezt követően WAN port
@ gduck, Neked is köszi!
[ Szerkesztve ]
"... Feltalálom a hidegfúziót oszt reszeltek az amcsiknak...":)))
-
petakpa1
őstag
Hát én Ms-Dos-on kezdtem anno, aztán csak Win, így szerkesztő nekem a notepad
. Linuxban egyáltalán nem vagyok otthon. Végzettségem is közgazdász, nem ITs .
És sajnos azt sem igazán értem, hogy hol és hogyan kellene megkeresnem az Unchanged saves filet...Előre is köszi, ha ránézel majd.
[ Szerkesztve ]
"... Feltalálom a hidegfúziót oszt reszeltek az amcsiknak...":)))
-
petakpa1
őstag
Sajnos továbbra sem sikerül
Az alábbiakat csináltam:
1) VLAN 2 sorban WAN porto off-ra kapcsoltam, majd Save & Apply => Sikeres
2) VLAN2 sor törlése, majd Save & Apply => Sikeres
3) Interface-k között WLAN és WLAN6 törlése, majd Save & Apply => Sikeres4) Ezután VLAN1 sorban WAN port untaged-re kapcsolása, majd Save & Apply => Sikertelen
4) lépést úhgy is próbáltam, hogy 1)-3) lépsek után volt egy reboot, majd csak ezt követően próbálztam 4)-et Save & Apply-al alkalmazni, de ez már sikertelen volt
Parancsorból hogyan kellene?
[ Szerkesztve ]
"... Feltalálom a hidegfúziót oszt reszeltek az amcsiknak...":)))
-
petakpa1
őstag
válasz
xabolcs
#71397
üzenetére
Próbálom ismét Luci alól egyenlőre.
1. Lépésként VLAN2 sorban WAN portot OFf-ra állítom. Ez sikeres
2. Lépésként VLAN2 sorban próbálom WAN portot untagged-re állítani. Rányomok a Save-re, majd jobb felül világoskákkel kiírja, hogy Unsaveds changes 2.
Erre a feliratra rákattintva az alábbi képernyő jön fel:
Itt a zöld Save & Apply gombra kattintva 90 secig pörög a configuration, de végül sikertelen lesz. Failed to confirm apply within 90s, waiting for rollback üzenetet kapok. Luci ablaka lefagy böngészőben, de új tabon megnyitva Lucit ismét bejön és visszajutok oda, hogy világoskék Unsaved changes: 2 felirat van jobb felső sarokban
@ Alex
OK akkor kipróbálom azt is, hogy WAN interface-t törlöm, mileőtt WAN portot VLAN1 sorban untagged-re próbálom állítani.Egyébként most tűnt fel még valami.
Miután WAN portot VLAN1 sorban próbáltam untagged-re állítani, de sikertelen lett a configuration azt vettem észre, hogy LAN4 porton is megszűnt a link, pedig be van LAN kábel abba a portba és lóg is rajta egy lapotop, amin valóban nincs így netkapcsolat
Újabb update 1-2 perc után LAN4 port megink aktívvá válik. Ki érti ezt...[ Szerkesztve ]
"... Feltalálom a hidegfúziót oszt reszeltek az amcsiknak...":)))
-
petakpa1
őstag
válasz
petakpa1
#71395
üzenetére
Hard reset után visszatöltöttem a korábbi beállításaimat. Most visszakerültem oda ahonnan indultam 4 LAN + 1 WAN portom van
Esetleg ha újból próbálkozom valami logból ki lehet olvasni, hogy miért nem sikerül alkalmaznia azt a beállítást amikor VLAN1 sorban WAN portot állítanám át off-ról untagged-re?
"... Feltalálom a hidegfúziót oszt reszeltek az amcsiknak...":)))
-
petakpa1
őstag
válasz
petakpa1
#71394
üzenetére
Sajnos restart sem segített. Pingre sem válaszol és Puttyal sem tudok belépni rá az ip címén keresztül
Most mi legyen Hard reset hátul gombbal? Ekkor az Openwrt beflashalésekori alapkonfiguráció áll vissza? Tehát minden újra kell konfigolnom?
"... Feltalálom a hidegfúziót oszt reszeltek az amcsiknak...":)))
-
petakpa1
őstag
válasz
petakpa1
#71393
üzenetére
Ajjaj.
Utolsó lépést próbáltam úgy, hogy előbb külon csak Save gombal menteni, majd Apply Unchecked módon alkalmazni.
Ezt lett az eredmény:
Could not regain access to the device after applying the configuration changes. You might need to reconnect if you modified network related settings such as the IP address or wireless security credentials.Azóta nem érem el böngészőből Lucit
Próbálok egy újraindítást hátha
"... Feltalálom a hidegfúziót oszt reszeltek az amcsiknak...":)))
-
petakpa1
őstag
válasz
petakpa1
#71391
üzenetére
Sajnos nem sikerül
Az alábbiakat csináltem ebben a sorrendben:
VLAN2 sorban WAN portot Off-ba raktam majd Save&Apply => Ez sikeres is
VLAN2 sort töröltem majd Save&Apply => Ez is sikeres
Ezt követően próbálnám
VLAN1 sorban WAn porto Untagged-re állítani majd Save&Apply, de ezt nem hajtja végre 90 secig fut, a configiration, de utánna Failed to confirm apply within 90s, waiting for rollback… hibár jelez felül és Luci le is vagy böngészőablakban. Új ablakban megnyitva Lucit WAN port WAN port untagged-ként van VLAN1 sorban, de jobb felül kékkel azt írja, hogy unsaved chnages "... Feltalálom a hidegfúziót oszt reszeltek az amcsiknak...":)))
-
petakpa1
őstag
válasz
vargalex
#71390
üzenetére
Köszi. Lehetőség szerint minél kevesebbet szeretnék módosítani, ha netán egyszer vissza kell álllítani akkor minél könnyebben meg tudjam azt majd tenni.
Tehát
VLAN1 sorban WAN portot untagged-re állítom
VLAN2 sorban WAN portot off ba kapcsolom.de sem VLAN2-t sem a WAN Interface-t nem törlöm egyenlőre. Ha így működik akkor jó, ha nem akkor törlöm utóbbi kettőt is.
"... Feltalálom a hidegfúziót oszt reszeltek az amcsiknak...":)))
-
petakpa1
őstag
válasz
Borisz76
#71385
üzenetére
+ 1 portért nem fogok üzemeltetni még egy kis áramszipkázót, mégha csak pár wattot is fogyaztana az újabb switch.
1043ND-m most gyakorlatilag AP módban üzemel, de nem a fő router (ami a Vodafone-tól származó HGW), hanem 1043ND osztja ki az ip címeket a LAN-omon belül. Azaz a 1043ND a DHCP szerver. Ennek megvolt az oka, hogy miért kellett ilyen opológiai hálót felépítenem a meglévő eszközökből, de most ebbe nem mennék bele. Korábban le volt itt írva a tipocban, hogy miért is kellett ez nekem....
Lényeg, hogy a 1043ND-m WAN portját szeretném átkonfigolni LAN porttá OpenWrt alatt.
"... Feltalálom a hidegfúziót oszt reszeltek az amcsiknak...":)))
-
-
petakpa1
őstag
Ismét kérnék egy kis segítséget a jelenleg vezetékes switchként, dhcp szerverként, és dyndns kliensként használt 1043ND-v1 eszközömhöz.
Arra lenne szükségem, hogy az eszköz WAN portját is LAN portként tudjam használni, mert lett egy negyedik vezetékes eszközöm is. Az eszköz 4 LAN portja már most is használatban van, 1 megy ugye a HGW-m felé a maradék 3-omba pedig vezetékes eszközeim vannak dugva.
Mit és hogyan kellene átállítanom Luciban, hogy a WAN port is LAN portként működjön? Meg lehet ezt egyáltalán Luciban csinálni, vagy konzolon keresztül kell?
Előre is köszi a segítséget!"... Feltalálom a hidegfúziót oszt reszeltek az amcsiknak...":)))
-
petakpa1
őstag
válasz
xabolcs
#71377
üzenetére
Tudom, én most elég jóra belottem a helyi hálómat benne az öregfiúval AP módban
.Csak az érdekelt volna, hogy továbbra is a gwlim féle fw a legjobb ha routerkent NATra is használja az ember az eszközt, vagy esetleg az újabb official openwrt-k gyorsabbak már.
[ Szerkesztve ]
"... Feltalálom a hidegfúziót oszt reszeltek az amcsiknak...":)))
-
#71375
petakpa1
őstag
eladohardver
#71374
petakpa1
őstag
válasz
eladohardver
#71374
üzenetére
Gwlim féle fw hozta ezt a sebességet?
"... Feltalálom a hidegfúziót oszt reszeltek az amcsiknak...":)))
-
petakpa1
őstag
-
petakpa1
őstag
Elmentünk 1 hétre nyaralni, mely alatt volt egy áramszünet aminek következtében értelemszerűen újraindult az AP módba konfigurált TP-Link 1043ND v1 eszközöm.
Viszont sajnos az újraindulás után az OpenWrt beli dyndns kliens nem indult el automatikusan. Ez az anomália (azaz, hogy a 1043ND újraindítása után dyndns kliens nem indul el automatikusan, hanem kézzel kell elindítani a process-t) már régebben fennállt, csak mivel itthon voltunk nem tulajdonítottam neki nagy jelentőséget, mert LAN-ról belépve az eszközbe kézzel elindítottam és kész. Tehát a hiba nem az áramszünettel van összefüggésben...
Ha nem vagyunk itthon és az áramszünet hosszabb ideig tart, akkor az áram visszatérte után a szolgáltatói HGW-m és 1043ND újraindulásakor nem biztos, hogy a korábbi ip címet kapom vissza és máris elvesztettem az itthoni hálózatom WAN felőli elérésének lehetőségét
. Ezért szeretném megoldani, hogy OpenWrt boot után automatikusan indítsa el Dyndns klienst is. Tudtok erre megoldást?
Gondolatom szerint System/Startup/Local Startup mezőbe kellene valamit beírnom, de mit?Amúgy az az érdekes, hogy a System/Startup/Initscripts menüben Enabled-re van állítva a dyndns kliens, de mégsem indul el automatikusan
.Közvetlenül újraindítás után így néznek ki a releváns menük:
[ Szerkesztve ]
"... Feltalálom a hidegfúziót oszt reszeltek az amcsiknak...":)))
-
petakpa1
őstag
válasz
vargalex
#71353
üzenetére
Nálam ugyanez a setup van, igaz nem Digis eszközzel, hanem fekete színű Vodafone HGW-vel tandemben dolgozik a v1-es TP-Link 1043ND:Voda HGW
- ő a gateway, ő NAT-ol
- sőt még a wifit is ő szórja 2,4 és 5 GHz-en is
- DHCP szerver kikapcsolva
- port forward-ok végzése mind a hozzá közvetlenül kapcsolodó vezetékes eszközökhöz, mind a TP-Link feléTP-Link 1043ND v1:
- DHCP szerver (ő osztja a belső ip címeket)
- általam bekonfigolt belső ip cím kiosztási rend fix ip címekkel
- switch a vezetékes eszközök felé, így összesen 7 ethernet portom van
- dyndns kliens
- wake on lan szolgáltatás
- port forwardok továbbítása a közvetlenül rá kapcsolódó vezetékes eszközöknek.Ismételten köszönet az itteni fórumtársaknak, hogy a fentit sikerült anno segítségükkel bekonfigolni
. "... Feltalálom a hidegfúziót oszt reszeltek az amcsiknak...":)))
-
petakpa1
őstag
Kb fél éve segítettek beállítani v1-s 1043ND routeremet speciális feladatra (switch+dhcp server+dyndns kliens+WOL funkció kettős port fw segítségével és Luci felületről is). Azóta is hibátlanul működik minden
.Emlékeztetőül így néz ki az itthoni hálózati infrastruktúrám:
(A narancssárga wifis rész továbbra sincs beüzemelve, mert HGW wifije elég jól lefed mindent egyenlőre. Később lehet el kel majd mozgatni HGW-t máshova és akkor már be kell majd kapcsolni az öregfiú wifijét is, de ez nem mostani téma még.)
Mostani témám/kérdésem az lenne, hogy be lehetne-e üzemelni a lehető legegyszerűbb, és legerőforrás-takarékosabb VPN servert (gondolatom szerint PPTP lenne az) öregfiún.
Cél nem a biztonság lenne, hanem csak annyi, hogy unokaöcsém havonta 1-2 alkalommal az én ip címemen keresztül tudjon bejelentkezni egy weboldalra.
Valami olyasmit képzeltem el, hogy a
1) HGW-n forwardolok egy újabb portot a 1043ND felé
2) unokaöcsém eszközein (Android okosteló és Windows PC) bekonfigurálom a beépített VPN kliens szolgáltatást úgy, hogy VPN servernek az én HGW-m WAN ip címét adom meg az 1) pontban FW-olt porton keresztül
3) 1043ND-n pedig beállítok a legegyszerűbb PPTP VPN servertMűködést úgy képzelném, hogy unokaöcsém eszközei mint VPN kliensek WAN-on HGW-men keresztül rácsatlakoznának a 1043ND-n futó VPN serverre, és rajta keresztül mennének ki az internet felé. Innentől kezdve az a weboldal, ahova unokaöcsém be akar lépni úgy érzékelné, hogy az én ip címemről jelentkeztek be rá. Amikor ez megtörtént akkor unokaöcsém bontaná is a VPN kapcsolatot és ezt követően már közvetlenül a saját ip címéről csatlakozna weboldalhoz. Weboldal használatának tudomásom szerint csak az a feltétele, hogy havonta legalább 1x arról az ip címről csatlakozzanak be a felhasználók, amit a weboldal üzemeltetője a szolgáltatás előfizetője saját ip címének gondol.
Működhet e a fenti, be lehet-e 1043ND-men erre a célra üzemelni egy light VPN servert? Ha igen hogyan, mit kell telepíteni, hogyan kell konfigolni? Ráadásul olyan konfig kellene, hogy VPN server ne csak a saját 192.168.0.1-255 tartományú LAN-on lévő eszközeimet lássa (akár az se lenne baj ah egyáltalán nem látná ezeket), hanem az, hogy VPN server vissza is engedje VPN kliens a net felé, egyfajta VPN gateway-ként funkcionáljon a VPN kliens számára.
A folyamatosan futó, igaz klienst csak havonta 1-2 alkalommal rövid időre kiszolgáló VPN server mennyire fogja belassítani 1043ND-met?[ Szerkesztve ]
"... Feltalálom a hidegfúziót oszt reszeltek az amcsiknak...":)))
-
petakpa1
őstag
Megint adódott egy problémám a jelenleg (switchként + dhcp serverként + dyndns kliensként) használt TPLink WR 1043ND v1 eszközömmel.
Egészen pontosan a dyndns klienssel.
Telepítve van a luci-app-ddns csomag, ami értelemszerűen telepítette a ddns-scripts csomagot is.2 problémám van:
1) Az eszköz újraindításakor alapból nem indul el maga a ddns szolgáltatás. Ezt onnan vettem észre, hogy dyndns.org oldalon lehet csekkolni az utolsó host update-k időpontját és ez az eszköz nincs benne, nem updateli se nem ellenőrzi a WAN ip címemet dyndns.org serverén
Ha Luciban a Services/Dynamic DNS menüben elindítom manuálisan a szolgáltatást, akkor onnantól kezdve eszköz csekkolja és updateli is rendesen a WAN ip címet, viszont többé ha Luciban a Services/Dynamic DNS menüre klikkelek akkor az alábbi hibaüzenetet kapom:
stack traceback:
/usr/lib/lua/luci/controller/ddns.lua:116: in function 'service_version'
/usr/lib/lua/luci/controller/ddns.lua:126: in function 'service_ok'
/usr/lib/lua/luci/model/cbi/ddns/overview.lua:20: in function 'func'
/usr/lib/lua/luci/cbi.lua:66: in function 'load'
/usr/lib/lua/luci/dispatcher.lua:1340: in function '_cbi'
/usr/lib/lua/luci/dispatcher.lua:1023: in function 'dispatch'
/usr/lib/lua/luci/dispatcher.lua:478: in function </usr/lib/lua/luci/dispatcher.lua:477>A 2. probléma tehát az, hogy ha fut a dyndns szolgáltatás akkor annak Luci app-ja nem működik
.Neten rákeresve a fenti hibaüzenetre az alábbiakakat találtam:
https://forum.openwrt.org/t/dynamic-dns-luci-gui-does-not-load-on-19-07-rc1/48064/1
https://github.com/openwrt/luci/issues/3395Az itteni javaslatok alapján opkg és luci-compat telepítettségét ellenőriztem, mindkettő fenn van.
Van még egy olyan javaslat is, hogy töröljem Luci cache-t az alábbi parancssal:
rm -r /tmp/luci-*Ha ezt megteszem, mi fog történni? Az eszközbe beállított konfigurációimat (pl belső ip címek fixálása, dyndns szolgáltatás konfigurációja, magának az eszköznek a swithcként való használatra történt konfigurálása) érinti ez a törlés?
Windows-okon cache törlése általában nem okoz gondot, ha valami mégis kellene onnan és törölve lett, azt Windows újra automatikusan létrehozza. Ugyanez igaz OpenWrt-re is?
Nyugodt szívvel kiadhatom a parancsot? Nem fagy le tőle eszköz? Újraindítás szükséges/ajánlott a parancs kiadása után?
Ismét köszönöm a segítséget előre is
[ Szerkesztve ]
"... Feltalálom a hidegfúziót oszt reszeltek az amcsiknak...":)))
-
petakpa1
őstag
-
petakpa1
őstag
válasz
vargalex
#71313
üzenetére
Köszi Alex,
Biztosan ki fogom ezt próbálni, mert sokkal jobb lenne ha PC kliensen maradhatna az automata IP kérés TPLink DHCP serverétől
.Viszont abban még biztosan segítség kell, hogy fentit hogyan is kell beadnom OpenWrt-nek. Ráadásul úgy, hogy TPLink rebootja után is megmaradjon.
+ Csak érdekességképp szeretném érteni is mit csinál fenti parancs. Nem IT-s vagyok, hanem közgazdász utoljára középiskolában láttam programynelvet, Basic-et ás Pascal-t
Ha jól értem MACADDR egy definiált string, amely PC-m MAC címének értékét veszi fel.
Aztán van egy ha függvény: Ha 2 string egyenlő MACADDR-el, akkor 3 string beli ip címhez rendelje hozzá 2 stringbeli MAC címet tartósan.
2 és 3 stringet nem kell megdefiniálni?
#!/bin/sh hely azt jelenti, hogy ez OpenWrt folyamosan figyelni fogja ezt a ha függvényt, és ha feltétel bekövetkezik, akkor végrehajtja ip neigh replace parancsot
Az egészet putty konzolon keresztül kell majd beadnom TPLink-nek, mert Luciben nincs erre input box?
Előre is köszi, ha segítessz, de nem sürgős fene tudja mikor jutok oda, hogy foglalkozzak vele...
"... Feltalálom a hidegfúziót oszt reszeltek az amcsiknak...":)))
-
petakpa1
őstag
Szeretném hinni, hogy meg oldottam (némi googlizással és olvasással):
1) Startup script így néz ki:
# Put your custom commands here that should be executed once
# the system init finished. By default this file does nothing.
sleep 30
ip neigh replace 192.168.0.101 lladdr aa:bb:cc:dd:ee:ff nud permanent dev br-lan
exit 0
Ahol aa:bb:cc:dd:ee:ff az élesztendő PC-m MAC címesleep 30 azért kell, hogy biztosan a boot folyamat végén fusson le az ip neigh replace parancs, akkor amikorra már az ip-tiny csomag is biztosan betöltődött és/vagy arp távla elkészült
ip neigh replcea parancs azért kell, mert ez egyben add és change is, ha nincs még ilyen bejegyzés ARP táblában, akkor létrehozza, ha van akkor megváltoztatja.
2) Ébresztendő PC TCP/IP beállításaiban fixálni kell IP címet, azaz ne DHCP szervertől kérjen ip címet.
Ha jól értem ez azért szükséges, mert az újabb OpenWrt-ben ha kliens kéri IP cím kiosztását DHCP szervertől, akkor ARP tábla azonnal befrissül, felülírja a korábbi ip neigh parancsok által rögzített IP-MAC összrenedeléseket.Ha a fenti startup scriptel indul TPLink majd kb 1-2 perc múlva bekapcsolom PC-met, is, és PC-ből putty-al csatlakozok TPLink-re és kiadom az ip neigh parancsot, akkor végre PERMANENT-et kapok PC-m IP címére.
Remélem holnapra is így marad, nem frissül semmi miatt ARP tábla, és akkor menni fog végre WOL WAN felül, kettős port FW-on keresztül. Cross fingers, holnap délelőtt próba következik.
Apró szápséghibája ennek a megoldásnak, hogy TPLink Luci felületén a Status/Overview menüben nem listázza PC-met mint DHCP-t bérlő kliens....
"... Feltalálom a hidegfúziót oszt reszeltek az amcsiknak...":)))
-
petakpa1
őstag
-
petakpa1
őstag
válasz
petakpa1
#71309
üzenetére
Sajnos továbbra sem jó
Fenti van a startup script-ben, és értelemszerűen lementettem.
Majd TPLinket újraindítottam úgy, hogy kb. 20 mp-re kihúztam tápkábelt, majd visszadugtam és hagytam, hogy teljesen bebootoljon, amíg a sys led folyamatosan ég.
Ezt követően indítottam csak PC-t.
Miután PC elindult 192.168.0.101 ip címet kapott (ezzel eddig sem volt gond), de sajnos továbbra sem PERMANENT, hanem REACHABLE módon.
Konzolba belépve, ip neigh ezt adja vissza:
192.168.0.101 dev br-lan lladdr aa:bb:cc:dd:ee:ff REACHABLE
Mit kellene máshogy csinálnom?
opennwrt forumokon valaki még ip neigh replace parancsot ajánlotta, illetve sleep 30-at mielőtt futnánka az ip neigh parancsok.
Illetve azt is még, hogy PC-men is TCP/IP beállításokban is állítsak be fix ip címet, de ennek nem értem mi köze lenne TPLink ARP táblájához, így ezt még ki sem próbáltam
.Update:
Ha most konzolban kiadom az ip neigh change 192.168.0.101 lladdr aa:bb:cc:dd:ee:ff nud permanent dev br-lan parancsot, akkor következő ip neigh parancs már PERMANENT-ként listázza a PC-met.Most kipróbálom azt, hogy az initscript-be betszem sleep 30-at is az ip neigh change és ip neigh add parancsok elé, hátha ez a megoldás...
[ Szerkesztve ]
"... Feltalálom a hidegfúziót oszt reszeltek az amcsiknak...":)))
-
petakpa1
őstag
válasz
vargalex
#71308
üzenetére
Szia Alex,
A sleep 20-at azért raktam be, mert egy pár hsz-el korábban általam linkelt openwrt forumon ezt javasolták, annak érdekében, hogy az ip neigh add parancs csak azt követően fusson le, hogy az arp tábla már létrejött.
PC-t értelemszerűen csak azt követően indítottam, hogy a TPLink teljesen bebootolt, azaz sys led immár folyamatosan világított. Kb bő 1 perc.Most kiveszem a sleep-et és berakom mindkét általad javasolt parancsot, azaz így fog kinézni startup konfig:
# Put your custom commands here that should be executed once
# the system init finished. By default this file does nothing.
ip neigh change 192.168.0.101 lladdr aa:bb:cc:dd:ee:ff nud permanent dev br-lan
ip neigh add 192.168.0.101 lladdr aa:bb:cc:dd:ee:ff nud permanent dev br-lan
exit 0
Ahol aa:bb:cc:dd:ee:ff értelemszerűen PC-m MAC címe.Mindjárt tesztelem...
"... Feltalálom a hidegfúziót oszt reszeltek az amcsiknak...":)))
-
petakpa1
őstag
válasz
petakpa1
#71306
üzenetére
Sajnos rossz hírem van, továbbra sem éled a gép, hosszabb kikapcsolt állapotból
.Az alábbi konfig van most:
Local Startup így néz ki:
# Put your custom commands here that should be executed once
# the system init finished. By default this file does nothing.
sleep 20
ip neigh add 192.168.0.101 lladdr aa:bb:cc:dd:ee:ff nud permanent dev br-lan
exit 0
ahol aa:bb:cc:dd:ee:ff értelemszerűen az ébresztendő PC MAC címe.Miután fenti el lett mentve aztán volt egy router restartt is, majd PC-t is bekapocsltam, használtam, leállítottam. Ez tegnap este volt
Ma este megpróbáltam kettős port FW szabályon keresztül küldött magik packettel évreszteni, de nem sikerült. Csak a broadcast címre köldött magic oacket ébreszti
.ip neigh az alábbit mutatja
root@TL-WR1043ND:~# ip neigh
192.168.0.101 dev br-lan lladdr aa:bb:cc:dd:ee:ff REACHABLE
fdb0:69d8:3c79:0:f034:db39:6258:cb4c dev br-lan lladdr aa:bb:cc:dd:ee:ff REACHABLE
root@TL-WR1043ND:~#
A gond egyértelműen az, hogy nem tartósan PERMANENT kapcsolja TPLink/OpenWrt az ip címet a MAC addresshez.Mit tudnék még tenni, hogy működjön a WOL WAN felől is?
"... Feltalálom a hidegfúziót oszt reszeltek az amcsiknak...":)))
-
petakpa1
őstag
válasz
vargalex
#71305
üzenetére
Köszi Alex,
Így már ip neigh parancsra
192.168.0.101 dev br-lan lladdr aa:bb:cc:dd:ee:ff PERMANENT eredményt kapok.Ugye ez a beállítás csak addig él amíg TPLink újra nem indul?
Ahhoz, hogy TPLink újraindítása esetén is végrehajtódjon a parancs azt kell csinálnom amit a #41756 hsz-ben írtál?
Oda még nem írom be egyenlőre, hanem most azt csinálom majd, hogy este majd kikapcsolom a PC-t, TPLink nyilván nem lesz újraindítva és holnap délelőtt megpróbálom a kétszeres portf fw szabályomon keresztól küldött magic packettel éleszteni a gépet. Ha ébred, akkor megoldódott a probléma és megcsinálom a #41756 szerint véglegesre.
Jelentkezem majd akár siker akár nem.
"... Feltalálom a hidegfúziót oszt reszeltek az amcsiknak...":)))
-
petakpa1
őstag
válasz
xabolcs
#71300
üzenetére
Köszi!
Telepítettem az ip-tiny csomagot, majd konzolba beírtam ezt:
ip neigh add 192.168.0.101 lladdr aa:bb:cc:dd:ee:ff nud permanent dev br-lan
ahol aa:bb:cc:dd:ee:ff helyett értelemszerűen PC-m MAC címe van
Az alábbit adta vissza konzol:
RTNETLINK answers: File existsMost elfogadta a konfiguráló parancsot vagy sem?
ip neigh-et minden paraméter nélkül kiadva ezt kapom:
192.168.0.101 dev br-lan lladdr aa:bb:cc:dd:ee:ff REACHABLE
REACHABLE helyett nem PERMANENT-nek kellene lennie mostmár? Sikeresen lefutott a parancs vagy sem?
Hogy tudom ezt tesztelni?
Első őtletem az, hogy kikapcsolom a PC-t, várok 3-4 órát, hogy TPLink ARP táblája frissüljön, és utánna próbálkozom megint a kettős port fw-on keresztüli WOL élesztéssel?
Ha éled, akkor jó rögzült ARP táblában a MAC cím?
Mennyi időt kell várnom PC-t kikapcsolva a teszteléssel, mennyi időnként frissül ARP tábla?"... Feltalálom a hidegfúziót oszt reszeltek az amcsiknak...":)))
-
petakpa1
őstag
válasz
vargalex
#71289
üzenetére
Szia Alex,
Köszi, hogy próbálsz segíteni.
System/Software menüben rányomtam, hogy az Update lists gombra majd, bal felül a keresőbe beírtam, hogy IP és kilistázott egy 767 csomagot, aminek leírásában/nevében benne van, hogy ip.
Viszont olyan aminek csak IP a neve nincs
ip-full és ip-tiny van.Putty-al konzolba bejelentkezve ip neigh parancsot kiadva nem sípol, hogy nem ismeri ezt a parancsot, tehát bennem felmerült, hogy kell bármilyen további csomagot telepítenem egyáltalán a parancs használatához?
Neten még keresgélve találtam ezt.
Be is nyomtam konzolba üresen a ip neigh parancsot, és az alábbi eredmény adódott PC-mre:
192.168.0.101 dev br-lan lladdr aa:bb:cc:dd:ee:ff ref 1 used 0/0/0 probes 1 REACHABLE
Ahol aa:bb:cc:dd:ee:ff nyilván a PC-m MAC címe, csak ezt már nem akartam ide beírni.Ez alapján az lehet a gond szerintem, hogy hiába van a Network/DHCP and DNS/Static Leases menüpontban fix ip cím állítva végtelen bérleti idővel a PC-m MAC címéhez az mégse PERMANENT-ként kerül be a TPLInk ARP táblájába
-UPDATE1:
Na próbálkoztam konzolból ip neigh add parancsal, de nem ismeri.
ip parancs csak az alábbiakat ismeri jelenleg:ip addr add|del IFADDR dev IFACE | show|flush [dev IFACE] [to PREFIX]
ip route list|flush|add|del|change|append|replace|test ROUTE
ip link set IFACE [up|down] [arp on|off] [multicast on|off]
[promisc on|off] [mtu NUM] [name NAME] [qlen NUM] [address MAC]
[master IFACE | nomaster]
ip neigh show|flush [to PREFIX] [dev DEV] [nud STATE]
ip rule [list] | add|del SELECTOR ACTIONMelyik csomagot kell telepítenem, hogy az ip neigh add parancs működjön? ip-full vagy ip-tiny?
[ Szerkesztve ]
"... Feltalálom a hidegfúziót oszt reszeltek az amcsiknak...":)))
-
petakpa1
őstag
válasz
vargalex
#71282
üzenetére
(a) Igen én is így gondolom, hogy kiesik. Viszont a 2x-es port forwardos megoldásnak meg pont e miatt kellene működnie, hiszen a TPLink 24/7-ben üzemel és össze van kötve a HGW-vel, így az nem eshet ki a HGW ARP táblájából sosem.
Ez utóbbit bizonyítja az is, hogy a HGW az 50001-es portra küldött csomagot továbbítja a TPLink 192.168.0.2-es íp címének 50001-es portjára és ezt a TPLink Status/Firewall menüjében a packetszám emelkedése igazolja is ahogy fentebb írtam.(b) Igen biztos. A TPLink WAN (kék) portjába nincs semmi dugva. A HGW felől jövő kábel megy LAN1be a PC-ből jövő pedig LAN2-be.
A TPLinken beállított port FW szabály részleteiben így néz ki:
A kérdés inkább az számomra, hogy a 2 port FW-os módszer miért nem működik?
Mintha TPLink ARP táblájából is kiesne idővel a PC, annak ellenére, hogy statikus ip cím van hozzárendelve a PC MAC címéhez végtelen bérleti idővel[ Szerkesztve ]
"... Feltalálom a hidegfúziót oszt reszeltek az amcsiknak...":)))
-
petakpa1
őstag
válasz
vargalex
#71280
üzenetére
És akkor hol a hiba, miért nem jut el
(a) sem HGW 27002-s portjára küldött magic pocket a 192.168.0.101 belső IP 7-es portjára a HGW-be konfigolt powrt FW szabály alapján
(b) sem a HGW 50001-s portjára küldött magic pocket a 192.168.0.101 belső IP 7-es portjára a HGW-be ÉS TPLInkbe konfigolt kettős port FW szabály alapján?Egyénként ma figyeltem a TPlink menüjében Status/Firewall alatt az alábbi részt:
És ahogyan okostelóról WAN felől külső ip címről küldözgettem a magick pocketeket a külsö ip címem 50001-es portjára, úgy szépen emelkedett itt a packet-ek száma és a frogalmazott mennyiség is.
Tehát mintha port FW működne TPLinken, de PC-m mégsem ébred
"... Feltalálom a hidegfúziót oszt reszeltek az amcsiknak...":)))
-
petakpa1
őstag
Ismét az itteni guruk segítségét kérném, mert nem sikerül beállítanom megfelelően port fw-ot a PC-m távolról történő magic pocketes élesztéséhez.
Hálózatom így néz ki:
Router tehát a Vodafone-os HGW-m, de az IP címeket a TPLink osztja.
TPLink gduck kolléga #71255 sz hozzászólása alapján lett beállítva.
Ezen kívül az alábbiakat állítottam még be:
Network/Interfaces/Lan/DHCP server/General setup részben az ip címeket csak a 192.168.0.200-250 tartományban oszt automatikusan.Network/DHCP and DNS/Static Leases menüben az összes klienshez hozzárendeltem manuálisan az ip címeket. A PC-m amit távolról éleszteni akarok mindig a 192.168.0.101 címet kapja, és bérleti idő végtelenre van állítva.
HGW-n beállítottam 2 ilyen port FW szabályt:
A felső elméletileg önállóan is ébreszteni a PC-met, ha külső ip címem 27002-es portjára elküldöm a PC-m MAC címét
Az alsó pedig a TPLinknek továbbítja csak a csomagot, melyet a TPLink az alábbi port fw szabály alapján továbbít PC-mnek:TPLinken beállított port FW szabály a Network/Firewall/Port Forwards részben
A probléma ott van, hogy a PC-m kikapcsolását követően valamennyi ideig mind külső ip címem 27002-es portjára mind a 50001-es portjára küldött csomag éleszti a PC-t.
Viszont ha hosszabb idő telik el, pl ha este kikapcsolom PC-t másnap reggel elmegyek dolgozni, és du-án szeretném éleszteni a PC-t akkor már sem a 27002-es portra sem az 50001-es prtra küldött csomag nem ébreszt.
Ellenben ha távolról belépek TPLink menüjébe és a Services/Wake onLan menüben a Host To Wake up legördülőben kiválasztom PC-t és rányomok a zöld gombra akkor gond nélkül éleszti a PC-t.
Továbbá ha amikor hazaértem és telom feljelentkezett a wifire, és a 255.255.255.255 címre elküldöm a PC-m MAC azonosítóját akkor is egyből ébred a PC.
Ezek alapján úgy vélem, hogy a probléma nem a PC oldalán van, hanem a TPLink oldalon.
Mit kellene máshogyan beállítanom, hogy legalább a 50001 portra küldött csomag biztonsággal ébressze PC-met?A legeslegeredeti problémám (ami miatt ismét beállítottam TPLinket hálózatomba) az volt, hogy HGW ARP táblája bizonyos időközönkét frissült, így időről időre kikerült belőle az az info, hogy a kikapcsolt állapotban lévő PC-m melyik LAN porton is lóg (akkor még közvetlenül a HGW Lan portjába csatlakozott). Így azt, hogy a 27002 portra küldött csomaggal egy idő eltelte múlva miért nem éled PC el tudom fogadni.
Azt viszont egyáltalán nem értem, hogy a 24/7-ben a HGW-hez kapcsolódó TPLink (aminek ip címe szintén fixált: 192.168.0.2) mint switch-re forwardolt 50001es port majd ezt TPLink által PC-m belső ip címére tovább forwardolt csomag miért nem éleszti PC-t?
TPLink ARP táblája is befrissül valamilyen időközönként annak ellenére, hogy PC-m ip címe végtelen bérleti idővel fixálva van TPLinkben.
Hogyan tudnám megoldani, hogy tartósan is üzembiztosan lehessen éleszteni PC-met távolról?
Ismét bocsi a nagyon hosszú postért, de igyekeztem minden infót megadni ami a helyzet megértéséhez szükséges.
[ Szerkesztve ]
"... Feltalálom a hidegfúziót oszt reszeltek az amcsiknak...":)))
-
petakpa1
őstag
Persze nyilván nem a 22-es és 80-as portokat nyitom ki wan felé, de egy port scannerrel simán kiszűrik a magasabb nyitott portokat is.
@ Szabolcs
HGW-m UPC-s, illetve mostmár Voda-s eszköz és szerinten nem támogat semmi ilyen specko funkciót, hogy MESH. El is engedtem ezt a témát, megleszek nélküle is"... Feltalálom a hidegfúziót oszt reszeltek az amcsiknak...":)))
-
petakpa1
őstag
Na igen, pont erre gondoltam én is. Ha a kliens érzékeli, hogy annak az AP-nak ahova csatlakozva van már gyengébb a jele, mint az ugyanazon SSID-vel rendelkező MESH hálózatban lévő de már erősseb jelű AP-nak, akkor automatikusan átvált utóbbira.
De azt gondolnám, hogy ehhez a HGW-nek is támogatnia kellene a MESH-t, az pedig szerintem hiányzik. Compal CH7465CF a HGW-m típusa egyébként.
Az világos, hogyha 2 rádiós egységem lesz 2,4 GHz-en akkor egyiket 1-es másikat 13-as csatornára kell állítanom, hogy ne legyenek átfedésben még 40 MHz-es tartomány esetén sem.
TPLink wifijének beüzemelése egyébként nem aktuális még, mert nincs meg a webkamera amit ki fog szolgálni. Kb egy falon és a szobán belül 3-4 m-en kell majd átlátnia a wifinek, szerintem ez menni fog.
Mesh nélkül meg elleszünk szerintem valahogy...
Még1x köszi mindenkinek a segítséget. A következő hetekben még tesztelem ezt az új setupot, és majd beszámolok hogyan muzsikál. Tök jó, hogy OpenWrt-vel mai napig használható ez az eszköz még
[ Szerkesztve ]
"... Feltalálom a hidegfúziót oszt reszeltek az amcsiknak...":)))
-
petakpa1
őstag
válasz
vargalex
#71259
üzenetére
Köszi, mindjárt átállítom így, mert ezzel a setuppal minden általam nem ismert kliens .200-al kezdődő ip címet kap majd, így könnyen felismerem akár a HGW-ből is, ha valami új kliens kapcsolódik, pl azért mert betört a wifi hálózatomba.
Közben belőttem a dyndns szolgáltatást is
.Később szeretném majd TPLink wifi-jét is beüzemelni. Azt meg lehet majd oldani, hogy HGW és TPLink wifie-jei MESH hálózatba legyenek majd rendezve? Vagy ez csak akkor lenne lehetséges, ha HGW is MESH képes. Sajnos nem az
."... Feltalálom a hidegfúziót oszt reszeltek az amcsiknak...":)))
-
petakpa1
őstag
válasz
vargalex
#71257
üzenetére
Köszi Alex,
Csomót mértem, és közvetlen HGW-PC kapcsolat esetén is néha csak 460-480 Mbps a sebesség. Tehát nem biztos hogy a TPLink a hunyó, lehet Vodafone hálózat terheltsége ingadozik így vasárnap este...
+ Ha gigabites switch van benne, akkor annak valóban nem lehet az a szűk keresztmetszet 500 Mbps-nél.
HGW-ben TPLink belső ip címén 80-as portra fw-olással megoldottam a WAN felőli elérést is
.Az egyik ok ami miatt belebonyolódtam ebbe az egészbe, az volt, hogy amíg a HGW volt a gateway is és a DHCP szerver is, addig ha a menüjében lekérdeztem a rá csatlakozó eszközökét, akkor némelyiknél kiírta a kliens nevét, némelyiknél nem, hanem ismeretlen eszközt írt. Nyilván attól függött, hogy a kliens küldött e ilyen infot magáról.
Most viszont, hogy a TP Link lett a DHCP szerver a a HGW már az összes kliensre azt írja ki, hogy ismeretlen
, tehát rosszabb a helyzet mint volt .Arra gondoltam, hogy TPLink-ben a Network/DHCP and DNS/Static Leases-ben beállítok minden általam ismert klienshez egy-egy fix ip címet 192.168.101-150 tartományban, míg a Network/Interfaces/DHCP Server/General Setup-ban beállítom, hogy 201 legyen az első ip cím amit kioszt, és maximum 50-et osszon ki.
A) Jól gondolom, hogy ennek az ez az eredménye, hogy a 101-150 tartoményból DHCP nem oszt ip címeket, ott csak az általam fixen kiosztottak lesznek, míg bármi egyéb ami a DHCP servertől kér le ip címet az a 201-250 tartományból fog kapni egyet?
B) Vagy ezzel a beállítással a DHCP server nem fog kiosztani azon klienseknek ip címet egyáltalán akikhez a 101-150 tartományban fixen hozzárendeltem ip-t?
"... Feltalálom a hidegfúziót oszt reszeltek az amcsiknak...":)))
-
petakpa1
őstag
Köszönöm, ez alapján sikerült belőnöm, most már a TpLInk van a switch helyén, és az osztja az ip címeket, de a gateway az továbbra is a HGW.
WAN -> HGW -> TPLink as switch -> PC irányú letöltési sebességet még tesztelgetem, mert mindtha nem mindig tolná ki a 500 Mbps-t...
Ha közvetlenül HGW-re dugom a PC-t (és PC TCP/IP konfigjában manuálisan adom meg a hálózati konfigurációt, (HGW-n DHCP funkció ki van kapcsolva ugyebár) akkor minden mérésnél megvan az 500 Mbps, tehát nem a netkapcsolat vag ISP gyengélkedik.
Még tesztelgetem, mi okozza a lassulgatást...
Illetve lenne még egy kérdésem:
Mit kellene beállítanom, ahhoz, hogy WAN felől is elérjem TPLink konfigurálós oldalát? Elég a HGW-ben egy portf fw szabály, amely egy általam kiválasztott portot (pl 12345) fw-ol a TPLink belső ip címére, azaz 192.168.0.2-re? Ezen belül melyik portra 22?
[ Szerkesztve ]
"... Feltalálom a hidegfúziót oszt reszeltek az amcsiknak...":)))
-
petakpa1
őstag
válasz
petakpa1
#71252
üzenetére
Héten nem nagyon volt időm foglalkozni az öregfiúval, leszámítva azt, hogy random méregettem rajta rajta keresztül letöltési sebességet, de sajnos 100%-ban stabilan nem tudja a 500 Mbps-t. Van, hogy áttolja, de van, hogy csak 460-480 jön át (nagyon ritkán még 450-nél is kevesebb és pár alkalommal meg kb 500). Teljesen random, hogy mikor mennyi...
Mindez úgy, hogy SFE flow offload engedélyezve van, és mindössze 1 db PC-t routol.Közben a netmegosztás hálózati topicban kaptam egy újabb ötletet, és ennek openwrt-n való belövésében kérném segítségeteket.
Róla lenne szó:
Ez lenne a cél amit el szeretnék érni.
Most ott tartok, hogy HGW-n még DHCP ON, és a 1043ND helyett egy sima buta switch van a hálózatomban.
A következő lépés lenne az, hogy a switch helyére bekerülne az előzetesen már egy laptop segítségével a fenti hálózati strukturára felkonfigolt 1043ND és ezzel egyidejűleg HGW-ben le is kapcsolnám a DHCP funkciót.
IP címek az alábbiak lennének:
HGW - 192.168.0.1
1043ND - 192.168.0.2
PC (1043ND mögött) - 192.168.0.101
MiniPC (HGW- egyik lan portján lógna!) -192.168.0.102
Laptop (1043 ND mögött) - amit DHCP szerver oszt neki
wifi kliensek (HGW-n) - amit a GDCP szerver oszt nekikGondolatom szerint az alábbiakat kellene beállítanom 1043ND-n lévő Openwrt-ben, illetve az alábbi kérdéseim lennének
1) 1043ND ip címét beállítani 192.168.0.2-re (célom az lenne, hogy HGW, 1043ND és az összes kliens is ugyanabban az alhálózatban legyen. => Hol tudom ezt megtenni Openwrt-ben. Mi legyen a netmask?
2) 1043ND-ben beállítani, hogy 192.168.0.101-250 között osszon ki IP címeket a klienseknek. Hol lehet ezt?
3) Mit kell még openwrt-ben beállítani, hogy ne routerként hanem switchként működjön?
[4) A 1043ND wifije egyenlőre nem lesz bekapcsolva, az csak egy jövőbeni opció, így a narancssárga szaggatottal jelölt résszel egyenlőre nem foglalkozom]
[5) Jó lenne ha később majd a 1043ND WAN portját is tudnám LAN portként használni, de ez is ráér majd később, nem SOS]
6) A HGW wifijére kapcsolódó kliensek (amennyiben ip beállításukat auto DHCP lekérésre állítom) fogják tudni, hogy nem HGW-től, hanem 1043ND-től kérjék az ip címet?
7) Előbbivel összefüggésben 1043ND a a DHCP ip cím kérelmekre ugye nem csak az ip címet fogja kosztani klienseknek, hanem a
(i) netmaskot,
(ii) gatewayt (ami ugye nem a 1043ND egyben DHCP server ip címe(192.168.0.2), hanem a HGW 192.168.0.1 ip címe lesz majd, azt adja ki, valamint
(iii) valamint a dns szerverek címét is. => Mivel a HGW-n nem fog futni DHCP server funkció, ezért a 1043ND honnan fogja megtudni az ISP-m DNS szervereinek nevét? Vagy hagyjam a fenébe a ISP DNS szerverét, és simán állítsam be 8.8.8.8-at illetve 8.8.4.4-et fixen 1043ND-ben és ezt osztja majd ki LAN klienseknek 1043ND? Hol és hogyan kel ezt beállítani Openwrt-ben?
8) HGW LAN2-4 portjaira kötött vezetékes kliensek (jelenleg csak a MiniPC) is ugye a 1043ND-től fogja kérni és kapni az ip címet, netmaskot DNS servert ugyanúgy, mint a HGW-re kapcsolódó wifis kliensek.
9) Ha a MiniPC-nek a 1043ND-vel fixen és MAC cím kötötten mindig a 192.168.0.102 ip cím kerül kiosztásra és a HGW-ben beállítők különféle port forward szabályokat WAN felől 192.168.0.102 irányába, akkor ezek fognak működni? HGW érteni fogja hogy hova kell ezeket a bejövő csomagokat továbbítani, annak ellenére, hogy nem ő a DHCP server?
10) Ha a 1043ND mögött lévő PC-nek szintén kiosztok egy fix és MAC cím kötött IP címet pl 192.168.0.101, és HGW-ben beállítok port FW szabályokan WAN felől 192.168.0.102-re, akkor ezek működni fognak?
Vagy inkább amiket a 1043ND mögötti kliensekre akarok FW-olni, azt úgy állítsam be, hogy:
(i) HGW-ben forwardolási szabály 1043ND (192.168.0.2) felé majd
(ii) 1043ND-ben FW-lás tovább a PC (192.168.0.101) felé.Húúú ez nagyon hossz lett, bocsika...
Azért remélem lesz aki tud segíteni, mint a korábbiakban
(u.i. Nyilván tudom, hogy egy pár 10 ezer forintos routerrel meg tudnám oldani sokkal egyszerűbben ezt, csak amíg 1043ND üzemel addig nem növelném vele az e hulladékot)
"... Feltalálom a hidegfúziót oszt reszeltek az amcsiknak...":)))
-
petakpa1
őstag
válasz
petakpa1
#71251
üzenetére
Siker
. A Material skin felment, illetve az OpenWrt is, de az nem tetszett így töröltem is.Most a sebességet tesztelem parancsoros speedtest-el, úgy, hogy wifi tiltva és LAN-on csak egy kliens van rácsatlakoztatva, amivel mérek. 10 mérés átlaga 485 Mbps.
Rooter-be konzollal is be vagyok jelentkezve és a TOP parancs 90% feletti CPU kihasználtságot mutat amikor kliensen a letöltési teszt fut.
Ezzel még így meg is békélnék. Kíváncsi vagyok ha rá lesz csatlakoztatva az AP is, és azon keresztül 10-15 egyéb kliens, döntően IoT eszközök is rajta lógnak, akkor mit produkál majd.
[ Szerkesztve ]
"... Feltalálom a hidegfúziót oszt reszeltek az amcsiknak...":)))
-
petakpa1
őstag
válasz
petakpa1
#71250
üzenetére
Amíg az Cisco AP vissza nem érkezik hozzám (egy itteni kolléga átfasheli nekem standalone/autonomous Fw-re a most rajta lévő, és csak külön kontrollerel működő lightweight WF-t), felkonfigolom az openwrt-t
WOL és DDNS szolgáltatások már fenn is vannak
.Szeretnék egy másik skin-t is a bootstrap helyett. A csomagok frissítése után ezek a skinek telepíthetők:
Bátran telepíthetem ezeket? Nem lesz gond, hogy 22. a verziószámuk? Fognak működni az én 19.07.10 verziós eszközömön?
"... Feltalálom a hidegfúziót oszt reszeltek az amcsiknak...":)))
-
petakpa1
őstag
válasz
iMaverick
#71244
üzenetére
Az a gwlim által optimalizált FW volt, de abból a 18 és 19-es főverziójúak már csak a 64 MB-ra moddolt v1-esre telepíthetőek asszem.
Épp ezért használtam én a hivatalos 19.07.7-es FW-t utoljára 2021 tavaszán, de az bekapcsolt wifivel SFE engedélyezése mellett sem tudta nekem kihajtani az új 500-as netet, na meg persze 5G-s wifi sem volt rajta... Ezért került kb másfél éve szekrénybe az öregfiú.
Majd most meglátjuk mire megy akkor ha a Wifi-t a Cisco AP fogja szórni...
Egyébként ma du-n fel is kúszott rá a 19.07.10-es verzió
Egyenlőre még nincs semmi bekonfigolva rajta, csak két kliens vezetéken fel lett csatlakoztatva, és még WAN kábel sem lett bedugva. A fenti kép alapján azért szabad memória is van még szépen. Igaz ennél csak magasabb lesz majd a kihasználtság ahogy több kliens kapcsolódik mind vezetéken, mind az AP-n keresztül.
Továbbá még minimum 2 kiegészítő csomagot is telepítenem kell: WOL és DDNS, valamint jó lenne valami szebb skin is és magyar nyelv, de utóbbi kettőről azért le tudok mondani ha muszáj...
Viszont lennének még kérdéseim:
ip6 és wifi szolgáltatást egyáltalán nem fogom használni? Ezeket elegendő letiltani, vagy ezeket a csomagokat uninstallálni is érdemes?Laikusként azt gondolom, ha letiltom, akkor a flash-ben foglalja a helyet, de a memóriába be sem töltődik, nem foglalja a RAM-ot és a CPU-t sem terheli. Jól gondolom ezt?
Mivel csak pár addicionális csomagra lesz szükségem amik el fognak férni a tárhelyben, még úgy is ha ipv6 és wifi csomagok maradnak, ezért nem távolítanám el őket.
Ha viszont letiltva is fogyasztják RAM-ot és eszik kicsit CPU-t akkor lehet érdemes lenne eltávolítani őket.
Hogy működik openwrt, azaz linux ilyen szempontból?
Ja és az is kérdésem lenne még, hogy hol lehet azt beállítani, hogy DHCP milyen ip tartományban ossza a címeket klienseknek? Azt szeretném ha a 192.168.1.101 lenne az első ip cím amit kioszt a 192.168.1.100 helyett...
"... Feltalálom a hidegfúziót oszt reszeltek az amcsiknak...":)))
-
petakpa1
őstag
Aham, hát én nem a 1043ND-t akarom AP módban használni.
Hanem 1043ND lenne maga routerem, de wifi rádió le lenne tiltva rajta, és a wifi szórást a Cisco AP-re bíznám. Így kellene hoznia az 500 Mbps letöltést de csak kábelen.
Gondolatom szerint wifi rádió openwrt-ben való letiltása is szabadít fel valamennyi erőforrást CPU-nak, kérdés, hogy ez elég lesz-e arra, hogy vezetékkel rákötött 3 kliens (PC, MiniPC és AP), illetve az AP-n keresztül routolás szempontból szintén rajta lógó 10-15 kisebb adatforgalmat kapcsolati szálat bíró eszköz mellett átjon-e majd még az 500 Mbps ha letöltök egy nagy fájl-t PC-mre.
Pár hét és megtudjuk
, de valszeg OpenWrt installálása és beállítása kapcsán is lesznek még kérdéseim...[ Szerkesztve ]
"... Feltalálom a hidegfúziót oszt reszeltek az amcsiknak...":)))
-
petakpa1
őstag
Ok. Akkor marad az utolsó 19-es.
Viszont a "csak a wifi-t AP-re" mondatokat nem értem.
Az alábbi lenne módon nézne ki a hálózaton:
Vodafone-os Compal HGW modem módba állítva.
1 patch kábel köti össze HGW-t a 1043ND WAN portjaval.
1043ND lenne a routerem.
1043ND-ben wifi rádió le lesz tiltva.
4 LAN portjahoz 4 eszköz csatlakozna patch kábellel: Fő asztali PC-m, egy MiniPC, a céges laptopon és a Cisco AP.
A wifit a Cisco AP szórnak, de a rá wifin kapcsolódó klienseknek a 1043ND osztaná az ip címeket és routolna is őket természetesen.
Wifin 2 okostelo, 1okostv, és kb 10 IoT eszköz lógnak, termosztát, klimak, porszívó, redőnyök kpi egysége, napelem invertere, webkamerak és ilyenek. Ezek igazából minimális forgalmat generalnak.500 Mbps letöltési sebességet végül is csak a saját PC-m vonatkozásában kellene tudnia a routernek. Az összes többi eszköznél nem lényeges a netsebesség. Magát a PC-sem torrentezesre használom. Csak azt szeretném, ha letöltöm egy nagyobb filmet az 500Mbs-el csorogjon lefelé.
"... Feltalálom a hidegfúziót oszt reszeltek az amcsiknak...":)))
-
petakpa1
őstag
1043ND v1.8 resurrection project
2021. áprilisában nyugdíjba küldtem kedvenc routeremet, mert az 500/22 Mbps sávszéleségre upgradelt UPC netemet már sajnos nem volt képes kiszolgálni, pedig sokat küzdöttem vele: https://prohardver.hu/tema/tp-link_wr1043nd_router/hsz_70915-70917.html
Azóta az immár Vodafone által adott Compal CH7465CF HGW-t használtam router üzemódban, de sajnos ez kompromisszumokkal jár, mert fix ip-t ugyan ki lehet osztani, de WOL mégse megy 100% biztonsággal.
Időközben hozzámkerült egy Cisco AIR-CAP1702I-E-K9 AP.
Tervem az lenne, hogy 1043ND-n letiltom a wifi funkciókat, melyet az AP fog a jövőben ellátni, és bízom abban, hogy wifi okozta terhelés nélkül 1043ND CPU-ja egy jól bekonfigolt OpenWrt-vel kábelen át tudja tolni az 500 Mbps, ha a WAN oldali kapcsolat DHCP.
Van erre esély szerintetek?Kérdés, hogy melyik OpenWrt-vel próbálkozzak?
Legutóbb 19.07.7. volt fenn, de ezt mindenképp cserélném 19.07.10-re.Ennél újabb verziókkal 21 vagy netén 22 érdemes próbálkoznom? Nyújtanak ezek neem bármit?
- WPA3 nem fog kelleni, mert azt az AP intézi majd.
- DSA kellhet nekem?
- 5.x-es Linux kernelnek van értelme?
- Firewall 4 kellhet nekem?
- Year 2038 problémába belefuthatok?Ezek lennének ez első körös kérdéseim, előre is köszönöm a válaszokat és javaslatokat.
[ Szerkesztve ]
"... Feltalálom a hidegfúziót oszt reszeltek az amcsiknak...":)))
-
-
petakpa1
őstag
válasz
Astery
#70939
üzenetére
Épp pár hónapja próbáltam a max teljesítményt kisajtolni ebből a routerből. Nagy nehezen elértem az 500 Mbps-t, de csak DHCP kapcsolat esetén. Az alábbiak kellettek hozzá:
- Legfrissebb OpenWrt
- SFE engedélyezése
- Wifi letiltása
Részleteket lásd a 70903-70917 közötti hozzászólásaimban.
Digis Gigabites nethez, ami ráadásul még PPPOE is egyértelműen kevés lesz ahogy Alex is írja ."... Feltalálom a hidegfúziót oszt reszeltek az amcsiknak...":)))
-
petakpa1
őstag
válasz
petakpa1
#70916
üzenetére
Ma mielőtt dobozba került az öregfiú visszatettem rá a 19.07.7-et, majd menüjéből rákerült még a Material theme, DynDNS, és WOL csomagok (értelemszerűen ezek is Luci appal és magyarítással), de semmi más nem lett beállítva Wireless rész sem volt engedélyezve.
Próbaképp csináltam még egy utolsó sebességmérést úgy, hogy csak 1 db PC csatlakozott hozzá, értelemszerűen kábelen.
SFE engedélyezése nélkül 188 Mbps-t mértem,
SFE-t engedélyezve viszont most ki tudtam mérni az 500 Mbps-t.Tanulság annyi, hogy ha sok klienst kell kiszolgálni, pláne wifi-n, akkor már nem elég az 500-as nethez az öregfiú, ellenben ha csak vezetékes kliensek vannak, akkor még igen
.Majd meglátjuk mi lesz a sorsa, egyenlőre dobozban pihen
.Még1x köszi mindenkinek a segítséget!
"... Feltalálom a hidegfúziót oszt reszeltek az amcsiknak...":)))
-
petakpa1
őstag
válasz
petakpa1
#70915
üzenetére
Na feltettem a gwlim MiniBuild-et, és egy minimálisat még hozott a sebességben, max 410-420 Mbps között mérek így, talán 1x volt 445 is, ha közvetlenül a HGW-re vagyok kapcsolódva akkor megvan az 500.
Négy választásom van:
1) Maradok ennél a gwlim fw-nél, de rászánok még 4-5 órát, hogy mindent újra bekonfigoljak + lemondok a WOL és DynDNS szolgáltatásokról, de cserébe kapok max +1020 MBps sebessgéet
2) Visszatérek 19.07.7-re, és beérem max 400 Mpbs-el
3) Nyugdíjba küldöm az öregfiút és használom a Vodás HGW-t routernek, ami tud AC-s wifit is már.
4) Veszek egy új saját modern routert.Valszeg egyenlőre 2) lesz mert az a leggyorsabb és érzek valami fejfájást így az oltás után, de lehet megpróbálkozom 3)-mal is majd.
Nagyon köszönöm mind xabolcs, mind gduck segítségét.
"... Feltalálom a hidegfúziót oszt reszeltek az amcsiknak...":)))
-
petakpa1
őstag
válasz
xabolcs
#70914
üzenetére
Köszi ez nagy lelkű, de nem kell még egy kütyü. Az öregfiú megtartásának legfőbb motivációja az, hogy ne szennyezzem a környezetet azzal, hogy egy még kisebb kompromisszumokkal, de használható eszközt lecserélek egy újra, a régi meg megy a veszélyes hulladékba. Valahol nagyon rosszul működik a világunk (fogyasztói társadalom) jelenleg
Küldtem egy privit folytassuk ott szerintem!
Itt meg majd utólag beszámolok, hogy sikerült e feltenni a gwlim féle MiniBuild-et és mennyi sebességet hozott? Nem e hétvége lesz, mert hamarosan megyek oltásra
"... Feltalálom a hidegfúziót oszt reszeltek az amcsiknak...":)))
-
petakpa1
őstag
válasz
xabolcs
#70912
üzenetére
Isten vagy, nagyon köszönöm!
Akkor megpróbálom feltenni az általad fentebb linkelt MiniBuild-et.
19.07.7-ről mehet fel simán a sysupgrade Lucin keresztül? Beállítások megtartására rákoczkáztassak vagy inkább konfigoljak újra mindent? (Ez elég hosszadalmas, mert rakat eszköz van és mindegyiknek fix ip-je csomó port fw szabállyal...).Ááá a fentiek nekem kínaiak, pénzügyi végzettségem van nem informatikai...
Másik OpenWrt-s eszközöm nincs sajnos.
A DynDNS-t elvileg meg tudom oldani, mert belső hálón van egy webkamera amiben van beépített DynDNS kliens (bár jobban szerettem, hogy eddig minden hálózattal és netkezeléssel kapcsolatos dolgot a router intézett).
Végülis a WOL-t is meg lehet oldani megfelelően konfigurált port fw-d szabályokkal, csak a múltban, mikor így csináltam nem mindig éledt LAN-on lévő gép. Ezért tértem át arra, hogy belépek távolról Luci-ba és WOL menüpontban ébresztem a célgépet. Ez minden alkalommal hibátlanul ment, míg WAN->LAN port fw esetében valahogy nem mindig jutott el a Magic Pocket a LAN-on lévő célgéphez. Ennek okára sosem tudtam rájönni .[ Szerkesztve ]
"... Feltalálom a hidegfúziót oszt reszeltek az amcsiknak...":)))
-
petakpa1
őstag
válasz
xabolcs
#70908
üzenetére
Aaa ez nekem bonyi. Windowson nőttem fel, ha nincs GUI akkor megáll a tudomány.
Van még Neked is ilyen routered? Kipróbálnád rajta? Nagyon szuper lenne! Köszönöm!
A Cannot support package installation Azt jelenti Rendszer/Szoftver menü teljesen hiányzik, package installer modul nincs is benne, vagy csak azt, hogy nincs több hely a Flash Rom-ban ezért nem lehet további csomagokat telepíteni?
@ gduck: Igen tudom, a most fenn lévő 19.07.7-ben is benne van, és engedélyeztem is, de ezzel is csak max 360-400 Mbps sebesség jön át.
[ Szerkesztve ]
"... Feltalálom a hidegfúziót oszt reszeltek az amcsiknak...":)))
-
petakpa1
őstag
válasz
xabolcs
#70904
üzenetére
Igen csak ebben az ún. MiniBuild-ben nincs Luci sem
Jól tudom ezt?
Én pedig parancssorból nem tudnám bekonfigolni a routert sajnos.
Továbbá WOL és DynDSN szolgáltatásokra is szükségem lenne.Nekem egy olyan build kellene a gwlim féléből, amiben nincs ipv6 egyáltalán, ellenben van Luci, WOL, és DynDNS. Szerinted lehet ilyet csinálni?
[ Szerkesztve ]
"... Feltalálom a hidegfúziót oszt reszeltek az amcsiknak...":)))
-
petakpa1
őstag
válasz
petakpa1
#70901
üzenetére
UP + újabb kérdések:
Voda/UPC megemelte a sávszélemet 120 Mbps-ről 500-ra, de sajnos ezt a sebességet már nem tudja áttolni az öregfiú még akkor se, ha Sofware Flow Offloading engedélyezve van a tűzfalbeállításokban. Max 400 Mbps-es letöltési sebességet tudok így mérni
Tennnék még egy próbát a gwlim féle fast path firmware-el is ( https://github.com/gwlim/Fast-Path-LEDE-OpenWRT/tree/master/Fast-Path/Dec-2018/Below%2064MB/TP-Link%20WR1043NDv1-mips24k ) bár ez sokkal régebbi így nélkülüzi az utóbbi 2 év kernel fejlesztéseit, security patch-ait.
Luci felületről tölteném vissza a fenti LEDE sysupgrade verziót, de az alábbi hibaüzenetet kapom:
Image metadata not found Use sysupgrade -F to override this check when downgrading or flashing to vendor firmware Image check failed.
Elméletileg frissítés kényszerítéssel továbbmehetek, de kérdés, hogy megtegyem? Nem fogom téglásítani az öregfiút?
"... Feltalálom a hidegfúziót oszt reszeltek az amcsiknak...":)))
-
petakpa1
őstag
További kérdések:
UPC-s HGW-m bridge módban van, így ipv6 egyáltalán nincs nállam.A routerben a Hálózat/Csatolók menüpontban a WAN6 csatolót (DHCPV6 ügyfél protokoll) letiltottam, el sem indul amikor bebootol a router.
Ennek ellenére router a LAN felőli klienseknek kioszt ipv6 címet is. Ezt hol kellene letiltani?
Mivel ISP-től egyáltalán nincs ipv6 nállam teljesen felesleges, hogy a LAN-on is legyen, sőt azt gondolom a mostani beállítás (router kioszt ipv6 címeket is klienseknek) sebesség szempontjából nem jó, mert kliensek gondolom alapértelmezetten ipv6-on próbálnának kommunikálni mind router, mind azon keresztül WAN felé, és mikor ez sikertelen akkor próbálkoznak csak ipv4-el
Jól gondolom ezt?
Valóban lenne értelme teljesen kikapcsolni ipv6-ot LAN oldalon is? Hogyan csináljam ezt?"... Feltalálom a hidegfúziót oszt reszeltek az amcsiknak...":)))
-
petakpa1
őstag
Ma végre volt időm feltenni az aktuális 19.07.7 fw-t a v1-es routeremre. Igen mai napig az öregfiút használom
.Új FW is tökéletesen működik egyenlőre.
Manuális upload-dal feltelepítettem az OpenWrt 2020 Luci témát is, de sajnos vannak hibái, így maradtam a Material-nál végül.
(Ha valakit érdekel megírom milyen problémák voltak 2020-as témával.)A router újrakonfigurálása során átbújtam a teljes menüt, és felvetődött bennem egy kérdés:
Vezeték nélküli Hálózat haladó beállításaiban lehet változtatni az országkódot. Van annak értelme, hogy olyan országkódot állítok be, amely a legnagyobb átviteli teljesítményt (Max Transmit Power) engedi 20dBm (100 mW)-nál magasabbra állítani?
Lehet ennek pozitív hatása a wifi átviteli teljesítményre?
Pl lakás távolabbi részein jobb lesz ettől a kapcsolat sebessége, vagy felesleges, mert 1043ND hardvere max 100 mW-tal képes csak sugározni, értelmetlen magasabbra állítani?
(Azt tudom, hogy egy ilyen beállítással törvényt szegek, mert itthon max 100 mW-al adhatnak a routerek 2,4 GHz-en, de nem hinném, hogy NMHH valaha is bekopogtatna e miatt).Ha magasabb adóteljesítménnyel használom tartósan attól károsodhat, tönkremehet a router?
Jövő héten váltok 120 Mbit-ról 500 MBites netkapcsolatra. Kíváncsi leszek mennyit tud majd áttolni ebből a sávszélből az öregfiú? Természetesen beszámolok majd az eredményről
"... Feltalálom a hidegfúziót oszt reszeltek az amcsiknak...":)))
-
petakpa1
őstag
válasz
vargalex
#70870
üzenetére
Köszi. És azután, hogy a available package-ként letöltésre felajánlott Freifunk-Generic sem működött nállam szerinted megpróbálkozhatom az általad linkelt 2020-assal?
Legroszabb esetben az sem működik és eltávolítom azt is terminálból mint a Freifunk-ot? Történhet ennél rosszabb, pl hogy teljesen használhatatlanná válik a router és nem tudok HO-ból dolgozni?
"... Feltalálom a hidegfúziót oszt reszeltek az amcsiknak...":)))
-
petakpa1
őstag
válasz
petakpa1
#70868
üzenetére
Illetve bocs, a System menüben kiválasztható maradt a Freifunk-Generic téma is, de ha kiválasztom a Bottstrap jön be helyette,.
A Software menüben viszont ezt installálhatónak mutatja a Freifunk-Generic-et azaz jelenleg nincs telepítve.
"... Feltalálom a hidegfúziót oszt reszeltek az amcsiknak...":)))
-
petakpa1
őstag
válasz
Headless
#70867
üzenetére
Sikerült
, nagyon köszönöm .Most az alábbi témák vannak telepítve
- Bootstrap Theme (default)
- Material Theme
- LuCI OpenWrt.org themeSajnos egyik sem úgy néz ki, mint amit iMaverick kolléga linkelt a #70852-ben
, pedig az nagyon bejövős "... Feltalálom a hidegfúziót oszt reszeltek az amcsiknak...":)))
-
petakpa1
őstag
válasz
Headless
#70865
üzenetére
Második általad javasolt parancs ezt az eredményt adta
luci-theme-freifunk-generic - git-21.027.57309-c621a42-1Akkor ezt a parancsot adjam ki az eltávolításához?
opkg remove luci-theme-freifunk-generic - git-21.027.57309-c621a42-1
Biztos, hogy ilyenkor visszaáll a default témára a bootsrapra?"... Feltalálom a hidegfúziót oszt reszeltek az amcsiknak...":)))
-
petakpa1
őstag
válasz
petakpa1
#70863
üzenetére
Ajjajj baj van
Telepítettem a luci-theme-freifunk-generic thémát, és azóta nem tudok belépni a router menujébe
Ezt adja ki a böngésző ha beírom a router ip címét belső hálón.
/usr/lib/lua/luci/template.lua:97: Failed to execute template 'admin_status/index'.
A runtime error occurred: /usr/lib/lua/luci/template.lua:97: Failed to execute template 'header'.
A runtime error occurred: /usr/lib/lua/luci/template.lua:97: Failed to execute template 'themes/freifunk-generic/header'.
A runtime error occurred: [string "/usr/lib/lua/luci/view/themes/freifunk-gene..."]:20: attempt to call field 'node_childs' (a nil value)
stack traceback:
[string "/usr/lib/lua/luci/view/themes/freifunk-gene..."]:20: in main chunk
stack traceback:
[C]: in function 'error'
/usr/lib/lua/luci/template.lua:97: in function 'render'
/usr/lib/lua/luci/dispatcher.lua:755: in function 'include'
[string "/usr/lib/lua/luci/view/header.htm"]:3: in main chunk
stack traceback:
[C]: in function 'error'
/usr/lib/lua/luci/template.lua:97: in function 'render'
/usr/lib/lua/luci/dispatcher.lua:755: in function 'include'
[string "/usr/lib/lua/luci/view/admin_status/index.h..."]:1: in main chunk
stack traceback:
[C]: in function 'error'
/usr/lib/lua/luci/template.lua:97: in function </usr/lib/lua/luci/template.lua:85>
(tail call): ?
/usr/lib/lua/luci/dispatcher.lua:1020: in function 'dispatch'
/usr/lib/lua/luci/dispatcher.lua:984: in function 'dispatch'
/usr/lib/lua/luci/dispatcher.lua:478: in function </usr/lib/lua/luci/dispatcher.lua:477>Mit lehet ilyenkor tenni?
[ Szerkesztve ]
"... Feltalálom a hidegfúziót oszt reszeltek az amcsiknak...":)))
-
petakpa1
őstag
válasz
vargalex
#70859
üzenetére
Szia Alex,
Csak most jutottam oda, hogy foglalkozzam ezzel a kérdéssel
Ez a firmware van jelenleg a v1-esemen:
OpenWrt 19.07.5 r11257-5090152ae3 / LuCI openwrt-19.07 branch git-20.341.57626-51f55b5A System / Software menüben rányomtam az az Update Lists gombra majd némi gondolkozás után kilistázta az upgradelhető installálható csomagokat.
Itt az Updates gomb alatt találtam 24 Upgradelhető csomagot, többek között egy
luci-theme-bootstrap nevűt, melyet git-20.341.57626-51f55b5-1 verzióról » git-21.044.30835-34e0d65-1 verzióra lehetne upgradelnem Szükséges ez? Egyáltaln mit jelenet az, hogy bizonyos csomagokat upgradelek? Érdemes ezzel foglalkozni?
Szintén ugyanitt Software menüben az Available gombra rányomva luci-theme-openwrt-re leszűrve installálható csomagként az alábbi jelent meg:
luci-theme-openwrtgit-21.044.30835-34e0d65-1Ezt telepítsem az új Luci skin-hez, vagy az általa fentebb linkelt 21.035.74863-4a00f5b verziót?
Köszi!
"... Feltalálom a hidegfúziót oszt reszeltek az amcsiknak...":)))
-
petakpa1
őstag
válasz
vargalex
#70857
üzenetére
És hogyan lehet ezt felvarazsloni legutolso v19-s stabil releasera?
Én a sysupgrade verziót töltöttem le, és beállítások megtartásával upgradeltem 18-srol, de még mindig a régi Luci felületen van.
[ Szerkesztve ]
"... Feltalálom a hidegfúziót oszt reszeltek az amcsiknak...":)))
-
petakpa1
őstag
válasz
iMaverick
#70852
üzenetére
Sajnos a gwlim felé fork nem megy már fel v1-re, illetve csak a minibuild megy fel, abban viszont nincs Luci egyáltalán.
Az új Luci tényleg pofás, vajon 19-es főverziora kijön meg, vagy csak 20-asra már. Sajnos v1-re már nem jön ki a 20-as főverzio. 19-es lesz az utolsó
.Esetleg új Luci verzió. Külön csomagból lehet szerintetek telepíteni majd v19 alá?
Te milyen hw-en használod a gwlim forkot?
"... Feltalálom a hidegfúziót oszt reszeltek az amcsiknak...":)))
-
petakpa1
őstag
Igen. Aktiválva is van
Viszont letöltési sebességen nálam ez nem segített, mert csak 120-as netem van, azt pedig flow offload nélkül is bírja a router.
Viszont bekapcsolt flow offload-dal alacsonyabb lett a CPU terheltség, így hagytam bekapcsolva.
Kollégának azért gwlim féle fw-t ajánlottam, mert azzal dokumentáltan mértek itt 600 Mbps körüli sávszélt WAN felől PPPoE kapcsolat esetén. Hogy hivatalos build is tudja-e ezt bekapcsolt flow offload esetén azt nem tudom sajnos tesztelni...
Mondjuk ha ő felteszi akkor igen. Kíváncsi vagyok visszatér-e még ide?
[ Szerkesztve ]
"... Feltalálom a hidegfúziót oszt reszeltek az amcsiknak...":)))
-
petakpa1
őstag
Bocs igazad van. Luci benne van a Mini Build-ben is, az alábbiak nincsenek benne:
- Cannot support package installation
- Have no USB SupportEbből az előbbi fájdalmas inkább, mert nekem a DDNS, WOL, uHTTPd csomagokra mindenképp szükségem van.
Ezért inkább a hivatalos build-et használom, 120-as netemhez bőven elég.
"... Feltalálom a hidegfúziót oszt reszeltek az amcsiknak...":)))
-
petakpa1
őstag
válasz
djdaniel
#70732
üzenetére
Probálkozz ezzel a fw-el. Ez kifejezetten sebességre van kigyúrva, igaz a legújabbak már nem mennek fel belőle v1-esre, de a régebbiek még igen, és 600 Mbit/sec es átviteli sebességet is elértek vele állítólag. Ebben a topicban is ha rákeresel "gwlim" szóra találsz mérési screenshotokat.
"... Feltalálom a hidegfúziót oszt reszeltek az amcsiknak...":)))
-
petakpa1
őstag
válasz
vargalex
#70725
üzenetére
Köszi Alex!
Végrehajtottam fenti lépéseket és ezt követően a LuCI-ban Network>Wireless menüben a saját wifi hálózatom beállításaiban a Wireless Security fülön megjelent a Enable WPS pushbutton, requires WPA(2)-PSK/WPA3-SAE gomb.
Ezt bepipáltam, save & reboot után már tudtam használni a router QSS gombját, és annak segítségével összepárosítottam a router wifit tudó klima beltérivel.
Biztonság kedvéért ezt követően ismét deaktiváltam a fenti gombot.
Szerencsére klíma ennek ellenére továbbra is kapcsolódik a wifi hálózatomhoz. Gondolom a WPS párosításkor elmentette magának a wifi hálózatom jelszavát.Szóval minden flottul ment és működik
.Kérdésem még, hogy szükséges-e eltávolítamon a wpad és hostapd-utils csomagokat és visszatenni a wpad-basic-et?
Továbbá a wireless overview menüben feltűnt, hogy van egy deaktivált wifi hálózatom.
Jelent ez problémát, hogy itt van? Érdemes törölni?
[ Szerkesztve ]
"... Feltalálom a hidegfúziót oszt reszeltek az amcsiknak...":)))
-
petakpa1
őstag
válasz
vargalex
#70723
üzenetére
Köszi Alex.
Akkor az alábbiakat kell csinálnom ebben a sorrendben
leszedem a wpad-basic-ot
reboot
felteszem a wpad-ot és a hostapd-utils-t
rebootÉs ezt követően LuCI-ban megjelenik a WPS opció, és ott már el tudom indítani a WPS csatlakozási folyamatot.
Ahhoz gondolom további konfigolás kellene, hogy a routeren lévő QSS gom nyomására induljon a WPS csatlakozási folyamat. (Ez nem is feltétlenül kell nekem, elég ha LuCI-ból tudom indítani).Teljes Wireless részt vajon újra kell majd konfigolnom, vagy megmarad a beállított wifi hálózat?
[ Szerkesztve ]
"... Feltalálom a hidegfúziót oszt reszeltek az amcsiknak...":)))
-
petakpa1
őstag
1043nd v1-es routeremen kellene WPS funkciót beállítani. 19.07.2-es Openwrt van rajta jelenleg.
Neten azt olvastam, hogy alapból nincs WPS az openwrt fw-ben.
wpad és hostapd-utils. csomagokat kellene telepíteni, de sajnos már a wpad sem megy fel. Azt írja, hogy wpad-basic már rajta van. Mi a teendő ilyenkor? wpad-basic biztos nem elegendő wps-hez?
Továbbá Luci-s felület is kellene nekem wps-hez
"... Feltalálom a hidegfúziót oszt reszeltek az amcsiknak...":)))
-
petakpa1
őstag
válasz
Doky586
#70548
üzenetére
Ez világos. WOL pont akkor kellene, ha nem menne 24/7-ben de azért, hogy bármikor fel tudjak rá tölteni fel kellenet tudni éleszteni.
A lényeg az lenne, hogy nem megy nonstop, de ha szükség van rá mégis elindítható. Sajnos WOL hiányában ez nem megoldható.
#Borisz
Nem kell NAS, mert az +1 áramfogyasztó lenne, és annyira nem használom ki, nem streamalek róla. Amire kell arra egy egyszerű ftp simán jó. Médialejátszásra használt MiniPC simán elbírja még ezt a server funkciót is pluszban.Ha a router is elbírná az még jobb lenne, mert akkor a MiniPC elmehetne standby-ba automatikusan, de eléggé elkanyarodtunk az eredeti témától.
Egyenlőre akkor marad a MiniPC-n az ftp server, 1043ND v1.8 pedig továbbra is kiszolgálja a netmegosztási igényeket: 120-as net 2 okosteló, 1 webkamera, 1 okostermosztát, 1 android tv, alkamanként 2 laptop wifin illetve a 1 Mini és 1 asztali PC vezetéken + alkalmanként a retró PC-om is vezetéken.
[ Szerkesztve ]
"... Feltalálom a hidegfúziót oszt reszeltek az amcsiknak...":)))
-
petakpa1
őstag
válasz
xabolcs
#70546
üzenetére
24/7 csak a kényelem miatt van, bármit, bárhonnan fel tudjak saját tárhelyre tölteni. Nem bízom a különféle cloud szolgáltatásokban
Az a baj, hogy a MiniPC-n nem sikerült beüzemelni a WOL-t. A MiniPC valójában egy Nexbox T11 csak más címkével. Ebben a vezetékes hálózati kártya az USB buszon egy USB2FE adapterrel van megoldva és akárhogy próbáltam nem megy a WOL.
Értem, ez is egy szempont. Köszönöm, akkor egyenlőre nem terhelem ftp-vel a router-t
"... Feltalálom a hidegfúziót oszt reszeltek az amcsiknak...":)))
-
petakpa1
őstag
Köszi. Azt mondod ne erőltessem az ftp szerver funkciót ezen az routeren?
Amikor a gyári firmware-tól átváltottam Lede-re és ezzel együtt elvesztettem az ftp funkciót akkor egy Intel Atom x5-Z8300 alapú Win10-et futtató mini pc-n bekonfiguráltam egy ftp szervert. Azóta is így működik.
Ezt a MiniPC-t médialejátszónak használtam ezt megelőzően, ami ugye ha nem volt használva elment standby-ba. Miután az ftp szerver átkerült ár értelemszerűen 24h-ban megy, ami 1-2 w-al több fogyasztást jelent.Két szempont miatt mérlegelem, hogy visszamenjen a routerre az ftp:
- energiatakatékosság
- MiniPC élettartama. (Olcsó kínai gyártmány, nem tudom, hogy jót tesz-e neki a 7x24h üzem. Igaz ha nincs terhelés alatt akkor visszaveszi órajelét 480 Mhz-re, de mégiscsak folyamatosan jár.)Mit gondoltok?
"... Feltalálom a hidegfúziót oszt reszeltek az amcsiknak...":)))
-
petakpa1
őstag
Csak jelenteném, hogy a kb. 2-3 hete beüzemelt 19.07.2 verziószámú kiválóan működik v1.8-as routeremen
A software flow offload funkció is nagyon jól szuperál, nagyon sokat levett a rendszer terheléséből, összességében nagyon elégedett vagyok ezzel a FW verzióval. Ilyen régi hardware-ből ilyen kiváló teljesítményt kihozni. Tényleg le vagyok nyűgözve.
Wifis webcamera sem veszti el a kapcsolatot routerrel szemben 18.06.04-el, ami alatt ez számtalanszor megtörtént.
Lehet megpróbálnám beüzemelni a ftp szolgáltatást is, amit anno gyári fw-el használtam, de aztán amikor gwlim féle fastpath lede verzióra tértem át nem lehetett többé, mert nem fért bele a flash rom-be.
Ezzel kapcsolatban lenne most jópár kérdésem:
1) Milyen csomagokat kellene telepítenem az alábbi szolgáltatásokhoz:
- USB kezelés
- USB kezelés Luci felület
- legalapabb ftp server funkció (jogosultságkezeléssel)
- ftp server funkció Luci app
- bármi más ami kell még ftp serverhez? Pl fálrendszer támogatás
2) Mennyit foglalnának el ezek a csomagok összesen? Jelenleg a System/Software menüpontban 3,6 MB szabad helyet ír ki.[ Szerkesztve ]
"... Feltalálom a hidegfúziót oszt reszeltek az amcsiknak...":)))
-
petakpa1
őstag
válasz
Doky586
#70488
üzenetére
Alapból nincs, de elméletileg lehet telepíteni:
The 19.07 release brings initial support for WPA3. However, WPA3 is not enabled by default and requires installing specific packages: to run WPA3 as an access point,
hostapd-opensslis needed. For use as a Wi-Fi station, you need eitherwpa-supplicant-openssl(station support only) orwpad-openssl(AP + station). Due to their large size, these packages are not installed by default, and it is impossible to install them on devices with less than 8MB flash.
It should also be noted that many existing client devices will never support WPA3, and that there are client devices that support WPA2 but cannot connect to an AP configured with WPA2+WPA3 mixed mode. Please only file bugs if you are sure the problem is not client related.
To configure your device as a WPA3 access point, see wpa_modes"... Feltalálom a hidegfúziót oszt reszeltek az amcsiknak...":)))
-
petakpa1
őstag
válasz
Doky586
#70486
üzenetére
v1-esre
ddwrt-m sosem volt, így nem tudok véleményt formálni, de nagyon elégedett vagyok a 19.07.2-vel. Leszámítva azt problémamat mit már 17-es Lede-n és 18.06.04-es OpenWrt-n is fennált és nem sikerült megoldani: 100 MBites linksebességgel csatlakozó eszközökön max 40-45 MBites letöltési sebességet mérek WAN-ról
"... Feltalálom a hidegfúziót oszt reszeltek az amcsiknak...":)))
-
petakpa1
őstag
Megvan, telepítást követően már ez is működik. Nagyon köszönöm!
Ez az egész Openwrt nagyon tetszik. A legjobb példája annak, hogy kellően optimalizált szoftverrel miket lehet kihozni régi vasakból is.
Egy Intel 7260HMW típusú wifi adatpterrel 300 Mbps linksebesség mellett 1 téglafalon keresztül ki tudom mérni a ISP-m által biztosított 120 Mbps sávszélességet, szóval a wifi rész is szuperül működik
"... Feltalálom a hidegfúziót oszt reszeltek az amcsiknak...":)))
-
petakpa1
őstag
Jelentem megtörtént az upgrade 19.07.2-re
Végül nem a beállítások megtartásával upgradeltem, hanem készítettem egy backup-ot, és azt töltöttem vissza miután a 19.07.2 felkúszott.
Először megijjedtem mert a menüben DynDNS szolgáltatásra kattintva hibát dobott a Lcui, de később valahogy megoldódott magától ez a probléma. Lehet volt közben egy reboot.
Wifi visszakapcsolására is elég nehéz volt rájönni, hogyan de végül megoldottam.
Amivel viszont nem boldogulok: 18.06.04-ben a Services menü alatt jelent meg az uhttpd szolgáltatás konfig felülete, 19.07.2-ben viszont se itt, se máshol nem találom
. Ebben tudnátok segíteni?
18.06.04-ben. magát az uhttpd szolgáltatást is manuálisan utólag kellett telepíteni, mert alapból nem volt benne a FW-ben.
19.07.2-ben viszont mikor telepíteni próbáltam már azt jelezte, hogy fenn van. Ennek ellenére a konfig felületét sehol nem találom. Mit kellene még telepítenem?Aminek viszont nagyon örülök az Software flow offloading funkció.
Ha ez nincs bekapcsolva és putty-on top parancs segítségével figyelem a SIRQ értéket (jól értem, hogy ez a CPU terheltség mértéke?) miközben egy 2 GB-os file töltök le asztali gépemmel, akkor olyan 75-85% értéket látok.
Ha viszont be van kapcsolva a flow offload akkor nem megy 50% felé a SIRQ
Jól gondolom, hogy az alacsonyabb CPU kihasználtság miatt némileg az áramfogyasztás és melegedés is kisebb lesz? Később hal meg a router?Csak 120-as netem van, amit flow offload nélkül is kihajtott a router így azt sajnos nem tudom tesztelni, hogy mi a max sebesség amit tudna.
[ Szerkesztve ]
"... Feltalálom a hidegfúziót oszt reszeltek az amcsiknak...":)))
-
petakpa1
őstag
Neked v1-sen van ez fenn?
Simán ment a főverzió váltás? Hanyasról váltottál 19.07-re?19.07 verzió release notes-ben olvastam, hogy Lucin is történt fejlesztés, hogy kevésbé terhelje a router CPU-ját, viszont ezzel az újítással még nem minden Luci app kompatibilis. Ebből érzékeltél Te valamit?
Ha jól emlékszem csak 3 extra szolgáltatást telepítettem a 18.06-ban lévőkhöz képest:
- DynDNS
- Wake on LAN
- uHTTPdEzek Lucis konfig felületével lesz vajon probléma?
"... Feltalálom a hidegfúziót oszt reszeltek az amcsiknak...":)))
-
petakpa1
őstag
Köszi!
Most jelenleg ezen a verzión vagyok:
Firmware Version: OpenWrt 18.06.4 r7808-ef686b7292 / LuCI openwrt-18.06 branch (git-19.170.32094-4d6d8bc)
Kernel Version: 4.9.184Ha jól látom a legfrissebb letölthető hivatalos a 19.07.2 erre az eszközre.
Beállításokat megtartó upgrade mehet szerinted? Jópár ip fixálás, port forward szabály be van állítva, nem szívesen konfigolnék mindent újra.
Gwlim féle verzióból továbbra is csak minibuild van v1-re, de ezekben régebben nem volt Luci, a nélkül viszont én nem tudom bekonfigolni.
Sajnos az aktuális readme-ből nem derül ki, hogy minibuildekben van-e vagy sem Luci? Erről tudsz valamit esetleg?Mivel a mostani netkapcsolatomhoz nincs szükség a gwlim féle sebességre optimalizált verzóra valószínőleg maradok a főverziónál. Már csak szabadidő kellene update-re
"... Feltalálom a hidegfúziót oszt reszeltek az amcsiknak...":)))
-
petakpa1
őstag
És V1-re mit javasolsz? Arra is a legfrissebb openwrt menjen, vagy inkább a gwlim féle verzió? Utóbbival az a baj, hogy már nem fér bele a Luci formware-be
KI kellene szedni belőle pár funkciót, ami nekem nem kell pár ipv6 támogatás, de ehhez sajna már nem értek "... Feltalálom a hidegfúziót oszt reszeltek az amcsiknak...":)))
. 
Ez így rendben van? Switch menüpontban VLAN funkcionalitás engedélyezve van még jelenleg, annak letiltását még nem próbáltam.
. Linuxban egyáltalán nem vagyok otthon. Végzettségem is közgazdász, nem ITs 
Új hozzászólás Aktív témák
- Apple Watch Series 7 Midnight Aluminium Case
- Xerox 106R04349 Dualpack fekete
- LG 27GR95QL - 27" OLED / Limitált LoL Edition / QHD 2K / 240Hz & 0.03ms / NVIDIA G-Sync / FreeSync
- Gamer Pc eladó! 32GB RAM/Ryzen 5 5600/ 1TB SSD/ 5700XT/ RGB-s ház
- Panorámás Gamer PC! i7-8700/GTX 1070 Ti 8GB/16GB RAM/512GB+128GB SSD
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: Axon Labs Kft.
Város: Budapest