-
Fototrend
OpenWrt topic
Új hozzászólás Aktív témák
-
Headless
őstag
válasz
xabolcs
#21257
üzenetére
Lehetne sorrendet változtatni am először ping utána touch, bár nem tudom egyáltalán van-e értelme a touchnak én csak azért raktam bele, mert vargalex által küldöttbe benne volt. Magamnak nem raktam volna bele (szerintem nem változtat semmit főleg nem ennyu sleepel), bár a 70-es sleepet is kissebre vettem volna magamnak.
Bár alapvetően én flash írastól nem félnék. Mi annó rengeteg statisztikai adatot mentettünk susteval percenként. (Hőmérséklet, cpu load, network stat interfészenként, etc) és nem tempbe hanem flashbe. Ez lehetett úgy 2018-ban és még mindig megy a router. Napi használatban.
De ha ettől fél valaki akkor lehetne a ping az első a sleep után és akkor kevesebbszer frissíti a modosítási dátumát a fájlnak.
*/5 * * * * sleep 70 && ping -c 1 192.168.111.3 >/dev/null || { touch /etc/banner;reboot;}t -
Headless
őstag
válasz
Truman
#21254
üzenetére
hali Én nem kevernék bele mégegy csomagot, ha a sima reboot neked megfelelő volt...
használj sűrűbb cron-t akár percenkéntit ( az alábbi 5 perces). és tegyél bele egy ping feltételt is. az ip címet cseréld le arra amire szeretnéd. akár valami online oldalra is. annyi hogy a sleep ne legyen nagyobb a futtatási időközödnél. habár az csak azért van hogy ne induljon újra folyamatosan.
*/5 * * * * sleep 70 && touch /etc/banner && ping -c 1 192.168.111.3 >/dev/null || reboot -
Headless
őstag
válasz
nimmrody
#18426
üzenetére
Két dolog kell ehhez:
1. Publikus ipv4 cím, ha ez az ip címed változik, otthoni szolgáltatások 90%-a változik. Szóval kell egy dinamikus dns cím és szolgáltatás a routeren.2. A webszerver elérése ez történhet több módon:
2.1 port forward/port opening 80-as vagy 443 portok valamelyikét kinyitod, vagy külső random portról továbbitod a belső port valamelyikére pl 8080->80 vagy 8443 ->443 (ez a megoldás kevésbé biztonságos, de kényelmes.
2.2 vpn kiépítese csak példák, nem fogok belemenni részletekbe, openvpn/wireguard/pptp/l2t stb... openvpn/wireguard az egyik legkönnyebb és vannak mindhez dokumentációk.
-
Headless
őstag
válasz
Indiant
#18350
üzenetére
szia, openwrt rndelkezik egy read only squashfs /root könyvtárral, és erre rácsatolódik egy "overlayfs" ezt a teljes overlay tartalmat le tudod menteni, minden telepített csomag, minden beállítás ide kerül. azt ne felejtsd el, hogy ha van utólag telepített kernel modulod, az is itt lesz és az a különböző verziók miatt problémákat okozhat.
/overlay/upper
ez másolható, persze megválogathatod, mit akarsz benne hagyni.
-
#18172
Headless
őstag
ArthurShelby
#18171
Headless
őstag
válasz
ArthurShelby
#18171
üzenetére
Amire a tűzfalszabályok jók azt csinál amit akar velük, pl ha csak egy bizonyos portot akar forwardolni az is megoldható. Én most azt írtam amit szeretett volna. De igen klónozás miatt, nem tökéletes, de a port forwardolás sem tökéletes. Az is lehet, hogy azon az interfészen csak egy bizonyos ip-re engedi a kapcsolódást. Vagy ha egyáltalán nincs szükség arra, hogy a kamerák maguk kapcsolódjanak, hanem a vezérlő kapcsolódik a kamerákhoz akkor elég ha az established kapcsolatokat engedélyezi. De most ezt nem akartam belevinni.
-
Headless
őstag
válasz
BullZeye
#18169
üzenetére
Első feladat a lan interfészek szétválasztása. https://openwrt.org/docs/guide-user/network/vlan/creating_virtual_switches
Ezután csinálj egy új interfészt ami ahhoz a vlanhoz van csatolva, állíts be egy ip cím tartományt, és engedélyezz dhcp szolgáltatást hozzá,
Ezután hozz létre egy tűzfal zónát ehhez az interfészhez és rendeld hozzá az interfészt is.
Ha szükség van internet hozzáférésre ezen forwardot engedélyezd a wan irányban az új zónából. Lanhoz hasonlóan létre kell hoznod szabályokat az új zónához is. Engedélyezed a lan -> új zóna továbbítást, viszont itt jön a csavar, tűzfal szabályokat hozol létre, hogy bizonyos mac címek továbbíthatnak LAN irányba. Így leírni nagyon nehéz most, lehet konfig mutatással egyszerűbb lenne. De most nem tudok sajnos.
-
-
Headless
őstag
válasz
vargalex
#17806
üzenetére
Egy szerver hozzáférés esetében ez igen reális, bár mondjuk azt nem tudom, hogy egy smb adatfolyam tudna-e pl két külön portra menni, lagg esetén.
Nem tudom a felhasználást jelenleg de valószínű a kollégának kár bajlódnia ezzel, mert nem lesz érdemi előnye vele, főleg, hogy wifiről van szó. Az más helyzet ha egy irodai hálózatról lenne szó, de akkor meg miért wifin dolgoznak?
Amúgy ahogy nézem az ax3600 -nak van egy 2.5gb-es portja. Habár Csak wan oldalon mondjuk openwrt-vel tehető bárhova. 2db ax3600-al fel lehetne építeni egy 2,5gbps linmet a gerincen, de a hgw-t akkor is csak gigabiten fogja tudni és ott Lagg-ra biztos nincs esély.
Igazából a kérdés az, hogy van-e vele értelme foglalkozni.
-
Headless
őstag
válasz
bzolika10
#17801
üzenetére
Link aggreagáció nem arra való, hogy 1 db klienssel több mint 1gbit sebességet érj el, hanem arra, hogy ha több adatforgalom keletkezik több különböző klienssel, akkor menjen több mint 1 gbit. Bár azért azt se felejtsd el, hogy wifinél az ax3600 csak úgy képes a 3600 elérésére, hogy több megfelelő kliens csatlakozik, és az is csak elméleti sebesség. Valós sebesség megfelelő klienssel 7-800mbps, ami még bőven gigabit alatt van.
A másik, hogy LAGG-ot nem fogsz konfigurálni egy telekom hgw-n. Openwrt-n se csináltam még de ott talán lenne lehetőséged. Bár hamarabb sikerülne szerintem egy managelt switchel. LAGG nem az otthoni user játékszere, főleg nem, hogy elérhetőek kezdenek lennei a multigig dolgok, vagyis 2,5gbit,5gbit,10gbit. De ha meg akarod közelíteni bármelyiket is felejtsd el a wifit.
-
Headless
őstag
-
Headless
őstag
válasz
attilam
#17621
üzenetére
szia openwrt-vel nekem mt7621-el kb 7-8mb/s-et sikerült elérnem wireguarddal, az rpi processzorban jobb, viszont kérdés melyik verziós rpi. nem tudom az újak milyenek de 2,3-nál még azért eléggé nem volt mondhatónak a gigiabit lan teljes értékűnek. osztozott usb kulcsokkal a sebességen. szóval én az egyszerűség kedvéért mennék/maradnék az openwrt mellett nagy különbséget nem fogsz tapasztalni szerintem sebességben.
Másik az 1. esetben sem kell mindent routingolni, hanem elég a subnetet (192.168.X.0/24), az internet felé routingolást feleslegesnek érzem (0.0.0.0), ha csak az a cél hogy ftp.re másolj.
-
#17121
Headless
őstag
SteveBeard
#17120
Headless
őstag
válasz
SteveBeard
#17120
üzenetére
Kliens konfigban, direkt van 0.0.0.0/0? Vagyis inkább használj ilyet 192.168.9.0/24 ahogy nézem ez a subneted.
Másik rosszul emlékeztem szerver oldalon nem kell a subnet beírás, se a route allowed ip, viszont kell tűzfal zóna és zóna továbbítás lanból wg-re és vissza.
-
#17118
Headless
őstag
SteveBeard
#17117
Headless
őstag
válasz
SteveBeard
#17117
üzenetére
A lan ip cím tartományodat beírtad allowed ip-hez? Mind a kliensben mind a szerverben? A szervernél a route alowwed ip-t is kapcsold be luciban.
-
#17088
Headless
őstag
ArthurShelby
#17087
Headless
őstag
válasz
ArthurShelby
#17087
üzenetére
1. Allowed Ip-be bekell írnod a lan ip-t is (,-vel elválasztva), valamint a route allowed ip funkciót is kapcsold be. Ezek luciban is beállíthatóak. Ezeket kliens konfigban is érdemes beállítani
-
Headless
őstag
válasz
Tarokk79
#16365
üzenetére
ebben az esetben én úgy állítanám be ha fontos a lokális címfeloldás, hogy az openwrt dns és az openwrt-ben a dns továbbításokat hozol létre az adguard szervereire ugyanis most csak siman azt adtad meg milyen dns szervert osszon ki a klienseknek a dhcp szerver.
a dhcp optiont pedig ki kell törölni.
-
Headless
őstag
válasz
Headless
#16172
üzenetére
ahogy gondoltam egy masquerade-al megoldottam, hogy a szerver azt lássa, hogy a router csatlakozik. (mivel a szerverhez nem férek hozzá)
A gyári vpn kliens beállítása segítségemre volt azért
ugyanis pont az volt beállítva ami kell, vagyis a remote az nem férhet hozzá az én lanomhoz.Valamint engedélyezni/tiltani azokat a kapcsolatokat, amik kellenek:
iptables -N ovpn1iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPTiptables -A INPUT -i tun0 ! -p icmp -j DROPiptables -A FORWARD -o br0 -j ovpn1iptables -A FORWARD -i tun0 -j DROPiptables -A ovpn1 -i tun0 -j ACCEPTiptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPTiptables -A -s 192.168.150.0/24 POSTROUTING -o tun0 -j MASQUERADEígy már elérem a kliens gépekről is.
-
Headless
őstag
Szerintem nem itt lesz a bibi.
az a gw a szerver oldali tunnel végpont, ott gondolom a forwardot megcsinálták annak rendje és módja szerint. (mint írtam ezek a szabályok mind push-al jönnek)
ha azt kitörlöm akkor még kliens végpontról sem tudom elérni a remote subnetet.
A felé járok, most hogy valószínű tűzfal probléma, inkább. a vpn kliens router is egyben és így alapvetően forward,input az droppolva van.
-
Headless
őstag
Sziasztok én is vpn kérdés, valahogy mindig fenn akadok ezeken a routolási problémákon...
Openvpn.site to site vpn
felállás:
nem általam kezelt openvpn szerver és subnet
192.168.8.0/24
tunnel subnet
192.168.108.0/24
gw 192.168.108.1Általam kezelt kliens
tunnel végpont:192.168.108.186
gateway (padavan) ezen futna az openvpn is de konzoloban kell beállítanom, mert a gui csak 1 klienst tud kezelni...
ami működik:
openvpn kliensről tudom pingelni a tunnel végpontot, és a remote lan tartoományt is.
kliens tartományból tudom pingelni a tunnel végpontját(192.168.108.186)ami nem megy:
saját subnetből nem tudom pingelni a távoli végpontot (192.168.108.1), se a távoli subnetet 192.168.8.0/24ip route részlet:
192.168.8.0/24 via 192.168.108.1 dev tun0192.168.108.0/24 dev tun0 proto kernel scope link src 192.168.108.186ip addr részlet
tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 100link/noneinet 192.168.108.186/24 brd 192.168.108.255 scope global tun0ipv4 forward engedélyezve van a kliensen, gondolom a szerveren is (nincs rálátásom).
jelenleg ennyi az egész ami történik a kliens oldalon
openvpn --config /path/to/config
természetesen a mutatott routeok pusholva vannak a szerverről.PUSH: Received control message: 'PUSH_REPLY,dhcp-option DNS 192.168.108.1,ping 20,ping-restart 60,topology subnet,route-gateway 192.168.108.1,ifconfig 192.168.108.186 255.255.255.0'mi hiányzik, hogy a subnetemből is elérjék a szerver oldali subnetet, de fordítva nem.
-
Headless
őstag
válasz
kriszrap
#16144
üzenetére
van egy amit mindenképp elfelejtenék.
az ntfs fájlrendszert linuxon ne használj ha nem muszáj.
egyrészt az inotify funkció hiányzik vagyis a minidlna nem fogja tudni, hogy új tartalom került be (csak manuális rescannel fog menni), másrészt lassabb sokkal mint egy ext4 fájlrendszer.
a problémádat talán az okozhatja hogy a transmission lefoglal valami fájlt ami megakasztja a dlna működését. De én inkább azt mondanám hogy a fő problémád az inotify hiánya vagyis az ntfs fájlrendszer.
-
#16125
Headless
őstag
ArthurShelby
#16121
Headless
őstag
válasz
ArthurShelby
#16121
üzenetére
szia mir3g nekem a 100-as netemet simán viszi wireguarddal 8-9mbyte/s). többet nem teszteltem mert ennyi az upstream kapcsolatom és lanon nem csináltam tesztet.
ha ennél több kell szerintem tedd a vpn kapcsolatot egy szerverre. egy low cost file szerver egy atommal vagy hasonló és az gyorsabb lesz.
-
Headless
őstag
válasz
abcde22
#15681
üzenetére
ebben az esetben csak az ethernet alapú továbbítas jatszik. virtualhere-vel hogy állsz én nem emlékszek semmi problémára annó meglepően felhasználó barát volt. indítottam bedugtam az eszközt kliensen azonnal megjelent ahol dupla klikkel már fel is csatolta. egy automatikus driver telepítés után.
Am csak hogy vargalexnek adjak igazat, valami féle rdp megoldás nem játszik? akár egy vékonykliens a célhelyen. ha játékra kell ott vannak a játékoptimalizáltak pl parsec, ha meg office orientált akkor microsoft remote desktopnál nem lesz jobb. kliensnél használhatod a rendes io-t és nem kell a coax sem a kép továbbításhoz.
-
-
Headless
őstag
válasz
abcde22
#15653
üzenetére
hát, én winscp-t szoktam használni windowson.
letöltöd legvalószínűbb, hogy mips vagy mipsel bináris kell neked. milyen routered van?
winscp-ben megkeresed és átmásolod mondjuk a routeren az sbin mappába vagy a bin mappába mindegy igazából.
utána futtatási jogot adsz neki.
chmod +x /fajl/utvonal.binvagy winscp-ben megadod tulajdonság szerkesztőben.
ezután már csak futtatnod kell elsőre próbáld ki nem démonként./fajl/eleresi_utvonalilyenkor ha jól emlékszem előtérben fog futni, és ír hibákat is.
Telepíted a klienst és kipróbálod. kész.Ha megfelelően működik, akkor legegyszerűbb, ha a startup scriptbe raksz egy sort az exit elé ez rebootkor el fogja indítani háttérben a megadott konfig fájlból a szervert. config fájlban átnevezheted az eszközöket utólag.
/fajl/eleresi_utvonal -b -c "/etc/virtualhere.conf"De amúgy szerintem bőven elég a honlapon lévő dokumentáció. Ha vásárolsz licenszet több eszközhöz kelleni fog, akkor arra figyelj, hogy hardver locked szóval ha most fogsz cserélni routert akkor várj a router megvásárlása utánra. Vagy megkell kérned, a fejlesztőt, aki amúgy lehet engedni is fogja a transzformációt, de nyűg. 50 usd szerintem nagyon reális ár ezért, pöpecül működik. és az otthoni felhasználóknak ott van a lehetősége az 1 eszköz továbbküldésére.
-
Headless
őstag
válasz
abcde22
#15651
üzenetére
tudom, hogy van én mir3g-n és 3600-on használom, nem kell telepíteni, csak a binárist kell felmásolni és futtatni engedélyezés után amit letöltesz megfelelő architectúra kell. mips, vagy ar71 vagy stb.
offline hardverkulcsokat osztunk meg vele. teljesen jól működik. így lesznek network licenszek
Látszik melyik gépről, milyen felhasználó használja az adott kulcsot és admin fiókkal ki is lőhetőek azok. Nekem nagyon bevált a két napos usbip szenvedés után 10 perc alatt konfigurálható volt. -
Headless
őstag
válasz
abcde22
#15648
üzenetére
De ezt mondom, hogy a windows oldalon nem nagyon lesz driver... az usbip xp-re volt megírva azóta csak hekkelgetések vannak de kb egyik sem működik. alapból a driver hitelesítést kikell kapcsolni, csak hogy egyáltalán feltelepítsd.
Ha több eszköz kell vedd meg a licenszt. sajnos az usbip windowson nem igen fog menni. De ha mégis találnál rá valamit engem is érdekelne.
Mondjuk a szerveroldali rész ettől függetlenüll mennie kéne, régen volt amikor probálkoztam vele de az pöccre ment. habár én azt hiszem egy kevésbé embedded eszközön próbáltam talán rpi-n archlinuxal. Alapvető usb-s dolgokra azokra gondoltam, hogy kmod-usb2 stb tehát egy sima lsusb megtalálja az eszközt? csak az usbip nem találja? Esetleg /dev-ben szerepel?
-
Headless
őstag
válasz
abcde22
#15645
üzenetére
ha windows mint mondtam a "server" oldali rész a kissebb probléma, haladj a virtualhere felé... 1 usb eszköz ingyenes. utána van licensz, de én pl csinálam azt, hogy két külön eszközbe kötöttem megosztásilag. sok binárisuk van. raspberryhez is lesz, routerekhez, switchekhez, stb.https://www.virtualhere.com/home
-
Headless
őstag
válasz
abcde22
#15643
üzenetére
szia!
windows eszközön szeretnéd használni a billentyűzetet?
ha igen és csak 1 dongle van akkor ajánlom a virtualheret csak felmásolod a binárist csinálsz rá egy init scriptet vagy boot utáni scriptbe beilleszted.
windowsos driver jól működik és aláírással rendelkezik nem úgy mint az usbip hekkelt driverek. amiből amúgy egyet sem sikerült működésre birnom.
az alapvető usb-s csomagok fent vannak amúgy?
-
Headless
őstag
válasz
attilav2
#15626
üzenetére
köszi ránézek, mivel most jövőhétig kell valószínű inkáb helyi eszközt szeretnék, még van tartalékba egy mir3g-m lehet az lesz és aztán upgradelek valamikor vagy itthon, vagy ott.. Am snapshottól nem félek, báűr valószínű, akkor inkább buildelek egy sajátot, amibe benne van minden ami kell.
wireguard teljesítményre mondjuk azért kíváncsi lennék, mert most nem raknék össze emiatt egy külön eszközt. régen nekem a mir3G openwrt-vel hozta a 7-8 mbyte/s-et ha kicsivel tudna többet nem lenne rossz.
-
Headless
őstag
válasz
@Jocó@
#15560
üzenetére
hát igen szerintem ez a legkézenfekvőbb, nem tudom, létezik-e dual wds,
ott a lan-t nem bridgelheted egybe, mert akkor elfogja érni a lanodat, szóval csak megadott tartományokba engedheted meg a kommunikációt, vagy a lan tartománya felé tiltod bizonyos ip cím tartomány, azt most nem tudom, de lehet a fő router felé engedned kell a forgalmat. ott pedig egy másik tűzfal szabállyal tudod korlátozni őket tovább, hogy csak wan felé kommunikálhasson. src ip-vel...
Bár ez most így elsőre elég káoszosnak tűnik, amit leírtam, remélem valamennyire érthető.
-
Headless
őstag
válasz
@Jocó@
#15556
üzenetére
Szia láttam ásik topikban is feltetted már a kérdést, ha tényleg separált guest networkről van szó, amiknek csak internet elérés kell, és nem zavar, ha külön alhálózatót kap, én simán felépíteném a második routeren is a sima guest hálót a saját wifijével és annyi, hogy az internet eléréshez keonfigurálsz egy tűzfal szabályt., hogy guest-ből wan-ba mehet a net, habár ügye a wds bonyolítja a helyzetet... kicsit játszanod kell a szabályokkal, hogy az tényleg csak a wan felé kommunikáljon...
-
-
Headless
őstag
válasz
Jofi81
#15374
üzenetére
Szia, nem ajánlatos megtartani, de frissítés után manuálisan visszaállíthatsz pár beállítást.
az etc/config mappából ésszel visszamásolhatsz dolgokat, pl dhcp lease lista, network konfigok, wifi konfig stb. De úgy, hogy felülvizsgálod a dolgokat. Transmission konfig valószínű egy az egyben maradhat, de erről nem tudok nyilatkozni pontosan.
Csomagokat külön kell telepítened.
-
#15293
Headless
őstag
Tesztelo.hu
#15292
Headless
őstag
válasz
Tesztelo.hu
#15292
üzenetére
pontosan milyen konfiguráció wds vagy sima repeater?
részletesen írd le mit csináltál, vagy hogy milyen leirást követtél.
-
Headless
őstag
válasz
vargalex
#15287
üzenetére
amúgy ez a "soft-brick" védelem kikerülése érdekében én minden olyan módosítást ami az eszköz elérhetését hivatott módosítani már jobban szeretem állítani ssh-n/config fájlba, egyszerűen halál ez a fallback settings, főleg windowsos kliensel, ahol nem kér magától új ip címet...
-
Headless
őstag
válasz
BullZeye
#15280
üzenetére
a kérdés az, hogy fix ip-vel dolgoznak a szerverek vagy nem... Nem vennék rá mérget.
ui: megnéztem dynu.com támogatja a txt rekordokat ingyenes felhasználóknak egy kitétellel, nem dynu.com hanem más domain alatt fusson (regisztráláskor másikat kell választani) dynu.net megy pl. és legalább 30 napja regisztrálva van.
4 db ddns-ig ingyenes teljesen, reklám/spam email nincs.
-
Headless
őstag
r3g-n
80-90 mbps-t tud a wireguard kernel modullal teljesen más kategória, mint az openvpn. de sajnos én itthoni környezetben padavanra váltottam go modullal már nem ilyen rózsás a helyzet de kb 40 mbps-t tud. kicsivel jobb mint az openvpn.
freenast én zfs és a könnyű konfigurálhatóság miatt ajánlom (auto snapshot, snapshotok elérhetővé tétele windows shadow copyval, active directory könnyű integrálása, stb).
docker van mindenhol
ha csak ez tartana vissza pl freenastól. meg vannak előre készített pluginok pl nextcloud egy kattintás.persze ezek megoldhatóak más op rendszerek alatt is csak sokszor nehezebbek.
az unraidet meg azért írtam mert tudtommal az egyetlen ahol nem raid van mégis van valamiféle parity drive és nem kell egyeznie a driveoknak, mint bármi más raidnél. otthoni felhasználásban megérheti azt az 50-60 usd-t. és akkor nem kell egybe megvenni az összes hdd-t. nyilván ennek teljesítménybeli hátránya van egy pici a hagyományos raidekhez képest de ezek nem otthoni felhasználásban jönnek elő.
-
Headless
őstag
válasz
Sanya228
#15257
üzenetére
otthoni használatra, igazából.
router/fw mehetne egybe, akár openwrt alapon
a gigabit link különbőző eszközökhöz egyértelmű hogy switch. Ha nem tervezel jelenleg bővíteni esetleg 10 gbitre akkor 8-16 portos switcheket kapsz "bagórért" akár irodában leselejtezetteket is használtan.
routeren/ tűzfalon elég egy wan/lan port.
accesspoint mindenképp külön vennék, nem tudom jelenleg mik vannak consumer kategóriában amik jók.
nas-ra én freenast használnék, viszont ha inkább össze-vissza tennél hdd-t bele mindig akkor bővítve amikor betelik, akkor érdemes lehet elgondolkozni unraid-en.
de ezek már inkább belépő enterprise szintű os-ek. De ha van időd átnézni a részletes dokumentációt, valamint úgy mész oda, hogy azért konyítasz hozzá nem lesz gondod. rengeteg plussz feature-el.
"kis" irodában még mindig nem jutottam el oda, hogy külön boxot építsek router/fw-nek jelenleg is egy openwrt-s mi router 3g megy wifit is szór. alapvetően jó kis cucc az olcsó is és nem is fogyaszt sokat, ami azért egy ősrégi pc-ről nem mondható el.
még vpn-t is képes szolgáltatni persze nem gigabitet, de azért openvpn-el tud egy 20-30 mbps-t.
-
Headless
őstag
válasz
Sanya228
#15254
üzenetére
Ha már pc-ből routert, szerintem ott vannak azért komolyabb OS-ek is. illetve pontosabban mit akarsz nas-t vagy tűzfalat/routert? mert mindkettőhöz van külön os.
nas pl freenas,
tűzfalhoz pl pfsenseA saját területén ég és föld a különbség, persze csak ha ilyen egyszerű mindenes valamit akarsz akkor jó az openwrt is.
Amúgy pc-ből routerre még annyit, hogy a wifi részt mindenképp egy külső accesspointra tenném, függetlenül a pctől... Szóval az ilyen usb-s wifi stickekkel ne szívnék, mert vannak pl olyan driverek simán, amik a host módot nem támogatják pl...Meg hát ezeknél bármi jobb stabilitást tudna adni szerintem... Akár a jelenlegi routereid egyikét befogod ap-nak.
-
Headless
őstag
válasz
Gabesz87
#15249
üzenetére
ahogy írtam korábban a dns szervert állítsd át pl google dns-re (8.8.8.8 illletve 8.8.4.4), valószínű nem rendelkezik dns szerverrel a thome-os router, hanem csak dhcp-n továbbít egyet. Ezért "nincs net" a routeren, mert itt manuális ip konfigurációt helytelenül adtad meg.
-
Headless
őstag
válasz
Gabesz87
#15246
üzenetére
tehát akkor valamiféle virtuálisgépen van az openwrt ezzel jól megbonyolítva az egészet, miért kell ez? android alapon is van valami torrent kliens...
miértnem rakod fel a mir3g-re mondjuk az egész torrentezős dolgot...
ebben nem tudok segíteni neked, nem ismerem az eszközt és a virtualizációját. de ott lesz a hiba...
-
Headless
őstag
-
Headless
őstag
válasz
Gabesz87
#15242
üzenetére
Először is nagyon sok mindent keversz.
A letöltés zárt port esetén is el kell, hogy induljon. ott valami más lesz a hiba. Kezdjünk az alapokkal van internet a zidon? luci -> network diagnostic, ping google.com
kapsz választ? ha nem, akkor nincs nete a zidonak. Itt azt állíthattad el, ha statikus ip-re van állítva a zido, akkor a gateway-t és dns-t lehet kihagytad a konfigurációból... gateway a telekom router ip címe, dns, ondjuk google dns 8.8.8.8 és 8.8.4.4.
Ha ezeket beállítottad ugorj megint diagnosztikára... Ha megjavult örülsz, ha nem részletes képet adj mi hova hogyan kötve és konfigurálva....
Távoli eléréshez lan ip címmel nem fog menni... először próbáld meg lanon (wifin) elérni a transmission remote-ot... Ha ez megy, akkor két felé vezet az út,
ami brámelyik úthoz kelleni fog:
-nézd meg, hogy publikus ip címed van-e... telekomos router wan ip címe egyezik-e pl a whats my ip oldalon találhatóval
-ddns konfigurálásaa biztonságos, nehezebb út: VPN konfigurálása és lan ip cím használata
a kevésbé biztonságos: port forward létrehozása a 9091-es portra és a ddns címedet írod be a transmission remote appba. (azt hozzáteszem, ha a telekomos hgw-n nincs nat loopback ebben az esetben külön konfiguráció fog kelleni otthoni és nem otthoni vezérléshez...) -
#15135
Headless
őstag
LiteCross91
#15134
Headless
őstag
válasz
LiteCross91
#15134
üzenetére
kulcsszó a szoftveres/hardveres offload ha ez nincs gargoylban, akor nemtudsz mit tenni, csak ha access pointként használod.
ha natolni akarsz, akkor pedig marad az openwrt vagy a gyári.
-
#15129
Headless
őstag
LiteCross91
#15127
Headless
őstag
válasz
LiteCross91
#15127
üzenetére
tesztelni, nem teszteltem, de beírni be lehet. Bár én továbbra sem értem minek a külön alkalmazás ott van a router gond nélkül ébreszteni fogja minden esetben.
vargalex: akkor van gond, ha a gépen tiltva van az imcp a tűzfalban. szerintem windowsban alapértelmezetten már egy ideje tiltva van alapból.
-
#15126
Headless
őstag
LiteCross91
#15125
Headless
őstag
válasz
LiteCross91
#15125
üzenetére
Azt nem értem miért szenvedtek ezekkel.
A wake on lan lényege, hogy broadcasoljon. egy bizonyos magic packetet, miért forwardoltok tűzfal szabályall fix ip-re ami lehet nem is létezik, ahelyett, hogy a lan broadcast ip-re forwardolnátok, így akár több gépet is feltudtok éleszteni, ahogy ki lett találva.
szimplán a tűzfalban csak a broadcast ip-t adod meg, mint cél ip 192.168.XXX.255
ha már ennyire külön alkalmazást akartok használni a wake funkcióra. -
Headless
őstag
válasz
woodworm
#15078
üzenetére
Ez már az újabb verzió
Ahol iptables szabályból mértem az adatot, itt ha flow offload van vagyis kikerülöd a tűzfalat, nem lesz adatod... , volt egy régebbi, ami az interfész adataiból szerzi az adatokat,
Azt nézd, meg, hogy ha a flow offload be van kapcsolva, akkor az interfészen látható adatforgalom nő-e... Ha igen akkor arra vissza kell írni a mentő scriptet és menni fog..
UI: mint írtam a kliensen szükséges internet kapcsolat a grafikon rajzoláshoz, mert a google chart javascriptet onnan húzza be, nem raktuk bele közvetlen a mentésbe, hogy ne foglalja a helyet. Azért dobta be a táblázatot, ha nem volt neted
-
Headless
őstag
válasz
woodworm
#15076
üzenetére
szia,
az adatgyűjtő scriptben lehet valami változás azt kéne megnézni rendben van-e. ha jól emlékszem a wan interfészen lévő transferred byteokat vizsgálja a script. (de lehet, hogy az újabb már a tűzfal szabályokkal operál) flow offload be van kapcsolva? mert ha a tűzfalas, és flow offload van akkor az offloaded rész nem fog megjelenni.
azt kéne megnézni, hogy ott bekerül-e mint forgalom?
a cstat_wan konfig fájlt mutasd meg de az a baj, nem nagyon van már környezetemben openwrt-s eszköz mostanság.
-
Headless
őstag
válasz
woodworm
#15064
üzenetére
szia!
mi annó csináltunk egy webfelületet.
szerintem elég egyszerű a használata szép google chartokat használ. internet kell hozzá a kliensen mondjuk, cserébe nem képeket ment/generál hanem csak adatokat tárol.
egy próbát megér most suste oldala nem tudom elérhető-e. de ha kell előhalászom a mentést és felrakom drivera.
ui: itt van pár hasznos link a fent említettekhez [link]
-
Headless
őstag
válasz
Gyurka6
#15061
üzenetére
első körben csinálj egy mentést a teljes blokk deviceról ehhez szükséges lesz egy másik hdd-re ami annál nagyobb.
dd if=/dev/sda of=/output_path/sda.isoezzel a jelenlegi állapotot lemented.
ha ez megvan akkor kell keresni megoldásokat. hurtelen ilyeneket találtam, de google... vagy ha olyanok vannak rajta, akkor adatmentő cégekhez fordulhatsz vagy itt ph-n is van topikja ezeknek.[link]
a lényeg, hogy mentést csinálj azonnal, még mielőtt fel lenne csatolva a swap.
-
Headless
őstag
válasz
Headless
#15028
üzenetére
ÓÓÓÓ hogy az a jóédes...
egy reboot kellett neki, valamiért, reboot után változatlan konfigokkal rendbe jött, azt gondolom hogy itt a host/guest közötti kapcsolatban volt valami fenn akadás, guestet újraindítva jó is lett...
utáálom, az ilyent, amikor jó valami de mégsem...
-
Headless
őstag
válasz
vampire17
#15026
üzenetére
Végülis melyik irányba mész? tűzfal, vagy route?
különbözik akettő út, ha tűzfal, akkor elvileg nem szükséges "AllowedIP"-hez hozzáadni, mert ügye azt a tűzfal egy masquerade-el megoldja, így minden kliens igazából a két végpont közötti ip címmel fog csomagot küldeni a másiknak.
Igazából ennyi amit bekell állítani.
Még kérdés, hogy ezek az eszközök gateway-ek a saját hálózatukban?
Gondolom igen.tehát ami kéne egyik tartományból forward a másikba, masq ráküldése.
A routeolt megoldással szenvedek én is most.
Nekünk ez a felállás:
szerver oldalon: Router-gateway -> lan -> Wireguard server (archlinux)
-amit én eddig megcsináltam a gatewayen statikus route a wireguard szerverre a vpn tunnel hálózatával.
-wireguard szerveren ez a leírás alapján systemd szervízként konfigoltam. [link]
-engedélyezve a net.dev.ip_forward sysctl,Ami megy:
kliens eszközről tudom pingelni a wireguard szervert mind lan ip mind vpn ip alapján. viszont valamiért nem forwardolja a többit a lan tartomány gateway felé, legalábbis ennyit látok. nem tudom hogy lehetne többet kideríteni...
#server oldali lan tartomány alapértelmezett átjárója nem elérhető (openwrt router)
traceroute to 192.168.152.1 (192.168.152.1), 30 hops max, 38 byte packets1 10.0.212.1 (10.0.212.1) 43.500 ms 52.200 ms 43.860 ms2 * * *#server lan ip címe elérhető (archlinux VM)
traceroute to 192.168.152.31 (192.168.152.31), 30 hops max, 38 byte packets1 192.168.152.31 (192.168.152.31) 55.720 ms 58.160 ms 38.820 ms#server vpn címe elérhető (archlinux VM)
traceroute to 10.0.212.1 (10.0.212.1), 30 hops max, 38 byte packets1 * 10.0.212.1 (10.0.212.1) 13.920 ms 11.960 msmásik irányba pedig szintén csak a wireguardig szerverig jutok... nem megy be a wireguard csatornába
traceroute to 10.0.212.2 (10.0.212.2), 30 hops max, 38 byte packets1 192.168.152.31 0.515 msroute tábla a wireguard szerveren
default via 192.168.152.1 dev enp0s4 proto dhcp src 192.168.152.31 metric 20210.0.212.0/24 via 10.0.212.1 dev WG-SRV0 proto static192.168.152.0/24 dev enp0s4 proto dhcp scope link src 192.168.152.31 metric 202egy nagyon hasonló setup, ami működik, és nem tudom miben különbözik... tudtommal ugyanezeket állítottam be...De az meg megy...
server oldali lan tartomány alapértelmezett átjárója elérhető...
annyi, hogy itt a default gateway egy mi router 3g padavannaltraceroute to 192.168.150.1 (192.168.150.1), 30 hops max, 38 byte packets1 10.0.11.1 (10.0.11.1) 7.480 ms 6.160 ms 6.600 ms2 192.168.150.1 (192.168.150.1) 13.520 ms 8.580 ms 9.740 ms -
Headless
őstag
válasz
yodee_
#14994
üzenetére
mi lenne ha elfelejtenéd ezeket az alkalmazásokat és routeren keresztül ébresztenéd fel?
luci szolgáltatások -> wol
br-lanra szórod és kiválasztod a macet...ha mindenképp alkalmazást akarsz, valószínű az a baj, hogy a az ip cím nem létezik arp-ban. próbáld meg, hogy broadcast ip-re forwardolod a portot x.x.x.255-ös a broadcast ip.
-
Headless
őstag
opkg update csak a csomagokat frissíti. Nem magát az openwrt-t routereken ilyet általában nem csinálunk, főleg nem kernel modulokkal amit nyilván csinált az update.. Ha frissíteni akarsz új fwt szedsz le és telepítesz.
Mivel az openwrt gyári particiója read only ezért egy sima factory reset megfogja oldani a problémád.
Persze config fájlokat lementeném előtte. Ne kelljen mindent előlről kezdened... -
Headless
őstag
válasz
Archttila
#14678
üzenetére
Két lehetőséged van, vagy elmented kivételnek, vagy pedig felraksz valami rendes kulcsot ezek vagy fizetősek, vagy letsencryptet tudsz ingyen, de 3 havonta frissíteni kell, jah és nem használhatsz ip címet valószínű az eléréshez.
Szóval maradjunk annyiba, hogy hozzáadod kivételnek.
-
Headless
őstag
válasz
CheGhost
#14655
üzenetére
Igazából a wireguard nem egy konvencionális szerver hanem peer to peer ezért irták el valószínű.
A lényeg, hogy minden kliens nek van egy private key-e és egy public key-e. És a public keyt kell megadni a másik kliensnek, hogy a handshake megtörténjen.
Röviden
wg genkey > privkey
wg genkey <privkey >pubkeyTermészetesen ez két fájlt fog létrehozni az éppen aktuális mappába. privkey és pubkey néven.
-
Headless
őstag
Ha hiba nélkül lefordul, de nincs image az általában azt jelenti, hogy túl nagy a mérete,nem férne bele az adott router flashébe a kijelölt csomagok. Sajnos ez esetben szelektálnod kell mit vehetsz még ki. Vagy a squashfs size-t növeled. De ezt imagebuilderrel nem tudom hol lehet.
-
#14564
Headless
őstag
SteveBeard
#14563
Headless
őstag
válasz
SteveBeard
#14563
üzenetére
Nem, még kell a konfig fájl a /etc/config mappából. És ha kliensed is volt, akkor az még mást is igényel, egyrészt egy etc/init.d/vpnclientX valamint a hozzá tartozó konfig fájlt azt most így fejből nem tudom hova teszi a webes script.
-
#14562
Headless
őstag
SteveBeard
#14561
Headless
őstag
válasz
SteveBeard
#14561
üzenetére
szia! az openvpn certificatek az /etc/openvpn mappában és/vagy a /etc/easy-rsa mappában találod meg.
-
#14123
Headless
őstag
st3v3np3t3r
#14122
Headless
őstag
válasz
st3v3np3t3r
#14122
üzenetére
hogy kötötted be?
TX->RX
RX->TX
GND->GNDHa így akkor nem tudom mi lehet még, ha a sebességek megfelelőek.
Az csak szerencséd, hogy nincs soros port a gépen mivel az feszültség illesztés nélkül zétégette volna a routert a 12 V-al
CH340 szerintem bőven jó, én cp2102-őt használok, de ugyanaz kb.
-
Headless
őstag
válasz
Headless
#13948
üzenetére
mint kiderült azért nem értem el a benti hálózatot, mert szerelés miatt nem volt áram...
igen itt volt a kutya elásva vagyis az engedélyezett ip címeknél. Mivel én gondozom mindkét hálózatot inkább engedélyeztem a megfelelő ip-ket rendesen, mint hogy egy felesleges plusz natot bele tegyek a kapcsolatba. Bár nem túl jó a késleltetés, de nem is olyan rossz immár működik "újra" padavan routerrel.
oda:
traceroute to 192.168.151.30 (192.168.151.30), 64 hops max, 40 byte packets
1 192.168.150.1 (192.168.150.1) 0.761 ms 0.339 ms 0.392 ms
2 192.168.150.72 (192.168.150.72) 0.451 ms 0.486 ms 0.415 ms
3 10.0.11.5 (10.0.11.5) 32.524 ms 33.478 ms 28.672 ms
4 192.168.151.30 (192.168.151.30) 36.503 ms 30.101 ms 34.010 msvissza (azért rövidebb mert a router kapcsolódik a VPN-re):
1 XiaomiMiRouter3G.lan (192.168.151.1) 0.353 ms 0.396 ms 0.469 ms
2 10.0.11.1 (10.0.11.1) 36.636 ms 31.419 ms 36.571 ms
3 192.168.150.30 (192.168.150.30) 36.602 ms 36.684 ms 36.720 msRemélem ezzel már kevesebb problémám lesz. az új openwrt-vel (kb 8300-as release óta) a dir 860, mir3g esetében nagyon nem stimmelnek a dolgok... Csak openvpn, wireguard szolgáltatásokat és sok klienst látnak el wifi-s (~15-20 db) plusz lanos (~30 db) eszközöket. Naponta egyszer behalt a hálózat, wifi mindig rossz volt kb.
Most majd megpróbálok váltani itthoni környezetben is ha jónak bizonyul... itthon is szenvedek mostanság, nem tudom mi okozza, de szörnyen lassú a webes felület is, sokszor újra kell tölteni történjen bármi is... kodi szintén nagyon lassú, mysql szerver a routeren fut. Csak itthon nem akarok külön eszközt a VPN-hez és úgy megszoktam már a WireGuardot, nem akarok visszaállni openvpn-re... úgyhogy azt külön kéne lebuildelnem... ráadásul régi kernel lehet nem lenne egyszerű...
-
Headless
őstag
válasz
vargalex
#13946
üzenetére
Valószínűleg ez lesz a megoldás, de most valamiért nem érem el az eszközt, lehet a ddns scriptem hibádzik valahol. ebben az egyben különbözik a routeren futtatott wg-vel... korábban a szerverként futtatot wg-n ngedélyeztem a más ip tartományból jövő kapcsolatokat. Csak nem rebestartoltam az interfészt így nem volt engedélyezve.hétfőn ennek utána járok.
-
Headless
őstag
Sziasztok!
Valami gubanc mindig előjön és ilyenkor nagyon sok időt el tudok vele rontani...
2 helység van cél wireguardal összekötni:
1. hely WG server openwrt routeren (telefonnal, másik routerrel tudok csatlakozni)
2. hely archlinux kliens router egy padavan (lecseréltem az openwrt-t, sajnos nem volt százas mostanság...)ha az archlinuxról közvetlenül próbálok, akkor minden patent:
traceroute to 192.168.151.30 (192.168.151.30), 30 hops max, 60 byte packets
1 10.0.234.1 (10.0.234.1) 29.123 ms 29.762 ms 30.081 ms
2 192.168.151.30 (192.168.151.30) 30.290 ms 33.676 ms 33.547 msaz arch linuxal egy hálózatban lévő gépeknél viszont már nem annyira patent...
Tracing route to 192.168.151.30 over a maximum of 30 hops
1 <1 ms <1 ms <1 ms 192.168.150.1
2 <1 ms <1 ms <1 ms adc1 [192.168.150.72]
3 * * * Request timed out.
4 * * * Request timed out.
5 * * * Request timed out.padavanon beállítottam a megfelelő route-ot hogy az archlinuxra küldje a csomagokat a megadott subnetről:
/home/root # ip r
default via 80.98.255.254 dev eth3 metric 1
10.0.11.0/24 via 192.168.150.72 dev br0
10.8.0.0/24 dev tun1 proto kernel scope link src 10.8.0.1
80.98.248.0/21 dev eth3 proto kernel scope link src 80.98.252.217
127.0.0.0/8 dev lo scope link
192.168.150.0/24 dev br0 proto kernel scope link src 192.168.150.1
192.168.151.0/24 via 192.168.150.72 dev br0arch linux routing table:
[root@adc1 alarm]# ip r
default via 192.168.150.1 dev eth0 proto dhcp src 192.168.150.72 metric 1024
10.0.11.0/24 via 10.0.11.1 dev WG-SRV0 proto static
10.0.234.0/24 via 10.0.234.1 dev WG_CL0 proto static onlink
192.168.150.0/24 dev eth0 proto kernel scope link src 192.168.150.72
192.168.150.1 dev eth0 proto dhcp scope link src 192.168.150.72 metric 1024
192.168.151.0/24 via 192.168.151.1 dev WG_CL0 proto static onlinktűzfal archlinuxon nincs. (a padavanos router végzi ezt)
ipv4 forward engedélyezve az archlinuxon...
[root@adc1 alarm]# sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 1Én biztos vagyok benne, hogy ez vagy routeolási vagy forwardolási gond lesz az archlinuxon, elvégre az látszik, hogy a csomag odáig eljut. Valamint az archlinuxról ügye elérem sőt még lucit is...
egyszerűen nem értem ezeket...
ennek mennie kéne. -
Headless
őstag
válasz
Headless
#13922
üzenetére
Csak hogy visszatérjek picit.
Nem tudom, hogy konfigurációs hiba, vagy sem, de lecserélve a beépített DNS szervert BIND-re az összes probléma megoldódni látszik, FreeNas is tudott kapcsolódni az AD-hoz, ahogy a windowsos gépek is gond nélkül. Következő talán egy második DC hozzáfűzése replikálva. Meg az egyéb szolgáltatások átállítása LDAP hitelesítésre.
-
Headless
őstag
válasz
vargalex
#13921
üzenetére
Gondoltam, hogy számíthatok rád
A samba beépített DNS szerverét használod?
Igen beépített DNS szervert használtam, a provisioning alatt.Biztos, hogy nem csak localhost-on hallgat?
Nagyon jó kérdés. A samba maga igen elérhető más interfészről is. nem tudom, hogy ez a beépített DNS szerverre is igaz-e... látom a netlogon, és sysvol megosztásait. Az adminisztrátor felhasználóval.A routeren futó dnsmasq-tól IP-t kapó eszközök hostneveit is fel kellene oldalnia?
Az én elméletem, hogy a routeren futó dns szervert egy az egyben ki kéne kerülni. az hogy abba a dns szerverbe hogy fog bejutni, azon később foglalkozok, de nekem úgy tűnt, hogy amint csatlakozik a DC-hez egy eszköz, az megkapja a megfelelő DNS beállításokat a Gépnév a gépeknél is helyesen van beírva. De ez még messzebb van. (ezt akkor csináltam, amikor sikerült a saját dns szerverét megkerülve bejutnom az AD-be.)Itt van egy leírás a DNS forwardolásról, csak sajnos össze vissza vannak keverve a remote.local, hostname.lan, example.local és stb... próbáltam összehozni, de sajnos itt a DNS, domainek működésében egy kicsit fenn akadtam...
pl a dnsmasq-ban is lehet megadni domain-t alapból
option domain 'lan'
option local '/lan/'nah de pl a FreeNas esetében is meg KELL adnom, ezeknek igazából meg kell egyezniük vagy sem? sok fekete folt van még.
-
Headless
őstag
Sziasztok!
Tapasztaltabbaktól van egy kis kérdésem elém került egy feladat, és kicsit fenn akadtam.
Hogy vázoljam mi is a feladat.
1 gép Archlinux 192.168.150.72: wiki alapján elkezdtem beállítani Active Directoryként a samba 4-et. resolv.conf módosítás után elérhető az összes szolgáltatás erről a gépről tökéletesen. (minden test ami itt található átmegy)
2 gép dir860l openwrt 192.168.150.1: dhcp szerver, primary DNS szerverként hirdetem az archlinuxot vagyis a Domain Controllert.
3. minden más gép: megkapják a primary dns címet helyesen: 192.168.150.72 másodlagos,harmadlagosnak pedig google/open dns-t. Viszont a szolgáltatások nem érik el az archlinuxon futó dns szervert, vagy pedig nincs jól konfigurálva. Így az Active Directory-t sem. már a test elején vagyis a dns tesztelése során elbukik a történet. semelyik host parancs nem talál címet, ping sem megy.
Archlinux egy tiszta telepítés tűzfal nincs.
1 valamikor működött félig a dolog. Méghozzá amikor a megfelelő SRV, A DNS-eket regisztráltam a dnsmasq-ban, de így igazából csak a Domain Controller DNS szerverét kerültem ki, és így sem volt tökéletes, mert a hálózatban lévő FreeNAS eszköz nem tudott csatlakozni a Directoryhoz, habár a Windpows 10-es kliens tudott. RSAT-ben el is értem és tudtam konfigurálni is rendesen az AD-t.
-
Headless
őstag
válasz
fpeter84
#13750
üzenetére
Ha a gyári kerneled megvan akkor módosítatlanul rajta vagyis a leírásokat követve flasheltél, akkor a leggyorsabb azt használni... Leírtam már korábban keress rá. Igazából csak belépsz uboot terminálba soros porton keresztül, majd módosítod a boot environmentet úgy, hogy a második failed legyen ekkor failbackel az első rootfs/kernel párosra ahol a gyári usb recovery fog várni.
-
Headless
őstag
válasz
fpeter84
#13742
üzenetére
Ha lan ip-t átkell írnod, akkor azt ne luciból tedd... Mivel az új luci ellehetetleníti a lan ip módosítást, mivel állandóan visszaállítja. Inkább írd át konfigba és reboot.
Majd felrakom valamikor ha nagyon kell, vagy inkább egy makefile-t adok annak több értelme van.
Amúgy meg fontold meg a switch üzemmódot. Mert minek két hálózat egy lakásba
-
Headless
őstag
válasz
fpeter84
#13739
üzenetére
Ha másképp nem meg vagy konfig fájlban kell átírni, vagy shell
uci set luci.main.lang=en
uci commit luci
/etc/init.d/uhttpd restartA többi is biztosan user error, konfigurálni kell megfelelően.
Amúgy meg szerintem mindegy a verzió, csak ti kihagytatok valamilyen csomagot, ami szükséges az usb támogatásból nem hinném hogy egy ekkora bug benne maradna a stabil kiadásba.
-
Headless
őstag
válasz
fpeter84
#13736
üzenetére
Nem nyúltam semmihez. Aminek az interfészekhez, van köze. Magyar nyelv csak egy kérés volt nyilván az angol is benne van. Én sem szeretem a magyart. Wan port, pppoe vagy dhcp, vagy statikus? Konfiguráltad megfelelően?
Amúgy git checkouttal tudsz visszamenni egy adott commitra a hash segítségével. Annyi biztos, hogy 18.06-os forrásból van a legutolsó build. Nem masterből.
Sambat használom működik, igazából dlna-n kívűl mindent használok benne és tudom, hogy működnek. Leggyakrabban használt dolog samba, wireguard openvpn, mariadb, file storage ext4-el, wol,transmission.
Igazából be van konfigolva alap állapotban szóval sok dologhoz nem kell hozzányulni. Persze ha szeretnéd kicsit jobban testre szabni, akkor lehet, de nem létfontosságú, samba pl alapból megy dlna-t transmissiont, csak hdd-t kötsz rá formázod 9092-őn ha már ext4 hdd,akkor átnevezed mnt-re és akkor csarolja automatikusan /mnt-be. Onnantól kezdve transmission és dlna-t is csak engedélyezni kell, de suste tárhelyén rengeteg plussz readme ha most használsz előszor olyan fw-t amit mi csináltunk.
-
Headless
őstag
válasz
fpeter84
#13731
üzenetére
módosítás nincs, csak benne vannak a csomagok, valamint a kiegészítő webes felületünk (http://router_ip:9092), de a kódbázis csak git checkout-al lett frissítve.
konfigokat nem tartalmaz. Az automount amiben egy kicsit különbözik, ez egy hotplug.d script ami automatikusan mountolja a külső meghajtókat bedugáskor. De ha használtál már általam/suste által készített buildet akkor ez ismerős lehet.
kernel konfig módosítás lehet van benne, de szerintem már ők is átálltak, az O2-es optimalziációra changelog van a driveomban a build mellett.
SZERK: nincs uas benne.
ugyanis pont az volt beállítva ami kell, vagyis a remote az nem férhet hozzá az én lanomhoz.
elég nagy hatóávolságot tudnak már ezek.. és szerintem nem lesz nagyobb input lag mint ezekkel a usbip és társaival. persze ha 30 m-re van a gép, nem fog menni de szerintem 10 m-en biztosan menni fog.
Látszik melyik gépről, milyen felhasználó használja az adott kulcsot és admin fiókkal ki is lőhetőek azok. Nekem nagyon bevált a két napos usbip szenvedés után 10 perc alatt konfigurálható volt.
ha csak ez tartana vissza pl freenastól. meg vannak előre készített pluginok pl nextcloud egy kattintás.
Új hozzászólás Aktív témák
- Mini PC
- Folyószámla, bankszámla, bankváltás, külföldi kártyahasználat
- Milyen Android TV boxot vegyek?
- Samsung kuponkunyeráló
- YouTube
- Luck Dragon: Asszociációs játék. :)
- Autós topik
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Brogyi: CTEK akkumulátor töltő és másolatai
- Vezetékes FEJhallgatók
- További aktív témák...
- LG 27GR95QE - 27" OLED / QHD 2K / 240Hz & 0.03ms / NVIDIA G-Sync / FreeSync Premium / HDMI 2.1
- BESZÁMÍTÁS! Sapphire B650M R7 8700F 32GB DDR5 1TB SSD RX 6800 16GB Zalman Z1 PLUS Seasonic 750W
- ÁRGARANCIA!Épített KomPhone Ryzen 5 7500F 32/64GB DDR5 RTX 5060 8GB GAMER PC termékbeszámítással
- Bomba ár! HP ProBook 440 G8 - i5-11GEN I 8GB I 256SSD I HDMI I 14" FHD I Cam I W11 I Gar
- Készpénzes / Utalásos Számítógép felvásárlás! Személyesen vagy Postával!
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: Laptopszaki Kft.
Város: Budapest