TP-Link WR1043ND router - Hálózat, szolgáltatók fórum

üzenetek

hozzászólások


vargalex
(félisten)
Blog

Igen, azóta már sok dolog változott, többek között a régi ifconfig-ról ip parancsra váltottak, viszont a busybox-ban megvalósított minimális funkcionalitással. Így, ahogy a kolléga is írja, tedd fel az ip-tiny-t, ha azzal sem megy, akkor ip-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...


Satrafuckar
(tag)

szia,

először is köszi a segítséget :R

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)

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 ki
    sql_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égezve
sql_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)

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 exists

Most 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?


vargalex
(félisten)
Blog

Szia

Mivel most éppen él a kapcsolat ezért az add előtt lehet, hogy kell egy change is. Azaz:

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


petakpa1
(őstag)

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.


petakpa1
(őstag)

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?


vargalex
(félisten)
Blog

Miért nem raktad be a change sort is? Ott egy sleep 20. Ha az ip neigh add parancs a gép IP cím kérése után futott le (a sleep miatt), akkor teljesen hatástalan volt...


petakpa1
(őstag)

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...


petakpa1
(őstag)

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 ]


petakpa1
(őstag)

Sajnos a sleep 30 beszúrása sem segít, így is REACHABLE nem PERMANENT az ip cím amit kioszt TPlInk a PC-nek.

Ellenben ha ezt követően konzolból kiadom az ip neigh change-et akkor átvált PERMANENT-re.


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íme

sleep 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....


vargalex
(félisten)
Blog

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.


petakpa1
(őstag)

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 :DDD

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...


vargalex
(félisten)
Blog

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 az busybox-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é az

option 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.


petakpa1
(őstag)

Pfff...
Hát ez 2 fokkal tűnik bonyibbnak, mint amit gondoltam :DDD, nem most lesz, hogy nekiesek, de köszi még egyszer ezt is és a korábbiakat is.
Jelentkezem ha erőt vettem magamon és hozzákezdek.


Satrafuckar
(tag)

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
(félisten)
Blog

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...


Satrafuckar
(tag)

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
(félisten)
Blog

Azért a minidlna-nak fel kell olvasnia az adatbázist... Különben hogy szolgálna ki?


Satrafuckar
(tag)

300 mega a db. ezzel azt mondod, hogy ahhoz h müködjön olyan router kellene amiben 300+mb ram van?

[ Szerkesztve ]


vargalex
(félisten)
Blog

Nyilván nem a teljes 300 MB-ot kell memóriában tartani…


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 ]


suste
(veterán)
Blog

DDwrt-re pont a gyáriról kell frissíteni....


ЯΞD
(senior tag)

Sziasztok lenne egy sok éves 1043 v2.1-es routerem gyári firmware-el. Mostanában elkezdett olyat csinálni, hogy dobálja a kapcsolatot. A kábelest is. Gyanítom valami Hardware-es gond lehet vagy esetleg software gyári alapbeállításokra segíthet?


xabolcs
(őstag)
Blog

Ha tenyleg a router a hibas es nem a szolgaltatod, akkor igen, elofordulhat.

Leggyorsabban egy masik (ujabb, jol mukodo ;)) tapegyseggel tudnad ellenorizni. Ha pedig nem felsz szetszedni, akkor nezd meg a kondikat rajta!


ЯΞD
(senior tag)

Hát abból gondolom, hogy nem szolgáltató mert mikor megszakad és kiírja mondjuk a facebook pc-n nincs kapcsolat akkor az óra mellett a földgömb van és elérhetetlen a router is. Aztán fél perc múlva újra van. Majd megint elmegy 10 másodpercre és ezt random időnként csinálja. Pc-t hálókártyát windows kizárom mert pont most váltottam és új win is van. Illetve wifin sincs akkor adatforgalom.

Szétszedéssel nincs bajom van egy kis technikai érzékem. És mit nézek a kondikon, hogy puposak-e?
Tápot nem igazán tudok leakasztani mást jelenleg.


xabolcs
(őstag)
Blog

Igen, a pupos meg a mar kifolyt kondikat.

Ha van multimetered, akkor megmerheted a tapegyseg feszultseget is. Amit persze jobb lenne terheles alatt. :))
Ha meg terheles nelkul is furcsa ertekeket produkal, akkor lehet gyanakodni.


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/3395

Az 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 ]


HiFiHobbi
(csendes tag)

Sziasztok!

Gondoltam kiraakom ide is, hátha valamelyik TP-Linkes szaki tud erre megoldást.

A következőben kérnék segítséget. Adott a telekom otthoni szolgáltatása, melyet a következőképp használok. A telekomtól kapott eszközön be van állítva a PPPOE Passthrough és az 1-es LAN portjára a saját routerem van csatlakoztatva és azon adom meg a felhasználónevet és a jelszót.
Eddig egy Speedport entry i2 eszközöm volt a szolgáltatótól, de miután kiépítették az optikai hálózatot a lakóhelyemen, átváltottam arra. Meg is történt a beüzemelés, kaptam a speedport helyett egy Sagemcom F@st 5670 eszközt. Csak net és telefon van Tv nincs.

Beállítottam ezen is a PPPOE Passthrough-t, 1-es proton rádugtam a routeremet. Na erre a Sagemcom úgy reagált, hogy kb 1-2 perc után totál kifagyott. Telefonhoz tartozó LED piros lett, power és PON ledek továbbra is zölden világítanak. Ilyenkor a webes felülete sem jön be a telekomos eszköznek. Újraindítás után megint 1-2-3 percig jó minden, aztán ugyanezzel a jelenséggel megszűnik minden. Speedtest vagy egyéb le és feltöltés esetén a művelet megkezdésekor 1 percen belül vagy azonnal kifagy a Sagemcom 5670. Ha viszont nem csatlakoztatom rá a saját routeremet, akkor újraindítás után jó minden, a PPPoE kapcsolatot a gépem építi fel, a router nincs a gép és az ONT között.
Szembejött esetleg valakinek már ehhez hasonló hiba? Vagy csak az új Telekomos eszköz ennyire hulladékra sikeredett?

Úgy tűnik, hogy egyszerűen a Sagemcom F@st 5670 eszköz finnyás a TP-Link TL-WR1043ND v2.1/v3.0 és a TP-Link AC1750 Archer C7 v2/v3 routerre. Mások is és Telekomos szakik is próbáltak segíteni, de csak nem akar együtt dolgozni ez a digitális elosztó az én routereimmel. Amik más szolgáltatóknál minden hiba és gond nélkül tökéletesen működnek, működtek. Többen azt a tanácsot adták kérjem át teljesen 100%-ra Bridge módba a Sagemcom F@st 5670 eszközt, az megoldja a problémát. Hogyan és hol kell kérni ezt a Bridge módba átrakást? Ha már a PPPoE Passtrought nem jött össze.

Köszönöm előre is az esetleges válaszokat.


Borisz76
(veterán)
Blog

Nekem Digis előfizum van és az ügyfélszolgálatotot kell hívni ha Bridge módba akarom rakatni vagy vissza router módba az általuk adott ONT-ot.

Gondolom Telekomnál is megoldható így.

Valamint van egy Digi-s weboldal, ahová bejelentkezve magam is tudom állítani a kívánt Bridge / Router üzemmódot.
Nem tudom, hogy a Telekomnál létezik e hasonló....


HiFiHobbi
(csendes tag)

Szia!

A csodás Telekomnál optikán nincs bridge mód. Ráfogják a router meg a kábel a hibás, cseréld ki reseteld. Csak ha már tudtukra lett adva több routerrel és kábellel is ugyanaz van hogy adhatnak ilyen választ ezt nem értem. De értem, nem értenek hozzá a @ telekom meg soha semmibe nem hibás, soha nem tévednek, soha nem náluk van a hiba.


Fooler89
(őstag)
Blog

Sziasztok!

Van egy TP-link wr1043nd v4. 1 gigabites Digi nettel.

Kérdésem az lenne, hogy képes az openwrt-vel a hwnatra?


xabolcs
(őstag)
Blog

Szia!

HWNAT-ot OpenWrt alatt sajnos csak a mediatek (pl. Xiaomi AX3200) es ramips/mt7621 platform routerjei tudnak.

Sot, az ujabb (22.03, SNAPSHOT) OpenWrt-knek van valami bajuk a PPPoE soft-offload-os gyorsitasaval: 22.03.0 IPv4 PPPoE software flow offload not working (#10224)


vargalex
(félisten)
Blog

Nem. Csak software flow offlload-ot tud.

üzenetek