- HiFi műszaki szemmel - sztereó hangrendszerek
- Az Apple megszerezné a klubvilágbajnokság közvetítési jogait
- Azonnali VGA-s kérdések órája
- SSD kibeszélő
- NVIDIA GeForce RTX 4080 /4080S / 4090 (AD103 / 102)
- AMD Ryzen 9 / 7 / 5 / 3 5***(X) "Zen 3" (AM4)
- Modern monitorokra köthető 3dfx Voodoo kártya a fészerből
- NVIDIA GeForce RTX 3060 Ti / 3070 / 3070 Ti (GA104)
- Amlogic S905, S912 processzoros készülékek
- Sony MILC fényképezőgépcsalád
Hirdetés
-
AMD Radeon undervolt/overclock
lo Minden egy hideg, téli estén kezdődött, mikor rájöttem, hogy már kicsit kevés az RTX2060...
-
Free Play Days 2024 - 18. hét: Headbangers: Rythm Royale
gp Extraként a Star Wars Jedi: Survort is kipróbálhatjuk 5 óra erejéig.
-
Megbírságolták a Razert a Zephyr maszkok miatt
ph A cég elég olcsón megússza az ügyfelei félrevezetését, de az üdvözlendő, hogy az Egyesült Államok hatóságai nem siklottak el az ügy felett.
-
PROHARDVER!
TP-Link WR1043ND - N450 router
Új hozzászólás Aktív témák
-
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 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 #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.
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...":)))
-
xabolcs
őstag
válasz petakpa1 #71253 üzenetére
Szia!
Ezt legszivesebben tavsegitseggel segitenem megcsinalni, mert latod leirni eleg sokaig tart!
Egyebkent teljesen jo es mukodokepes megoldas, a miniPC-s port forwardtol sem kell feljel, az is mukodni fog!
aláírás1: csocsó-vesztes vagyok, főleg a Bog és Bocha páros ellen, aláírás2: van mobilarénáskulcstartóm! :D
-
gduck
addikt
válasz petakpa1 #71253 üzenetére
Hát ez kicsit hosszúra sikeredett, de igazából én semmi bonyolultságot nem látok benne
0) HGW-n letiltod a DHCP szervert és beállítod a FIX IP-t és a Wifi-t. Openwrt alatt letiltod a Wifi-t.
1) Interfaces/LAN
General settings fül
IPv4 address: 192.168.0.2
IPv4 netmask: 255.255.255.0
IPv4 gateway: 192.168.0.1
Advanced setings fül:
Use custom DNS servers: DNS szerverek megadása, midegyik után + zöld gombot ne felejtsed el megnyomni2) Interfaces/LAN/DHCP server fül
General settings fül
Start: 101
Limit: 150
Advanced setings fül:
DHCP-options:
3,192.168.0.1 (majd zöld + gomb megnyomása!)
6,8.8.8.4,8.8.8.8 (amint látod, a '6,' után kell felsorolni a DNS szervereket! Cseréld ki arra, amit szeretnél. Többet is meg lehet adni! Majd itt is a zöld + gomb megnyomása!)3) Igazából "semmit". A WAN port helyett a LAN porba dugod a kábelt.
A WAN és a WAN6 portok indítását le is tilthatod:
Interfaces/LAN/General settings fülön 'Bring on boot' pipa kiszedése.5) A 4)-es pontban említetted, hogy majd be akarod kapcsolni a Wifi-t. Ha átállítod LAN portra a WAN portot, a "WAN-LAN" kapcsolat a procit fogja terhelni és Wifi-vel együtt használva mindkettő lassabb lesz!
6) Ők a hálózaton lévő DHCP szervert keresik, ennyire egyszerű
9) Igen, érteni fogja!
10) Igen, érteni fogja, véletlenül se bonyolítsad!
-
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 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
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...":)))
-
xabolcs
őstag
válasz petakpa1 #71260 üzenetére
A MESH az akkor hasznos, amikor nem tudod osszekotni vezetekkel az eszkozeidet, ezert az "uplink-et" is radion keresztul kell megoldani.
Nalad vezetekezve van a ket eszkoz, igy csak annyi a dolgod, hogy ugyanazzal a titkositassal, SSID-val (a csatorna viszont legyen minel messzebb) bekapcsolod a wifit a TP-Link-en.
aláírás1: csocsó-vesztes vagyok, főleg a Bog és Bocha páros ellen, aláírás2: van mobilarénáskulcstartóm! :D
-
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...":)))
-
xabolcs
őstag
válasz petakpa1 #71263 üzenetére
A megfelelo kliens roaminghoz leginkabb megfelelo kliens kell!
Segitheted a klienseidet ha bekapcsolsz mindenfele roamingolast segito szolgaltatast az AP-idon, de a MESH nem az.
OpenWrt vilagaban a MESH csak egy "atviteli kozeg", pont mint az UTP kabel. Mellette kell inditanod egy masik wifit, AP-kent, amire tudnak kapcsolodni a kliens eszkozok.Olyat erdemes megprobalni bekapcsolni, amit mindegyik AP tamogat! Pl. ha az TP-Link tudja a 802.11r-et, de a HGW nem, akkor szerintem nem vagy elorebb!
aláírás1: csocsó-vesztes vagyok, főleg a Bog és Bocha páros ellen, aláírás2: van mobilarénáskulcstartóm! :D
-
zsero
aktív tag
Sziasztok, egy ismerősömnek ledobja a ThinkPad X240-es laptopját a router, gyári FW-n. Valamelyik másik FW szerintetek segíthet? Ha igen, melyiket ajánljátok? Nem kell tudjon semmit, sima NAT. v4 vagy v5.
[ Szerkesztve ]
-
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...":)))
-
#46824192
törölt tag
Először próba...
Routerban wifi csatorna csere , laposon driver csere/update. Csatorna választást érdemes lenne oda tenni ,ahol nincs másik wifi vagy nagyon gyenge. Ez egy okostelefonos bármelyik wifi scan progi is megmutatja. Illetve sok eszköz nem szereti a magas csatornaszámokat (magasabb frekvenciát)De nálam pl. már volt olyan laptop ,hogy bármilyen eszközt eldobált ha wpa2 -n ment a wifi titkosítás.
A samsung a53 telefonom pedig a 1043nd v2(gyári fw) wifit dobja el néha.
Ezt még nem tudtam megfejteni mi okozza.[ Szerkesztve ]
-
-
#46824192
törölt tag
Sajnos ezt nem tudom megmondani.
Elég régen volt már hogy napi szinten használtam.
+a HW nat hiánya miatt el is engedtem a dolgot.Ma már csak wifi nélküli switch funkciót lát el.
Még ami eszembe jutott , hogy egy táp hiba is tud érdekes dolgokat produkálni.
Esetleg az is hogy haldoklik az elektronika a routerban.
(kiszáradt kondi ,stb...)Laptopon minden driver legutolsó, Intel, volt egy frissítés, nem változtatott semmit.
Az azért nem olyan biztos. Attól hogy kintről minden ugyanaz, magába a driverbe azért rendesen bele tudnak nyúlni. Egyáltalán nem biztos , hogy a legutolsó a legjobb/legstabilabb.Sajnos a wifi hiba tud egyszerű és tud nagyon szívatós is lenni.
-
zsero
aktív tag
Itt lent azt olvasom az OpenWRT v19 a legstabilabb. Megpróbálom azt. Aztán ha az sem jó akkor vagy másik router vagy marad da vezetékes hálózat, nincs más ötletem.
-
iMaverick
addikt
válasz #46824192 #71270 üzenetére
Még ami eszembe jutott , hogy egy táp hiba is tud érdekes dolgokat produkálni.
Esetleg az is hogy haldoklik az elektronika a routerban.
(kiszáradt kondi ,stb...)Ezt korábban más is írta, érdemes lehet ránézni.
"Sokkal könnyebb gazdagon boldognak lenni, mint szegényen" (Moldován András)
-
jozsef111
csendes tag
Sziasztok.
Szeretném elmondani mit csinálok.1. Fő router asus rt-n18u portforward kinyitva a torrent klienseim felé.
2. tp-link_wr1043nd openwrt-fe okosítás-t átléptem a transmission felment,port forwardot a 2. router-nek ki lett nyitva,plusz az 1. router transmission portja is kinyilt.
Okosítás: https://logout.hu/cikk/tp-link_tl-wr1043nd_okositas/bevezetes_specifikacio.html?stext=TP-Link%20TL-WR1043ND
De a gépen futó kliensek passzív módot kaptak.
Most ismerkedek a fórummal.
További szép napot.
Hogyan lehet a gépen lévő torrent kliensek aktív módot kapni?[ Szerkesztve ]
-
jozsef111
csendes tag
válasz woodworm #71277 üzenetére
Nos a laptomon futnak a transmission és qbittorrent.
1. router rt-n18u kapcsolódik a laptophoz.
2. TP-Link WR1043ND kapcsolódik asus routerhez dhpc módon.
1. router ppoe módon kapcsolódik a digi optikai routerhez egy kábelen.
elraktam a TP-Link WR1043ND routert majd később előveszem, kell seedelnem, így napi 2-3 órát szánok rá,amolyan hobbi szinten.[ Szerkesztve ]
-
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.
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
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...":)))
-
vargalex
Topikgazda
válasz petakpa1 #71281 üzenetére
(a) a HGW-n kiesik az ARP táblából a géped, így nem tudja, hogy mely MAC címre kellene továbbítani a csomagot (mivel nincs IP cím társítva hozzá).
(b) ha valóban switch módban van config-olva, akkor ennek nem kellene működnie.
Biztos, hogy LAN-LAN összekötésben van a két eszköz?Alex
-
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...":)))
-
Satrafuckar
tag
sziasztok,
TpLink1043v3
suste/headless@OpenWrt@0.8.1 Barrier Breaker 14.07röviden: lehet ebben a régi fw-ben a dropbear package-et frissiteni valahogy 2018 v utáni verzióra?
vagy van ujabb suste/headless/vargalex/egyéb custom build amiben alapbol benne van ez a sok hasznos dolog ami a fentiben?hosszan:
usb hdd elérése netről a cél, sftp sshfs winfsp
ez az eddigi legjobb leirás, most végre működik, de csak régi verziós sshfs-win-nel (2 napja projektelem mire erre rájöttem...)friss verzios sshfs-win -nel az openwrt rendszer log-ban:
dropbear[...]: Exit before auth: No matching algo kex
vsz mert tul régi a dropbear, ez alapján
próbáltam a package listák átírásával frissiteni, pl innen (de sok más verziot is probáltam) de nem sikerült,... has no valid architecture, ignoring.
mindig. Ahogy nézem ar71xx - ath79 - mips_24kc amik elvileg jók nekem, de nem teljesen vagyok tisztában az architekturákkal, utasításkészletekkel.egyebek:
ddns megy
samba win7-el megy, win10 még nem látja
minidlna csak kb 10763 file-t indexel a több100k-ból, de azt legalább minden restartnál előről
szóval van még projekt, de egyelőre a fenti amiben nem jutok önerőből tovább.köszi!
-
#46824192
törölt tag
válasz Satrafuckar #71284 üzenetére
A csomagok verzióira már nem emlékszem, de arra igen hogy a minidlna engem szét sz.patott.
Egyszerűen elfelejtett tartalmakat látni. Asszem addig jutottam ,hogy a mappán ahová az adatbázist írja,teljsesen random mindig megkotlott a jogosultság. Így nem tudott bele írni.
Win10 alatt pedig default tiltva van az smbv1 ,ezt külön engedélyezni kell, azután látni fogja.
-
vargalex
Topikgazda
válasz Satrafuckar #71284 üzenetére
Nem ismerem a winfsp-t, de nem ad lehetőséget legacy key exchange algorithm-ok engedélyezésére? Ez ugye a legújabb openssh esetén egyetlen kapcsoló.... Általában attól, hogy valami alapból nem tiltott, kézzel még engedélyezhető szokott lenni egy rendes software esetén...
Alex
-
Satrafuckar
tag
válasz vargalex #71286 üzenetére
köszi vaggalex!
rákeresgéltem, vsz inkább az sshfs-win -ben kéne ezt beállitani valahogy. szenvedtem is vele pár órát, de annyira nem lényeg. a dropbear frissitése lett vna a szimpibb/elöreláthatolag fenntarthatobb irány, ha az nem lehetséges akkor jo igy.samba: igen köszi boxoslaca közben megtaláltam én is ezt, viszont azt is hogy smbv1 hiányában csak a tallózás nem megy, a bepötyögős/networkdrive verzió viszont igen, igy tképp ez is jó igy.
na már csak a dlna van akkor
-
vargalex
Topikgazda
válasz petakpa1 #71288 üzenetére
Szia!
Rögzítsd fixen a MAC címet az ARP táblába.
De nekem továbbra is fura az a port forward. LAN-LAN nincs tűzfal, így nem értem, hogy mit továbbítana...
[ Szerkesztve ]
Alex
-
vargalex
Topikgazda
válasz Satrafuckar #71287 üzenetére
A minidlna adatbázisának helyét állítsd át egy a HDD-n lévő könyvtárra, mert alapban a /var-on van, ami RAMDRIVE, azaz újraindulás esetén megy a kukába. Illetve az indexelés is azért állhat le, mert elfogy a hely a /var-on.
[ Szerkesztve ]
Alex
-
xabolcs
őstag
válasz vargalex #71289 üzenetére
Erre (az ARP tablas rogzitesre) vartam!
Koszonom!A fo router is fel fogja tudni ebreszteni, ha csak az OpenWrt-s eszkozben van rogzitve? Van olyan okos, hogy megkerdezze tole?
aláírás1: csocsó-vesztes vagyok, főleg a Bog és Bocha páros ellen, aláírás2: van mobilarénáskulcstartóm! :D
-
Satrafuckar
tag
válasz vargalex #71290 üzenetére
ja bocs, elfelejtettem irni, azt már alapból átállítottam a hdd-re, ahogy a logot is. igy is 10763 képnél megállt mindig, és rebootkor elölröl kezdte az egészet, majd ugyanott megállt.
most beállítottam h csak fotókat keressen (főleg az van a hdd-n), így tovább jut, de marha lassu és nagyon dögledezik közben az egész rendszer (Átlagos terhelés4.81, 2.52, 2.48, hálózati megosztás ill luci hosszu 10mp-ekig fagy / nem reagál).
30k-nál tart kb 5h után (ez normális?), és több100k kép van a vinyón.
nem merem ujrainditani h kiderüljön h megmarad e a dbnormál müködés szerint megmarad rebootkor a db, és csak updatelgeti, vagy az a normál ha indulásnál nullárol ujraépiti? (uj nekem a minidlna).
update: áh és ennyi, ebben a pillanatban az egész meghalt lefagyott ujraindult, ezzel együtt az indexelés is ismét nulláról....
[ Szerkesztve ]
-
#46824192
törölt tag
válasz Satrafuckar #71294 üzenetére
Lehet nagyfalat már ez ennek a vasnak
-
Satrafuckar
tag
hmm most éjjel végigszkennelte, reggel megjelent a logban
[2022/11/14 06:38:44] scanner.c:793: warn: Scanning /share/Kulso finished (141492 files)!
ráadásul alig 6 óra után. v.ö. előtte 5h alatt 30k file.
viszont a memória teljesen el volt fogyva, a gyakorlatban használhatatlan volt luci, samba, dlna, minden.
így aztán ujraindítottam / közbe lefagyott ujraindult magától.
és most megint elölről kezdi a scannelést, pedig már fel volt épitve a db, 260 mb (ezt ki is mentettem ujrainditás előtt, meg a logot is. még 1 érdekesség, a logban mintha nem stimmelnének a timestamp-ek / a sorok sorrendje, log ld itt)konkrét kérdések:
-alapvető működésben normális-e, hogy minden indulásnál nullárol ujraépiti az adatbázist?
-hogy lehet rávenni, hogy ezt ne tegye
-hogy tudom a meglévő adatbázisomat betolni neki h tessék ezt használdbonusz kérdések:
-mi a logban a timestamp káosz
-miért irja suste itt hogy "Amilyen gyorsan csak lehet kilépünk a Luciból!!!" -
Satrafuckar
tag
válasz #46824192 #71295 üzenetére
lehetséges, igen, bár most pont sikerült 1x végigérnie..
itt irnak egy ilyet "Tips
If you have a decent size music library, you will more than likely find building the minidlna database on your OpenWrt device extremely slow or impossible due to RAM constraints. The solution is to build the minidlna database on a Linux PC."
szoval valami ilyesmi kéne, 1x megépiteni az adatbázist, akár külső gépen, majd rávenni, hogy ezt használja. Ezutóbbi a ködösebb számomra. -
vargalex
Topikgazda
válasz Satrafuckar #71296 üzenetére
Szia!
Egyáltalán nem normális, hogy újrainduláskor nulláról építi fel az adatbázist. Biztos, hogy nem hibás? Esetleg maga a HDD? De ekkora mennyiség tényleg nem egy 32 MB-os routernek való...
A PC-s adatbázis felépítésnél arra kell figyelni, hogy pont ugyan oda legyen csatolva, különben mit sem ér az egész...[ Szerkesztve ]
Alex
-
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...":)))
-
vargalex
Topikgazda
válasz petakpa1 #71299 üzenetére
Igen, azóta már sok dolog változott, többek között a régi
ifconfig
-rólip
parancsra váltottak, viszont a busybox-ban megvalósított minimális funkcionalitással. Így, ahogy a kolléga is írja, tedd fel azip-tiny
-t, ha azzal sem megy, akkorip-full
. A kettő együtt úgysem lehet fenn.
A static lease rögzítése soha nem volt összefüggésben az ARP táblába történő rögzítéssel...Alex
-
Satrafuckar
tag
válasz vargalex #71298 üzenetére
szia,
először is köszi a segítséget
ha ujra lehetne inditani ugy hogy megmarad a db, akkor szerintem tudná kezelni a helyzetet.
tegnap megint sikeresen végigszkennelte, a db file mérete pont ugyanannyi mint a korábbi sikeres scan után, logban
[2022/11/14 21:46:29] scanner.c:793: warn: Scanning /share/Kulso finished (141492 files)!hogyan lehetne nyomozni-debuggolni, hogy hol a hiba?
probáltam bövebb logolást beállítani az alapján, de vagy nem müködik a beállítás, vagy igy is elég szükszavu
config minidlna 'config'
option port '8200'
option interface 'br-lan'
option friendly_name 'Router'
option inotify '1'
option notify_interval '900'
option serial '12345678'
option model_number '1'
option album_art_names 'Cover.jpg/cover.jpg/Album.jpg/album.jpg/Folder.jpg/folder.jpg'
option db_dir '/share/Kulso/minidlna'
option log_dir '/share/Kulso/minidlna'
option log_level 'general,artwork,database,inotify,scanner,metadata,http,ssdp,tivo=debug'
option root_container 'B'
option enabled '1'
list media_dir 'P,/share/Kulso'
gondoltam hátha ez a probléma, de a minidlna -t ujrainditva (rendszer/rendszerinditás) is ujra kezdi a db épitést, DE MIÉRT ??
[2022/11/14 21:46:29] scanner.c:793: warn: Scanning /share/Kulso finished (141492 files)!
[2022/11/15 20:07:41] minidlna.c:154: warn: received signal 15, good-bye
[2022/11/15 20:07:53] minidlna.c:1014: warn: Starting MiniDLNA version 1.1.3.
[2022/11/15 20:07:53] minidlna.c:355: warn: Creating new database at /share/Kulso/minidlna/files.db
[2022/11/15 20:07:55] minidlna.c:1053: warn: HTTP listening on port 8200
[2022/11/15 20:07:55] scanner.c:706: warn: Scanning /share/Kulso[ Szerkesztve ]
-
Satrafuckar
tag
válasz Satrafuckar #71302 üzenetére
nos. (hátha valakinek hasznos lesz)
sikerült a bövebb logolást beállítani, de ehhez át kellett irni az inditoszkriptet (/etc/init.d/minidlna,minidlna_cfg_addstr $cfg log_level
a minidlna_create_config() fv-be), ami valamiért nem vette figyelembe ezt az opciot amikor megcsinálja a /tmp/minidlna.conf file-t az /etc/cofig/minidlna file-bol.
a részletes logokat a megfelelö verzioju forráskóddal összevetve a scanner.c 850.sor start_scanner fv -ben a ScanDirectory fv még végigfut, viszont a start_scanner maradéka ugy tünik valamiért nem. talán ez akasztja kisql_exec(db, "create INDEX IDX_SEARCH_OPT ON OBJECTS(OBJECT_ID, CLASS, DETAIL_ID);");
a main/check_db viszont továbbfut, start_inotify .. generálja az "add watch" logokat.
a routeren megépített "majdnemkész" adatbázis file-t pc-re másolva, azon a hiányzo 2 müveletet elvégezvesql_exec(db, "create INDEX IDX_SEARCH_OPT ON OBJECTS(OBJECT_ID, CLASS, DETAIL_ID);");
...
sql_exec(db, "pragma user_version = %d;", DB_VERSION); // DB_VERSION==9
sikerült elérni, hogy ujrainditásnál nem törli és épiti ujra a db-t. hurrá! hittem ezt 1 percig.. -->VISZONT
a helyzet kb rosszabb mint előtte, mert igy most viszont akárhány reboot után is rögtön valami használhatatlanná lassitja a rendszert, luci belépés esélytelen, putty/ssh is rettentő döcögősen épph müködik. probálom kideriteni mi.. -
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...":)))
-
vargalex
Topikgazda
-
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 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 #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 #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
-
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...":)))
-
vargalex
Topikgazda
válasz petakpa1 #71312 üzenetére
Szia!
Ahogy a #71310-et olvastam, akkor jutott eszembe, hogy valószínűleg változott a rendszer és DHCP címkiosztás esetén felülírja a permanensen rögzített IP címet. Erre egy megoldás lehet az általad is írt fix IP a kliensen (hiszen ekkor ugye a dnsmasq nem nyúl az ARP táblához. De rugalmasabb, ha kihasználod azt, hogy a dnsmasq-nak adhatsz egy custom scriptet (dhcpscript opció, LuCI-ra sajnos úgy látom, hogy nincs kivezetve), ami megkapja paraméterként a művelete (add, old, del), a MAC címet, az IP címet és a hostname-ot, ha küldi a kliens. Így egy saját scriptben simán felépíthető a parancs:
#!/bin/sh
$MACADDR="aa:bb:cc:dd:ee:ff"
if [ "$2" == "$MACADDR" ]; then
ip neigh replace $3 lladdr $2 nud permanent dev br-lan
fi
A MAC cím vizsgálatot akár ki is hagyhatod, úgy minden géped permanensen benne lesz az ARP listában.
Alex
-
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...":)))
-
vargalex
Topikgazda
válasz petakpa1 #71314 üzenetére
Szia!
Maga a dnsmasq képes egy scriptet futtatni, amikor IP címet oszt (vagy megújít, esetleg release-eli) ki egy kliens számára. A linkelt dnsmasq manual-ban keress rá a --dhcp-script szövegre, ott a második találat lesz. Ezt a scriptet maga a dnsmasq úgy hívja meg, hogy paraméterként átadja neki sorban a típust (add/old/del) MAC címet, az IP címet, és a host nevet. Egy shell scriptben ezek rendre a $1, $2, $3, $4 változókkal hivatkozhatóak.
A#/bin/sh
egyszerűen a parancsértelmezőt jelöli, azt mondja meg, hogy az fogja futtatni a scriptet (esetünkben egyébként ez egy symlink azbusybox
-ra).
A lényeg, hogy létrehozol valahova egy scriptet (pl. a/root
-ba). Legyen mondjuk ez a/root/make_ip_permanent.sh
.Mivel a LuCI-ban nem lehet megadni, így vagy kézzel szerkeszted a
/etc/config/dhcp
file-t és a dnsmasq szekcióba felveszed a többi közé azoption dhcpscript '/root/make_ip_permanent.sh
sort, majd újraindítod a dnsmasq-ot:
/etc/init.d/dnsmasq restart
Vagy uci-val adod hozzá:
uci set dhcp.@dnsmasq[0].dhcpscript='/root/make_ip_permanent.sh'
majd szintént újraindítod a dnsmasq-ot.
A fenti scriptet nagyjából jól érted. Ugye az első sor a parancsértelmező, ezt írtam. A második sorban definiáljuk a számunkra érdekes MAC címet (nem kötelező definiálni, be lehet írni az if-be a $MACADDR helyére is. Csak én szeretem egyszer definiálni, hátha többször fogom használni.
A 3. sorban a script megvizsgálja, hogy a 2. paraméterként érkező érték (a fenti leírás alapján ugye ez a MAC cím) egyezik-e a számunkra érdekes MAC címmel. Ha nem, akkor nem csinál semmit.
A 4. sorban pedig rögzíti permanensen a szomszédot a paraméterként érkező IP cím és MAC cím segítségével.Ha csak kíváncsi vagy, hogy valóban futtatja-e a dnsmasq a scriptet, akkor legyen ennyi a tartalma:
#!/bin/sh
logger -t make_ip_permanent "Incoming type: $1, MAC address: $2, IP address: $3, Hostname: $4"
Majd, ha újraindítod a dnsmasq-ot, akkor minden dhcp kéréskor/megújításkor/release-kor látni fogsz egy sort a rendszer logban a fenti tartalommal. Ez a script csak logol, semmi mást nem csinál.
Alex
-
petakpa1
őstag
-
Satrafuckar
tag
válasz Satrafuckar #71303 üzenetére
minidlna adatbázist routeren kivül linuxos vm-el megépítettem próbaképp.
de továbbra is az van, hogy ha minidlna engedélyezve van akk bekapcs/restart után valami használhatatlanná lassitja a rendszert. logban semmi extra nem látszik.nincs további ötletem, illetve nem tudom hogyan lehetne nyomozni
-
vargalex
Topikgazda
válasz Satrafuckar #71317 üzenetére
Szerintem egyszerűen kevés a RAM egy ekkora adatbázishoz. Nyilván az index létrehozása sem véletlenül nem futott le. Nem azonnal a disk-re történik...
Alex
-
Satrafuckar
tag
válasz vargalex #71318 üzenetére
de mi történik? most elvileg a minidlna-nak nem kéne semmit csinálnia, kliens nem csatlakozik, az adatbázis már megvan, scannelés nem történik, elv csak vár a bejövö kapcsolatokra
amugy sikerült nagynehezen egy ilyet produkálni
Mem: 60088K used, 1388K free, 0K shrd, 1624K buff, 2432K cached
CPU: 0% usr 99% sys 0% nic 0% idle 0% io 0% irq 0% sirq
Load average: 10.54 7.62 3.61 3/55 2879
PID PPID USER STAT VSZ %VSZ %CPU COMMAND
297 2 root RW 0 0% 47% [kworker/u2:2]
2826 1 root D 43264 70% 10% /usr/bin/minidlna -f /tmp/minidlna.co
2757 2 root SW 0 0% 8% [kworker/0:0]
2756 2331 root D 2908 5% 7% /usr/sbin/smbd -D
2878 2331 root D 2468 4% 5% /usr/sbin/smbd -D
696 2 root DW 0 0% 4% [kworker/0:3]
2333 1 root D 2552 4% 4% /usr/sbin/nmbd -D
2355 1 root D 1364 2% 2% /usr/sbin/ntpd -n -p 0.openwrt.pool.n
2764 2759 root R 1364 2% 2% top
1 0 root S 1392 2% 2% /sbin/procd
96 2 root SW 0 0% 2% [kswapd0]
1071 1 root D 2268 4% 1% mount.ntfs-3g /dev/sda2 /share/Kulso
1980 1 root S 2152 3% 0% /usr/sbin/uhttpd -f -h /www -r TpLink
2823 2 root SW 0 0% 0% [kworker/u2:0]
2227 1 root S 2848 5% 0% /usr/sbin/vsftpd
2331 1 root S 2468 4% 0% /usr/sbin/smbd -D
2879 1980 root D 2152 3% 0% /usr/sbin/uhttpd -f -h /www -r TpLink
2439 1 root D 1576 3% 0% /usr/sbin/hostapd -P /var/run/wifi-ph
1102 1 root S 1480 2% 0% /sbin/netifd
1535 1 root S 1420 2% 0% {dynamic_dns_upd} /bin/sh /usr/lib/dd[ Szerkesztve ]
-
vargalex
Topikgazda
válasz Satrafuckar #71319 üzenetére
Azért a minidlna-nak fel kell olvasnia az adatbázist... Különben hogy szolgálna ki?
Alex
-
vargalex
Topikgazda
-
Zigi
senior tag
Sziasztok. Elrontottam egy "frissítést" a 1043v2-es routeren. Tftpd-n tudok rá flashelni bin-t, fel is megy de nem indul a vas. Openwrtről mentem volna ddwrt-re azóta nem jó. Próbáltam gyári fw-t openwrt fw-t de nem éled fel. Segítsetek pls. Mit flasheljek rá?
[ Szerkesztve ]
-
Zigi
senior tag
Tárgytalan, helyrejött. Rá engedtem a gyárit, utána pedig az openwrt-t gyáriról és jó lett. Igaz még mindig openen vagyok, de most megint nekifutok. Lehet inkább visszamegyek gyárira és utána át egy másik fw-re, mert ez az openről dd-re kicsinálta .
ui: ha valaki így járna Tfpd-s leírás tökéletesen működik az fw neve: wr1043v2_tp_recovery legyen v2es router esetén[ Szerkesztve ]
Új hozzászólás Aktív témák
- Képeken az egyik kameráját elvesztő Sony Xperia 10 VI
- HiFi műszaki szemmel - sztereó hangrendszerek
- Az Apple megszerezné a klubvilágbajnokság közvetítési jogait
- Gitáros topic
- Azonnali VGA-s kérdések órája
- Végre megjelenési dátumot kapott az xDefiant
- Kerékpárosok, bringások ide!
- Apple iPhone 15 Pro Max - Attack on Titan
- Bemutatkozott a Moto G32 4G
- Lakáshitel, lakásvásárlás
- További aktív témák...
- Triangle Heliade Es hangfalpár
- Apple iPhone 14 128gb Midnight + Garancia
- Apple iPhone 12 Pro Max, Pacific Blue, 128Gb, független 86% akku
- Szuper Akció:Igényeseknek-Exkluziv-12Genes-Core i7-Dell Latitude 5430-Harmad áron-garival!!!
- Western Digital 6TB NasWare 3.0 WD60EFRX-68l0bn1 keveset használt eladó.
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: Ozeki Kft.
Város: Debrecen