Hirdetés
- Videós, mozgóképes topik
- Calibre, az elektronikus könyvtár
- AMD Ryzen 9 / 7 / 5 7***(X) "Zen 4" (AM5)
- Példátlan a 2 nm-es TSMC node iránti kereslet
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Milyen videókártyát?
- Akciókamerák
- ASUS ROG Ally
- NVIDIA GeForce RTX 5080 / 5090 (GB203 / 202)
- Milyen TV-t vegyek?
-
PROHARDVER!
OpenWrt topic
Új hozzászólás Aktív témák
-
vargalex
Topikgazda
válasz
roti86 #20228 üzenetére
Ha jól nézem a fimrware-t (letöltöttem a sysupgrade snapshotot), kicsomagoltam belőle a squashfs-t, továbbra sincs benne LuCI. A csomaglista szerintem az általad linkelt oldalon csak a Request build-re vonatkozik (azaz a felsorolt csomaglista az imagebuilder paramétere lesz).
-
vargalex
Topikgazda
Szia!
fdisk
-el is nyugodtan particionálhattad volna (sőt, én linuxon is azzal szoktam).transmission-daemon
csomag nincs. Vantransmission-daemon-mbedtls
, vagytransmission-daemon-openssl
. Attól függően, hogy openssl-t, vagy embedded tls-t szeretnél használni a titkosított kapcsolatokhoz. -
vargalex
Topikgazda
-
vargalex
Topikgazda
válasz
E.Kaufmann #20214 üzenetére
Kernel csomagokon kívül mást frissíthetsz, persze, ha nincs valamilyen konkrét kernel függősége...
-
vargalex
Topikgazda
válasz
attila.86 #20213 üzenetére
Saját (vagy imagebuilder-es) build-be szerintem elfér az MC is. De sok értelme nincs, ha úgysincs USB, stb... Szóval, routernek szerintem bőven jó a Cudy. Illetve eddig azért volt itt az ajánlott, mert régebbi (és régebb óta támogatott) eszköz. Ráadásul gyártó által támogatott OpenWrt átállás webes felületről.
-
vargalex
Topikgazda
válasz
KergeTomi #20192 üzenetére
Na, ez gargoyle alatt már jól meg van bonyolítva. A tűzfal még behúzza a
/etc/wireguard.firewall
-t is (és még a/usr/lib/gargoyle_firewall_util/gargoyle_additions.firewall
-t, valamint a/etc/firewall.user
-t), amit ugye most így nem látunk, hogy mit csinál.
Illetve a Network config-ban a kliens definíciónál nem tudom mi az a remote, miért kell subnet_ip és mask... -
vargalex
Topikgazda
-
vargalex
Topikgazda
válasz
KergeTomi #20186 üzenetére
A korábban is linkelt leírás szerint a WireGuard network-ot be kell tenni a LAN tűzfal zónába. A tűzfalon pedig csak az a forgalmi szabály (rule) kell, amit írtam is, illetve a leírásban is benne van.
Ez az egyszerűbb történet. Lehetne saját zónába is tenni, a zónák között pedig átjárással, NAT-olással, ahogy az általad linkelt második leírás is csinálja. -
vargalex
Topikgazda
válasz
KergeTomi #20183 üzenetére
Abban a leírásban azért nem látod a forward-ot a vpn és a lan között, mert ott a wireguard vpn network-ot a lan zónába teszi:
uci del_list firewall.lan.network="${VPN_IF}"
uci add_list firewall.lan.network="${VPN_IF}"Ugye itt a biztonság kedvéért először törli belőle (ha benne lenne), majd beleteszi. A VPN_IF korábban van definiálva:
VPN_IF="vpn"
És ugye ilyen nevű network interface-t hoz létre:
# Configure network
uci -q delete network.${VPN_IF}
uci set network.${VPN_IF}="interface"
uci set network.${VPN_IF}.proto="wireguard"
uci set network.${VPN_IF}.private_key="${VPN_KEY}"
uci set network.${VPN_IF}.listen_port="${VPN_PORT}"
uci add_list network.${VPN_IF}.addresses="${VPN_ADDR}"
uci add_list network.${VPN_IF}.addresses="${VPN_ADDR6}"Szerk.: Egyébként a második linkeden nagyon nem a wan zónába teszi a wireguard network-ot, hanem saját zónát hoz létre neki.
-
vargalex
Topikgazda
válasz
KergeTomi #20180 üzenetére
Szia!
Ha a
list addresses '192.168.11.0/24'
config bejegyzésre gondolsz, akkor az jó szerintem, mert ott a VPN tartomány kell, hogy szerepeljen.
Azt továbbra sem értem a tűzfaladon, ha a wireguard network-ot a LAN zónába teszed, akkor mi értelme van saját zónát és átjárást definiálni a kettő között. Szerintem pont az zavarja meg a tűzfalat, hogy a wireguard network-od 2 zónában is benne van, amik között ráadásul átjárást is definiálsz.
Illetve aconfig redirect
option dest 'lan'
option target 'DNAT'
option name 'VPN'
option src 'wan'
option src_dport '1194'
option dest_ip '192.168.10.1'
option dest_port '1194'
list proto 'udp'helyett szerintem egy sima rule-ra lenne csak szükséged:
config rule 'wireguard'
list proto 'udp'
option name 'wireguard'
option src 'wan'
option dest_port '1194'
option target 'ACCEPT'Ezt a leírást követted egyébként? Nyilván itt command line van leírva, de könnyen átfordítható LuCI-ra.
-
vargalex
Topikgazda
válasz
KergeTomi #20177 üzenetére
Szia!
Én ugyan nem routeren használok Wireguard-ot, de amit látok:
- létrehoztál egy VPN zónát, benne a WireGuard network-el
- engedélyezted az átjárást a VPN->wan felé
- beraktad a WireGuard network-ot a wan zónába isUtóbbit miért tetted?
A VPN->LAN forward-ot miért nem engedélyezted?
A wireguard config-od hogy néz ki a router és hogy a kliens oldalon? -
vargalex
Topikgazda
válasz
Benoe77 #20158 üzenetére
Szia!
A sysupgrade egy tar-olt file, ami egy CONTROL file-t, a kernelt és a squashfs image-t tartalmazza. A CONTROL file egy 20 byte-os file, amiben a board típusa található, tehát elhanyagolható. A dts file-ban a kernel 4 MB-osnak, az ubi (squasfs) pedig 46 MB-osnak van definiálva. Viszont a kernel mérete dinamikus, pl. az általam most build-elt firmware-ban csak 2,28 MB. Így összesen ugye kb. 50 MB-os lehet sysupgrade file, de kibontás nélkül nem tudod, hogy mekkora belőle a kernel. De egyébként, ha a squashfs mérete nagyobb lenne, mint 46 MB, akkor nem állna elő a firmware bináris, hiszen ezt ellenőrzi a build keretrendszer.
-
vargalex
Topikgazda
OpenWrt alatt nem entware csomagok vannak. Az adott stabil kiadáshoz tartoznak repository-k, amikben található csomagok később már csak akkor frissülnek, ha valami sebezhetőség miatt feltétlenül szükséges (ilyen volt pl. anno az openssh). De egyébként a tailscale verziója a 23.05.4-es repo-ban 1.58.2, szóval nem tudom mi az a 17 és 15, amit írsz...
A snapshot verzió repo-jában pedig 1.70.0-r1 verziójú tailscale található.
(Ebből arra következtetek, hogy az általad írt 17 és 15, az valójában 1.7x és 1.5x).Annyit meg lehet próbálni, hogy a snapshot package repo-t (a core repo-t semmiképpen, mert kernel ütközés lesz) hozzáadod a forrásokhoz (van manuálisan csak a tailscale-t töltöd le) és telepíted a tailscale-t. Mivel nem kernel csomag, így nagy gond nem lehet. Csak libc, ca-bundle és kmod-tun függősége van, úgyhogy elvileg simán mennie kell.
Szóval, ezt csináld az eszközön:wget -O /tmp/tailscale_1.70.0-r1_x86_64.ipk https://downloads.openwrt.org/snapshots/packages/x86_64/packages/tailscale_1.70.0-r1_x86_64.ipk
opkg install /tmp/tailscale_1.70.0-r1_x86_64.ipkPersze a csomagot letöltheted PC-n is és felmásolod SCP-n a routerre.
-
vargalex
Topikgazda
válasz
UberMutant #20145 üzenetére
A transmissionnak annyi gondja van, hogy 1 magot használ. De egy x86-nak ez nem kellene, hogy gondot okozzon.
-
vargalex
Topikgazda
válasz
E.Kaufmann #20132 üzenetére
Azt csak én vetettem fel, mert nem derült ki, hogy volt-e közben újracsatlakozás (azóta kiderült, hogy nem).
-
vargalex
Topikgazda
válasz
BullZeye #20125 üzenetére
Rögtön a LuCI kezdő oldalon le tudod választani bármelyik wifi klienst, aztán majd újracsatlakozáskor kap új IP-t.
Vezetékes eszköznél a fizikai kapcsolatot (akár csak port kikapcsolással) kell megszakítani, hiszen ő a lease time feléig semmit nem akar a DHCP szervertől. Pl. PPPoE, VPN esetén tud a szerver oldal bontani.
A lease time-t szerintem felesleges 5 percre rakni ezért, mert akkor minden kliens 2,5 percenként DHCP kéréssel fogja “bombázni” a routert tök feleslegesen. -
vargalex
Topikgazda
válasz
BullZeye #20112 üzenetére
A lease time felénél az eszköz küld egy DHCP renew-t. Ilyenkor elvileg a dnsmasq válasz üzenetben NAK-ot küld és az új IP címet. De egy Air fryer-t nem olyan nehéz áramtalanítani...
Ha nem kapja meg az új IP címet, akkor vagy elírtad a MAC címet, vagy random MAC címet használ az eszköz... -
vargalex
Topikgazda
5 GHz-en tedd 80, vagy 160 MHz-re. Nekem 80 MHz-en van. Vodafone 500/22 Mbps net.
5 GHz-en AC-s klienssel (Intel AC egy Dell Notebook-ban) 866 Mbps kapcsolati sebességgel:2,4 GHz-en 40 MHz csatornaszélességel, 300 Mbps kapcsolati sebességgel (itt csak N-et tud a kliens):
SW és HW flow offload nálam ki van kapcsolva, ekkora sebességhet nem szükséges.
Ezeket a sebességeket az AC-s mobilok is tudják nálam (ez konkrétan egy iPhone XS Max):Itt egyébként láthatod, hogy 20 MHz esetén 2 Spatial Stream-al (gyaníthatóan olyan kliensed van) csak 173 Mbps a kapcsolati sebesség 5 GHz-en. Optimális esetben ennek a felénél valamennyivel több (max 2/3-a) van meg fizikailag.
-
vargalex
Topikgazda
válasz
E.Kaufmann #20069 üzenetére
Ez csak attól függ, hogy külön GPIO-ról vezérelhetőek-e, vagy az ethernet driverben megvalósították-e.
-
vargalex
Topikgazda
válasz
Celtis #20043 üzenetére
A config-ból hiányzik a
listen_http
, illetve opcionálisan alisten_https
attribútum, így az van, amire tippeltem, hogy nincs beállítva, hogy bárhol is hallgasson..
A teljes helyes config ez lenne:config uhttpd 'main'
list listen_http '0.0.0.0:80'
list listen_http '[::]:80'
list listen_https '0.0.0.0:443'
list listen_https '[::]:443'
option redirect_https '0'
option home '/www'
option rfc1918_filter '1'
option max_requests '3'
option max_connections '100'
option cert '/etc/uhttpd.crt'
option key '/etc/uhttpd.key'
option cgi_prefix '/cgi-bin'
list lua_prefix '/cgi-bin/luci=/usr/lib/lua/luci/sgi/uhttpd.lua'
option script_timeout '60'
option network_timeout '30'
option http_keepalive '20'
option tcp_keepalive '1'
option ubus_prefix '/ubus'
config cert 'defaults'
option days '730'
option key_type 'ec'
option bits '2048'
option ec_curve 'P-256'
option country 'ZZ'
option state 'Somewhere'
option location 'Unknown'
option commonname 'OpenWrt'Természetesen a
listen_https
,cert
éskey
attribútumokat ki is szedheted, ha nem akarod, hogy https-en is figyeljen. -
vargalex
Topikgazda
válasz
@Jocó@ #20035 üzenetére
Az aktuális config-jaim alapján (még jobb egy
uci show network
, stb. parancs kimenete) írtam meg magam az uci parancsokat. Nem egy nagy dolog ezek birtokában...
És ugye csak azok kellenek, amik a default-tól eltérnek, vagy új config bejegyzések. Így egy esetleges változás esetén nem valószínű, hogy buktató lenne... Nekem az egész egy 418 soros script lett... Ebben network, system, ddns, wireless, dhcp, firewall, adblock config-ok vannak. -
vargalex
Topikgazda
válasz
E.Kaufmann #20033 üzenetére
Én pont ezért nem konkrét config-okkal buildelek (manapság lustaság miatt már inkább csak imagebuilderrel, amihez írtam egy shell scriptet, hogy még egyszerűbb legyen), hanem uci-defaults scriptet teszek be, ami első indításkor lefut és minden config-ot helyesen beállít. Hogy univerzális legyen wifi szempontból is, kiolvassa, hogy melyik a 2,4 GHz-es rádió es melyik az 5 GHz-es és így biztosan a megfelelőnél fogja a számomra szükséges értékeket beállítani.
-
vargalex
Topikgazda
válasz
E.Kaufmann #20017 üzenetére
Látom, az előbb nem is jól linkeltem a wiki-t. Most viszont javítottam a leírást/linket.
-
vargalex
Topikgazda
válasz
E.Kaufmann #20015 üzenetére
Én még ki sem bontottam és nem mentettem le korábban a Cudy által aláírt firmware-t. De az OpenWrt wiki-ben hivatkozott új site-ról elérhető Google Drive linken ott a letölthető firmware. Vagy ez nem ugyan az?
-
vargalex
Topikgazda
válasz
E.Kaufmann #20005 üzenetére
Épp írni akartam. Én is rendeltem, ma át is vettem. Sőt, ha még nem használtad fel (vagy új regisztrációval, esetleg regisztráció nélkül másik e-mail címről rendelsz) a kuponkódot, akkor 1500 Ft lejön belőle. A kuponkód:
ujD8AJp5DHzml913rAd
(15000 Ft kosárérték felett érvényes, de ugye a router éppen túllépi azt).Szerk.: most nézem, hogy van egy felbontott is, picivel olcsóbban (kupon nélküli árnál olcsóbb).
-
vargalex
Topikgazda
válasz
E.Kaufmann #19992 üzenetére
Most nézem a képet. Az is gond lehet, hogy a VPN zónánál nincs engedélyezve a LAN zónába forward-olás, csak a WAN-ba.
-
vargalex
Topikgazda
válasz
gyulank #19971 üzenetére
De az ONT-ban kikapcsoltad a DHCP szervert? De ezekre a számokra történő hivatkozásokat szerintem felejtsük el, mert neked lehet, hogy mond valamit, de nekünk nem... Szerintem jobban jársz, ha fizetsz valamilyen összeget egy hálózatokban jártas embernek, aki beállítja ezt neked, mert (ne haragudj, hogy ezt írom) láthatóan neked nem megy.
-
vargalex
Topikgazda
válasz
gyulank #19958 üzenetére
Nem mondom, hogy teljesen értem, amit írtál. Mi az 1.6? (Gondolom 192.168.1.6, de melyik eszköz)? Az AP ezek szerint 192.168.1.15. Az ONT 192.168.1.20-tól oszt. A kamerát nem értem. Azt írod, hogy az 192.168.1.7, pedig az ONT-on 192.168.1.23-ra van beállítva a lease, de mégis 192.168.1.26? Akkor most 192.168.1.7, vagy 192.168.1.26??? Vagy a 192.168.1.7 az egy másik router/AP lenne, amire a kamera van csatlakoztatva?
Az is megoldás lehet, amit a kolléga ír. Ha lehet, akkor az ONT-on kapcsold ki a DHCP-t, azt bízd valamelyik saját eszközre. Azt nem mondom, hogy az ONT-ot tedd bridge-be és a a NAT-ot is bízd a saját eszközre, mert a gigabithez OpenWrt-vel a TL-WDR4300 kevés.
-
vargalex
Topikgazda
válasz
gyulank #19954 üzenetére
A WDR4300-on ha a 2,4 GHz-es wifi-re csatlakozol, akkor még normális is lehet az a sebesség. Viszont akkor is normális lehet, ha az 5GHz-re, de a kliens csak 1 antennás, mert ugye a TL-WDR4300 csak n-es wifi-t tud.
Az AP vezetéken, vagy wifi-n csatlakozik a TL-WDR4300-ra (ha oda)? Ha wifi-n és a 2,4 GHz-re, akkor szintén elfogadható a sebesség... -
vargalex
Topikgazda
válasz
xabolcs #19937 üzenetére
Valóban, meg sem néztem a linket, valamiért egy általános fa struktúrát gondoltam mögötte.
Hát, ebből nem látszik, hogy a dumb AP bármi gondot is okozna... Legfeljebb az okozhat IP ütközést, amit írtam. Nyilván minden eszköznek lesz egy management IP-je (ez az OpenWrt routerek esetén a LAN IP lesz), ezek nem ütközhetnek és ahogy írtam, mindenképpen a DHCP tartományon kívülieknek kell lenniük, hogy a DHCP szerver véletlenül se ossza ki egyik kliensnek sem a címet. -
vargalex
Topikgazda
válasz
gyulank #19935 üzenetére
Pedig jó kell, hogy legyen, ha jól van beállítva. Nyilván az eszközök LAN IP címeit vagy beállítod kézzel a DHCP tartományon kívüli értékre és egyedire (gondolom el akarod őket néha érni), vagy ha OpenWrt eszközökről van szó, akkor egyszerűbb, ha rögtön statikusról DHCP-re állítod magát a LAN-t is. Ekkor a DHCP címkiosztás egyébként is inaktív lesz, az AP/router IP címét pedig az elsődleges routertől megtudod.
Lehet, hogy bennem van a hiba, de nagyon nehezen tudom értelmezni (ha egyáltalán jól) a hozzászólásaidat. Szóval, próbáld meg higgadtan, pontosan leírni a problémát, a mostani hálózati topológiát (mi mivel, hogyan van összekötve). Mert olyanokból, hogy TP-Link, Ubi AP, "beállítandó" magáról a topológiáról semmi nem derül ki.
-
vargalex
Topikgazda
válasz
gyulank #19930 üzenetére
Nem értette félre a kollága. Attól, hogy nagy területet kell lefedni, nem kell minden routernek címfordítást végeznie. Elég az elsőnek és akkor a mögötte bármelyik routeren/AP-n csüngő eszközök egy hálózaton lesznek és elérhetik egymást. Persze lehet, hogy éppen az a célod, hogy külön hálózatot alkossanak. De akkor sem kell feltétlenül NAT-olni, hanem a fa struktúrában a feljebb lévő eszközökön kell jól beállítani a routing-ot.
-
vargalex
Topikgazda
Próbálj hálókábelt cserélni, esetleg másik portot a routeren. Ugyanis a feltöltésnek gyorsnak kellene lenni. Mivel ilyen lassú, így lehet, hogy átviteli hiba van, ezért az ellenőrzés elhasal, így nem is flash-eli fel.
Illetve ahogy a wikin is linkelve van, lehet, hogy csak egy bizonyos méretű firmware-t fogad el a recovery. Így a leírásnak megfelelően vágni kell belőle. -
vargalex
Topikgazda
válasz
attila.86 #19887 üzenetére
Failsafe módban tudod javítani a config-ot, ha szerinted az hibás.
Biztos, hogy nem kapott másik IP-t az eszköz és valójában azért nem éred el? Mert, ha dumb AP-nek config-oltad, akkor valójában LAN felől próbálod elérni, ott nincs tűzfal. -
vargalex
Topikgazda
A stabil OpenWrt verziókat itt találod. Suste build-je azt hiszem, hogy 18.06-ra épül, most 23.05.3-nál járunk.
Az imagebuilderről itt olvashatsz, de vannak hozzá frontendek is (így a kész firmware-t tudod letölteni). A lényege, hogy te mondod meg, hogy milyen eszközre, milyen csomagokkal, esetleg milye saját file-okkal (pl. configokkal) készüljön el.
A tftp-ről az eszköz wiki oldalán olvashatsz. Természetesen windows alól is megoldható. -
vargalex
Topikgazda
Soros porton nyilván kiderülhet még, hogy mégsem a filerendszer omlott össze. Így egy felesleges flash-t, illetve config-ot úszhatsz meg vele.
Igen, a Suste build sem mai már, ő is befejezte ezt a vonalat. De, ha nem gond a kézi config és csomagok utólagos telepítése, akkor bármelyik stabil OpenWrt-t felteheted. Vagy akár imagebuilderrel csinálsz saját firmware-t.
-
vargalex
Topikgazda
válasz
E.Kaufmann #19871 üzenetére
Nekem sincs durva jelszavam, illetve a kezdetek óta azt használom.
-
vargalex
Topikgazda
válasz
E.Kaufmann #19869 üzenetére
Nem kellene, hogy ilyen problémát okozzon, mivel a kliens nyilván nem tud szabályosan kapcsolatot bontani, ha egyszer csak megszűnik a kapcsolat, vagy kiveszed az akkut a telefonból (mondjuk manapság ez utóbbi már nehéz). Tehát szerintem ez egy szabályos működik.
Sem roaming, sem multi to unicast nincs beállítva nálam.
-
vargalex
Topikgazda
válasz
E.Kaufmann #19867 üzenetére
Az biztos, hogy a Cudy-nak egész nagy a hatótávja. Hogy bezavar-e, azt nem tudom.
Ha a MAC Vendor lookup nem ad eredményt, akkor ezek randomizált MAC címek, amiket alapból pl. a legtöbb mobil használ. Persze ettől függetlenül lehetnek támadások is. -
vargalex
Topikgazda
-
vargalex
Topikgazda
válasz
E.Kaufmann #19852 üzenetére
Mind a 2 default értéken van (így a config-ban nincs is beállítva). Azaz a
disassoc_low_ack
1
(azaz a LuCI-n a Disassociate On Low Acknowledgement ki van pipálva), askip_inactivity_poll
pedig0
(tehát a LuCI-n a Disable Inactivity Polling nincs kipipálva).De nekem a többi interface esetén is default értékkel vannak ezek a beállítások.
-
vargalex
Topikgazda
Ilyen működéssel, ahogy leírtam, azaz percenként mér, közben deep sleep, 10 percenként wifi-vel ébred (ekkor van egy time sync is és esetleg várakozás, hogy nagyjából szabályos időközönként küldje az értékeket a szerverre) és POST-ol, majd újra deep sleep, egy notebook akkuból bontott, 1900-2000 mAh kapacitású (Liitokala lii-500-al mérve) akkuval 3-4 hónapot elmegy. Persze méri a cella feszültséget is, azt is POST-olja és szerver oldalon van rá riasztás, hogy tudjam időben cserélni.
Az adatokat a két POST között RTC memóriában tárolja (azért jó, mert nem kell flash-t írni, és a tartalom megmarad deep sleep állapotban is).
Ezeket anno direkt azért csináltam, hogy a lakás bármelyik pontjára le tudjam dobni őket. Az előbb rosszul írtam, de nagyjából ugyan az: ESP12F-eket használtam, ilyen board-ra forrasztottam őket. -
vargalex
Topikgazda
válasz
E.Kaufmann #19844 üzenetére
Nálam ESP8266 alapú Tasmota firmware-os okos konnektorokból 1 db Blitzwolf SHP2, 2 db GoSund EP2, 3 db saját készítésű (a program is saját, Arduino alapkon) DS18B20 hőmérőket használó 18650-es celláról üzemelő hőmérő ESP-01 alapokon (ezek percenként mérnek, közben deep sleep-ben vannak, 10 percenkénti ébredés esetén csatlakoznak is a wifi-hez és POST-olják az addig mért értékeket), illetve 2db, ESP32-n futó WLED működik hibátlanul.
Nálam a Cudy-n 23.05.2 fut. Annyi, hogy ezen a radio-n csak wpa2-psk titkosítás van bekapcsolva. -
vargalex
Topikgazda
válasz
E.Kaufmann #19841 üzenetére
Ezzel a hostapd
supported_rates
, illetvebasic_rates
paramétereit módosítod (alulról limitálod, amit egyébként a hardware tudna). Így elképzelhető, hogy ez kliens oldalon nagyobb teljesítmény igényt jelent, mivel nem tud a számára elegendő minimális kommunikációs sebességet kiépíteni, kénytelen magasabbra kapcsolni. (Konkrétan tudhatna akár 6 Mbps, vagy alacsonyabb sebességen kommunikálni, de te aHighest
beállítással minimum 24 Mbps-re kényszeríted.) -
vargalex
Topikgazda
válasz
ArthurShelby #19818 üzenetére
Egy olyan - a Cudy által készített - OpenWrt firmware image, amit a gyári webes felület elfogad frissítésként.
-
vargalex
Topikgazda
válasz
maestro87 #19745 üzenetére
Az 1.1.7 az általam build-elt All-In-One OpenWrt build kicsit kiegészítve, scriptekkel, egyebekkel ellátva. Ebben van Samba server, ftp server, miniDLNA, Transmission (torrent kliens), stb. Ha ezeket nem használod, mert saját "szervered" van, akkor felesleges és nyugodtan mehet rá egy friss build. Nem tudom, hogy a 23.05.2 mennyire gyors ezen a viszonylag régi vason, de meg lehet próbálni. Ha lassú, akkor 22.03.6, ha még az sem elég gyors, akkor 21.02.7. Ezekből már ath79 target van a TL-WDR4300-ra. Innen indulhatsz ki.
-
vargalex
Topikgazda
válasz
maestro87 #19743 üzenetére
Hú, az már tényleg nagyon régi. Pont van egy ilyen firmware-vel telepített eszközöm és sajnos az a kernel alapból nincs IGMP_SNOOPING opcióval fordítva. A fenti beállítás nélkül a multicast üzenetek nem mennek át a LAN-WIFI között sajnos. Megpróbálhatsz egy új build-et, ha az 1.1.7-ből igazából csak a router funkciókat használod.
-
vargalex
Topikgazda
válasz
maestro87 #19738 üzenetére
SSH-n megnéznéd ezt a routeren:
cat /sys/devices/virtual/net/br-lan/bridge/multicast_snooping
Ha ez nem 0 értéket ad, akkor próbáld ki, hogy mi történik, ha beállítod arra:
echo "0" > /sys/devices/virtual/net/br-lan/bridge/multicast_snooping
#19739 aldebaran: Nem a kolléga csinált VLAN-okat, hanem egyetlen fizikai interface (switch, az eth0) van az eszközben, amin VLAN-al vannak szeparálva a WAN és a LAN portok. Ez az alap konfiguráció.
-
vargalex
Topikgazda
válasz
pinnacle #19711 üzenetére
HU countrycode esetén:
root@Smarthome-RT-AC65P:~# iw reg get
global
country HU: DFS-ETSI
(2400 - 2483 @ 40), (N/A, 20), (N/A)
(5150 - 5250 @ 80), (N/A, 23), (N/A), NO-OUTDOOR, AUTO-BW
(5250 - 5350 @ 80), (N/A, 20), (0 ms), NO-OUTDOOR, DFS, AUTO-BW
(5470 - 5725 @ 160), (N/A, 26), (0 ms), DFS
(5725 - 5875 @ 80), (N/A, 13), (N/A)
(5945 - 6425 @ 160), (N/A, 23), (N/A), NO-OUTDOOR
(57000 - 66000 @ 2160), (N/A, 40), (N/A)Részletesen, csatornák szerint:
root@Smarthome-RT-AC65P:~# iw list | grep "MHz \["
* 5180 MHz [36] (23.0 dBm)
* 5200 MHz [40] (23.0 dBm)
* 5220 MHz [44] (23.0 dBm)
* 5240 MHz [48] (23.0 dBm)
* 5260 MHz [52] (20.0 dBm) (radar detection)
* 5280 MHz [56] (20.0 dBm) (radar detection)
* 5300 MHz [60] (20.0 dBm) (radar detection)
* 5320 MHz [64] (20.0 dBm) (radar detection)
* 5500 MHz [100] (26.0 dBm) (radar detection)
* 5520 MHz [104] (26.0 dBm) (radar detection)
* 5540 MHz [108] (26.0 dBm) (radar detection)
* 5560 MHz [112] (26.0 dBm) (radar detection)
* 5580 MHz [116] (26.0 dBm) (radar detection)
* 5600 MHz [120] (26.0 dBm) (radar detection)
* 5620 MHz [124] (26.0 dBm) (radar detection)
* 5640 MHz [128] (26.0 dBm) (radar detection)
* 5660 MHz [132] (26.0 dBm) (radar detection)
* 5680 MHz [136] (26.0 dBm) (radar detection)
* 5700 MHz [140] (26.0 dBm) (radar detection)
* 5720 MHz [144] (13.0 dBm) (radar detection)
* 5745 MHz [149] (13.0 dBm)
* 5765 MHz [153] (13.0 dBm)
* 5785 MHz [157] (13.0 dBm)
* 5805 MHz [161] (13.0 dBm)
* 5825 MHz [165] (13.0 dBm)
* 5845 MHz [169] (13.0 dBm)
* 5865 MHz [173] (13.0 dBm)
* 2412 MHz [1] (20.0 dBm)
* 2417 MHz [2] (20.0 dBm)
* 2422 MHz [3] (20.0 dBm)
* 2427 MHz [4] (20.0 dBm)
* 2432 MHz [5] (20.0 dBm)
* 2437 MHz [6] (20.0 dBm)
* 2442 MHz [7] (20.0 dBm)
* 2447 MHz [8] (20.0 dBm)
* 2452 MHz [9] (20.0 dBm)
* 2457 MHz [10] (20.0 dBm)
* 2462 MHz [11] (20.0 dBm)
* 2467 MHz [12] (20.0 dBm)
* 2472 MHz [13] (20.0 dBm)
* 2484 MHz [14] (disabled)De pl. US countrycode esetén:
root@Smarthome-RT-AC65P:~# iw list | grep "MHz \["
* 5180 MHz [36] (23.0 dBm)
* 5200 MHz [40] (23.0 dBm)
* 5220 MHz [44] (23.0 dBm)
* 5240 MHz [48] (23.0 dBm)
* 5260 MHz [52] (24.0 dBm) (radar detection)
* 5280 MHz [56] (24.0 dBm) (radar detection)
* 5300 MHz [60] (24.0 dBm) (radar detection)
* 5320 MHz [64] (24.0 dBm) (radar detection)
* 5500 MHz [100] (24.0 dBm) (radar detection)
* 5520 MHz [104] (24.0 dBm) (radar detection)
* 5540 MHz [108] (24.0 dBm) (radar detection)
* 5560 MHz [112] (24.0 dBm) (radar detection)
* 5580 MHz [116] (24.0 dBm) (radar detection)
* 5600 MHz [120] (24.0 dBm) (radar detection)
* 5620 MHz [124] (24.0 dBm) (radar detection)
* 5640 MHz [128] (24.0 dBm) (radar detection)
* 5660 MHz [132] (24.0 dBm) (radar detection)
* 5680 MHz [136] (24.0 dBm) (radar detection)
* 5700 MHz [140] (24.0 dBm) (radar detection)
* 5720 MHz [144] (24.0 dBm) (radar detection)
* 5745 MHz [149] (30.0 dBm)
* 5765 MHz [153] (30.0 dBm)
* 5785 MHz [157] (30.0 dBm)
* 5805 MHz [161] (30.0 dBm)
* 5825 MHz [165] (30.0 dBm)
* 5845 MHz [169] (27.0 dBm) (no IR)
* 5865 MHz [173] (27.0 dBm) (no IR)
* 2412 MHz [1] (29.0 dBm)
* 2417 MHz [2] (29.0 dBm)
* 2422 MHz [3] (29.0 dBm)
* 2427 MHz [4] (29.0 dBm)
* 2432 MHz [5] (29.0 dBm)
* 2437 MHz [6] (29.0 dBm)
* 2442 MHz [7] (29.0 dBm)
* 2447 MHz [8] (29.0 dBm)
* 2452 MHz [9] (29.0 dBm)
* 2457 MHz [10] (29.0 dBm)
* 2462 MHz [11] (29.0 dBm)
* 2467 MHz [12] (disabled)
* 2472 MHz [13] (disabled)
* 2484 MHz [14] (disabled) -
-
vargalex
Topikgazda
válasz
bmxbandita #19684 üzenetére
Vagy azok a korábbi eszközök, amik gyári felülete megette az OpenWrt image-ot.
-
vargalex
Topikgazda
Ha LAN-on lévő DNS szervert akarsz használni, akkor jó lehet. Viszont vagy megoldod a dnsmasq-ból a forward-olást a DHCP kérések esetén (hogy a Pi hole is tudjon a LAN eszközök nevéről), vagy kézzel felveszed oda őket.
A network config-ba én a WAN-hoz tenném a dns szervert.
-
vargalex
Topikgazda
Ha valóban azt szeretnéd, hogy a LAN-on lévő kliensek a google szerverét kapják DNS szerverként, akkor jó. De biztosan ezt akarod? Ugye akkor nem lesz LAN oldali névfeloldásod (ha kellene). Szerintem sokkal jobb, ha a router számára állítod be a DNS szervert és a kliensek a routert kapják DNS szerverként. Így csak a forwardolt DNS kérések mennének a google szervere felé, megmarad a LAN oldali névfeloldás is.
-
vargalex
Topikgazda
válasz
body007 #19643 üzenetére
Még egyszer: a külső eléréshez nem kell nginx. Feleslegesen vagy egy ilyen kis flash-al szerelt routerhez.
A kérdést egyébként nem igazán értem: tedd fel a routeredhez való valamelyik stabil firmware-t és telepitsd a luci-ssl csomagot. Állítsd be a jelszót és a tűzfalon a külső elérést. -
vargalex
Topikgazda
válasz
E.Kaufmann #19641 üzenetére
Csakhogy a https eléréshez elegendő a
luci-ssl
csomag, az nem fog egy teljesnginx
-et is felhúzni, csak néhány kisebb csomagot az ssl végzödtetéshez. Az uhttpd is ki tud szolgálni https-en...
Új hozzászólás Aktív témák
Hirdetés
- ESET termékek hivatalos forgalmazója / NOD32 / Internet Security / Android / Server / Mail / stb.
- Eladó Steam kulcsok kedvező áron!
- Windows, Office licencek kedvező áron, egyenesen a Microsoft-tól - Automata kézbesítés utalással is!
- Assassin's Creed Shadows Collector's Edition PC
- Játékkulcsok olcsón: Steam, Uplay, GoG, Origin, Xbox, PS stb.
- AKCIÓ! Apple MacBook Pro 16 M4 Pro - M4 Pro 24GB 512GB SSD garanciával hibátlan működéssel
- Új! Targus - USB-C Dual HDMI 4K HUB - 2 HDMI-vel. Saját töltő nélkül 2 monitorral (120Hz)
- Bomba ár! Dell Latitude 7480 - i7-6GEN I 8GB I 256GB SSD I 14" FHD Touch I HDMI I Cam I W10 I Gari!
- Xiaomi Redmi 13C 128GB, Kártyafüggetlen, 1 Év Garanciával
- IPhone 15 Pro 128GB Függelten! Akku: 89% Jótállás: 2027.01 hó ig
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest