-
Fototrend
OpenWrt topic
Új hozzászólás Aktív témák
-
.-..-.
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. -
.-..-.
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? -
.-..-.
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. -
.-..-.
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. -
.-..-.
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.
-
.-..-.
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?
-
.-..-.
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. -
.-..-.
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. -
.-..-.
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?
-
.-..-.
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.
-
.-..-.
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.
-
.-..-.
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) -
.-..-.
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. -
.-..-.
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] -
.-..-.
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
-
.-..-.
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. -
.-..-.
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? -
.-..-.
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ó.
-
-
.-..-.
tag
válasz
xabolcs
#20369
üzenetére
Köszönöm az infókat.
Nem bírtam holnapig várni, fel is raktam próbából. [kép]
Amúgy "sima" ügy volt felrakni szerencsére.
Mászni nem volt kedvem az asztal alá, ezért az sftp-s módszerrel tettem fel.
Bár az scp-nek kellett egy "-O" paraméter, mert nem látott sftp-szervert.Még állítgatom, de egyelőre nem láttam magát a hw-nat kapcsolót, már ha van ilyen.
Sebesség teszt sem volt még, egyelőre a kliensek IP-jét adogatom hozzá a DHCP-hez, hogy pár eszközömnek a megszokott legyen.Update: Mértem és nem megy 400Mb/s fölé a letöltés.
-
.-..-.
tag
Sziasztok.
Van egy Asus RT-AC65P routerem, amit PPPoE (Digi, gigabit optika) kapcsolattal használok.
Sajnos a legutolsó FW is 2021-es hozzá, ami 2020-as security patch-eket tartalmaz.
Úgy vélem, hogy ez eléggé problémás lehet így, ezért valamit lépnék.
Felmerült az OpenWRT, mint utolsó lehetőség ehhez a routerhez.
Viszont nem tudom vajon PPPoE esetén van HW-NAT ehhez a Mediatek verzióhoz?
Enélkül ugyanis túl lassú sebesség/magas cpu terhelés lenne.Használhatom még ezt a routert?
Mi lehet a gondja, hogy torrent kliensben a "Connection status: Firewalled" rémséget mutatja?
)
Új hozzászólás Aktív témák
- Star Wars The Old Republic Collector's Edition
- AKCIÓ! Jogtiszta Windows - Office & Vírusirtó licencek- Azonnal - Számlával - Garanciával - Nint.hu
- Vírusirtó, Antivirus, VPN kulcsok
- Árváltozás + játék DVD: Watch Dogs Deadsec Edititon
- Árváltozás+játék DVD: Borderlands 2 Ultimate Loot Chest Limited Edition
- Lenovo V130-15IGM laptop (Pentium Silver N5000/8GB/256GB SSD
- ÁRGARANCIA! Épített KomPhone Ultra 9 285K 32/64GB RAM RTX 5070 12GB GAMER PC termékbeszámítással
- Magic Trackpad legújabb fajta, lightning csatlakozóval
- HP ZBook Power 15 G8 Mobile Workstation i7-11850H 32GB 512GB Nvidia RTX A2000
- Bomba ár! Dell Latitude E7440 - i5-4GEN I 8GB I 500GB I 14" HD I HDMI I Cam I W10 I Gari!
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: Promenade Publishing House Kft.
Város: Budapest