-
IT café
OpenWrt topic
Új hozzászólás Aktív témák
-
kutga
félisten
válasz
trance89
#20927
üzenetére
Úgy látom az én Cudymra is elérhető már a 24.10.0, jelenleg 23.05.5 verzió fut rajta. Ha frissíteni szeretném, akkor jól gondolom, hogy elég betallózni a letöltött Sysupgrade image fájlt, és az openwrt webes felületéről telepíteni? Valamiféle visszaállítást érdemes csinálni, előtte és/vagy utána?
-
.-..-.
tag
válasz
attilav2
#20929
üzenetére
Igazabol nekem csak a kabeles reszre kell Router, mert van egy Mikrotik AP-m, ami megoldja az 5GHz Wifi kerdest a telefonokhoz/tabletekhez. Es egy n66u router switc-kent hasznalva a mikrokontrollerek 2.4GHz-e miatt elhelyezve nagyjabol a terulet kozeppontjan.
Tarsashaz leven iszonyu sok Wifi van es minden egyeb helyen kabel van nalam a stabilitas miatt. Gigabitre kabeleztem anno (CAT5E) minden helyiseget.
Emiatt tovabbra is ugy gondolom, kenyelmesebb volna az x86 vonal. Nagyobb szabadsagot ad a varialassal, nem kell foglalkoznom vele, hogy eleg eros-e a cpu, megy-e rendesen a hw offload, stb. -
adika4444
addikt
válasz
xabolcs
#20924
üzenetére
Köszi a választ! Úgy néz ki, HW offload nélkül jobb, de fura, mert a MikroTik hAP ac3-mal is hasonló a jelenség.
Offload nélkül meg az MT7621 nagyon gyenge önmagában.
Agyalok egy GL.iNet GL-MT6000 beszerzésén, ahogy elnézem, ez gyakorlatilag HW offload nélkül is képes lenne elbánni a nettel és szerintem megoldaná a problémámat.
-
attilav2
őstag
válasz
.-..-.
#20925
üzenetére
Esetleg egy Archer C7v5 beszerzése használtan(hátha a realtek kártya jó barátságban lesz a qualcomm routerrel), ha visszaolvasol akkor az egyik korábbi hozzászólásomból láthatod hogy majdnem teljesen kihajtja a gigabitet 23.05.5-el, illetve az Archer C7v4 is kis hackeléssel (archattila leírja egyik hozzászólásában, illetve neki megfelelő beállításokkal 24.10 alatt is vitte a gigabitet megfelelő beállításokkal). Ez áthidaló megoldásként szóbajöhet míg egy combosabb routerre össze nem jön a pénz, pl GL.inet Flint2.
-
válasz
trance89
#20927
üzenetére
Lattam, igaz csak ma reggel raktam fel Attended Sysupgrade -el es hat nagy meglepetesemre a WAN / PPPoE nem tudott csatlakozni. Szerencsere upgrade elott (is) mindig csinalok egy teljes config backup-ot, szoval egy config restore utan a friss rendszeren is minden ugy mukodik mint elotte..
-
devast
addikt
válasz
.-..-.
#20925
üzenetére
Nem tudom hasznalhatoak-e, de en tavol tartanam minden broadcom dologtol. Szimplan az uzletpolitikajuk miatt. intel 2.5g-s kartyak nagyjabol mukodnek, (i226-v), az elso revizioik katasztrofak voltak (i225- v1 - v3). Nekem konkretan a realtek-el sincs bajom (azon kivul, hogy aspm-et le kell tiltani), bar nem hasznalok 2.5-ös (rtl8125) verziót linux alatt. Mas "olcso" nic nagyon nincs.
-
.-..-.
tag
A jelenlegi AC65P routeremtol fuggetlenul, egy sajat x86_64-alapu routert csinalok.
Amolyan kivancsisagbol, mert kezd erdekelni a Linux halozatkezeles melyebben az eddigi ismereteimhez kepest.
Illetve szeretnek sajat szabalyokat alkalmazni a halozatkezelesnel es ugy gondolom az x86 vonal eleg eros es konnyebben beszerezheto vonal lenne ehhez.
Azt mar elhataroztam, hogy nem Realtek lesz a halozati vezerlo.
Az irant erdeklodnek, hogy az Intel ketportos kartyai mellett/helyett mennyire hasznalhatoak a Broadcom ketportos kartyai?
Van esetleg valami ismert problema, ami esetleg rossz valasztassa tenne egy ilyen kartyat Linux hasznalathoz? -
adika4444
addikt
válasz
adika4444
#20922
üzenetére
Küzdöttem a gonddal és furcsa mód akkor jön elő igazán, ha aktív a HW offload. HA inaktív, akkor az iperf3 mérés 200 Mbps fölé is megy (offload-dal 100 a teteje), viszont offload nélkül azért szépen látszik a CPU-terhelés, offloaddal meg marad 0, de valahogy még is megáll a sebesség.
Tesztelek majd egyet MikroTik-kel, kíváncsi vagyok, az jelenleg mit fog produkálni, a korábbi eredmények pár hónaposak, ezek szerint változhatott valami a képletben.
MT7621-es platformon ez amúgy ismert hiba? Olyat láttam, hogy PPPoE-val nem az igazi a HW offload, de ezek régebbi posztok voltak.
-
adika4444
addikt
Hali!
Már emlegettem korábban is ezt a problémát, de azóta is fennáll és azóta is szeretnék a végérejárni, mert iszonyat idegesítő.
Van nekem egy gigabites One (ex DIGI) FTTH internetem, és mögötte egy ASUS RT-AX53U OpenWRT-vel, de előtte volt már Ubiquiti EdgeRouter ER-X (chipset mondjuk ugyanaz az MT7621), szintén owrt-vel.
A problémám és ezt főleg külföldi desztinációkon tapasztalom (hosszabb trace, magasabb késleltetés), hogy a router mögött lévő munkaállomásokon az egyszálas TCP és UDP sebességg számottevően lassabb, mint a routeren. Van több OVH, netcup és egyéb szerverem, VPS-em és kivétel nélkül azt tapasztalom, hogy ha pl. iperf3-mal mérek, Wireguard VPN-ben csinálok bármit vagy épp SCP-vel másolok, sokkal lassabb egy Windows, Debian laptopon kábelen és wifi-n, vagy telefonon, mint akkor, ha a routerről megy a mérés, a routeren SCP-zek vagy a routeren van a Wireguard alagút vége és a mögötte lévő klienseket a router NAT-olja a VPN-hez.
Ha közvetlen laptopon építek PPPoE-t, akkor igazán hasít minden, a routernél mindig azt látom, hogy a CPU-ból fogy ki, ha rajta megy az iperf3, VPN etc. Belföldi célokon ezt kevésbé tapasztalom, bár itt is jellemző, hogy a gigabitet sehová nem tudom kimérni, 500--600 Mbps körül tetőzik. Volt már próbálva MikroTik routerrel is, de hasonló a hibajelenség. Próbálkoztam azzal, hogy a MTU-t állítgatom a PPPoE interfészen, de szintén nem segít, meg a routeren nézve jó amúgy is a sebesség.
Röviden összefoglalva tehát a problémám az, hogy ezen a DIGI végponton, ha NAT-olt IPv4 hálózat és router mögötti (az nem NAT-olt) IPv6-ról próbálok csinálni valamit, az meglehetősen lassabb, mint közvetlen a PPPoE-t felépítő eszközön.
Amit eddig próbáltam:
- Elvittem a routert egy Telekomos giga/giga végpontra, nem tapasztaltam a hibát.
- Bedugtam a laptopom a környéken egy DIGI-s eszközbe, az router módban van és ugyanez a szomorú eredmény.
- Csekkoltam teljesen másik fejállomáson lévő DIGI végponton, hasít minden hibátlanul és ezt a régi DIGI topikban is lejátszottuk, ott is többnyire jó eredmények voltak, de 1--2 ember azért szintén belefutott ebbe.Valami gond tehát a routolás / NAT-olás frontján lehet, de lövésem sincs, hogy mi. Talán MTU?
Ha valakinek van valami ötlete, mindenképp ossza meg, mert ez egy hosszú évek óta fennálló probléma. Zavart eddig is, de most már főleg, hogy közvetlen kapcsolódva és másoknál látom, hogy milyen jó lett az One-nal a külföldi peering, tehát a probléma biztosan nálam van, vagy a végponton, vagy a fejállomáson, de sajnos az ügyfélszolgálat ezzel eddig nem igazán tudott mit kezdeni.
-
adika4444
addikt
válasz
.-..-.
#20898
üzenetére
Mindenképp jó volna tesztelni valami mással. Ez az r8168 az MT7621-gyel nálam sem igazán jött ki jól, ilyen link down-up köröket tolt, néha naponta, néha hónapokig semmi. Nem tudom, mi okozta, nálam az lett a megoldás, hogy kidöglött a gép, amiben ez a chip volt.
Én is raktam kernelmodult, cserélgettem a kábeleket, de semmi, nem tudtam elérni a hibamentes működést.
-
.-..-.
tag
válasz
vargalex
#20916
üzenetére
Nem fogod elhinni mi volt a hiba ...
Persze user error
Semmi OpenWRT, az teszi a dolgát rendesen.Az volt a gond, hogy telepítés közben (arch-chroot /mnt) írtam meg a /etc/resolvconf fájlt, még a legelső normál boot folyamat előtt.
Azt viszont nem tudtam, hogy ilyenkor a systemd-resolved felülírja egy saját, nagy semmi konfiggal.
Így csak éppen a nameserver, ami esetemben a router, na az hiányzott.
A vicces az egészben, hogy mindeközben csomagokat tudtam telepíteni a repo-ból és ping esetén is működött valahogy a névfeloldás.
Nem látom át a miérteket sajnos, de az valamiért gondolom a /etc/systemd/network/20-wired.network konfigot használta.
Ott a Gateway és DNS is a router IPv4 címe.
De ami a resolvconf-ra támaszkodott, az elvérzett.
Oda is beírva a nameserver RouterIP címet, helyreállt a rend. -
vargalex
Topikgazda
válasz
.-..-.
#20915
üzenetére
A linkelt oldal TCP-n ellenőriz (UDP-n nem is tud). Pont ezt tudnád ellenőrizni telnet-el is. Az nginx is TCP-n hallgat.
Nem lehet, hogy valami blokkolja az UDP forgalmat? UDP-t többféle módon is tudsz ellenőrizni. Én lehet, hogy az iperf3-at preferálnám. Elindítanám a szerveren szerver módban, és egy külső gépről megpróbálnám a klienst futtatni.#20914 .--..-. Nem volt egyértelmű, hogy nem ugyan arról a szerverről van szó...
-
.-..-.
tag
válasz
.-..-.
#20914
üzenetére
Egy olyan jellegű trükköt most megcsináltam, hogy
- qbittorrent leállít
- nginx felrak
- nginx konfigolva 20000 portra
- nginx látható intranetről/internetről (az ISP-től kapott IP-t használva)Ergo a Port Forward működik.
Vagyis nem OpenWRT gond.
A hiba tehát már a PC-ben van.Vicces, ha itt a saját IP-m és a 20000-t csekkolom, akkor minden rendben és azonnal meg is lesz a torrent-kliensben a várt Connected Status.
Bár nem tudom ez így mennyire valid, mert tracker oldalon nincs nyoma. -
.-..-.
tag
válasz
vargalex
#20913
üzenetére
Amiről a linux haladóban írtam, az egy VPS. Azon természetesen mindenféle védelmet állítok, mert "megtalálják zsiványok", mivel több domain is van hozzá.
Amiről most szó van, az a "házi-szerverem", az amivel küzdök már egy ideje.
A LAN eldobós, folyton úratelepítős, VPN-el leállós, Port Forward-dal nem működős.
Hisz tudodA telnet-es dolgot nem ismerem.
A router éppen használatban van, asszony még aktívan dolgozik. -
vargalex
Topikgazda
válasz
.-..-.
#20912
üzenetére
A linux haladó topicban azt írtad, hogy van ufw...
LAN-ról tudsz csatlakozni telnettel a szerver 20000-es portjára? A HW NAT-nak ehhez nincs köze.Esetleg privátban nem tudsz adni valamilyen távoli hozzáférést (mondjuk SSH) a routerhez? Adok IP-t, tehát nem kellene a teljes netről megnyitni. Persze, ha csak megbízol bennem...
-
.-..-.
tag
válasz
vargalex
#20911
üzenetére
Na ... visszatérve az alapokhoz.
Port ForwardAkkor vagyon egy új OS és systemd-networkd/resolved beállítva.
A PC a 192.168.100.100 IP címet kapja.
Ugyan az OpenWRT-ben a DHCP-ben beállítottam, hogy az adott MAC-Address esetén mindig ezt adja neki, de a szerveren is statikusra vettem ugyanezt az IP-t neki.Namost a szokott módon a Port Forward be van állítva a 20000 portra, de mégsem lesz aktív a torrent kliens kapcsolata, pedig ott is ugyanez a port van ismét beállítva.
Nem rakott az ISP-m NAT mögé, mert ugyanazt az IP-t látom a Router-ben és a WhatIsMyIP-n is.
A PC-n nincs felrakva még az ufw sem, tehát minden port nyitott.
Az IP-cím is klappol, mert különben az ssh sem találna oda.Így mutat az OpenWRT:
Mi lehet a gondja, hogy torrent kliensben a "Connection status: Firewalled" rémséget mutatja?Feltételezem nem a Router-ben beállított HW-NAT okozza a hibát. Legalábbis remélem.
-
vargalex
Topikgazda
válasz
.-..-.
#20910
üzenetére
Nem lehet, hogy éppen a névfeloldás állt meg nálad? Az
openresolvcsak opcionális függősége awireguard-tools-nak és ahogy a linkelt bejegyzés is mutatja, megysystemd-resolved-el is (sőt, az az ajánlott), csak fel kell tenni asystemd-resolvconf-ot.
Sőt, konkrétan a linkelt bekezdés kiemeli aNetworkManager-t, hogy az ugye alapból nem használja aresolvconf-ot, így megállhat a névfeloldás (lehet, hogy ez történt korábban is nálad). És ez ugye csak akkor probléma, ha a teljes forgalom awireguard-on van keresztülzavarva.
A wiki-t mindig érdemes átnézni. De ez már lassan inkább az Arch topicba való, hiszen régen nem az OpenWrt-ről beszélünk.A portforward-nak működnie kell, ha nincs tűzfal a szerveren, illetve ha publikus IP-t kapsz a szolgáltatótól (azaz a WAN IP-d egyezik pl. az itt láthatóval).
Én egyébként
systemd-networkd-t használok a szerveren. DesktoponNetworkManager-t.Szerk.: De nem kell ám mindig új install...
-
.-..-.
tag
válasz
vargalex
#20909
üzenetére
Már nem vagyok biztos semmiben
Nekem elég érthetetlen, hogy VPN nélkül például miért nem volt például portforward, holott a routeren beállítottam.
Az sem tetszett, hogy a wg-quick-nek (wireguard-tools) kellett az openresolv és így tiltanom kellett a systemd-resolved-t.Simán lehet, hogy én szúrok el valamit, de akkor nagyon lépésenként kéne épitkezni.
Kezdve a LAN probléma kiderítésével.
Azt már elfogadtam, hogy egy ideig nem lesz a megszokott seed, majd megy, amikor megy.De akkor most visszatérek a kályhához...
- teljesen új install (Arch)
- systemd-networkd - a hálózathoz (talán Static ismét és nem DHCP)
- systemd-resolved - a névfeloldáshoz
- közvetlen kapcsolat a Router-szerver között, új CAT6 kábellal (eddig CAT5e volt)
- nem lesz VPN (egyelőre)
- lesz PortForward (egyelőre)
- lesz Samba (ez az egyetlen ami rendben is működött mindig)Aztán ha ezek mennek rendesen, akkor mennék tovább.
A LAN kapcsolat probléma mellet ezt a PortForward dolgot is ki kéne deríteni, mert érthetetlen, hogy miért nem működött.Egy kérdés amúgy:
Te (vagy más, aki foglalkozik ilyennel) milyen network-manager-t használsz szerver esetében a wired kapcsolathoz?
(NetworkManager, systemd-networkd, netctl ... etc) -
-
.-..-.
tag
Teljes katasztrófa ...
Arra jövök haza, hogy nagyjából 22 óra környékén megint leállt minden seed.
Sem a router, sem a szerver logban nincs semmi erre utaló jel. Nem mutat lan kapcsolat eldobást.A szerver logban ennyi látszik aból az időszakból:
Apr 16 17:00:12 server systemd[1]: Starting Cleanup of Temporary Directories...Apr 16 17:00:13 server systemd[1]: systemd-tmpfiles-clean.service: Deactivated successfully.Apr 16 17:00:13 server systemd[1]: Finished Cleanup of Temporary Directories.Apr 16 21:23:19 server kernel: perf: interrupt took too long (2509 > 2500), lowering kernel.perf_event_max_sample_rate to 79000Apr 16 22:27:05 server systemd-timesyncd[390]: Timed out waiting for reply from 81.0.124.253:123 (2.arch.pool.ntp.org).Apr 16 22:27:15 server systemd-timesyncd[390]: Timed out waiting for reply from 195.111.92.55:123 (2.arch.pool.ntp.org).Apr 16 22:27:25 server systemd-timesyncd[390]: Timed out waiting for reply from 62.112.195.56:123 (2.arch.pool.ntp.org).Apr 16 22:27:36 server systemd-timesyncd[390]: Timed out waiting for reply from 193.227.197.2:123 (2.arch.pool.ntp.org).Apr 16 22:27:46 server systemd-timesyncd[390]: Timed out waiting for reply from 193.227.197.2:123 (3.arch.pool.ntp.org).Apr 16 22:27:56 server systemd-timesyncd[390]: Timed out waiting for reply from 193.6.222.20:123 (3.arch.pool.ntp.org).Apr 16 22:28:06 server systemd-timesyncd[390]: Timed out waiting for reply from 213.157.100.71:123 (3.arch.pool.ntp.org).Apr 16 22:28:17 server systemd-timesyncd[390]: Timed out waiting for reply from 194.38.104.150:123 (3.arch.pool.ntp.org).A szerveren jelenleg nincs internet elérés sem, kizárólag az itthoni hálózat él.
Nem értem az egészet. Nem a VPN használat kavar be neki ennyire?
Lehet egy ideig VPN nélkül kellene kipróbálnom?Elméletileg futott a service, de egy "systemctl restart wg-quick@wg0" hatására visszajött a szerveren a net.
-
.-..-.
tag
válasz
vargalex
#20906
üzenetére
Természetesen nem. Különben az itthoni RasPi kliensek sem találnák meg a filmeket rajta
De most amúgy is már VPN mögött van, szóval nincs használatban a port.
Viszont nem értem miért nem akart működni. Mindegy, most már lepróbálni sem tudom, mert a wg0-t használja a torrent kliens.Még várom a Lan eldobásról a log-ot...
-
.-..-.
tag
válasz
vargalex
#20904
üzenetére
Természetesen. Nincs ufw sem (még) és a kliesben is az a port van beállítva és úgy tűnik a szolgáltató sem rakott NAT mögé.
Mondjuk most éppen a wg-quick (wireguard-tools) és a resolvconf (openresolv, függősége a wireguard-tools-nak) segítségével próbáltam VPN-t beállítani.
Nem látom, hogy azzal menne esetleg a dolog ...Update ...
Megjött a VPN kapcsolat a wg0-val. -
.-..-.
tag
válasz
vargalex
#20901
üzenetére
Az a reviziós LAN, a másik alaplapban volt.
Abban a miniITX lapban, amit most is használok és régebben is ezt használtam, olyan kártya van, mint a tiedben.03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8211/8411 PCI Express Gigabit Ethernet Controller (rev 11)Tegnap megpróbáltam systemd-networkd használattal beállítani a VPN-t, de nem sikerült.
Volt wg0 eszközöm, de nem működött valamiért. Talán rossz helyre írtam az értékeket a szolgáltató által adott conf fájlból, nem tudom.
Mivel nem sikerült systemd-networkd esetében bekonfigolnom a VPN-t, ezért letiltottam és a NetworkManager-t raktam fel. Azzal beimportálva működött a VPN.
Így ment egész éjjel és reggelre láttam a hibákat.Most újratelepítettem az Arch-ot ismét és VPN nélkül használom systemd-networkd megoldással. Így figyelem lesz-e valami hiba.
Arra számítok, hogy valamelyik oldalon lesz a logban bejegyzés.Most próbáltam a Router-ben PortForward-ot beállítani, de valamiért a torrent kliens tűzfal mögötti állapotot jelez.
Elrontottam valamit?
-
vargalex
Topikgazda
válasz
.-..-.
#20893
üzenetére
A systemd-networkd-nek natív wireguard támogatása van. De wg-quick-hez is van systemd service, nálam azzal megy.
#20894 devast: A kollégának nem a routeren fut a wireguard...
-
vargalex
Topikgazda
válasz
.-..-.
#20900
üzenetére
Sajnos olyan is előfordul, hogy 2 hálózati eszköz "inkompatibilis" egymással. Persze ezt akár ki is lőhetnénk, hiszen azt írtad, hogy korábban évekig nem volt vele semmi gond.
Viszont nyilván azóta cserélődött a kernel, így a kernel modulok is mind a router, mind a szerver oldalán. Esetleg meg lehet próbálni Arch-on egy LTS, vagy ZEN kernellel is, hátha változik a helyzet.Egyébként nekem ez a hálókártya van a mini szerveremben:
01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8211/8411 PCI Express Gigabit Ethernet Controller (rev 11)Tehát az, mint a tiéd, csak másik revízió. Nem használok AUR kernel modult. Korábban Atheros ar71xx routereim voltak, majd MT7621-esek, most Mediatek Filogic (természetesen mindegyik OpenWrt-vel), egyikkel sem volt problémám.
Ha Budapesten laksz, én is fel tudok ajánlani tesztre konkrétan Asus RT-AC65-öt is.
Még az lehet, hogy az AC-65P tápja, vagy belső tápáramköre haldoklik, így esetleg egy tápcserét is megpróbálhatsz.
-
.-..-.
tag
válasz
vargalex
#20899
üzenetére
Nekem ez az alaplap (pontosabban ez már a második ugyanilyen) olyan 5-6 éve van használatban. Eddig nálam sem volt semmi gond vele. Persze ettől még változhatott valami a kernelben, hogy most igen, de az akkor valami új dolog.
Bekötöttem a Switch-et az AC65P és a PC közé.
Próbából 2 perc eltéréssel kihúztam mindegyikből a LAN kábelt és a saját logjában mindegyiknek megjelent a művelet, de ugyanúgy 2 perc eltéréssel.
Így elsőre jó ötletnek tűnik ez, hogy kiderüljön mielyik oldalon van a hiba.Most várok...
de addig ...mindenképpen szeretném megköszönni az eddigieket Neked és a Többieknek is, akik foglalkoznak a "kis" nyűgömmel.
És sűrű elnézéskérés közepette szánom-bánom, hogy csak félig-meddig OpenWRT-vel kapcsolatos dologgal szemeteltem tele a topic-ot. -
vargalex
Topikgazda
-
.-..-.
tag
Teszt erejéig megoldható lenne egy másik hálókártya.
Ha az eredetileg használt mini-ITX alaplapnál maradok, akkor csak USB-s jöhet szóba, mert az egyetlen PCIe csatlakozóban egy 6 portos SATA kártya van.
Ha átköltöztetem egy nagyobb gépbe akkor mehetne bele valami Intel, azzal gondolom nincs macera.Amúgy felmerült bennem egy ötlet és egy kérdés...
Ha mondjuk a router és a gép nem direktben lenne összekötve, hanem beékelnék közé egy 4portos switch-et, akkor nem lehetne kiszűrni, ha hardveres gond van, az melyik oldalon történik?
Úgy értem ...
- ha a router dobja a portot, akkor a gép-switch között megmarad fizikailag
- ha a gép/realtek lan dobja a portot, akkor a router-switch között megmarad fizikailag
Ezt így nem lehetne a log-okból visszanézni?
Jelenleg, hogy direktben van összekötve, mindkét oldalon (router/pc) ott van a logokban a leállás. -
.-..-.
tag
-
.-..-.
tag
válasz
vargalex
#20889
üzenetére
Na, visszacuccoltam az eredeti mini-ITX alaplapra és telepítettem egy új OS-t.
Most nem használtam a networkmanager-t, systemd-networkd adja a netet és statikus IP-re álltam át.
Sikerült felrakni az r8168-dkms csomagot is és elméletileg most az van használatban.03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8211/8411 PCI Express Gigabit Ethernet Controller (rev 11)Subsystem: ASRock Incorporation Motherboard (one of many)Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-Latency: 0, Cache Line Size: 64 bytesInterrupt: pin A routed to IRQ 42Region 0: I/O ports at e000 [size=256]Region 2: Memory at ff900000 (64-bit, non-prefetchable) [size=4K]Region 4: Memory at fc800000 (64-bit, prefetchable) [size=16K]Capabilities: <access denied>Kernel driver in use: r8168Kernel modules: r8169, r8168Még ki kell találnom, hogy a Wireguard config fájlt, amit a szolgáltató ad, hogyan tudom ehhez használni.
-
.-..-.
tag
válasz
vargalex
#20889
üzenetére
Az mkinitcpio.conf fajlban atirtam a MODULES=(r8168) reszt es volt mkinitcpio -P , de ugyanaz van.
Ket masodpercenkent a LAN ledje az alaplapon ki/be kapcsol.
A log szerint valami 8168.fw-t nem talal.Sajnos azt hiszem tulmutat ez mar a kepessegeimen.
Most nincs halozat es mivel sikerult beleakadnom a billentyuzetem kabeljaba, most epp billentyuzetem sincs.Szoval ... azt hiszem rovid piheno a gepnek is es nekem is.
-
.-..-.
tag
válasz
vargalex
#20887
üzenetére
Az a helyzet, hogy akkor csak azt figyeltem, hogy megszakad-e a seed.
Akkor nem tette, ahogy ma reggel sem az 1-1 rövid leállásnál.
Az a rendszer már nincs meg, mert az ssd-t, ram-ot átraktam ebbe a lapba.
És igen, igazad van, akkor és ott a szerver logot kellett volna figyelnem, de nem tettem, mert a hibát nem tapasztaltam.Amúgy a dkms verziót tettem fel: [link]
Viszont tartok tőle, hogy valamit elszúrtam, talán a blacklist-et, mert most nincs kapcsolat a szerverrel.
Rövidesen keresek valami monitort és ránézek. -
vargalex
Topikgazda
válasz
.-..-.
#20886
üzenetére
Ha a wiki-n linkelt probléma van, akkor szerintem a szerver logban a szolgáltatói eszközt használva is látható kellett, hogy legyen link down üzenet. A korábbi szerveren ezt nem tudod ellenőrizni (ha emlékszel az időintervallumra, amikor a szolgáltatói eszközt használtad)?
Egy próbált megérhet a wikiben írt megoldási javaslat...
-
.-..-.
tag
válasz
vargalex
#20885
üzenetére
Ez a verzió van a routeren:
OpenWrt 24.10.0 r28427-6df0e3d02a / LuCI openwrt-24.10 branch 25.014.55016~7046a1cAz előzőre nem emlékszem, de azzal is ugyanez a hiba volt.
A szerver alaplapont pont a linkkelt hálókártya van:
2:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8211/8411 PCI Express Gigabit Ethernet Controller (rev 06)És az eredetileg használt mini-ITX alaplapon szerintem szintén: [link]
Lehet, hogy akkor ez okozza a problémát? -
-
.-..-.
tag
válasz
.-..-.
#20883
üzenetére
Közben most látom 08:19-kor megint volt egy LAN1 bontás:
Router:
Tue Apr 15 08:19:21 2025 kern.info kernel: [42045.202304] mt7530-mdio mdio-bus:1f lan1: Link is DownTue Apr 15 08:19:21 2025 kern.info kernel: [42045.212743] br-lan: port 1(lan1) entered disabled stateTue Apr 15 08:19:21 2025 daemon.notice netifd: Network device 'lan1' link is downTue Apr 15 08:19:24 2025 kern.info kernel: [42048.490837] mt7530-mdio mdio-bus:1f lan1: Link is Up - 1Gbps/Full - flow control rx/txTue Apr 15 08:19:24 2025 kern.info kernel: [42048.490934] br-lan: port 1(lan1) entered blocking stateTue Apr 15 08:19:24 2025 kern.info kernel: [42048.517115] br-lan: port 1(lan1) entered forwarding stateTue Apr 15 08:19:24 2025 daemon.notice netifd: Network device 'lan1' link is upServer:
Apr 15 08:19:21 server kernel: r8169 0000:02:00.0 enp2s0: Link is DownApr 15 08:19:21 server dhcpcd[404]: enp2s0: carrier lostApr 15 08:19:21 server dhcpcd[11737]: Dropped protocol specifier '.link' from 'enp2s0.link'. Using 'enp2s0' (ifindex=2).Apr 15 08:19:21 server dhcpcd[404]: enp2s0: deleting route to 192.168.100.0/24Apr 15 08:19:21 server dhcpcd[404]: enp2s0: deleting default route via 192.168.100.1Apr 15 08:19:21 server dhcpcd[11739]: Dropped protocol specifier '.dhcp' from 'enp2s0.dhcp'. Using 'enp2s0' (ifindex=2).Apr 15 08:19:24 server dhcpcd[404]: enp2s0: carrier acquiredApr 15 08:19:24 server NetworkManager[399]: <info> [1744697964.5759] device (enp2s0): carrier: link connectedApr 15 08:19:24 server kernel: r8169 0000:02:00.0 enp2s0: Link is Up - 1Gbps/Full - flow control rx/txApr 15 08:19:24 server dhcpcd[404]: enp2s0: IAID 80:52:84:3cApr 15 08:19:24 server dhcpcd[404]: enp2s0: soliciting an IPv6 routerApr 15 08:19:25 server dhcpcd[404]: enp2s0: rebinding lease of 192.168.100.100Apr 15 08:19:25 server dhcpcd[404]: enp2s0: probing address 192.168.100.100/24Apr 15 08:19:30 server dhcpcd[404]: enp2s0: leased 192.168.100.100 for infinityApr 15 08:19:30 server dhcpcd[404]: enp2s0: adding route to 192.168.100.0/24Apr 15 08:19:30 server dhcpcd[404]: enp2s0: adding default route via 192.168.100.1Apr 15 08:19:30 server dhcpcd[11747]: Dropped protocol specifier '.dhcp' from 'enp2s0.dhcp'. Using 'enp2s0' (ifindex=2).Apr 15 08:19:30 server systemd-resolved[318]: enp2s0: Bus client set DNS server list to: 192.168.100.1Apr 15 08:19:30 server systemd-resolved[318]: enp2s0: Bus client set search domain list to: lan, lanApr 15 08:19:36 server dhcpcd[404]: enp2s0: no IPv6 Routers available -
.-..-.
tag
válasz
vargalex
#20882
üzenetére
Nem emlitettem, de most egy gyari LAN kabelt hasznalok eppen a szerverhez. Amikor tegnap este ujrainditottam a router-t, akkor a kabelt is atcsereltem. Ezt a kabelt pont akkor hasznaltam, amikor az ONT router modban volt es jol mukodott.
Ez volt az ONT es a switch kozott.Anno az N66U-val kuzdottem, de amikor valtott a Digi optikara, akkor mar cserelnem kellett, mert nem birta NAT-olni a PPPoE 1Gb tempot.
Nem emlekszem pontosan miket produkalt, de valami meg volt a lassu tempo mellett. Ezert lett most Switch+AP belole.A NetworkManagert azert hasznalom, mert az nmcli paranccsal szoktam beimportalni a Wireguard konfigot (Proton VPN) es az csinalja meg a wg0 virtual kapcsolatot, amit aztan beallitok halozati eszkoznek a qbittorrent webui-ban.
Azt hiszem amikor Debian-t hasznaltam, akkor automatikusan ment fel, Arch eseteben en tettem fel.Esetleg rosszul csinaltam valamit?
-
vargalex
Topikgazda
válasz
.-..-.
#20881
üzenetére
Tudom, próbáltál másik LAN kábelt, de azért én egy olyannal is próbát tennék (ha van rá lehetőség), ami egy másik eszközön nem produkálja a hibát. Esetleg meg lehetne próbálni (szintén, ha van rá lehetőség), hogy az RT-N66U-ra kötöd a szervert.
Szerveren egyébként nem overkill a NetworkManager? -
.-..-.
tag
válasz
vargalex
#20880
üzenetére
Ez egy teljesen másik vas.
Az eredeti, amit használnék is szervernek, ahogy eddig tettem, egy mini-ITX lap, integrált CPU-val.
Most egy mATX alaplap van használatban valami s1155 cpu-val a foglalatban.
Szóval totál új vas.
És újratelepítettem az OS-t is. Régebben Arch volt, legutóbb Debian, most ment vissza az Arch.Köszönöm a sed tippeket.
-
vargalex
Topikgazda
válasz
.-..-.
#20879
üzenetére
Szia!
Az új szerver azt jelenti, hogy egy teljesen másik vas? Mert az akkor nagyon fura, ahogy az is, hogy mindig azt a portot dobja el, amire a szerver van kötve. Sajnos a logokból az nem derül ki, hogy melyik eszköz dobja el előbb.
A MAC cím törlése, ha a teljes MAC címet el akarod rejteni:
logread | sed 's/..:..:..:..:..:../xx:xx:xx:xx:xx:xx/g'Ha az első 3 tagot (ami a vendor) meg akarod tartani, ahogy tetted is, akkor:
logread | sed 's/\(..:..:..:\)..:..:../\1xx:xx:xx/g'Ez egy nagyon egyszerű módja, mert arra épít, hogy csak a MAC cím lesz ilyen formátumú (azaz 6x2 karakter köztük kettősponttal) a logban. Lehetne ezt valóban csak MAC cím formátumra engedni:
Teljes elfedés:
logread | sed -E 's/([0-9a-fA-F]{2}:){5}[0-9a-fA-F]{2}/xx:xx:xx:xx:xx/g'Vendor azonosítás meghagyásával:
logread | sed -E 's/(([0-9a-fA-F]{2}:){3})([0-9a-fA-F]{2}:){2}[0-9a-fA-F]{2}/\1xx:xx:xx/g' -
.-..-.
tag
Egy kis fejlemény ... (ha nem bánjátok, hogy "teleszemetelem" a topic-ot
)Tegnap este a szerver kábelt átraktam a LAN1 portba és 20:38-kor újraindítottam a router-t.
Az előző hozzászólásban látni, hogy eltűnt egy adag log és 20:39-nél kezdődik újra.Ma reggel ugyan nem láttam seed szakadást (vagy helyreállt már), de a LuCI-ban megnézve a Log-ot láttam, hogy a LAN1 port (most ebben van a szerver) 02:38-kor leállt, majd visszajött. Azaz 4 óra múlva, hogy újraindítottam a router-t.
Úgy látom csak 1x csinálta (többször szokta egymásután) és talán ezért nem szakadt meg a Wireguard (wg0) kapcsolat a szerveren.
Szerver oldalról is megnéztem a Log-ot és ott is látszik a LAN kapcsolat eldobás.Felraktam az AC65P újraindítása (20óra 38perc) óta keletkezett Log-ot pastebin-re.
Router log: [link]
Server log: [link]Kis segítség az AC65P portokhoz, DHCP-hez:
LAN1 - Server (192.168.100.100)
LAN2 - Yamaha erősítő
LAN3 - RT-N66U switch-ként és AP-ként (ESP cuccokhoz) távolabb az AC65P-től
LAN4 - Desktop PC(Amúgy van valami kultúráltabb módja a MAC Address törlésnek a log-ból, mint kézzel átírni?)
Lehet, hogy nem is az AC65P-vel van a gond?
Azért fura a dolog, mert láthatóan az a port áll le, amiben a szerver van, bármelyik gép is legyen használatban. Kábelt is cseréltem.
Az erősítő és az N66U szintén folyamatosan rá van kötve, ott nem figyeltem fel leállásra, de most figyelni fogom.
A desktop PC esetében pedig normális, hogy lekapcsolásnál offline lesz a port. -
.-..-.
tag
válasz
vargalex
#20876
üzenetére
Teljesen új kábel és most a LAN4 portban van.
Másik gép és másik rendszer. A szerver logban nem látok semmit a journalctl-el nézve, gyakorlatilag abban az órában az egyetlen bejegyzés az ssh csatlakozás.
A router log viszont ugyanaz csak most LAN4 néven fut az egész.
Három napig ment gond nélkül.xabolcs:
Elfelejtettem újraindítani a router-t a debug bejegyzéssel, csak most tettem meg, amikor eldobta a lan portot.
Mondjuk most vicces kicsit a luci-ban a router log, mert a reboot óta eltűnt egy jó adag bejegyzés.
-
xabolcs
őstag
válasz
.-..-.
#20875
üzenetére
Majd a proba topikba linkelt logread kimeneteket szivesen olvasom!
Illetve ha budapesti vagy, akkor tudok kolcsonadni mindenfele routert ramips/mt7621-tol kezdve a qualcommax/ipq807x-n keresztul a mediatek-ig.
De tovabbra sem vagyok meggyozve, hogy cserelni kellene a routeredet!
![;]](//cdn.rios.hu/dl/s/v1.gif)
Legyszives engedd, hogy segitsunk: valaszold meg vargalex es az altalam feltett kerdeseket! -
.-..-.
tag
válasz
.-..-.
#20872
üzenetére
Na, 3 nap uptime után ez a szerver is eldobta a lan kapcsolatot.
Nemrég történt, most kezdenek a seed-elt cuccok kifutni a frissítési időlimitből és váltanak "stopped" státuszra.Egyértelmű, a router adta meg magát, bár most elég sokáig bírta.
Azt hiszem nem lesz most időm küzdeni egy saját router összerakásával, úgyhogy vásárolok majd egy olcsó, OpenWRT képes komplet routert.
Még nem tudom milyet, de ötletet elfogadok, ha van.
(1Gb PPPoE-hez kell) -
PBA
aktív tag
Sziasztok,
OPENWRT-t próbálok telepíteni egy Banana PI R3-ra, de elakadtam. Oda vissza elolvastam mindent a neten, de nem jutok előrébb. A megfelelő IMG-t kiírtam SD-re, jumpereket beállítottam jól (mind felfelé), USB-TTL kábellel csatlakozom. Viszont akár PUTTY akár MobaXTermmel nézem, a kezdőmenüből nem tudom kiválasztani a 8-ast, semmilyen billentyűre nem reagál és megy tovább a boot folyamat, nem tudom megállítani. Cseréltem már SD kártyát, újból letöltöttem az IMG-t és kiírtam, stb. De ugyanaz a szitu. Már csak az USB-TTL kábelre tudok gyanakodni, de ha azzal lenne a gond, akkor talán egyáltalán nem lenne kapcsolat.
Találkoztatok már ezzel a jelenséggel? Mit ronthatok el? Nagyon köszönök bármilyen tippet. -
adika4444
addikt
válasz
.-..-.
#20868
üzenetére
Proxmox-ot nem ismerem, nálam egy alap Debian-on fut a Libvirt és Qemu párosa (viszonylag gyenge szerver és nem kell az overhead), de általánosságban a virtuális gépeket is elképzelheted az interfészeikkel mint egy-egy fizikai eszközt a switch-re kötve és így már könnyebb lehet elhelyezni. Kell csinálni egy bridge-t, mondjuk virbr0-t (azthiszem a ProxMox alatt is Libvirt szolgálja ki a Qemu/KVM gépeket), utána azt kell elérni, hogy a routeren lévő eth0 belekerüljön. Épp emiatt én az OpenWRT-n nem is hoznék létre bridge-t, ez X86-on szintén nem tudom fejből, hogy miként van, hanem azt a virtuális interfészt, ami az OpenWRT-n belül eth0, azt beraknám egy bridge-be a többi virtuális géppel és a szerver fizikai csatolójával. A másik csatolót meg, ami a WAN, átadnám valami passtrough-gal, talán úgy a legkisebb az overhead és a sebességvesztés.
Kb. mint egy kétportos fizikai router, egyik a WAN, a másik a LAN, LAN bemegy egy switch-be amin lógnak a virtuális gépeid. -
.-..-.
tag
válasz
attila.86
#20871
üzenetére
Köszönöm.
Már "elméletben" lejátszottam a folyamatot, utánanéztem a lehetőségeknek.
Viszont még ott tart a dolog, hogy az AC65P+OpenWRT kombót használom, egy másik gépre megcsinált szervert és új kábelt.
Tegnap estére sikerült "rendbetenni", most figyelem a működését.Ha újra lesz hiba, akkor router gond, ha nem lesz, akkor valószínű szerver hardver gond volt.
Utóbbi esetén a magic része érthetetlen lenne. Nevezetesen, akkor miért volt jó a szerver, ha az ONT router-módban volt és egy sima switch-et használtam az otthoni hálóhoz.
De még várok, hogy mi lesz a kifejlet a jelenlegi megoldással.
(másik szerver, másik kábel, eredeti router)
Egyelőre ennyire futotta. -
.-..-.
tag
válasz
vargalex
#20867
üzenetére
Igen, tisztában vagyok vele, hogy a lan2 és wan hibának nem kéne, hogy szoftveres köze legyen egymáshoz.
Simán lehet, hogy az AC65P táp vagy a router tápkör a probléma.
Az is lehet, hogy a "wan" probléma tényleg csak a "keepalive" gond volt, de nem ez okozta a seed leállást, csak ezen akadt meg a szemem a log-ban.
Mivel jelenleg nem tudom mit kellene lecserélni, egyesével kicserélem az alkatrészeket.Most nem tudom a router-t leállítani (home office), ezért a szervert lőttem le és rakom át másik gépre ideiglenesen és csináltam egy teljesen új cat5e kábelt is biztos-ami-biztos alapon.
Ha továbbra is hibázik, a gépcserével kizárnám a szerver oldali hardver hibát.
(új LAN, új LAN-kábel)
Mivel most reinstall is lesz (Debian már a probálkozás része volt, megy vissza az Arch) a szoftveres rész is más lesz, bár erre nem gyanakodnék, mert ONT-Router módban jól ment a jelenlegi Debian is.Az AC65P RJ54 érintkezőit megtisztítottam, szóval ezzel sem lehet már hibaforrás.
Rövidesen ezeket megcsinálom és várom a következő hibát.
Ha előjön összenézem a szerver log-gal.Router funkció:
Az nem világos, hogy ugyanazon a gépen VM-ben mondjuk megoldom a router-részt.
Ezzel például az eth0 bridge lesz és arra teszek egy switch-et és megy az itthoni net, az eth1 pedig a wan lesz, amit pppoe-vel használok.
Ez idáig rendben van, de nem tudom a másik VM-ben futó seed server hogyan kapcsolódik az eth0-hoz, ami a bridge (br0) ebben a felállásban?xabolcs:
Beállítottam, de most nem tudom újraindítani a pppoe kapcsolatot, pici türelmet kérnék.
Ha megtettem, akkor pár órát hagyom és az eredményt megosztom. -
vargalex
Topikgazda
válasz
.-..-.
#20860
üzenetére
A LAN2 megszakadásnak már végképp nincs semmi köze a WAN oldali beállításokhoz. Ugyan ebben az időpillanatban a szerveren mi látszik? Nem lehet, hogy döglődig a táp, vagy valamelyik belső kondi az AC65P-ben?
Én a router funkciókra úgy általánosan gondoltam, bámelyik linux alatt megoldható.
-
xabolcs
őstag
válasz
.-..-.
#20865
üzenetére
Legyszives noveld meg a "System log buffer size" legalabb 10 MByte-ra!
Legyszives kapcsold be (pl. WinSCP-vel, ha esetleg nem megy a nano vagy a vi) a "debug"-ot a pppd-nek a "/etc/config/network" fajl "wan" szekciojaban: pppd_optionsconfig interface 'wan'
option device 'lan1'
option proto 'pppoe'
option username 'DIGI username'
option password 'DIGI password'
option keepalive '80 20'
option pppd_options 'debug'
option ipv6 'auto'Ha ez megvan, akkor legyszives inditsd ujra a PPPoE kapcsolatot es varj nehany orat!
Utana legyszives futtasd le az alabbi "logread"-os parancsot, SSH-n keresztul (PuTTY, ssh PowerShell-ben) belepve a routerre:logread | grep -e pppd -e "$(uci get network.wan.device)" | grep -e 'LCP terminated' -e 'Connect: ' -e 'Connect time' -e "$(uci get network.wan.device)"
Az eredmenyt majd irdd meg!
-
.-..-.
tag
válasz
xabolcs
#20864
üzenetére
Igazából pár hónapja szivat napi rendszerességgel a router.
Most nekem is bridge módban van a ZTE, ezért használom a router-t.
Amikor a ZTE router módban volt, semmi bajom nem volt vele.
És pont ez itt a magic része a dolognak.
Természetesen beállítottam az említett paramétereket.
Most ez van : [link] -
xabolcs
őstag
válasz
.-..-.
#20849
üzenetére
(Ugyanis van egy tippem, hogy az AC65P esetében nálam a HW-NAT okozza a problémát)
Nekem is volt szerencsem ramips/mt7621-gyel DIGI optikai netet NAT-olni, s nem volt ilyen napi szakadasos bajom, amiota beallitottam az emlitett keepalive beallitasokat.
Nekem is ZTE modem van, de bridge modban. Most egy Dynalink DL-WRX36 van beallitva, de ahogy mar irtam, egy D-Link DIR-860L B1-gyel se volt semmi bajom.
Mar nagyon raporogtel az x86-os OpenWrt-re, vagy van ertelme megmutatnom, hogy semmi baj nincs az AC65P HW-NAT-javal OpenWrt alatt?
Mert akkor szivesen visszarakom a DIR-860L-emet par hetre.A ZTE modem kelloen stabil, bridge modban:
root@DL-WRX36-7DE ~ # logread | grep pppd | grep -e 'LCP terminated' -e 'Connect: ' -e 'Connect time'
Fri Feb 14 16:30:35 2025 daemon.notice pppd[4650]: Connect: pppoe-wan <--> lan1
Sat Feb 22 13:42:33 2025 daemon.debug pppd[4650]: rcvd [LCP TermReq id=0x2 "Connect time expired"]
Sat Feb 22 13:42:33 2025 daemon.info pppd[4650]: LCP terminated by peer (Connect time expired)
Sat Feb 22 13:42:33 2025 daemon.info pppd[4650]: Connect time 10136.4 minutes.
Sat Feb 22 13:42:34 2025 daemon.notice pppd[9655]: Connect: pppoe-wan <--> lan1
Mon Feb 24 12:56:15 2025 daemon.info pppd[9655]: LCP terminated by peer (Peer not responding)
Mon Feb 24 12:56:15 2025 daemon.info pppd[9655]: Connect time 2833.7 minutes.
Mon Feb 24 12:56:16 2025 daemon.notice pppd[15910]: Connect: pppoe-wan <--> lan1
Mon Feb 24 13:21:20 2025 daemon.info pppd[15910]: LCP terminated by peer (Peer not responding)
Mon Feb 24 13:21:20 2025 daemon.info pppd[15910]: Connect time 25.1 minutes.
Mon Feb 24 13:21:21 2025 daemon.notice pppd[18298]: Connect: pppoe-wan <--> lan1
Mon Feb 24 13:32:55 2025 daemon.info pppd[18298]: LCP terminated by peer (Peer not responding)
Mon Feb 24 13:32:55 2025 daemon.info pppd[18298]: Connect time 11.6 minutes.
Mon Feb 24 13:32:56 2025 daemon.notice pppd[20464]: Connect: pppoe-wan <--> lan1
Mon Mar 3 14:23:34 2025 daemon.debug pppd[20464]: rcvd [LCP TermReq id=0x2 "Connect time expired"]
Mon Mar 3 14:23:34 2025 daemon.info pppd[20464]: LCP terminated by peer (Connect time expired)
Mon Mar 3 14:23:34 2025 daemon.info pppd[20464]: Connect time 10130.6 minutes.
Mon Mar 3 14:23:35 2025 daemon.notice pppd[6255]: Connect: pppoe-wan <--> lan1
Mon Mar 10 15:40:15 2025 daemon.debug pppd[6255]: rcvd [LCP TermReq id=0x2 "Connect time expired"]
Mon Mar 10 15:40:15 2025 daemon.info pppd[6255]: LCP terminated by peer (Connect time expired)
Mon Mar 10 15:40:15 2025 daemon.info pppd[6255]: Connect time 10156.7 minutes.
Mon Mar 10 15:40:16 2025 daemon.notice pppd[27433]: Connect: pppoe-wan <--> lan1
Wed Mar 12 23:04:45 2025 daemon.info pppd[27433]: LCP terminated by peer (User request)
Wed Mar 12 23:04:45 2025 daemon.info pppd[27433]: Connect time 3324.5 minutes.
Wed Mar 12 23:18:31 2025 daemon.notice pppd[26599]: Connect: pppoe-wan <--> lan1
Sun Mar 16 19:00:40 2025 daemon.info pppd[26599]: LCP terminated by peer (Peer not responding)
Sun Mar 16 19:00:40 2025 daemon.info pppd[26599]: Connect time 5502.1 minutes.
Sun Mar 16 19:00:41 2025 daemon.notice pppd[20032]: Connect: pppoe-wan <--> lan1
Sun Mar 23 19:23:49 2025 daemon.debug pppd[20032]: rcvd [LCP TermReq id=0x2 "Connect time expired"]
Sun Mar 23 19:23:49 2025 daemon.info pppd[20032]: LCP terminated by peer (Connect time expired)
Sun Mar 23 19:23:49 2025 daemon.info pppd[20032]: Connect time 10103.1 minutes.
Sun Mar 23 19:23:50 2025 daemon.notice pppd[3117]: Connect: pppoe-wan <--> lan1
Sun Mar 30 20:56:58 2025 daemon.debug pppd[3117]: rcvd [LCP TermReq id=0x2 "Connect time expired"]
Sun Mar 30 20:56:58 2025 daemon.info pppd[3117]: LCP terminated by peer (Connect time expired)
Sun Mar 30 20:56:58 2025 daemon.info pppd[3117]: Connect time 10173.1 minutes.
Sun Mar 30 20:56:59 2025 daemon.notice pppd[21642]: Connect: pppoe-wan <--> lan1
Sun Apr 6 22:55:51 2025 daemon.debug pppd[21642]: rcvd [LCP TermReq id=0x2 "Connect time expired"]
Sun Apr 6 22:55:51 2025 daemon.info pppd[21642]: LCP terminated by peer (Connect time expired)
Sun Apr 6 22:55:51 2025 daemon.info pppd[21642]: Connect time 10198.9 minutes.
Sun Apr 6 22:55:52 2025 daemon.notice pppd[7344]: Connect: pppoe-wan <--> lan1Az egy hetnyi uptime altalaban megvan.
-
attila.86
tag
válasz
.-..-.
#20862
üzenetére
A proxmoxnak 2 gigát ajánlanak meghagyni fórumok alapján. Ha elég a seednek 1, akkor jó vagy, mert openwrt-hez is elég lehet 1. ARM-en már az 512MB is elég korrektnek számít az openwrt-hez, tegyük fel, hogy a duplája elég az x86 többletigénye miatt. Egyébként pont utóbbi miatt hosszú távon egy combos arm szerintem a tökéletes, kevesebb erőforrás, kisebb fogyasztás. Vannak amúgy magyar bemutató/leíró videók is proxmox-ra, pl kernelpánik nevű csatorna elég sokat foglalkozik a témával.
-
.-..-.
tag
válasz
attila.86
#20861
üzenetére
Most a meglévő eszközeimmel tesztelnék. Nincs sok, mert elosztogattam.
Jelenleg egy mATX lapot használnék a célra, amiben egy Celeron G550 van.
Ebbe bele tudok tenni egy plusz pcie LAN kártyát, hogy 2db legyen az alaplapival együtt.
Illetve belemegy a pcie 6port sata kártya is.
Viszont csak 2GB-os ramjaim vannak és 2db-ot fogad. Elég lehet a dologhoz (proxmox+seed szerver VM+router VM) 4GB DDR3 RAM?ProxMox teljesen új nekem ... kizárólag a logóját láttam eddig, amikor a VPS-t virtuális konzolról érem el és épp indul a gép
-
attila.86
tag
válasz
.-..-.
#20860
üzenetére
Ha egy adott X86-on router mellett mást is használnál, akkor tuti külön virtuális gépeket telepítenék mondjuk proxmox alá, így technikailag külön gépek, csak a vas ugyanaz. Amúgy állítólag a rpi4 is tud már gigát natolni hwnat nélkül, de az openwrt supported devices között vannak olyan arm alapú eszközök, amiben nem csak az eco magok kaptak helyet (mint egy arm nas-ban pl), hanem a performance core-ok is, ilyenből egy combosabb 2 giga felett is tud natolni önerőből.
-
.-..-.
tag
Hát ez nem megy ...
A seed 6+ órája áll, a router az éjjel megint eldobálta a kapcsolatot.
Most nem a WAN port, hanem a Lan2 csinálta, ezen van a szerver.Gondolhatnék arra, hogy annak a hálókártyája a probléma, de akkor 6 teljes napig miért működött, amikor az ONT router-módban volt és switch-el használtam.
Kábelcsere többször volt és már szerintem a mindenféle sorrendben voltak a kábelek a router-ben.Így néz ki a log: [pastebin]
(kipucolva belőle a DHCPDISCOVER/DHCPOFFER/DHCPREQUEST/DHCPACK a MAC Address-ek miatt)Van ötlet mi lehet itt a gond?
vargalex:
Említetted, hogy lehetne egy gépen a seed és a router. Ez hogyan nézne ki?
Kifejtenéd kicsit? -
.-..-.
tag
Na, ideiglenesen összedobtam egy PC-t és tettem bele +1db LAN kártyát, így most 2db van benne.
Egyelőre az OpenWRT x86 verzióját használom.
Ott tartok, hogy látszanak az eth0, eth1 hálókártyák.
Az eth0 lett a br0 és DHCP-vel csinál is magának egy 192.168.1.x IPv4 tartományt, a laptop szépen eléri a LuCI-t.
Az eth1-et átneveztem WAN portnak és DHCP kliensként a mostani hálózatomra csatlakozik, ami 192.168.100.x IPv4 tartományban van.
Kap is IP címet, de a laptopomon mégsincsen net, ami az alhálózaton (192.168.1.x) van.Tehát:
Internet ->
-> SohoRouter (192.168.100.1 - OpenWRT - DHCP Server) ->
-> RouterPC (192.168.100.107 - OpenWRT - WAN (eth1) ) ->
-> RouterPC (192.168.1.1 - OpenWRT WAN - br0 (eth0) ) ->
-> Laptop (192.168.1.105/Gateway 192.168.1.1) -> Nincs InternetLaptopról (192.168.1.105)
- ping 192.168.1.1 = válaszol
- ping 192.168.100.107 = válaszol
- ping 192.168.100.1 = Destination Port UnreachableDesktop gépről (192.168.100.1)
- ping 192.168.100.1 = válaszol
- ping 192.168.100.107 = Destination Port UnreachableMit szúrok el?
UPDATE:
Nem előszört történik, hogy azután, hogy leírtam mi a probléma, beugrik, hogy mit rontottam el.
A WAN-hoz nem társítottam tűzfal profilt. Beállítottam és már működik is. -
kutga
félisten
válasz
.-..-.
#20857
üzenetére
Nekem is megtetszett. Az alap os nálam a Proxmox vitruális környezet, erre tettem az Opnsense-t, mint virtuális gépet. Mindkét oprendszernek van topikja (a router os-t Pfsense néven keresd), sokat tanultam onnan. Hálókártyából valami kétportos Intelt javasolnék először, ha olcsón kell, akkor valami ilyesmit (nem a reklám helye), ha drágábban, akkor valami ilyet.
-
.-..-.
tag
válasz
vargalex
#20854
üzenetére
A szerver jelenleg egy mini-ITX AMD A4 APU-val szerelt gép.
Nem tudtam, hogy biztonsággal megoldható, hogy egyben NAT és seed szerver is lehessen.
Másrészt egyetlen pice csatlakozója van, amiben egy 6 portos sata kártya van most.
De amúgy bővíteném és sanszos, hogy mATX lesz belőle, szóval akár lehet több pcie csatlakozóra is alapozni.
Harmadrészt nem biztos, hogy kényelmes megoldás lenne, ha bármiért leállítom, akkor megszűnne itthon az internet. Asszonnyal mindketten H.O. dolgozunk, kell a folyamatos kapcsolat.Igen, illene túlélnie a wireguard-nak a kihagyást. Sőt illik neki egy hálózati váltást is, de valamiért mégis gondok vannak.
Lehet valami user error, de akkor miért nincs gond az ONT-router mód esetén?
Igazából nem tudom az okot. -
.-..-.
tag
válasz
Archttila
#20850
üzenetére
A táblázatot nézve, elég combos hardvere van.
Feltételezem nem hazai beszerzés volt, igaz? Itthon nem találtam hirtelen forgalmazót.
Amúgy nálam a wifi egyáltalán nem szempont, amit lehet kábeleztem.
Szóval akár valami "csak" kábeles router is megteszi.
A lényeg, hogy OpenWRT kompatibilis legyen.
Nálam a probléma a seed szervernél jelentkezik.
Fizetős/gyors VPN-t (wireguard - nmcli wg0) használok hozzá, ami a szerveren fut, nem a routeren.
Naponta többször képes leállni és ilyenkor kiesik a seed-ből. Ha kivettem a router-t és az (exDIGI) ZTE ONT router-módban használtam switch-el akkor 6! napig hiba nélkül futott.
Tegnap visszaraktam a ZTE-t bridge-módba és használni kezdtem a routert, pár órával később leállt.Szóval ezért volna jó ezt rendbetenni, mert pont azt a gépet akarom bővíteni, de így kb. most felesleges.
vargalex:
Igen próbáltam, most a logban nincs a WAN port down/up, de ennek ellenére belefutottam a fentebb említett hibába.
Múlt héten (amikor visszaáltam a szolgáltató ONT router módra) már kínomban szétszedtem az AC65P-t és a tápkörből kihagyott kondikhoz még beraktam 1-2 darabot, hátha ... de nem.
Már elgondolkodtam valami miniITX x86 cucc összerakásán is. -
-
.-..-.
tag
Tudnátok ajánlani olyan olcsó, de erős SoC-al szerelt routert, ami OpenWRT kompatibilis és "röhögve" megy neki az 1Gb PPPoE is akár HW-NAT nélkül is?
(Ugyanis van egy tippem, hogy az AC65P esetében nálam a HW-NAT okozza a problémát)
Például azt látom, hogy az OpenWRT One routerben MediaTek MT7981B van.
Ez mennyire számít gyorsnak? Egy ilyennel szerelt router jó lehet nekem? -
vargalex
Topikgazda
válasz
skippper
#20846
üzenetére
Szia!
Szerintem a logod első sorában ott a miértre válasz:
No response to 5 echo-requestsAzaz a szolgáltató PPPoE concentratora nem válaszolt 5 db egymás után kiküldött echo request-re, így a pppoe daemon azt gondolja (jogosan), hogy megszakadt a kapcsolat, így újra kell azt építeni. Ez anno Digi esetén néhány embernél előjött (valószínűleg leterhelt a concentrator, vagy elvesznek csomagok) és ez a beállítás elvileg segített a problémán (most nézem, 11 éves a hozzászólás
).Szerk.: Bár, azóta elvileg bejött a keepalive_adaptive beállítás, ami default-ban bekapcsolt és ilyenkor csak akkor küld echo request-et, ha nincs forgalom az interface-on. A fenti linken viszont az is látható, hogy valóban 5 az
lcp-echo-failurealapértéke (ez magyarázza, hogy miért 5 válasz nélküli echo request után dönt úgy, hogy megszakadt a kapcsolat). -
.-..-.
tag
válasz
skippper
#20846
üzenetére
Szia.
Komolyan mondom, örülök, hogy rátaláltam a hozzászólásodra.
A helyzet az, hogy nálam is hasonló issue van, bár nálam régebb óta.
Én már ott tartok, hogy 2 napja új router-t keresek, mondván a régi elromlott.Nekem egy Asus RT-AC65P routerem van, amin az OpenWRT van az Asus által már nem támogatott gyári firmware helyett.
Nálam is az a helyzet, hogy ugyanabban a másodpercben (logok szerint) egy WAN down, majd egy WAN up történik.
Ez akár naponta 3 alkalommal is megtörténik néha.
A szerver gépem, ami VPN-el fut, ilyenkor ki is fekszik és megszakad a torrent seed és amig nem teszem rendbe, addig nincs feltöltés.
Az intranet viszont akadás nélkül megy ez idő alatt is.
A fura az egészben, hogy a router gyári firmware esetében is ezt produkálta.
Ezért és mert nem kap már frissítéseket, váltottam OpenWRT-re.
Viszont a hiba megmaradt.Szóval a hw/sw környezet:
- exDigi, One PPPoE kapcsolat
- ZTE zxhn f618v2 modem, optikai kapcsolattal (csak internet)
- Asus RT-AC65P router
- OpenWRT (most frissítettem, latest verzió)
Jelenleg saját router nélkül vagyok, az ZTE router módban fut, rajta egy 4portos TP-Link Switch-el van itthoni hálózat. Így 6 napja nincs problémám.
Emiatt azt gondoltam a router okozza a hibát és keresem már, hogy mit vegyek helyette.Viszont az, hogy nálad ugyanez a gond van, hát ... több, mint elgondolkodtató.
-
skippper
senior tag
Sziasztok!
Küzdök egy PPPoE issueval már 1-2 napja, esetleg valaki tapasztalat hasonlót?
https://prohardver.hu/tema/one_otthoni_szolgaltatasok_tv_internet_telefon/hsz_6814-6814.html -
xabolcs
őstag
válasz
PistiSan
#20844
üzenetére
Amit nem igazán értek, hogy miért van a firewall alatt "Flow offloading type" beállítás "None" értéken alapból?
Azert, mert nem foglalkoznak az osszes tamogatott eszkoz ilyesfajta dolgaival.
Ket platform eszkozei tudjak a hardveres NAT-olast OpenWrt alatt: a ramips/mt7621 es a mediatek/*.Orulok, hogy tettel egy probat es maradsz!
Egyebkent ez is olyan, hogy SNAPSHOT alatt nincs LuCI (csak firmware-selector eseteben), meg alapbol ki van kapcsolva a WiFi es jelszo sem tartozik hozza.
-
PistiSan
addikt
Sziasztok!
ASUS RT-AC65P routerem van, a gyártói fw 2021-es
Pár éve próbáltam az OpenWrt-t, de akkor a hardveres nat nem működött jól, vissza álltam a gyári fw-re.
Most megint tettem egy próbát, most már maradok
.
OpenWrt 24.10.0 r28427-6df0e3d02a
Amit nem igazán értek, hogy miért van a firewall alatt "Flow offloading type" beállítás "None" értéken alapból?Egy pár sebesség teszt:
Gyári asus fw
OpenWrt alap beállítás.
openwrt_Flow offloading type_Software
openwrt_Flow offloading type_Hardware
Nem igazán találtam releváns infót a sebességről amit tud a router OpenWrt-vel, ezért gondoltam itt hagyom ezeket a méréseket.
Az én szolgáltatómnál DHCP-n osztják az IP-t, nem tudom pppoe, vagy más kapcsolattal ez az érték hogyan változik. -
#20843
xabolcs
őstag
E.Kaufmann
#20842
xabolcs
őstag
válasz
E.Kaufmann
#20842
üzenetére
Pont most csereltem ramips/mt7621 + ipq40xx komborol 2x mediatek/filogic-ra a fenti halozatban. Atvittem kezzel a halozati konfigot, a kliensekkel semmit se kellett csinalnom.
Persze OpenWrt-rol OpenWrt-re tortent a csere, szoval nem volt kihivas.
-
#20842
E.Kaufmann
veterán
xabolcs
#20841
-
#20841
xabolcs
őstag
E.Kaufmann
#20840
xabolcs
őstag
válasz
E.Kaufmann
#20840
üzenetére
Az egyik altalam larbantartott halozat pont ilyen: be van kapcsolva a WDS a 2.4 GHz-s wifi-n, 5 GHz-n pedig nincs ... es meg az SSID-ik is megegyeznek (roamingot segitendo).
Mindezt ket eszkozzel: router + dumb AP, osszesen 4 savval.Teljesen jol mukodik minden, bar a TV vezeteken kapcsolodik, mert nem birja a hosszu wifi jelszot!
-
attila.86
tag
válasz
E.Kaufmann
#20838
üzenetére
Ha egy mód van rá, inkább wds vagy 802.11s mesh, ezeken keresztül működik minden, wol, ipv6 stb. Ha az AP nem openwrt, talán a wds még úgy is összejöhet. Sokkal koherensebb hálózatot kapsz ezekkel, mint a relayd-vel.
-
#20838
E.Kaufmann
veterán
E.Kaufmann
veterán
Hogy tudok egy relayd mögötti eszközt felkelteni WoL-lal? Kellene valami tűzfa szabály?
Az openWRT-t futtató eszköz a Wifi kliens és mögötte van vezetékesen az eszköz. Magárol a relayd-t futtató eszközről működik a WoL csomag küldés, az eszköz felébred. De már az AP-ról vagy a LAN többi részéről nem megy a felébresztés Mac cím alapján (gondolom, mert trükközik a relayd a MAC címekkel)
Pont azért próbáltam volna OpenWRT eszközt közbeiktatni, mert az adott kliens tudott Wifi-t csak ha ki volt kapcsolva, nem lehetett ébreszteni, ethernet portján viszont lehetne, csak nem madzagoznék miatta. -
attilav2
őstag
Életre keltettem az AX3000T gyors wifi csatlakozásra szolgáló NFC-jét.
Ezzel a kis programmal. Hogy működjön a tárolóból fel kell telepíteni két függőségét, az i2c-tools-t és amiről az oldal szemérmesen hallgat, de enélkül el sem indul a program(hibák garmadáját ömleszti), a libstdcpp6-ot. Ezután az oldal leírása szerint ellenőrizni kell hogy melyik i2c buszon ül az nfc chip. Utána jöhet a wifi ssid jelszó és titkosítási mód beírása az NFC chipbe(wpa3 beírását nem teljesen támogatja sajnos). Ha a xinfc-wsc -t paraméter nélkül futtatjuk akkor kilistázza a támogatott a megadható titkosítási módokat.
psk2+ccmp-t használok így esetemben a felparaméterezett parancs így nézett ki:
./xinfc-wsc 0 0x57 SSID jelszó psk2+ccmp
Alig 1 perc alatt lemegy a folyamat, a következők jelennek meg a konzolban:
Ha sikeres volt a művelet, mint ahogy az ábra mutatja, akkor a telefont a router NFC-s sarkához érintve a megfelelő ponton, felajánlja a telefon a hálózathoz csatlakozást.
Az NFC chip gyári tartalmáról készül egy mentés a program első használatakor, (pirossal aláhúzott, nfc_ndef_backup.bin, ezt érdemes lementeni a gépre).
Természetesen a leírással ellentétben nemcsak 23.05.x-en használható hanem 24.10-en is működik, azon próbáltam ki. A vendég wifit érdemes így megosztani, akinek van. -
kutga
félisten
válasz
PistiSan
#20833
üzenetére
A linkelt oldalon is szerepel, a 'Returning to stock' résznél, az ASUS Firmware Restoration Tool alkalmazással. Persze nem tudjuk mekkora a baj, de ha a recovery megy, ezzel nekem is sikerült nem egy Asus routert feléleszteni.
-
vargalex
Topikgazda
válasz
LaMotta
#20832
üzenetére
Nem gond a soros porton történő flash-elés (Budapesten tudok ebben segíteni), de van ott egy Easy installation metódus is. Az nem egyértelmű, hogy a wifi kalibrációs adatok mentése miért kell (gondolom biztonsági okokból, ha nem lenne wifi, így később visszatölthető), mert a leírás (és a linkelt leírás) utána nem használja.
-
LaMotta
aktív tag
Van "itt" valaki, aki hardveresen tud router-t OpenWRT-re flash-elni?
Pontosabban, egy ASUS RT-AC58U v1-ről lenne szó..
-
#20831
kutga
félisten
st3v3np3t3r
#20830
kutga
félisten
válasz
st3v3np3t3r
#20830
üzenetére
Ha csak erre kell szerintem olcsón kapni openwrt képes routert.
-
#20830
st3v3np3t3r
nagyúr
kutga
#20829
-
#20829
kutga
félisten
st3v3np3t3r
#20827
kutga
félisten
válasz
st3v3np3t3r
#20827
üzenetére
Viszont ezt a routert sajnos nem látom a támogatott eszközök között. Itt azt írja, hogy csak valami kiherélt verziót lehet rá feltenni, de abban meg nincs wireless driver.
-
#20828
kutga
félisten
st3v3np3t3r
#20827
kutga
félisten
válasz
st3v3np3t3r
#20827
üzenetére
Azt viszont valóban nem tudja a gyári fw.
-
#20827
st3v3np3t3r
nagyúr
kutga
#20826
pontosan... azaz a routerrel szeretnék másik routerhez csatlakozni vezetéknélküli kapcsolattal, majdnemcmint egy reapeter, csak itt nem lenne jelerősítés...
az alkalmazási cél az lenne, hogy a lan vezetékes nyomtatót vezetéknélküli hálózatra tenném át.Volt egy tplink reapeterem, de az sajna megadta magát.
-
attila.86
tag
válasz
st3v3np3t3r
#20824
üzenetére
Minden router tud AP lenni, ha kikapcsolod rajta a DHCP szervert, becímezed ugyanabba az alhálóba, ahol a többi eszközöd van, és elfelejted rajta a WAN-portot. Felesleges nekiállni főzőcskézni, ha csak ennyi az igény.
-
#20824
st3v3np3t3r
nagyúr
Szebb napot, van egy tl-wr542g ver6.7 routerem gyári formware-rel, de sajna ez még nem tud AP funkciót, kérdésem lrnne, hogy openwrt-ből össze lehetne-e sütni egy olyan firmware-t, ami alcsak AP funkcióként működtetné a routert?
-
attilav2
őstag
válasz
xabolcs
#20822
üzenetére
Azért ennyire pro nem vagyok
maximum nagyon nagyon shell egyszerű scriptet tudnék írni.
Itt gombnyomáskor a scriptnek ellenőriznie kell hogy a ledek égnek és ha égnek akkor ki kell kapcsolnia őket, ha nem égnek akkor be kell kapcsolnia őket.
Vargalex ezt uci parancsokkal oldotta meg(wrt160nl wifi ki/be kapcsolás), így sokkal szebb és rövidebb a script. Feltételezem meg lehet uci parancsokkal oldani a led ki/be kapcsolást gombnyomásra ax3200-on. -
attilav2
őstag
'uci show system' kimenetének ledekkel kapcsolatos része:
system.led_wan=led
system.led_wan.name='WAN'
system.led_wan.sysfs='blue:net'
system.led_wan.trigger='netdev'
system.led_wan.dev='wan'
system.led_wan.mode='link'
system.@led[1]=led
system.@led[1].name='Power LED'
system.@led[1].sysfs='blue:power'
system.@led[1].trigger='default-on' -
attilav2
őstag
Vargalex egy ilyen uci alapú scriptet mutatott nekem annak idején wrt160nl wps gombos wifi ki/be kapcsolásra, ezt át lehet valahogy írni az ax3200 ledjeinek ki/be kapcsolására a mesh gombbal ?
#!/bin/sh
if [ "$BUTTON" = "wps" ]; then
if [ "$ACTION" == "pressed" ]; then
WIFI_RADIOSTATUS=`uci get wireless.radio0.disabled`
if [ $WIFI_RADIOSTATUS == '1' ]; then
uci set wireless.radio0.disabled=0 && \
uci commit wireless && \
logger "Wi-Fi radio is on."
else
uci set wireless.radio0.disabled=1 && \
uci commit wireless && \
logger "Wi-Fi radio is off."
fi
wifi
fi
fi -
attilav2
őstag
válasz
yodee_
#20813
üzenetére
Tovább léptem és logoltam az ax3200 mesh gomb megnyomásakor keletkező eseményt a wiki leírás szerint:
-Prometheus- ezt a scriptet javasolta nekem amikor wrt160nl-en a wps gombra állítottam a wifi ki/be kapcsolást. Ez a script hogy nézne ki akkor ha /root/ledoff.sh és a /root/ledon.sh (esetleg az /etc/init.d/led start) scripteket akarnám vele meghívni, tehát amikor megnyomom a mesh gombot akkor kikapcsolnak a ledek mikor újra megnyomom bekapcsolnak ? -
attilav2
őstag
válasz
yodee_
#20813
üzenetére
Mivel a villogást nem szeretem ezért luciban átvariáltam hogy folyamatosan kéken égjen a 3200-on mindkét led, a power led folyamatosan ha be van kapcsolva a router, a wan led pedig ha van ethernet link a modemmel, akkor szintén folyamatosan világítson.
Tehát a visszakapcsoláshoz nekem elég ennyi:
echo "1" > /sys/class/leds/blue:power/brightness
echo "1" > /sys/class/leds/blue:net/brightness
Megcsináltam ledoff.sh-t és beírtam a crontabba az időzítést amit írtál.
Gombokra hirtelen ezt találtam.
Lefuttattam ezt a parancsot:
A leírás szerint ez az AX3200 gombjainak hex értéke. Innen kéne valahogy tovább lépnem. -
yodee_
őstag
válasz
attilav2
#20812
üzenetére
Nagyon egyszerű :
ledoff.sh
echo "0" > /sys/class/leds/blue:power/brightnessecho "0" > /sys/class/leds/blue:net/brightnessledon.sh
echo "heartbeat" > /sys/class/leds/blue:power/triggerecho "1" > /sys/class/leds/blue:power/brightnessecho "netdev" > /sys/class/leds/blue:net/triggerecho "wan" > /sys/class/leds/blue:net/device_nameecho "1" > /sys/class/leds/blue:net/linkecho "1" > /sys/class/leds/blue:net/txecho "1" > /sys/class/leds/blue:net/rxecho "1" > /sys/class/leds/blue:net/brightnessÉs ezek vannak az ütemezőben:
00 21 * * * /root/ledoff.sh00 8 * * * /etc/init.d/led start
Most látom a led bekapcsolásnál reggel nem is kell szkript csak egy sima indítás -
C7 utan a Flint 2 egy teljesen mas szint... most hagyjuk a baba speckokat, de hogy konkretan a load mint olyan zero
mindegy hogy terhelem Mediatek+OpenWrt Fantasztikus eszkoz, koszi az ajanlast!
viszont egy alvas mos ramfer, lévén lassan ket napja ebren vagyok
Pont előttem kérdezték meg.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Mi lehet a gondja, hogy torrent kliensben a "Connection status: Firewalled" rémséget mutatja?
)
Ha sikeres volt a művelet, mint ahogy az ábra mutatja, akkor a telefont a router NFC-s sarkához érintve a megfelelő ponton, felajánlja a telefon a hálózathoz csatlakozást.
-Prometheus- 
A leírás szerint ez az AX3200 gombjainak hex értéke. Innen kéne valahogy tovább lépnem.
Új hozzászólás Aktív témák
- BESZÁMÍTÁS! Intel Core i9 13900K 24 mag 32 szál processzor garanciával hibátlan működéssel
- 119 - Lenovo Legion Pro 5 (16ARX8) - AMD Ryzen 7 7745HX, RTX 4070 (48 hónap garancia!)
- Telefon felvásárlás!! Xiaomi Redmi Note 13, Xiaomi Redmi Note 13 Pro, Xiaomi Redmi Note 13 Pro+
- Bomba ár! Lenovo ThinkPad T490s - i5-8GEN I 16GB I 512SSD I 14" FHD I Cam I W11 I Gari!
- iPhone 15 Pro 128GB, Szép állapot, Független, 100%, Garanciával!
Állásajánlatok
Cég: Laptopszaki Kft.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest