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

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 ]

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

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?

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

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.

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?

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

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

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 ]

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.

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

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.

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

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.

Pfff...
Hát ez 2 fokkal tűnik bonyibbnak, mint amit gondoltam , 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.

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

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

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 ]

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