Hirdetés
- Samsung Galaxy A57 - kecses test, lusta lélek
- Megérkezett Európába a Soundcore Space 2 fejhallgató
- Hivatalos a OnePlus Watch 4
- Így spórolhat az Apple az iPhone 18 kijelzőin
- OnePlus 15 - van plusz energia
- Fittyet hány a pesti napfényre a Honor 600
- Mobil flották
- iOS alkalmazások
- Microsoft Rewards
- Milyen okostelefont vegyek?
-
Mobilarena
OpenWrt topic
Új hozzászólás Aktív témák
-
-
-
vargalex
Topikgazda
válasz
yodee_
#21723
üzenetére
A feed lehet local filerendszeren is. Ha másképp nem megy, akkor bontsd ki a csomagot és a FILES könyvtárba tedd be a file-okat a helyükre. Igaz, így nem fogja mutatni, hogy a csomag telepítve van, de minden elérhető lesz.
Esetleg adsz egy konkrét parancsot, ahogy build-eled és a csomagok elérhetőségét? Vagy valahova fel tudod tölteni az egészet egyben?
-
vargalex
Topikgazda
válasz
#42990592
#21709
üzenetére
A 800/250Mbps-t nem tudom, hogy bírja-e, de már TP-Link TL-WR1043ND-n (sőt, előtte Asus WL-500gP-n) is sokan torrenteztek, használtak Samba-t. Aztán MT7621-en is, a Filogic pedig jóval erősebb ezeknél.
Szerk.: Emag-on, igaz AzetShop nevű eladótól van 21496 Ft-ért is.
Szerk.: A WR3000 v2-nél nem az volt, hogy más SoC-ot is használtak? Én nem látom még a támogatottságát az OpenWrt-nél... Bár, a techdata-nál azt írja, hogy csak színben különbözik. De a gyártónál mégis más oldala van. Ott a v1-nél szépen írják, hogy Filogic, míg a v2-nél nem.
-
#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ó. -
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. -
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.
-
#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. -
-
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. -
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.
-
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.
-
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. -
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.
-
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...
-
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).
-
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.
-
-
vargalex
Topikgazda
Nyilván ennyi támogatott vas esetén több ezer issue várható. Ez teljesen normális.
A 2FA LuCI logint én is rétegigénynek mondanám.A LuCI csak belső hálózatról történő elérése egyáltalán nem probléma. Sőt, csak onnan érhető el (mint egyébként minden, így az SSH is) alapból. De természetesen az SSH nyitása után SSH tunnel-en keresztül nem probléma bármilyen belső szolgáltatás elérése.
Legalábbis én ezt értettem meg a hozzászólásodból.#21587 cree: az OpenWrt-t jellemzően nem drága vasakon futtatják, szóval megint nem értem, hogy miről beszélsz...
-
-
-
vargalex
Topikgazda
válasz
ssgt1981
#21565
üzenetére
Pedig annyi, amit korábban is írtam: "Ha bekapcsolod a PPPoE Passthrough-ot a Telekom eszközben, akkor amint az Asus routeren beállítod a WAN interface protokollt PPPoE-ra, megadod a bejelentkezési adatokat, akkor máris mennie kell a netnem az Asus-ra csatlakozott eszközökön."
A dupla NAT egyébként a kimenő kapcsolatot általában nem zavarja, akkor okoz gondot, ha kívülről kell a te eszközödet elérni.
-
vargalex
Topikgazda
válasz
ssgt1981
#21560
üzenetére
Ha DMZ-t akarsz, akkor a Telekom routert az Asus WAN portjába kell kötni. De nem kell ide AI... Ha bekapcsolod a PPPoE Passthrough-ot a Telekom eszközben, akkor amint az Asus routeren beállítod a WAN interface protokollt PPPoE-ra, megadod a bejelentkezési adatokat, akkor máris mennie kell a netnem az Asus-ra csatlakozott eszközökön.
Amit viszont nem nagyon értek: folyamatosan azt írod, hogy az Asus-on akarod DMZ-be tenni a Telekom routert. De ilyet biztos nem kell csinálnod, legfejlebb a Telekomon kell DMZ-be tenni az Asus-t, ha nem akarsz PPPoE Passthrough-ot.
Természetesen az is megoldható, hogy minden a 192.168.0.x-en legyen. Ekkor érdemes az Asus-t switch módba konfigurálni. Akkor a Telekomos eszköz lesz a DHCP szerver is, az Asus csak wifi-t szór. Minden attól függ, hogy mit szeretnél.
Egyébként vannak olyan Telekomos eszközök, amik kötelezően a Telekomos eszközhöz kell, hogy csatlakozzanak?
Egy a lényeg: az első lépés az, hogy el kell dönteni, milyen hálózati topológiát szeretnél megvalósítani.
-
vargalex
Topikgazda
válasz
ssgt1981
#21539
üzenetére
Ahogy a többiek is írták, a PPPoE passthrough a triviális megoldás. De az sem feltétlenül ördögtől való, hogy a szolgáltatói eszköz építi fel a PPPoE kapcsolatot. Ekkor az OpenWrt eszközt én switch-ként konfigurálnám, hogy ne legyen dupla NAT. Ekkor bármelyik eszközbe/eszközre csatlakozott eszközök azonos hálózatba tartoznak.
-
vargalex
Topikgazda
válasz
PistiSan
#21516
üzenetére
Felajánlottam azt is, hogy folytassuk a beszélgetést egy mindkét fél által többé/kevésbé beszélt nyelven (pedig lehet, hogy szembe megy a fórum irányelveivel). De erre még csak nem is reagált.
Azt továbbra is tartom, hogy senki nem személyeskedett, nem bántotta meg a topictársat a fogalmazás/nyelvi nehézségek miatt, csak rákérdezett/rákérdeztünk a nyilvánvalóra.
A megérthető információk alapján tényleg mindenki segíteni próbált a legjobb tudása szerint. A legutóbbi hozzászólásom is egy magyarázat volt, erre megkapjuk ezt... -
vargalex
Topikgazda
Ne haragudj, de kérhetném, hogy inkább valamelyik általad jobban beszélt nyelven próbáld meg leírni, mert ez így teljesen értelmetlen. Tippen szerint ennél jobb fordítást ad egy google fordító.
De azért próbálok értelmesen is válaszolni: még szerencse, hogy a különböző developer board-ok különböző IP-t kapnak. Éppen az azonos IP lenne hibás működés.
A beragadásról ismét csak ezt tudom írni. Nem beragad, hozzá rendelte az IP címet. -
vargalex
Topikgazda
Szerintem itt félreértés/tévedés van részedről és a linkelt thread-ba író emberek részéről is. A thread-ban említett lenyíló listában nem csak a dhcp lease-ek jelennek meg, hanem többek között az ARP én IPv6 neighbour táblákban, wifi association list-ben, stb található eszközök. Szóval, ez egy jóval nagyobb lista éppen azért, hogy tudj static lease-t rendelni egy eddig nem ismert eszközhöz is.
De továbbra sem értelek. Az eredeti problémád az volt, hogy mindig más IP-t kap a fejlesztői board-od. Ez azóta kiderült, hogy nem így van. Ha nem így van, akkor minek nézegetni a DHCP lease listát?
-
vargalex
Topikgazda
Nagyon jól sikerült megtalálnod, ahol leírják ugyan azt, amit én, csak angolul: "Note that just because a device is no longer connected does not mean that the lease is stale -- it's only actually stale after it has expired. (for example, the default lease time is 12 hours; even if a device connects just for a minute and then is disconnected, the lease is still valid for the full 12 hours since it was issued)."
Tényleg nem írom le már többet: attól, hogy egy eszközt kikapcsolsz, a lease még nem szűnik meg! És ez nem OpenWrt esetén, hanem minden DHCP szerver esetében így normális! Ezért hívják lease-nak. Ez nem az aktív eszközök, hanem az érvényes lease-ok listája!
-
vargalex
Topikgazda
Még egyszer megpróbálom leírni: az Active DHCP Leases listából csak akkor fog eltűnni egy kliens, ha szabályosan DHCP release-t küldött, vagy lejárt a lease time. Ennek így is kell működnie!
Egy wifi hatókörből kilépő, vagy tápellátást tovább nem kapó kliens jellemzően nem fog release-t küldeni, de abban sem vagyok biztos, hogy wifi kikapcsoláskor még elküldi-e.Az Associated Stations listában én minden kliensnél látok IP címet, pedig 23.05.5-ön vagyok. Akkor tud szerintem ilyen előfordulni, ha nem DHCP-n kérnek IP-t, hanem statikus IP van raktuk beállítva. Vagy, ha ez az eszköz egy repeater, de akkor minden kliens úgy jelenne meg.
-
vargalex
Topikgazda
Ezt próbáld meg még egyszer leírni kérlek. De azért megpróbálom értelmezni:
1. Ha a MAC cím azonos, akkor a dnsmasq nem tud más IP-t kiosztani DHCP-n, mivel a MAC az elsődleges azonosító. Így a DHCP listában biztos, hogy nem láthatsz azonos MAC címeket...
2. A DHCP rezerválásokat file-ban tartja (/tmp/dhcp.leases), ami egyébként RAMDISK, de az alkalmazás erről nem tud, de mindegy is, mert ugyan úgy filerendszer. Ami így nyilván egy újraindítás esetén elveszik.
3. A túl nagy overhead miatt egyik DHCP szerver sem ellenőrizgeti, hogy egy kliens él-e még. Azért sem, mert lehet, hogy 1 perc múlva jön, minek szabadítsa fel az IP címet. És az első pont miatt ugye ugyan azt az IP-t fogja kapni. És egyébként is erre való a lease time lejárata (amit egyébként tudsz konfigurálni), ami után eltűnik a listából az eszköz. A lejárati időt látod is a LuCI Állapot->Áttekintés oldalán.
4. Nem értem, hogy mi a problémád, ha most pedig azt írod, hogy azonos a DHCP-n kiosztott IP cím.
Csak jelezném, hogy ez volt az eredeti problémád: "Mivel nagyon zavaró ha inditasz egy wifis fejlesztö modult aminek mindig uj ip cime van és keresgélsz melyik él a listában ez nagyon zavaró! "Akkor most új IP-t kap, vagy nem?
OpenWrt alatt az aktív DHCP bérleteknél valóban a DHCP lease-okat fogod látni. Ha az adott eszköz nem küld DHCP release-t, akkor innen csak lejáratkor fog eltűnni bármi. Ha te wifi-s eszközökkel dolgozol, akkor nézd inkább ugyan ezen az oldalon a Vezeték nélküli kapcsolat alatt a csatlakoztatott eszközök listáját. Ott csak az aktív wifi klienseket látod IP címmel együtt.
-
vargalex
Topikgazda
Mert nem küld a kliens DHCP release-t. Így az a lease time lejártáig valóban hozzá van rendelve, tehát ez a helyes működés. Itt a hibát inkább a wifis fejlesztő modulban kell keresni. Az, hogy nem küld release-t érthető, mert gondolom egyszerűen megszűnik a tápellátása. Az érdekesebb inkább az, hogy miért generál magának mindig új MAC címet? Pl. az ESP lapok nem teszik ezt. Ha nincs firmware-ha rögzített MAC címe, akkor gondoskodj te kódból fix MAC címről.
-
vargalex
Topikgazda
válasz
Viperator
#21446
üzenetére
Ahogy az általam linkelt github oldalon szépen le van írva, forrásból kell build-elni. Azért nem megy a v1 verzió a v3-as eszközön, mert más platform.
Az segít, ha build-elek neked egy firmware-t v3-ra, ami tartalmazza a csomagot? Vagy elég csak maga a csomag? Ha firmware kell, akkor az alap csomagokon kívül csak ez kellene bele?
-
vargalex
Topikgazda
válasz
xabolcs
#21444
üzenetére
Ha jól látom, itt a forrás. És build-elhető is.
#21443 Viperator: Az alap OpenWrt telepítésben nagy varázslatot nem látok, annyi, hogy TFTP-n lehet felrakni.
Szerk.: A Hubai Zoltán név nekem valahonnan nagyon ismerős (Nem a te neveddel keverem...
). Persze az lehet, hogy csak wigyori-ra (Herpai Zoltán) asszociáltam. Ő ugye OpenWrt fejlesztő. -
vargalex
Topikgazda
válasz
Petikeje
#21414
üzenetére
Ha egy újraindítás nem segít rajta, akkor akár hardware probléma is lehet.
Nekem van egy Linksys WRT3200ACM-em, ami csak a dobozában pihent (összesen volt kb. 2 hetet használva). Legutóbb, mikor elővettem, nem ment az 5 GHz-es wifi. De annyira, hogy a gyári firmware-t visszatéve az össze is dől és újraindul (kikapcsolt rádió esetén is, tehát gyári firmware-val teljesen használhatatlan az eszköz). Nem volt időm foglalkozni vele, hogy mi lehet a problémája. Munkához kellett, a wifi nem volt lényeges. Azóta ismét a dobozában pihen. -
vargalex
Topikgazda
-
vargalex
Topikgazda
válasz
PistiSan
#21394
üzenetére
Szia!
Jól érted. Az olyan extra scripteket, config-okat, amiket a
sysupgradesorán meg szeretnél őrizni, azokat a /etc/sysupgrade.conf-ba kell felsorolni.Szerk.: De, ahogy xabolcs is írja, a sysupgrade.conf file feljécében olvasható is.
-
-
#21380
vargalex
Topikgazda
E.Kaufmann
#21379
vargalex
Topikgazda
válasz
E.Kaufmann
#21379
üzenetére
Tökéletesen tisztában vagyok a SoC-al. De! Anno még az offload előtti időkben is tudott ilyen sebességet a router, így Soft offload-al többet kellene tudnia. Igaz, ahogy írtam, a kernel bonyolultabb lett, így bármi lehet.
Illetve attilav2 topictárs egy Archer C7 v5-el közel gigabitet mért szintén PPPoE neten. Annyival pedig nem erősebb a SoC: 750 MHz vs. 560 MHz, architektúra azonos. Persze ki tudja, lehet, hogy számít ennyit. -
-
#21336
vargalex
Topikgazda
E.Kaufmann
#21335
vargalex
Topikgazda
válasz
E.Kaufmann
#21335
üzenetére
Egy rádiós egység lehet egyszerre kliens és AP is. Nem kell ehhez semmilyen külön program. Én ezt azért nem vetettem fel, mert úgy láttam, hogy a kolléga érti, mit szeretne és nem szeretné felezni a wifi sebességet.
-
vargalex
Topikgazda
Hogy kötötted össze a két routert? Vagy hogy van konfigurálva az OpenWrt?
Ha az interface-nál kikapcsolod a DHCP-t, akkor nincs az az Isten, hogy az OpenWrt osszon IP címet! Ha LAN-LAN kötöd össze, akkor pedig (ha már él a Telekom router DHCP szervere) szintén nem indul el, hacsak nem force-olod. -
vargalex
Topikgazda
Milyen DHCP-t nem tudsz letiltani? A LAN interface-nál próbáltad? Egyébként, ha engedélyezve is van és a két eszköz LAN-LAN van összekötve, akkor ha már fut egy DHCP szerver a hálózaton, az OpenWrt nem indít még egyet. Hacsak nem force-olod...
-
vargalex
Topikgazda
Na, ennyire szoktam nézegetni a LuCI-t.
Szerintem nem csak a CPU-n átmenő forgalmat mutatja. Hiszen alap konfiguráció szerint az a WAN-LAN forgalom lenne. Ha nincs bekapcsolva a HW NAT, akkor annak viszont mindnek meg kellene jelennie. Nálam nincs bekapcsolva sem a SW, sem a HW NAT, viszont:
Ilyen viszont nem fordulhatna elő... Felfelé több a LAN portok forgalma, mint a WAN porté, lefelé viszont jóval kevesebb.
Mondjuk a bridge forgalma sem stimmel:
-
vargalex
Topikgazda
A @wan-t beraktad a wan tűzfal zónába?
A wiki-ben található leírásból a végén található "If the WAN L2 device doesn't match L3 device like in case of PPPoE, change the modem interface." részt megcsináltad? Ugyanis az éppen érint téged... -
vargalex
Topikgazda
Milyen IP címmel hoztad létre a @wan interface-t, mi a modem IP címe és mi a saját LAN-od IP tartománya? Statikus route-ok nincsenek beállítva?
Egyébként nálam One (volt Vodafone, előtte UPC) HGW van bridge módban. Nincs @wan interface definiálva, a modemet elérem a 192.168.100.1-es IP-n. Hiszen a router úgyis a WAN felé tolja ki a csomagot, a HGW (legalábbis az One-os) pedig jól fogadja is...
-
vargalex
Topikgazda
válasz
Headless
#21258
üzenetére
Én sem szoktam
touch-ot betenni, csak linkeltem a wikiben található "hivatalos" megoldást.
Ott szépen meg is van magyarázva a miértje: induláskor asysfxtimea/etc-ben található utoljára módosított file módosítási időpontjára állítja be.a rendszeridőt. Ezzel atouch-al el lehet kerülni, hogy esetleg egyrebootután rögtön ismét újraindítást végezzen a cron, ezzel végtelen újraindításba kerülve. -
Nálam a szerver általában headless megoldást jelent.
Új hozzászólás Aktív témák
Hirdetés
vargalex- Víz- gáz- és fűtésszerelés
- 4K vs 8K – Megéri-e a 8K TV 2026-ban?
- A jövőben nem csak a gazdagok kiváltsága lehet az Intel CPU-k tuningja
- Milyen notebookot vegyek?
- Sci-fi
- Mesterséges intelligencia topik
- Kertészet, mezőgazdaság topik
- Konzolokról KULTURÁLT módon
- Crimson Desert
- Villanyszerelés
- További aktív témák...
- MS SQL Server 2016, 2017, 2019
- Játékkulcsok olcsón: Steam, Uplay, GoG, EA, Xbox stb.
- Eladó jogtiszta, Windows 11/10, Office 2019/2021/2024, Fizikai és Digitális licencek, Számlával.
- Játékkulcsok ! : PC Steam, EA App, Ubisoft, Windows és egyéb játékok
- Kaspersky, BitDefender, Avast és egyéb vírusírtó licencek a legolcsóbban, egyenesen a gyártóktól!
- GAMING PC! Intel i5-12400F / RTX 4060 Ti / 16GB DDR4 / H610 / 512GB NVMe / 600w! BeszámítOK
- iPhone 11 Pro 64GB 100% (3 hónap garancia)
- Xiaomi Redmi 13C 6/128GB fekete / 12 hó jótállás
- GYÖNYÖRŰ iPhone 13 128GB Green -1 ÉV GARANCIA - Kártyafüggetlen, MS4495, 100% Akkumulátor
- HIBÁTLAN iPhone 11 128GB White -1 ÉV GARANCIA - Kártyafüggetlen, MS4258
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest