É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

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

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

sziasztok,

TpLink1043v3
suste/headless@OpenWrt@0.8.1 Barrier Breaker 14.07

rö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!

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.

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

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

Erre a problémára további ötlet?

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 ]

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 ]

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?

Szerintem ő nem fogja megkérdezni. Csak a saját szomszédait ismeri, de persze egy próbát megér.

Akkor viszont jol gondolta petakpa1, hogy a komolyabb dolgokhoz OpenWrt-t hasznal.

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 db

normá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 ]

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áld

bonusz 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!!!"

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.

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 ]

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 ACTION

Melyik csomagot kell telepítenem, hogy az ip neigh add parancs működjön? ip-full vagy ip-tiny?

[ Szerkesztve ]

Ha a tiny-vel nem megy, akkor probald az ip-full-lal.