- Apple iPhone 17 - alap
- „Új mérce az Android világában” – Kezünkben a Vivo X300 és X300 Pro
- Samsung Galaxy S24 Ultra - ha működik, ne változtass!
- Xiaomi 15T Pro - a téma nincs lezárva
- Apple Watch Sport - ez is csak egy okosóra
- Telekom mobilszolgáltatások
- Több könyvet passzolna el a Samsung, mint kagylót
- Android alkalmazások - szoftver kibeszélő topik
- Milyen okostelefont vegyek?
- Motorola Edge 60 Fusion - nem csak a forma időtálló
-
Mobilarena
OpenWrt topic
Új hozzászólás Aktív témák
-
#21689
vargalex
Topikgazda
SztiviVander
#21688
vargalex
Topikgazda
válasz
SztiviVander
#21688
üzenetére
Miért támogatnának régi csomagokat? Ha a függőségi láncban lenne egy kernel függőség, akkor mit kezdene az automatizmus? A kolléga által használt L850-GL csomagnak pont van kernel függőség.
Ha a hivatalos repoban nem érhető el valami, akkor joggal várják el 1 év távlatában, hogy a third party csomagot biztosító fejlesztő adja az apk-t.
A legegszerűbb valóban az ipk kibontása (ami egy tar.gz) és a file-ok megfelelő helyre másolása.
De elérhető a forrás is, így elvileg tényleg fordítható. -
#21688
SztiviVander
addikt
xabolcs
#21685
SztiviVander
addikt
válasz
xabolcs
#21685
üzenetére
Sokan nem vagyunk ennyire linux guruk hogy forditgassunk
Oke, valahogy bemasolgatni 10-15 csomagot be lehet vegulis, meg pocsoreszni a fuggosegekkel meg a jogisultsagokkal, de azert ennek a hozzallasnak hadd ne tapsoljak. Nezhetjuk ugy is hogy az az egy ev eleg lett volna arra is hogy a regi ipk-kat lehessen tovabbra is telepiteni a luci csomagkezelobol, nem? Foleg ha az csak egy egyszeru tomoritett fajl... -
#21685
xabolcs
őstag
SztiviVander
#21684
xabolcs
őstag
válasz
SztiviVander
#21684
üzenetére
A 24.10-nel is az utolso pillanatban vettek ki az apk-ra valo atterest, igy bo egy ev volt felkeszulni a csomagkezelo valtasra.
Egyebkent meg mar volt szo rola, hogy az ipk csak egy tomoritett fajl egy-kwt leiroval kiegeszitve.
Tehat ha megvan az ipk, akkor kicsomagolod, felmasolod a megfelelo hely(ek)re es elvegzed a szukseges dolgokat, ami a leiro fajlokban vannak es kesz is.Ha pedig megvan a forras, akkor az SDK-val lehet apk-t forditani belole.
-
#21684
SztiviVander
addikt
yodee_
#21683
SztiviVander
addikt
válasz
yodee_
#21683
üzenetére
Egyelore engem is ez tart vissza a 25-tol es en sem talaltam meg ra egyertelmu mondast hogy mi lesz az ipk csomagokkal, azon kivul persze hogy tolsd le az uj apk verziojat es meg van oldva. Ja, mintha az x eve nem fejlesztett csomagokbol majd hirtelen lenne apk... Jo persze tudom ok csak a hivatalos repoval foglalkoznak, de azert a visszafele kompatibilitast megtarthattak volna a kezi csomagtelepitesnel.
-
hmzs
tag
-
#21680
Multibit
nagyúr
GhostVector
#21679
Multibit
nagyúr
válasz
GhostVector
#21679
üzenetére
Azt fogalmazd meg magadnak, hogy mit hiányolsz a jelenlegi rendszeredból, vagy mi kéne, hogy másképp működjön! Aztán nézz utána, hogy ezek elérhetők-e OpenWrt-ben
-
#21677
Multibit
nagyúr
GhostVector
#21676
Multibit
nagyúr
válasz
GhostVector
#21676
üzenetére
Ha ez kérdés számodra, akkor neked nem érdemes.
-
#21676
GhostVector
tag
GhostVector
tag
Cudy M3000 estében érdemes feltenni OpenWrt-t?
Mi javulna, mi pluszt adna?
-
xabolcs
őstag
válasz
hunaqua
#21670
üzenetére
Szerintem a static DHCP (avagy static leases) lesz a baratod, amit azon az eszkozon kell beallitanod, ami az IP cimeket osztja ki (pl. ezt a 192.168.1.343-at)!
Ha OpenWrt-s eszkoz intezi az IP cineket, akkor a "Network" / "DHCP and DNS" menupont alatt, a "Static leases" fulecsken talalod a beallitasokat!
Leginkabb az eszkoz MAC cime es a kiszemelt IP cim szukseges!
-
Asycid
tag
válasz
xabolcs
#21666
üzenetére
Van itthon egy ASUS AC65P, több, mint elég nekem (szüleimnek lesz az új, mert nekik egy ezer éves tplink van, és állandóan összezuhan), de sajnos már nem kapni, használtan meg nem veszek, mert van úgy azért ilyen eszközöknél, hogy egyszercsak megmakkan. Mindenesetre mint irtam, már berendeltem két cudy WR3000H -t, a legrosszabb eset, hogy a 2025 RC3 openwrt-t kell rátenni. Magamnak is vettem, ha már, majd beszámolok róla, hogy megy-e.
-
xabolcs
őstag
válasz
Asycid
#21660
üzenetére
Ha eleg az AC is es nem kell AX, akkor nezz valami mt7621-es routert, esetleg valami ipq40xx-et hasznaltan, apropenzert!
Ha esetleg van jo, akkor a filogic-bol vegyel, azok 5GHz-n AX-esek (nemelyike 2.4-en is
), szinten hasznaltan!A Qualcomm-bol csak mar bizonyitott modelleket ajanlok nyugodt szivvel, a tobbi draga es sokkal rosszabb!
Pl. Xiaomi AX3600 vagy testvere, AX6 (nem osszekeverendo AX6s-sel, ami pedig az AX3200 rokona, persze ezek is jok) ha talalsz! -
Asycid
tag
Bár most látom...
[link]Ez a lap a Table Of Hardware-nél nem volt ott, máshogy találtam meg...
Since nov. 2025, models are shipped with an new memory chip. Serial numbers start with 2543 or later. These devices can only run with 24.10.5 or later. For security reasons, it is recommended to run the latest stable version anyway.
More information here https://forum.openwrt.org/t/cudy-started-using-a-new-flash-chip-in-their-ax3000-devices-its-currently-unsupported/243547 and here https://www.cudy.com/blogs/faq/openwrt-software-download. PR submitted in order to support this new memory chip https://github.com/openwrt/openwrt/pull/20962.
As of jan. 2026, some devices are shipped with an alternate chip for the WAN port. Default OpenWrt 24.10 image won't detect this chip. This is fixed by a commit since 25.12.0-rc3 and main (13 jan. 2026): image must include the kmod-phy-motorcomm driver. It would have been smarter from Cudy to create a v2 for this device rather than changing the hardware without noticing the user. Info in the commit: https://github.com/openwrt/openwrt/commit/8d407de4910712213afff1919830b3fe5c33e1b4
-
vargalex
Topikgazda
válasz
Asycid
#21662
üzenetére
Jó tudni, hogy van már v2 is. A gyártónál úgy látom, hogy még a WR3000E-ből van v2, így ezt a két típust érdemes egyelőre kerülni. A többivel elvileg nem nyúlhatsz mellé.
Sajnos egyre több gyártó csinálja azt (vannak, akik már évek óta), hogy különböző revíziók esetén teljesen más SoC-ot használnak. -
Asycid
tag
válasz
vargalex
#21661
üzenetére
Köszönöm, de pontosan a WR3000-rel van lutrizás mostanra:
Cudy WR3000 v1
Attention!
New model2.0has been released by Cudy and features completely different TRIDuctor hardware. Also CPU processor speed is 1.2 Ghz instead of 1.3 Ghz.
It can be identified by looking at the bottom of the case, showing 2.0 at the end.
→ OpenWRT is not supported on the new WR3000 2.0 revision! -
Asycid
tag
Sziasztok!
A kérdésem az lenne, hogy milyen routert ajánlanátok mostanság OpenWRT-hez? Sima Dumb AP lesz belőle, és a lényeg, hogy a hatótáv viszonylag nagy legyen (illetve megbízhatóan működjön), illetve telepítenék rá egy-két extra modult is (Pl. Wi-Fi "jelenlétet" érzékelő cuccot), emiatt ha nem is kell gigászi tárhely, de ne csak pár MB legyen szabad OpenWRT telepítés után.
Illetve ami még fontos, hogy viszonylag egyszerű legyen a telepítés, ne kelljen forrasztgatni, és ne legyen lutri, hogy milyen verzió a HW (CUDY, rád nézek...).
USB port nem kell, gigabites portok tökéletesek. Igazából Wifi6 sem nagyon szükséges, 5 is elég, nincs a célhálózatban olyan eszköz ami a WiFi6 -ot kihasználná.
Ja, igen, ne kelljen félszázezer forintot költeni ha lehet
Létezik ilyen egyáltalán?
Előre is köszönöm!
-
vargalex
Topikgazda
Te megint keversz valamit! Ez az üzenetet a kliens mondja, nála maradt foglalt a port. Azért marad foglalt, mert a kliens tartja nyitva (pl. böngésző)! A dropbear újraindítás nyilván megoldja, mert azzal is megszakad a kapcsolat. Ha bezárod a kérdéses böngésző lapot, akkor egy idő után a böngésző elengedi a kapcsolatot, vagy ha bezárod a böngészőt, akkor azonnal.
-
cree
tag
cliens1 gép ssh port forwal le futamon innen kilépek( ssh cliens program)!
másik fizikai gépen cliens2 megnyitom és hivatkozás:
-----
ssh: TCP forward failed: Error listening: Address in use
ssh: Failed local port forward (null):8080:localhost:80
ssh: TCP forward failed: Error listening: Address in use
ssh: Failed local port forward (null):8443:localhost:443
------
mert a serveren fut ssh port forwald amit cliens1 tetem!
manuálisan dropbear restart megoldja a fenti hibát "de e ezt lehetne automatikusan is cliens kilép akor ez elindulna pl!
-
Geth
veterán
dropbear restart ssh cliens kilépéskor?
Ez nem normális működés, valami ott el van kefélve.ssh portforval még akkor is fut ha bezárom az ssh clienset!
Ez előfordulhat például aktív adatkapcsolat esetén (pl. böngésző). Vagy lehet SSH multiplexelés miatt is, ha használod ezt a feature-t. -
#21648
ArthurShelby
addikt
vargalex
#21647
ArthurShelby
addikt
válasz
vargalex
#21647
üzenetére
Munka után mértem, amikor már a többiek haza mentek (akkor is többször).
Másnap is mértem, ugyanez a "hiba" volt. 2mp alatti különbséget talán elkönyvelném mérési hibának (bár akkor is idegesítene).A vlan tag-es válaszod részét nem értem.
Céges hálón vpn nélkül 1472-es payload-dal (hosszúsággal) tudok pingelni (ergo megy az 1500-as mtu), illetve acces port van, ergo észrevétlenül megoldja/elintézi ezt a céges switch. (Azt hogy vlan van, azt én csak onnan tudom, hogy hallottam beszélni a hálózatost, hogy az adott portot beteszi az 50-es vlan-ba pl.) -
#21647
vargalex
Topikgazda
ArthurShelby
#21646
vargalex
Topikgazda
válasz
ArthurShelby
#21646
üzenetére
Én pedig azt mondanám, hogy ez csak a két hálózat éppen aktuális kihasználtsága miatt lesz inkább. Gondolom nálad is van közben forgalom, a céges hálón pedig gyaníthatóan különösképpen.
Az 1392-es MTU-t elvileg magától állítja be a használt MTU függvényében. Az 1420-as MTU valószínűleg azért lassított, mert darabolni kellett neki a frame-okat, mert a VLAN-os frame-ba már nem fért be a wireguard overhead-al együtt. -
#21646
ArthurShelby
addikt
ArthurShelby
addikt
Hátha ti tudjátok, sok okos ember van a topikban:
2 vpn-t (openvpn és wireguard) hasonlítok össze 100MB-on és 1GB-on (script-tel). Munkahelyemtől mérek az otthoni xpenlogy szerverem felé. Az otthoni internet kapcsolatom a szűk keresztmetszet, mert ott a one/upc hfc koax van 1000/40-nel (dhcp net, nem pppoe).
WireGuard 100MB MERES:
Letoltes: 26.806 mp
Feltoltes: 2.882 mpWireGuard 1GB MERES:
Letoltes: 220.601 mp
Feltoltes: 19.148 mpOpenVPN 100MB MERES:
Letoltes: 23.481 mp
Feltoltes: 7.577 mpOpenVPN 1GB MERES:
Letoltes: 238.557 mp
Feltoltes: 91.089 mpMinden szép és jó, csak a 100MB-os wireguard letöltés zavar be (40Mb/s korlát), lassabb wiregard-dal, mint openvpn-nel
.
A céges hálón vlan van, annak a nagyobb Ethernet kerete bezavarhat, azaz mégsem, mert access port van, ergo az eszköz nem látja a vlan tag-et, azt megoldja magának a céges hálózat baby giant funkcióval gondolom.Google-t pingelve Wireguard-dal 1392 a max payload, anélkül 1472, ergo az 1420-as mtu a max wireguard vpn-nél.
Ha fixen 1420-ra állítom a wireguard profilban az mtu-t, akkor a leöltés javul, viszont a feltöltés rosszabbodik.
WireGuard 100MB MERES:
Letoltes: 21.882 mp
Feltoltes: 9.401 mpValaki meg tudja ezt nekem magyarázni? Esetleg a szolgáltató is beleszólt (Micro-bursting és/vagy Policer)?
Illetve már vissza sem tudom állítani a wireguard profilt (hiába szedem ki az 1420-as mtu-t, marad a lassabb feltöltés)
Mérési hibát nem mondanék, mert egymás után többször mértem és hasonlóak voltak az eredmények. -
-
vargalex
Topikgazda
2 nap az nem sok idő. Ott is mindenki szabadidőben foglalkozik a dolgokkal. A LuCI-s kérdésekel leginkább a fejlesztő (Jow) szokta megválaszolni egyszemélyben, így nagyon leterhelt. Úgyhogy kár sürgetni. De biztosan törölték?
Én egyébként a konkrét szövegre lettem volna kíváncsi... És nyilván a sürgető üzenetre is. -
Gyurka6
őstag
válasz
vargalex
#21629
üzenetére
Feltöltöttem a sysupgrade változatot, 20dBm -ig lehet növelni a teljesítményt.
Egy újabbra akartam frissíteni, de mást vár:
The uploaded image file does not contain a supported format. Make sure that you choose the generic image format for your platform.Ilyen formátumút nem találtam, hogyan tudom újabbra frissíteni?
-
cree
tag
válasz
vargalex
#21631
üzenetére
Angol irtam amit a forditó kiadot! A Bemutatkozásuk elég volt szerintem!
Vagyis 2 kérdés volt!
Csak egy egyszerü dátum/orát szeretem volna kirakni Authorization Required kezdő oldalra jielenkezet álapotba is látszodjon! 2 napig volt fen mekérdeztem mit csináltok itt? És törölték is hát kulturális hozzá álás! -
vargalex
Topikgazda
válasz
Gyurka6
#21628
üzenetére
A snapshot-ban elvileg apk csomagkezelő van, így a telepítés és indítás:
apk update
apk add luci
/etc/init.d/uhttpd enable
/etc/init.d/uhttpd startHa esetleg mégis opkg lenne (régen snapshot-oztam már), akkor:
opkg update
opkg install luci
/etc/init.d/uhttpd enable
/etc/init.d/uhttpd startHa jól tudom, még itt sem írható a radio partíció. Viszont anno én build-eltem egy olyat, amiben írhatóak. Ebből van egy sysupgrade változat is. Aztán volt egy későbbi hozzászólásom is. Sajna nem emlékszem, hogy végül most melyik verzió érhető el.
Természetesen, ha a sysupgrade verziót teszed fel, akkor nem kell recovery-ből telepíteni.
-
Gyurka6
őstag
válasz
vargalex
#21627
üzenetére
DE, arra... Elvileg van mentésem, radio, firmare, factory meg uboot backup.
Most egy snaphost verziót töltöttem rá (nem szándékosan), 2,4.en tudok kapcsolódni, csak nincs titkosítás rajta. Esetleg tudod merre keressem a luci telepítési módját? Szeretném látni, mi más mint a régebbi veziónál. -
vargalex
Topikgazda
válasz
Gyurka6
#21626
üzenetére
Nem a DIR-860L topicra gondolsz?
Pont erre céloztam. A wifi kalibrációs adatok így mentek a levesbe. Meg lehet próbálni egy másik DIR-860L mentését beírni. Sajna a kalibrációs adatok nélkül a gyári firmware sem megy.
-
cree
tag
válasz
vargalex
#21622
üzenetére
Már amikor ott irtad felraktam luci-ssl de otvan az összes sriptje nehezéknek a flashben nem teszi a dolgát?
csinálok egy gyári visszaálitás sokadjára már és elkezdem ujra amit itt leirtál már nincs ötletem mi az a fö probméma ahol elakad! mert volt amikor a uhttp config defaut álapotban volt amit irsz http,https rész 0.0.0.0 de igysem ment az átirányitás .... 
loopback is piszkáltam már ott a mask rész mert gyanus volt a 255.0.0.0 belsö hálotatomon minden 255.255.255.0 van de változás nemtörtént eben sem! -
vargalex
Topikgazda
Nem értem az utolsó mondatodat. Én leírtam, hogy a jelenlegivel nem is fog menni, mert csak a loopback interface-on hallgat az uhttpd. Miért módosítottad 127.0.0.1-re?
Ahogy írtam, LAN oldalról a tűzfal egyáltalán nem is szól közbe.A hálózatodban a 192.168.1.2 az egy router az OpenWrt router előtt? Hogy van bekötve ez az OpenWrt router? A 192.168.1.2-ből érkező kábel az egyik LAN-ba van csatlakoztatva?
A wiki-ben található leírásnak megfelelően tettél fel saját private key és certificate-okat, vagy telepítetted a
luci-sslmeta package-t, hogy generáljon magának?Az uhttp config-ot írd vissza a default-ra:
config uhttpd 'main'
list listen_http '0.0.0.0:80'
list listen_http '[::]:80'
list listen_https '0.0.0.0:443'
list listen_https '[::]:443'
option redirect_https '0'
option home '/www'
option rfc1918_filter '1'
option max_requests '3'
option max_connections '100'
option cert '/etc/uhttpd.crt'
option key '/etc/uhttpd.key'
option cgi_prefix '/cgi-bin'
list lua_prefix '/cgi-bin/luci=/usr/lib/lua/luci/sgi/uhttpd.lua'
option script_timeout '60'
option network_timeout '30'
option http_keepalive '20'
option tcp_keepalive '1'
option ubus_prefix '/ubus'
config cert 'defaults'
option days '730'
option key_type 'ec'
option bits '2048'
option ec_curve 'P-256'
option country 'ZZ'
option state 'Somewhere'
option location 'Unknown'
option commonname 'OpenWrt'(A cert generálásnál beírtam az általad módosított két értéket -
dayséscommonname- de ez lényegtelen változás.)Majd indítsd újra az uhttpd-t:
/etc/init.d/uhttpd restartAzért bizonyosodjunk meg róla, hogy valóban hallgat minden interface-on a 443-as porton is:
root@WR3000:/www/luci-static# netstat -anlp | grep 443
tcp 0 0 0.0.0.0:443 0.0.0.0:* LISTEN 15457/uhttpd
tcp 0 0 :::443 :::* LISTEN 15457/uhttpdEzután PC-ről már mennie kell az SSH tunnelnek, ahogy korábban írtam is:
ssh -L 8080:localhost:80 -L 8443:localhost:443 root@192.168.1.254Ezután a PC-n a böngészőben http://localhost:8080 URL-en HTTP-n, a https://localhost:8443 URL-en HTTPS-en éred el a router LuCI-ját. De, hogy ennek LAN oldalról mi értelme, arra továbbra is kíváncsi lennék! Az SSH tunnelnek akkor lenne értelme (és valószínűleg ezt kevered), ha pl. külső hálózatból SSH-n eléred a routert, akkor a 80-as titkosítatlan HTTP portot nem kell kinyitni, hanem tunnelen keresztül titkosított forgalommal férsz hozzá.
#21621 cree: szerintem sajnos a hálózati ismereteid is hiányosak. Mit az a 127.0.0.1:123 átjáró? A 123 az valóban az NTP port, de mit vársz attól, hogy önmagával szinkronizáljon? (Ugyanis a 127.0.0.1 a localhost, tehát a router maga!)
A lua-s scripteket felejtsd el. Írtam, hogy JavaScriptre álltak át! A status oldalt nézd meg, ott szépen látszik, hogy
ubushívással kéri el az időt a routertől. -
cree
tag
válasz
vargalex
#21619
üzenetére
openwrt api egyedi erröl én nem találtam semit hiába a js vagy http nyelv ha nemtudom meghivni ao openwrt egyedi api részt itt esetembe time,date ami fontos lene sajnos offline modban a rooter orája elcsuszik ntp server nincs szinkronban Totp lehetösége elromlik rossz time miat !Windows ntp server szinronizálása még nem sikerölt openwrt ntp beratram hogy csinálja meg 127.0.0.1:123 átjárobol de nem müködik!
script rész nem sikerül összehozni date/ time
meglévökböl sem...
https://www.openwrt.pro/post-677.html
https://www.openwrt.pro/post-333.html
https://forum.archive.openwrt.org/viewtopic.php?id=42834
https://www.lua.org/pil/22.1.html
https://stackoverflow.com/questions/12466950/lua-program-shows-current-time
https://stackoverflow.com/questions/34346499/how-to-read-post-from-lua-on-openwrt-uhttpd
https://dev.iopsys.eu/feed/luci/-/blob/openwrt-21.02/docs/api/modules/luci.http.date.html?ref_type=heads
https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CSP -
vargalex
Topikgazda
Az általad linkelt hozzászólásban egy szó nincs SSH tunnel-ről...
Viszont az a beállítás szerintem teljesen rossz. Azzal azt érted el, hogy csak a loopback interface-on hallgat azuhttpd. Az alap config szerinti 0.0.0.0 IP cím jelenti azt, hogy az összes interface-on elérhető azuhttp.#21618 cree: mivel, ahogy írtad, javascript-re tértek át LuCI oldalon, a dátum, idő kiírásért nem a LuCI biztosít API-t, tisztán javascriptben elérhető. De egyébként a LuCI client side API-nak is nagyon jó dokumentációja van.
-
cree
tag
válasz
vargalex
#21610
üzenetére
LuCi script kodhoz is értesz?
bár a mostani uj motorját js tolják átt lua helyet!
Késöbb lene egy másik kérdés ezel kapcsolatban!
Login oldalra szeretem volna egy belső dátum és órát kirakni de nem sikerül az a szriptet ami ezért felelne napon kevés luci minta példa van erre api pl most az ujaknál js ben date,time api! -
-
cree
tag
networkconfig interface 'loopback' option device 'lo' option proto 'static' option ipaddr '127.0.0.1' option netmask '255.255.255.0'
config globals 'globals' option ula_prefix 'fd58:2361:7b3e::/48' option packet_steering '1'
config device option name 'br-lan' option type 'bridge' list ports 'lan1' list ports 'lan2' list ports 'lan3' list ports 'lan4'
config interface 'lan' option device 'br-lan' option proto 'static' option ipaddr '192.168.1.254' option netmask '255.255.255.0' option ip6assign '60' option gateway '192.168.1.2' list dns '192.168.1.2'
config interface 'wan' option device 'wan' option proto 'dhcp'
config interface 'wan6' option device 'wan' option proto 'dhcpv6' -
cree
tag
uhttpd
config uhttpd 'main' list listen_http '127.0.0.1:80' #list listen_http '[::]:80' list listen_https '127.0.0.1:443' #list listen_https '[::]:443' option redirect_https '0' option home '/www' option rfc1918_filter '1' option max_requests '3' option max_connections '100' option cert '/etc/uhttpd.crt' option key '/etc/uhttpd.key' option cgi_prefix '/cgi-bin' list lua_prefix '/cgi-bin/luci=/usr/lib/lua/luci/sgi/uhttpd.lua' option script_timeout '360' option network_timeout '30' option http_keepalive '20' option tcp_keepalive '1' option ubus_prefix '/ubus'
config cert 'defaults' option days '397' option key_type 'ec' option bits '2048' option ec_curve 'P-256' option country 'ZZ' option state 'Somewhere' option location 'Unknown' option commonname 'iStoreOS' -
cree
tag
firewallconfig defaults option syn_flood '1' option input 'REJECT' option output 'ACCEPT' option forward 'REJECT'
config zone option name 'lan' list network 'lan' option input 'ACCEPT' option output 'ACCEPT' option forward 'ACCEPT'
config zone option name 'wan' list network 'wan' list network 'wan6' option input 'REJECT' option output 'ACCEPT' option forward 'REJECT' option masq '1' option mtu_fix '1'
config forwarding option src 'lan' option dest 'wan'
config rule option name 'Allow-DHCP-Renew' option src 'wan' option proto 'udp' option dest_port '68' option target 'ACCEPT' option family 'ipv4'
config rule option name 'Allow-Ping' option src 'wan' option proto 'icmp' option icmp_type 'echo-request' option family 'ipv4' option target 'ACCEPT'
config rule option name 'Allow-IGMP' option src 'wan' option proto 'igmp' option family 'ipv4' option target 'ACCEPT'
config rule option name 'Allow-DHCPv6' option src 'wan' option proto 'udp' option dest_port '546' option family 'ipv6' option target 'ACCEPT'
config rule option name 'Allow-MLD' option src 'wan' option proto 'icmp' option src_ip 'fe80::/10' list icmp_type '130/0' list icmp_type '131/0' list icmp_type '132/0' list icmp_type '143/0' option family 'ipv6' option target 'ACCEPT'
config rule option name 'Allow-ICMPv6-Input' option src 'wan' option proto 'icmp' list icmp_type 'echo-request' list icmp_type 'echo-reply' list icmp_type 'destination-unreachable' list icmp_type 'packet-too-big' list icmp_type 'time-exceeded' list icmp_type 'bad-header' list icmp_type 'unknown-header-type' list icmp_type 'router-solicitation' list icmp_type 'neighbour-solicitation' list icmp_type 'router-advertisement' list icmp_type 'neighbour-advertisement' option limit '1000/sec' option family 'ipv6' option target 'ACCEPT'
config rule option name 'Allow-ICMPv6-Forward' option src 'wan' option dest '*' option proto 'icmp' list icmp_type 'echo-request' list icmp_type 'echo-reply' list icmp_type 'destination-unreachable' list icmp_type 'packet-too-big' list icmp_type 'time-exceeded' list icmp_type 'bad-header' list icmp_type 'unknown-header-type' option limit '1000/sec' option family 'ipv6' option target 'ACCEPT'
config rule option name 'Allow-IPSec-ESP' option src 'wan' option dest 'lan' option proto 'esp' option target 'ACCEPT'
config rule option name 'Allow-ISAKMP' option src 'wan' option dest 'lan' option dest_port '500' option proto 'udp' option target 'ACCEPT'
config rule option src 'wan' option target 'ACCEPT' option proto 'tcp' option dest_port '22' option name 'ssh-en' -
cree
tag
válasz
vargalex
#21610
üzenetére
Öt szoktam nézni elég érthetö a folyamat....
https://www.youtube.com/watch?v=ZL4FKjLc3bU
uhttpd.conf luci server http gui érdemében felelne az egész produkcioért ha jol látom ezt az egészet!
firewall.conf kikapcsoltam teljesen ebben a 22 port alabol engedélyezet ssh részére ilyenkor egy port forwald szabály sem érvényes tiltot tüzfalnél! lehet network.conf lehet még valami alap átjáró akadálya.... a böngészö 404 hibával ál ki az irányitot ip vagy port oldalon mindig! -
-
vargalex
Topikgazda
Az OpenWrt forumon sem teljesen érthető, amit írsz. De az azért teljesen világos, hogy a tűzfal szabály, amiről a képet készítetted, LAN irányból nem lép életbe... Ugyanis LAN-LAN nincs tűzfal. Illetve te egyébként is WAN-t jelöltél meg forrásnak a tűzfal szabályban.
A következő config-ok tartalmát jó lenne látni:
uhttpd.conf
network.conf
firewall.confMost éppen nem vagyok otthon, de innen a munkahelyről elérem a szerveremet és onnan megcsináltam minden port továbbítás nélkül:
[gavarga@arch ~]$ ssh -L 8088:localhost:80 root@192.168.22.1
root@192.168.22.1's password:
BusyBox v1.36.1 (2024-10-17 09:00:40 UTC) built-in shell (ash)
_______ ________ __
| |.-----.-----.-----.| | | |.----.| |_
| - || _ | -__| || | | || _|| _|
|_______|| __|_____|__|__||________||__| |____|
|__| W I R E L E S S F R E E D O M
-----------------------------------------------------
OpenWrt 23.05.5, r24106-10cc5fcd00
-----------------------------------------------------
root@WR3000:~#Majd szintén a szerverről egy curl a localhost SSH tunnel-ezet portjára:
[gavarga@arch ~]$ curl http://localhost:8088
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Cache-Control" content="no-cache, no-store, must-revalidate" />
<meta http-equiv="Pragma" content="no-cache" />
<meta http-equiv="Expires" content="0" />
<meta http-equiv="Expires" content="Thu, 01 Jan 1970 00:00:00 GMT" />
<meta http-equiv="refresh" content="0; URL=cgi-bin/luci/" />
<style type="text/css">
body { background: white; font-family: arial, helvetica, sans-serif; }
a { color: black; }
@media (prefers-color-scheme: dark) {
body { background: black; }
a { color: white; }
}
</style>
</head>
<body>
<a href="cgi-bin/luci/">LuCI - Lua Configuration Interface</a>
</body>
</html>Ahogy látod, ez már a LuCI webes felület. Bocs, de a szerveremen nincs grafikus felület, ezért mutattam be curl-al.
Egyébként az itteni topic-ban kerestem az ssh szót a hozzászólásaid között. Még csak hasonló kérdést sem tettél fel eddig...
-
cree
tag
válasz
vargalex
#21608
üzenetére
Akkor csak a feltet kérdésekre kell válaszolni semmi más vacakolás és nem lesz ennyi szemét a topicban ami nem oda való!
Akkor még egyszer!
Miért nem müködik a webes luci alapu ip és port átirányitás ssh Keresztül? A-Z Z-A minden lehetöságet kiprobáltam !Egy teljes folyamat elejétöl a végéi!
Minden akadályt kikapcsoltam mindkét oldalon hogy nem legyen blokolva ip se port sem openwrt és win alat sem tüzfal mindkét oldalt kiapcsolva!
Ez nem vezet eredményre az átirányitot porton sincs elérhetö webes felület nem hogy ipn!
https://openwrt.org/docs/guide-user/luci/luci.secure
de nem müködik a valoságban hiábba csinálom meg!
https://forum.openwrt.org/t/ssh-tunneling-problems/49271 -
vargalex
Topikgazda
A kezdetektől nem érti tökéletesen senki, hogy mit is szeretnél. Ezért vetettük fel az idegen nyelv használatának lehetőségét annak ellenére, hogy ez egy magyar nyelvű fórum.
Bocsánat, de személyeskedést, lekezelést, a legjobb segítő szándékban is a negatívumot keresést, illetve belemagyarázást csak tőled láttam. Nagyon úgy tűnik, hogy neked üldözési mániád van, vagy nagyon negatív korábbi tapasztalataid.
Már több 10 (100) hozzászóláson keresztül csak a vélt sérelmeket olvassuk tőled, de semmivel nem jutottunk közelebb a problémádhoz (a megoldásról nem is beszélve, mert a probléma ismerete nélkül nem tudunk javasolni értelmes dolgot).
-
cree
tag
válasz
vargalex
#21605
üzenetére
Utasitgatnak mit hogyan csináljak nyelvi magatartás milyen nyelven xxx az nemjó akor irjál yyy (3 hete legalább) én ezt(személyezkedésnek és lekezelőnek veszem) enek semni köze az eredeti feltet kérdésekhet!
De ezt hogyis gondolják?Én megatam mindenkinek azt a tiszteletet nem keztem el felé ugyan ezt(megtehetem volna)de a türelmem véges egy idő után!Kár hogy ilyen hülyeségekel itt foglalkozni nem a hasznos topic valodi tartalmával! 
-
vzozo
senior tag
válasz
vargalex
#21605
üzenetére
ezt is félreérted, itt saját VPN-ről van szó, nem a forgalmat akarja a kolléga egy VPN szolgáltatón keresztül irányítani.
Ez kicsit arra emlékeztet, amikor interjúztattam egy érdeklődőt az egyik erősen technikai pozinkra, és a CV-jében nagyon ki volt emelve, hogy ő VPN expert. Amikor rákérdeztünk, hogy ez mit is takar, akkor halál komolyan elkezdte mondani, hogy xy random provider VPN-jét úgy kell telepíteni, hogy next-next-finish.
Ott köszöntük meg a lehetőséget, és idő előtt véget ért a felvételi beszélgetés.
-
vargalex
Topikgazda
Megint félreérted. Semmilyen személyeskedés nem volt a kolléga hozzászólásában, egy egyszerű (amit már én is írtam) és logikus kérés annak érdekében, hogy segíteni tudjunk.
#21604 cree: ezt is félreérted, itt saját VPN-ről van szó, nem a forgalmat akarja a kolléga egy VPN szolgáltatón keresztül irányítani.
-
-
vargalex
Topikgazda
válasz
xabolcs
#21601
üzenetére
De közvetlen kapcsolatra port nyitás nélkül legfeljebb uPnP-vel lehet képes (a kifelé történő forgalom miatt a NAT táblába bekerülő portra csak a cél IP-ről - esetünkben ugye a Concentrator IP-je - lehetséges reverse tunnelen visszajönni). Másrészt, ha jól értem, ők is Wireshark-ra építenek, így triviális választás lehet az, teljesen saját üzemeltetéssel.
Oke, valahogy bemasolgatni 10-15 csomagot be lehet vegulis, meg pocsoreszni a fuggosegekkel meg a jogisultsagokkal, de azert ennek a hozzallasnak hadd ne tapsoljak. Nezhetjuk ugy is hogy az az egy ev eleg lett volna arra is hogy a regi ipk-kat lehessen tovabbra is telepiteni a luci csomagkezelobol, nem? Foleg ha az csak egy egyszeru tomoritett fajl...
LTE modemhez szükséges csomagok.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
csinálok egy gyári visszaálitás sokadjára már és elkezdem ujra amit itt leirtál már nincs ötletem mi az a fö probméma ahol elakad! mert volt amikor a uhttp config defaut álapotban volt amit irsz http,https rész 0.0.0.0 de igysem ment az átirányitás .... 
loopback is piszkáltam már ott a mask rész mert gyanus volt a 255.0.0.0 belsö hálotatomon minden 255.255.255.0 van de változás nemtörtént eben sem!
De ezt hogyis gondolják?Én megatam mindenkinek azt a tiszteletet nem keztem el felé ugyan ezt(megtehetem volna)de a türelmem véges egy idő után!Kár hogy ilyen hülyeségekel itt foglalkozni nem a hasznos topic valodi tartalmával! 
Új hozzászólás Aktív témák
- PC Game Pass előfizetés
- Windows 10 11 Pro Office 19 21 Pro Plus Retail kulcs 1 PC Mac AKCIÓ! Automatikus 0-24
- Számlás!Steam,EA,Epic és egyébb játékok Pc-re vagy XBox!
- Windows, Office licencek kedvező áron, egyenesen a Microsoft-tól - Automata kézbesítés utalással is!
- Eredeti Microsoft termékek - MEGA Akciók! Windows, Office Pro Plus, Project Pro, Visio Pro stb.
- BESZÁMÍTÁS! MSI B450M R5 5600X 16GB DDR4 512GB SSD Strix RTX 2060 6GB Rampage SHIVA CM 650W
- Azonnali készpénzes nVidia RTX 2000 sorozat videokártya felvásárlás személyesen / csomagküldéssel
- LG UltraFine 4K - 6K és Smart Monitorok -30%
- Raktáron lévó VGA-k!!! Kamatmentes részletre is!! Érdeklődj!!!
- HP EliteOne 800 G4 All-in-One i5-8500 32GB 1000GB 23.8" Érintőkijelző!! 1 év garancia
Állásajánlatok
Cég: Central PC számítógép és laptop szerviz - Pécs
Város: Pécs
Cég: Laptopműhely Bt.
Város: Budapest