-
GAMEPOD.hu
Specifikációjához képest meglepően olcsó router, ami AC1200-as Wifi-t és gyári firmware-val is több hasznos szolgáltatást ígér (fájlmegosztás, dlna, nyomtató megosztás, stb.)
Új hozzászólás Aktív témák
-
Gyurka6
őstag
Hali!
Sikerült frissítenem 17...-19... v.mennyire, most már nem elérhető.
A sorosporton kívül lehet még életet lehelni bele (v.már úgy sem)?Gyurka
-
vargalex
Topikgazda
-
Gyurka6
őstag
válasz vargalex #2058 üzenetére
Hali!
Valóban, 3napi próba után xp-s hdd cserével működött!
Eőtte win7 és ubuntu/debian alól nem ment 3. napja szenvedek, v. tényleg béna voltam.Köszi mind kettőtöknek(qnadam)! (már elő volt készítve a csavarhúzó, páka.)
Még egy kérdés, az initramfs-kenel.bin az mi volna?
[ Szerkesztve ]
Gyurka
-
fireqpeg
csendes tag
Hello! Ha valakit érdekel Radmir frissítette a firmware-t:
Mar 5 11:16:41 DIR-860L: firmware version: 3.4.3.9L-100_56960f9
Mar 5 11:16:41 kernel: klogd started: BusyBox v1.30.1 (2020-03-01 14:37:07 MSK)
[link][ Szerkesztve ]
-
dchard
veterán
Ha valakit érdekel: gőzerővel folyik az 5.4-es LTS kernelre való áttérés Openwrt alatt. A minket is érintő ramips targeten mostmár elég jó eredményeket lehet elérni, a korábbi - alapvetően a switch chip meghajtóhoz köthető - problémák végre megszűnni látszanak, mivel az új upstream kernelben teljesen új switch chip meghajtó debütál. Egyelőre HW NAT nem lesz benne, de így is el lehet érni PPPoE-n 800-850megabites sebességet. Mostmár 3 hete tesztelem, eddig nem tapasztaltam vele problémát.
Természetesen ez nem csak a 860L-t, hanem minden mt7621-es SoC-kal szerelt routert érint.
Az érdeklődők itt követhetik nyomon a fejlesztést: [link]
[ Szerkesztve ]
A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]
-
dchard
veterán
válasz hudyfiu #2065 üzenetére
Teljesen jó a Wifi (860L-en legalább is). 55/55Mbit 2.5gigán, SISO 20MHz-ben. 280/270Mbit AC-n SISO 80MHz-ben.
Amire te gondolsz, az újabb wifi chipsetekkel van (7615-tel főleg), de annak a fejlesztése még gőzerővel zajlik, tehát nehéz megítélni, hogy a kernel váltás e az oka vagy az mt76 driver-t kéne reszelni. Tekintve, hogy az ősrégi 7602,7603 és 7612 is csak tavaly érte el a stabil állapotot, így kell még ezekhez némi idő. Itt megint látsizk, hogy a Mediatek és a QCA között óriási a különbség a QCA javára. Ha olvasod a topikot, akkor láthatod hányszor kerül elő témaként az mt7621-ben lévő in-silicon bugok sora, vagy a második gmac interfésze amit ha beköt a gyártó akkor interferenciát okoz, és még sorolhatnám...
A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]
-
dchard
veterán
válasz Kisbatyu75 #2067 üzenetére
Nem, ez még nincs mergelve. Neked kell forgatni saját verziót master alapján és alkalmazva a fent linkelt PR-t. Fontos tudni, hogy a sysupgrade nem fog működni, mivel a switch rész teljesen megváltozik. Frissítés előtt mentett konfigok sem fognak működni. Tehát ha valaki ki akarja próbálni, a frissítésnél NE válassza ki a beállítások megtartása kapcsolót.
A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]
-
veterán
némely gyártó (pl pont a d-link) igazán elgondolkodhatna azon, amire néhány már rájött, hogy openwrt-vel szállítsa a routereit (akár valami opcionális egyszerűsített felülettel). a vevő is jobban járna, és a jó vagy korrekt hardvert se húzná le a gyenge szoftveres rész. plusz lenne frissítés sokkal tovább, mint szokott.
istálló? gazemberség? hupákolás?
-
dchard
veterán
A probléma csak látszólag van a D-Link-kel (vagy a gyártókkal úgy általában). Ezek a cégek komplett SDK-t kapnak készen a Mediatek-től vagy a Qualcomm-tól, és utána már csak apró customizálásokat hajtanak végre a szoftveren, annak alapját valójában nem ők készítik, nincs is különösebb ráhatásuk.
Az alap probléma itt az, hogy maguk a chipset vendorok eleve nem frissítik a saját SDK-jukat, és a látottak alapján ki merem jelenteni: olyan trágya munkával hekkelik bele a - valami jellemzően ezer éves - kernelbe a szir-szar drivereiket, hogy azt akkor sem mergelné senki a linux kernelbe, ha erre hajlandóak lennének, de jellemzően ezerrel megy a titkolózás. A QCA sokat javult az elmúlt években (na nem hibátlan). A Mediatek támogatás viszont alapvetően nem a gyártó, hanem a megszállott fejlesztők elképesztő munkája, illetve némi szivárogtatás árán javult az elmúlt időszakban. 2019 szeptemberében kaptam "friss" Mediatek SDK-t pont mt7621 platformhoz az egyik gyártó partnerünktől, és egy pontosan 8 éves 2.6-os kernel köré épült... Elképesztő. És csodálkozunk, hogy ezekhez a tákolt szarokhoz nem érkezik támogatás... Szóval itt a chipset vendorokra kéne nyomást helyezni, de eszköz nem nagyon van senki kezében ehhez... A QCA ezt a szegmenst láthatóan nem akarja lefedni (budget 2 magos rendszer AC-s wifivel), így nincs verseny sem. Szóval amellett hogy egyetértek veled, ezt tartom alapvető problémának.
A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]
-
dchard
veterán
Örömmel jelentem, hogy az 5.4-es kernelre történő átállással kapcsolatos PR 3 órája bekerült az openwrt master-be. Néhány óra múlva - a következő napi snapshot-ban - már tesztelhető is a dolog. Így mostmár az is tud fájdalommentesen tesztelni, aki nem akar saját verzió fordításával bíbelődni. Ismét hangsúlyozom, hogy a sysupgrade-et (meglévő beállítások menétse) NE használja senki, mivel a switch architektúra jelentősen változik!
[ Szerkesztve ]
A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]
-
dchard
veterán
válasz xabolcs #2075 üzenetére
Nemtom mi a fene lehet, korábban legfeljebb 24 óránként volt build, de volt hogy napi kettő is. Én nem vártam ki, hanem forgattam magamnak egy sajátot már a master merge után. Faszán működik, de fontos megjegyezni, hogy legalább 14-15 napnyi uptime kell ahhoz, hogy a korábbi ismert hibákról kiderüljön, hogy valóban megoldották őket.
A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]
-
xabolcs
őstag
A korabbi ismert hibak reprodukalahoz csak az ido mulasa kell, vagy pl. meg lehet gyorsitani folyamatos iperf-es meressel?
Lusta vagyok forditani, mert telepitenek ra mas csomagot is.
aláírás1: csocsó-vesztes vagyok, főleg a Bog és Bocha páros ellen, aláírás2: van mobilarénáskulcstartóm! :D
-
dchard
veterán
válasz xabolcs #2077 üzenetére
Sajnos nincs ismert mód a hiba előfordulásának a felgyorsítására. Nálam a leghosszabb idő 14 nap volt, ami után előjött. Van kifejezetten két olyan patch, ami mostmár a masterben van, amiknél legalább a vélt magyarázat logikusnak tűnik, és az ok mögött nincs foraglom függés. Egyébként 5.4-en még senkinél nem jött elő a korábbi ismert probléma, tehát bizakodó vagyok
MOD: úgy tűnik fordítási hiba miatt nem frissülnek a snapshot build-ek az openwrt oldalán, aki nem akar forgatni, attól kis türelmet kérnek a fejlesztők.
[ Szerkesztve ]
A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]
-
dchard
veterán
Mai napon látott napvilágot néhány hír, miszerint mégsincs olyan messze a HWNAT az új 5.4-es kerneltől, mint ahogy elsőre tűnt
A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]
-
xabolcs
őstag
válasz xabolcs #2077 üzenetére
Hahaha! Muszaj leszek megiscsak forditani!
A "Tue Apr 7 05:04:05 2020" datumu, r12857-7daab62861 verzioju OpenWrt SNAPSHOT nekem csak az "openwrt-ramips-mt7621-dlink_dir-860l-b1-initramfs-kernel.bin" fajl segitsegevel indul el.
Please choose the operation:
1: Load system code to SDRAM via TFTP.
2: Load system code then write to Flash via TFTP.
3: Boot system code via Flash (default).
4: Entr boot command line interface.
7: Load Boot Loader code then write to Flash via Serial.
9: Load Boot Loader code then write to Flash via TFTP.
You choosed 3
0
3: System Boot system code via Flash.
## Booting image at bfc50000 ...
addr:80500000
We have SEAMA, Image Size = 2424768
Verifying Checksum ...
Uncompressing SEAMA linux.lzma ... LZMA ERROR 1 - must RESET board to recoverAz initramfs-t Linux alol, dnsmasq-kal szolgalom ki, Windows alol nem erte el a tftpd32-t.
$ sudo dnsmasq --no-daemon --port=0 --enable-tftp --tftp-root=/tmp dnsmasq: started, version 2.79 DNS disabled dnsmasq: compile time options: IPv6 GNU-getopt DBus i18n IDN DHCP DHCPv6 no-Lua TFTP conntrack ipset auth DNSSEC loop-detect inotify dnsmasq-tftp: TFTP root is /tmp dnsmasq-tftp: sent /tmp/openwrt-ramips-mt7621-dlink_dir-860l-b1-initramfs-kernel.bin to 192.168.0.1
Bootlog:
Got it
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
####################
done
Bytes transferred = 3761449 (396529 hex)
NetBootFileXferSize= 00396529
Automatic boot of image at addr 0x80A00000 ...
## Booting image at 80a00000 ...
Image Name: MIPS OpenWrt Linux-5.4.28
Image Type: MIPS Linux Kernel Image (lzma compressed)
Data Size: 3761385 Bytes = 3.6 MB
Load Address: 80001000
Entry Point: 80001000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
Starting kernel ...
[ 0.000000] Linux version 5.4.28 (builder@buildhost) (gcc version 8.4.0 (OpenWrt GCC 8.4.0 r12857-7daab62861)) #0 SM0
[ 0.000000] SoC Type: MediaTek MT7621 ver:1 eco:3
[ 0.000000] printk: bootconsole [early0] enabled
[ 0.000000] CPU0 revision is: 0001992f (MIPS 1004Kc)
[ 0.000000] MIPS: machine is D-Link DIR-860L B1
[ 0.000000] Initrd not found or empty - disabling initrdEz a "Uncompressing SEAMA linux.lzma ... LZMA ERROR 1 - must RESET board to recover" hiba pedig egyszer mar felutotte a fejet itt, az MT7621 SoC-nal, amin jow igazitott egy kicsit.
A problema viszont egyaltalan nem ujkeletu: Uboot - Not enough buffer for decompression LZMA ERROR 1
Ott irja hnyman, hogy 2012-ben is osszefutott egy ilyennel.Most 20 bittel probalkozok, remelem meggyogyul tole.
diff --git a/target/linux/ramips/image/mt7621.mk b/target/linux/ramips/image/mt7621.mk
index cdae42f3e4..5f1e200e71 100644
--- a/target/linux/ramips/image/mt7621.mk
+++ b/target/linux/ramips/image/mt7621.mk
@@ -6,7 +6,7 @@ include ./common-tp-link.mk
DEFAULT_SOC := mt7621
-KERNEL_DTB += -d21
+KERNEL_DTB += -d20
DEVICE_VARS += UIMAGE_MAGIC SERCOMM_HWNAME
# The OEM webinterface expects an kernel with initramfs which has the uImageSiker!
Please choose the operation:
1: Load system code to SDRAM via TFTP.
2: Load system code then write to Flash via TFTP.
3: Boot system code via Flash (default).
4: Entr boot command line interface.
7: Load Boot Loader code then write to Flash via Serial.
9: Load Boot Loader code then write to Flash via TFTP.
0
3: System Boot system code via Flash.
## Booting image at bfc50000 ...
addr:80500000
We have SEAMA, Image Size = 4718532
Verifying Checksum ...
Uncompressing SEAMA linux.lzma ... OK
## Transferring control to Linux (at address 00000000) ...
## Giving linux memsize in MB, 128
Starting kernel ...
[ 0.000000] Linux version 5.4.28 (xabolcs@ut1804) (gcc version 8.4.0 (OpenWrt GCC 8.4.0 r12857-7daab62861)) #0 SMP M0
[ 0.000000] SoC Type: MediaTek MT7621 ver:1 eco:3
[ 0.000000] printk: bootconsole [early0] enabled
[ 0.000000] CPU0 revision is: 0001992f (MIPS 1004Kc)
[ 0.000000] MIPS: machine is D-Link DIR-860L B1
[ 0.000000] Initrd not found or empty - disabling initrd[ Szerkesztve ]
aláírás1: csocsó-vesztes vagyok, főleg a Bog és Bocha páros ellen, aláírás2: van mobilarénáskulcstartóm! :D
-
xabolcs
őstag
válasz xabolcs #2081 üzenetére
Az a dnsmasq parancs nem sikerult tul jol
$ sudo dnsmasq --no-daemon --port=0 --enable-tftp --tftp-root=/tmp
dnsmasq: started, version 2.79 DNS disabled
dnsmasq: compile time options: IPv6 GNU-getopt DBus i18n IDN DHCP DHCPv6 no-Lua TFTP conntrack ipset auth DNSSEC loop-detect inotify
dnsmasq-tftp: TFTP root is /tmp
dnsmasq-tftp: sent /tmp/factory.bin to 192.168.0.1
dnsmasq-tftp: sent /tmp/factory.bin to 192.168.0.1
dnsmasq-tftp: sent /tmp/initramfs.bin to 192.168.0.1Most 20 bittel probalkozok, remelem meggyogyul tole.
Igazi SNAPSHOT-ot forditva sikerult nem indulo image-eket keszitenem!
Nem tudom milyen hibaval allok szemben, de 19 bittel is "Uncompressing SEAMA linux.lzma ... LZMA ERROR 1 - must RESET board to recover" hibat kaptam.
Csokkentem tovabb a dictionary meretet ...aláírás1: csocsó-vesztes vagyok, főleg a Bog és Bocha páros ellen, aláírás2: van mobilarénáskulcstartóm! :D
-
dchard
veterán
válasz xabolcs #2082 üzenetére
Nálam ma érdekes jelenség történt 5GHz-en:
Kernel log:
[386286.289285] device wlan0 left promiscuous mode
[386286.298528] br-lan: port 5(wlan0) entered disabled state
[386286.390128] br-lan: port 5(wlan0) entered blocking state
[386286.400999] br-lan: port 5(wlan0) entered disabled state
[386286.412183] device wlan0 entered promiscuous mode
[386348.042589] br-lan: port 5(wlan0) entered blocking state
[386348.053386] br-lan: port 5(wlan0) entered forwarding stat
És ez fogadott a syslog-ban:daemon.notice hostapd: wlan0: DFS-RADAR-DETECTED freq=5500 ht_enabled=0 chan_offset=0 chan_width=3 cf1=5530 cf2=0
Namost ezzel csak egy probléma van: hogy ezen a sávon nincs budapesti radar (hacsak éppen ma be nem kapcsoltak egyet), és az a kettő ami van, azt is kitakarja egy komplett hegy.
Tehát ez fals detektálás, még sosem láttam ilyet mt76-on...
A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]
-
vargalex
Topikgazda
Pedig sokan panaszkodnak Asus routerek esetén is, hogy a 100-as csatornáról folyamatosan elmászik radar detect miatt. Ugye elvileg 5600-5650 MHz között vannak ezek az (hivatalos) időjárási radarok. Gondolom a rádió hullámok tulajdonságai miatt viszont ezek "találkozhatnak"...
Ugye 80 MHz csatorna szélesség esetén 5530-as center csatornával 5570-ig (biztos van még valamennyi túlnyúlás) foglalja a router.Alex
-
veterán
válasz vargalex #2085 üzenetére
engem a tp-link eap dob le mindig a 122-ről, 100-on (ami igazából 106) simán ott marad.
szerk: most ránéztem, ami eddig 100-on volt, valamikor átlépett 44-re, pedig eddig ilyet sose tett... de log híján fogalmam sincs, mikor.
[ Szerkesztve ]
istálló? gazemberség? hupákolás?
-
dchard
veterán
válasz vargalex #2085 üzenetére
Jól mondod, de nincs átnyúlás: az OFDM elég jól vág a sávhatáron. Mi több: az OBW mindig kisebb mint a csatorna sávszélesség:
Ez a 860L B1 által kiadott 100-as csatorna teljes terhelésen, spektrum analizátorral Szépen látszik a DC offset középen.
De hogy visszatérjek a témához: nálam évek ota 100-as csatornán megy a 860L, és még sosem váltott csatornát.
A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]
-
Payskin
tag
Sziasztok!
A véleményeteket, segítségetek szeretném kérni. Padawant használok, amit a leírásotok alapján raktam fel... mikor is... hát, jó régen volt. Nem frissítettem. Ez a verzió van benne: 3.4.3.9-099_cf494ea, ha jól látom, ez ugyanaz, ami Radmir letöltési oldalán is szerepel 2018-as dátummal.
Digi adja alám optikán a gigabitet, a fehér Huawei optikai modemjük bridge-be van rakva. Nem vagyok az a lognézegetős típus, sőt, az admint sem nagyon piszkálom, ha van internet és minden ok, de mostanában nem az. Letöltések, online beszélgetések szakadnak meg, a Facebook Messenger (a családi kommunikáció alapja) napjában többször jelzi, hogy nem érez maga alatt internetet. Illetve különböző online játékok is rendre kihajigálnak azzal, hogy valami nem oké a hálózati beállításaimmal, noha korábban nem volt ilyen probléma. Mindez vezetéken, nem WiFi-n. Tegnapelőtt odáig fajult a dolog, hogy minden hálózati eszközt szépen újraindítottam. Lehet, hogy csak a DIGI szarakodik, és semmi köze a routerhez, mert ma éjfél után megint órákig nem volt net. Ennek kapcsán belenéztem a logba, és ezt láttam:Apr 17 03:28:50 pppd[11743]: PPP session is 3904 (0xf40)
Apr 17 03:28:50 pppd[11743]: Connected to 0c:c4:7a:bc:b8:2d via interface eth3
Apr 17 03:28:50 pppd[11743]: Using interface ppp0
Apr 17 03:28:50 pppd[11743]: Connect: ppp0 <--> eth3
Apr 17 03:28:59 pppd[11743]: Remote message: Resource temporarily unavailable^J
Apr 17 03:28:59 pppd[11743]: PAP authentication failed
Apr 17 03:29:02 pppd[11743]: Connection terminated.
Apr 17 03:29:02 pppd[11743]: Sent PADT
Apr 17 03:29:47 pppd[11743]: Timeout waiting for PADO packets
Apr 17 03:31:02 pppd[11743]: Timeout waiting for PADO packets
Apr 17 03:32:17 pppd[11743]: Timeout waiting for PADO packets
Apr 17 03:33:32 pppd[11743]: Timeout waiting for PADO packets
Apr 17 03:34:47 pppd[11743]: Timeout waiting for PADO packets
Apr 17 03:35:02 pppd[11743]: PPP session is 7720 (0x1e28)
Apr 17 03:35:02 pppd[11743]: Connected to 0c:c4:7a:bc:b8:2d via interface eth3
Apr 17 03:35:02 pppd[11743]: Using interface ppp0
Apr 17 03:35:02 pppd[11743]: Connect: ppp0 <--> eth3
Apr 17 03:35:06 pppd[11743]: PAP authentication succeeded
Apr 17 03:35:06 pppd[11743]: peer from calling number 0C:C4:7A:BC:B8:2D authorized
Apr 17 03:35:10 pppd[11743]: local IP address 94.21.106.20
Apr 17 03:35:10 pppd[11743]: remote IP address 10.0.0.1
Apr 17 03:35:10 pppd[11743]: primary DNS address 193.110.56.8
Apr 17 03:35:10 pppd[11743]: secondary DNS address 193.110.57.4
Apr 17 03:35:10 DIR-860L: WAN up (ppp0)
Apr 17 03:35:10 dnsmasq[469]: read /etc/hosts - 3 addresses
Apr 17 03:35:10 dnsmasq[469]: read /etc/storage/dnsmasq/hosts - 0 addresses
Apr 17 03:35:10 dnsmasq-dhcp[469]: read /etc/dnsmasq/dhcp/dhcp-hosts.rc
Apr 17 03:35:10 dnsmasq[469]: using nameserver 193.110.56.8#53
Apr 17 03:35:10 dnsmasq[469]: using nameserver 193.110.57.4#53
Apr 17 03:35:10 PPPoE: ConnectedElőrebocsátom, hogy nem értek hozzá, és ebben kérném a segítségetek. Ha jól gondolom, az első fele (több ilyen is volt, csak az utolsó adagot másoltam be) az a rész, amikor a router próbálja magától felvenni a DIGI-vel a kapcsolatot, de nem sikerül neki. Aztán 03:35:02-től kezdve elkezd válaszolni a DIGI. Amit itt nem értek, az a local és a remote IP. A 94.21.106.20 az a külső IP, amin én látszom a neten (whatismyip szerint), a 10.0.0.1-et meg végképp nem tudom értelmezni, nincs ilyen tartomány az egész felállásban, hacsak nem a optikai cuccnak nem ez az IP-je. De a local/remote dolog akkor is fura. Mindegy, ez a kisebb baj. A nagyobb baj ez, kapcsolódás utáni 4. perctől jön hegyekben:
Apr 17 03:39:02 login[13627]: invalid password for 'UNKNOWN' on 'pts/0'
Apr 17 03:39:11 login[13628]: invalid password for 'UNKNOWN' on 'pts/0'
Apr 17 03:39:20 login[13629]: invalid password for 'UNKNOWN' on 'pts/0'
Apr 17 03:39:29 login[13630]: invalid password for 'UNKNOWN' on 'pts/0'
Apr 17 03:39:39 login[13632]: invalid password for 'UNKNOWN' on 'pts/0'
Apr 17 03:39:48 login[13633]: invalid password for 'UNKNOWN' on 'pts/0'
Apr 17 03:39:57 login[13634]: invalid password for 'UNKNOWN' on 'pts/0'
Apr 17 03:40:06 login[13635]: invalid password for 'UNKNOWN' on 'pts/0'
Apr 17 03:40:15 login[13637]: invalid password for 'UNKNOWN' on 'pts/0'
Apr 17 03:40:24 login[13638]: invalid password for 'UNKNOWN' on 'pts/0'
Apr 17 03:40:33 login[13639]: invalid password for 'admin' on 'pts/0'
Apr 17 03:40:43 login[13640]: invalid password for 'admin' on 'pts/0'
Apr 17 03:40:52 login[13642]: invalid password for 'admin' on 'pts/0'
Apr 17 03:41:01 login[13643]: invalid password for 'UNKNOWN' on 'pts/0'
Apr 17 03:41:10 login[13644]: invalid password for 'UNKNOWN' on 'pts/0'
Apr 17 03:41:19 login[13645]: invalid password for 'UNKNOWN' on 'pts/0'
Percenként 5-6 bejegyzés, folyamatosan. Ez mi? Valaki brute-force-szal próbál bejönni? Mi az a pts/0? Próbáltam keresni, de Google nem volt a barátom, pontosabban, ilyen szinten nem értek a dologhoz, nem mond semmit az, hogy pseudo terminal slave. Kell ettől tartanom? Tudok tenni ellene valamit?
Köszi előre is. -
mozzer14
csendes tag
Sziasztok. Az mitól lehet, hogy Padavan firmware alatt nem látszik nekem a 'VPN Server' és 'VPN Client' menüpont ?
Verzió: 3.4.3.9L-100 -
Payskin
tag
válasz Payskin #2088 üzenetére
Szóval, igen, tárva-nyitva volt minden, hatalmas "IDE LŐJETEK!" neonreklám villogott hívogatóan. Pár hálózatos ismerős ránézett, mondták, hogy ajajaj, nagy a baj. Nem emlékszem, hogy piszkáltam volna a Padavan alapbeállításait, de simán benne van a pakliban, hogy én voltam hülye, és állítottam el ezeket, csak nem látom okát vagy értelmét, miért piszkáltam volna.
Először is kiderült, hogy a 80-as porton feljött a WebUI login, tehát az IP-címem ismeretében bárki próbálkozhatott. Nagyon sokáig nem találtam, hogy ezt hol a francba lehet letiltani -- míg rábukkantam egy bitbucketes ticketre, ahol pont ezt reklamálták, hogy miért nincs ilyen beállítás. Erre az a válasz érkezett, hogy ők (a fejlesztők) ezt nem így képzelik el, hanem tűzfal. Elmentem hát megnézni, hogy mi a fene az a tűzfal (mert én mást értek tűzfalon), és ekkor derült ki, hogy ott vannak az olyan biztonsági lehetőségek, mint a WebUI (meg a minden is) tiltása a WAN felől. Sóhaj. Már csak a telnetet és az SSH-t kellett letiltani, és el is tűntem a "térképről", reggel 9 óta nem jött invalid password a logba.
Boldogság, öröm. Szóval, tűzfal. -
veterán
válasz Payskin #2093 üzenetére
a nyitott 22-es port ilyen. pár napja a qnap supportnak kellett megoldania valamit a gépemen, kérték, hogy tegyem már a 22-es portra az ssh-t. nem egészen értettem, a webadminra is ráláttak, de meg is kérdezhették volna, hogy hol van, de oké, átteszem. volt, hogy pár percenként jöttek a próbálkozások.
istálló? gazemberség? hupákolás?
-
Payskin
tag
válasz vargalex #2095 üzenetére
Úgy érted, hogy alapból a firewall be van kapcsolva? Mert abban a pillanatban, hogy bekapcsoltam a firewallt, megjelent az Access to Router Services from WAN részleg, amin belül tényleg minden le volt tiltva. Csak ez nem érvényesül, és ami még rosszabb, nem is látszódik mint beállítási lehetőség, ha a firewall ki van kapcsolva, ami valami elképesztő hülye UI/UX-megoldás.
Szóval, lehet, hogy a firewallt én kapcsoltam ki és egyben nem vettem észre, hogy az oldal beállításainak a fele hirtelen eltűnt. Csak valószínűtlen. -
Headless
őstag
válasz Payskin #2096 üzenetére
ha nem nyúlsz a routerhez alapértelmezetten biztos be van kapcsolva, nem véletlenül. Ha meg nem tudod mi az ne kapcsold ki elvet kéne követni leginkább.
bevett szokás, hogy ha nem releváns az adott konfigban akkor nem jelennek meg, egyszerűen túl bonyolultak/átláthatatlanok lennének.
LEDE - R3G/DIR860l -> https://tinyurl.hu/Ntkb/