- Xiaomi 13 - felnőni nehéz
- Mobil flották
- Poco X6 Pro - ötös alá
- Android szakmai topik
- Samsung Galaxy S24 Ultra - ha működik, ne változtass!
- Samsung Galaxy S21 és S21+ - húszra akartak lapot húzni
- Samsung Galaxy S10e - esszenciális
- Megérkezett a Google Pixel 7 és 7 Pro
- Milyen okostelefont vegyek?
- Az iPhone 15 frissítésgaranciát, a 16 szép rendereket kapott
Hirdetés
-
Olajkereskedelem dollár helyett CBDC-ben?
it Szaúd-Arábia is csatlakozott a Nemzetközi Fizetések Bankja és Kína által vezetett jegybanki digitális pénzes projekthez, ami nagy változásokat hozhat.
-
Computex 2024: az MSI és a Mercedes-AMG frigyéből két laptop született
ph Egy 16 és egy 18 hüvelykes, Stealth sorozatú megoldás látott napvilágot, amik Intel Core Ultra platformra és NVIDIA GeForce RTX 4000-es GPU-kra épülnek.
-
Retro Kocka Kuckó 2024
lo Megint eltelt egy esztendő, ezért mögyünk retrokockulni Vásárhelyre! Gyere velünk gyereknapon!
-
Mobilarena
TP-Link WR1043ND - N450 router
Új hozzászólás Aktív témák
-
vargalex
Topikgazda
Hi!
Közben a pendrive-omat (USB 3.0-ás) megnéztem egy 3.0-ás kernel-ű ARCH Linux-on és ott is ugyan az az üzenet (write cache: disabled...).
A kódot is átnéztem és az scsi driver forrásában az van, hogy ha a cache módot nem tudja lekérni a drive-től, akkor írja ki az "Assuming drive cache: write through" üzenetet. Tehát nem igazán lesz (szerintem) a loadhoz köze.Alex
-
vargalex
Topikgazda
válasz SteveBeard #25006 üzenetére
Érdekes, nálad is 1.1 van, de csak ez van a dmesg-ben:
[ 18.340000] sd 0:0:0:0: [sda] 1953525168 512-byte logical blocks: (1.00 TB/931 GiB)
[ 18.350000] sd 0:0:0:0: [sda] Write Protect is off
[ 18.360000] sd 0:0:0:0: [sda] Mode Sense: 38 00 00 00
[ 18.360000] sd 0:0:0:0: [sda] No Caching mode page present
[ 18.370000] sd 0:0:0:0: [sda] Assuming drive cache: write through
[ 18.390000] sd 0:0:0:0: [sda] No Caching mode page present
[ 18.390000] sd 0:0:0:0: [sda] Assuming drive cache: write through
[ 18.420000] sda: sda1 sda2 sda3
[ 18.440000] sd 0:0:0:0: [sda] No Caching mode page present
[ 18.440000] sd 0:0:0:0: [sda] Assuming drive cache: write through
[ 18.450000] sd 0:0:0:0: [sda] Attached SCSI diskAlex
-
vargalex
Topikgazda
válasz sziada5925 #25029 üzenetére
Hi!
A forward szabálynál illene megadni a Destination-nál a belső gép IP-jét is!
Valamint a képből úgy gondolom, hogy a beállítások megtartásával frissítettél, ellenkező esetben az ssh és ftp forwardok nem lennének (az 1.1-ben a firewall.user-ben található iptables parancs formájában).
Alex
-
vargalex
Topikgazda
válasz sziada5925 #25034 üzenetére
Hi!
Nyilván, ha a géped más IP-t kap (erre mondjuk meglehetősen kicsi az esély), akkor nem fog menni. Viszont a Network->DHCP and DNS menüpontban a Static leases-nél tudsz a MAC címedhez IP-t rendelni. Így mindig azt fogja kiosztani neki.
Alex
-
vargalex
Topikgazda
Hi!
Igaz, hogy nagyjából már kaptál választ (2 egymásnak ellentmondót is ), de azért leírom. Szóval a /rom 100%-os foglaltsága teljesen normális, ugyanis ott a firmware található squashfs csak olvasható partíción. Amit módosítani tudsz, az a /overlay (amit ugye "mixel" a /rom-al a /-be), ahol elvileg van is 37%-nyi helyed.
Mit szeretnél konkrétan módosítani?Alex
-
vargalex
Topikgazda
válasz glocker #25063 üzenetére
Hi!
Egyrészt az látszik, hogy lenne extroot-od, de korábbi használat miatt nem a /overlay-ba csatolta. Érdemes lenne azt a partíciót törölni, mivel úgyis régi kernelhez tartozó file-okat tartalmaz:
rm -rf /tmp/overlay-disabled/*
tar -C /overlay -cvf - . | tar -C /tmp/overlay-disabled -xf -
umount /tmm/overlay-disabled
rebootMondjuk a sebesség problémát biztos nem ez okozza. Én egy microSD-vel próbáltam, ment rendesen.
Transmissionnal sem volt gondom.
Esetleg másik PC-ről nem tudod megpróbálni? Mi a samba config-od (/etc/config/samba és /etc/samba/smb.conf.template tartalma is kellene).[ Szerkesztve ]
Alex
-
-
vargalex
Topikgazda
válasz stanazol #25120 üzenetére
Hi!
Ha a logrotate config-ot beállítottad rendesen, akkor ahogy írod, a Scheduled Tasks-hoz (másnéven a crontab-ba) kell felvenni, hogy mikor fusson a beállított configgal a logrotate.
Pl. minden nap éjfélkor:0 0 * * * /usr/sbin/logrotate -f -s /var/log/logrotate.status /etc/logrotate.conf >/dev/null 2>&1
Ez egy status file-t is létrehoz és az error outputot a standard out-ra irányítja.
(#25122) doberman: a logrotate ezt is elintézi helyetted. A configban (példák) megadhatod, hogy visszamenőlegesen mennyi rotált log file-t tartson meg, milyen méret esetén, milyen gyakran rotáljon, tömörítsen-e, e-mail-t küldjön-e róla, üres file esetén végrehajtsa-e, stb. Bővebben pl. itt olvashatsz.
[ Szerkesztve ]
Alex
-
vargalex
Topikgazda
válasz sto1911 #25126 üzenetére
Hi!
A factory gyári firmware-ra készült, a sysupgrade pedig már telepített OpenWrt frissítésre.
Természetesen a flash-ba elfér, marad is 960 KB szabad hely, amiből kb. 720 KB használható is.
SSH-n frissítve automatikusan reboot-ol, ha az mtd parancsot -r kapcsolóval hívod (a leírások egyébként így írják).
Viszont néhány embernek gondja akadt az 1.1-es verzióval, így elérhetővé tettem a korábbi, 1.02.1-es verziót is. Erről még megvárhatod mások véleményét is. (Nálam sem a samba sebességével, sem a transmission sebességével nem volt gond 1.1 alatt.)
Alex
-
vargalex
Topikgazda
válasz Kris87 #25131 üzenetére
Hi!
Ha jól emlékszem, egyszer tettem már DD-Wrt-re OpenWrt factory-t. (Csak megnéztem, hogy tényleg nem megy-e az NTFS támogatás DD-Wrt-n, illetve a több partíció mountolását.)
1.02.1-el voltak akiknek nem ment rendesen a realtime graph.
WiFi-nél próbálj csatornát váltani, nekem a G-s telefonommal nincs gondom.
Nincs sajnos gcc, csak PC-n tudsz cross compile-olni.Monitor mode-ra ezt, illetve ezt találtam.
(#25132): a DynDNS működik, de a beállítások után egy network restart (vagy router restart) kell, ugyanis a ddns-script az interface up-ra indul.
[ Szerkesztve ]
Alex
-
vargalex
Topikgazda
válasz sto1911 #25157 üzenetére
Hi!
Ha nem változtattál a tűzfal config-on, nem másik router mögött vagy és publikus IP-t ad a szolgáltatód (nem privátot, mint pl. Mobilnet esetén), akkor kívülről az ssh (és az scp) a 2222-es, az ftp a 2221-es, a LuCI a HTTPS (443), a transmission GUI pedig a 9091-es porton érhető el. Feltétel még természetesen, hogy ahonnan próbálkozol ezek a portok ne legyenek tiltva.
[ Szerkesztve ]
Alex
-
vargalex
Topikgazda
válasz sto1911 #25164 üzenetére
Hi!
Igen, a dropbear (SSH daemon) valóban úgy van config-olva, hogy a 22-es porton hallgasson. Az, hogy kívülről a 2222-es porton legyen elérhető, tűzfal szabályokkal szabályokkal oldottam meg, azért, hogy ne kelljen külön dropbear példányt futtatni. Illetve ezen a porton Brute Force támadás elleni védelem is megvalósításra került.
Az ezt végző tűzfal szabályok:
/etc/config/firewall-ban (LuCI-ban Network->Firewall->Traffic Rules):
config 'rule'
option 'target' 'ACCEPT'
option '_name' 'ssh_WAN'
option 'src' 'wan'
option 'proto' 'tcp'
option 'dest_ip' '192.168.1.1'
option 'dest_port' '22'Ez ugye annyit csinál, hogy a WAN oldalról a 192.168.1.1-es IP 22-es portjára irányuló forgalmat engedélyezi (ez átirányítás nélkül nem lehetséges, mert kívülről nem megcímezhető a 192.168.1.1).
Illetve hozzá tartozóan a /etc/firewall.user-ben (Luci-ban Network->Firewall->CustomRules
iptables --table nat -I zone_wan_prerouting -p $PROTO --dport $PROTECTEDPORT -m state --state NEW -m recent --set --name $SERVICE -j DNAT --to-destination 192.168.1.1:$SERVICEPORT
iptables --table nat -I zone_wan_prerouting -p $PROTO --dport $PROTECTEDPORT -m state --state NEW -m recent --update --seconds 60 --hitcount $BRUTEFORCE_PROTECTION_START --name $SERVICE -j DNAT --to-destination 192.168.1.1:$BRUTEFORCE_DROPPORT
iptables --table nat -I zone_wan_prerouting -p $PROTO --dport $PROTECTEDPORT -m state --state NEW -m recent --rcheck --seconds 60 --hitcount $BRUTEFORCE_PROTECTION_START --name $SERVICE -j LOG --log-prefix "BruteForce-${SERVICE} "Ez forwardolja a WAN oldalra 2222-es portra érkező kérést a 192.168.1.1 22-es portjára, miközben figyeli a próbálkozások számát. A megadott küszöbérték elérésekor egy nem használt (DROP-olt) portra irányítja és logol.
[ Szerkesztve ]
Alex
-
vargalex
Topikgazda
válasz huliganboy #25167 üzenetére
Biztos, hogy a 192.168.1.100-as gép 12001-es portjára akartad forwardolni a 12000-es portra érkező kéréseket?
Alex
-
-
vargalex
Topikgazda
válasz huliganboy #25171 üzenetére
Hi!
Az általad adott képen pedig különböző port szerepel. Illetve azt is írtad, hogy most ugyan az a szabály mindkét helyen 12000-es porttal működik.
VPN külön telepítendő.
Alex
-
vargalex
Topikgazda
válasz huliganboy #25175 üzenetére
Hi!
Alapból átmennek a csomagok, mivel kifelé minden engedélyezve van. Én is használok többféle VPN klienst.
Alex
-
vargalex
Topikgazda
válasz huliganboy #25179 üzenetére
Hi!
Tehát a PC-de fut VPN szerver. Akkor a használt portokat kell forwardolni a PC-re.
Alex
-
vargalex
Topikgazda
válasz huliganboy #25182 üzenetére
Hi!
Milyen redirect-et hoztál létre? A GRE (47) protokollt kell elvileg továbbítani. A hozzá tartozó config elvileg így néz ki:
config 'redirect'
option '_name' 'teszt'
option 'src' 'wan'
option 'proto' 'GRE'
option 'dest_ip' '192.168.1.x'
option 'target' 'DNAT'
option 'dest' 'lan'GRE helyett írhatsz akár 47-et is.
Soha nem próbáltam, így előfordulhat, hogy kell hozzá a kmod-gre csomag is, bár a tűzfal nélküle is megeszi.
Illetve, ha jól sejtem még a 1723-as TCP portot is forwardolni kell.[ Szerkesztve ]
Alex
-
vargalex
Topikgazda
Üdv mindenkinek!
juhosg OpenWrt fejlesztővel közösen (illetve egy ismeretlen személy is besegített) a LuCI fordítását jelenleg 43%-osra megcsináltuk. Nyilván vannak benne hibák, de a százalékos készültség nem olyan rossz, tekintve, hogy a build-emben érintett részek a következő készültségűek:
modul készültség
------------------
base 96%
ddns 100%
firewall 71%
hd_idle 100%
p910nd 100%
qos 100%
samba 100%
upnp 100%
ushare 100%
wol 100%Ezeken felül a saját oldalak (transmission, miniDLNA, vsftpd, Run Command) még nem kerültek lefordításra. Azt gondolom, hogy ez már egy használható állapot, így készítettem belőle egy telepíthető csomagot. Az URL-t a LuCI System->Software oldalán található Download and install package mezőbe bemásolva az OK gombra kattintva a magyar nyelv.
Természetesen a telepítés megtehető ssh-n is:opkg install http://vargalex.uw.hu/luci-i18n-hungarian_vargalex_ar71xx.ipk
Gábor jóvoltából a fordítások bekerültek az SVN-be is, így a későbbiekben egy default OpenWrt esetén is elérhetőek lesznek.
A csomag biztosan telepíthető az általam build-elt 1.02.1-es, illetve 1.1-es verzióra is (korábbiakat nem ellenőriztem, de elvileg azokon is jó).
A fordítással kapcsolatosan (is) várok minden visszajelzést, legyen az fordítási hiányosság, vagy hiba (mindkettő van benne).
[ Szerkesztve ]
Alex
-
vargalex
Topikgazda
Hi!
Igen, ez ilyen sajnos, mi is megfigyeltük. A LuCI fejlesztői felé talán már jelezte Gábor. Olyan, mintha a LuCI application-hoz tartozó nyelvi fájlt csak akkor töltené be, ha aktív a menü.
Aki nem vette észre a hibát: pl. Szolgáltatások->Network Share menüpont van, ha kiválasztod, magyar lesz.
Természetesen nem csak a magyar ilyen kivitelezett, minden nyelv esetén így működik.
[ Szerkesztve ]
Alex
-
vargalex
Topikgazda
Sziasztok!
A fordításnál található menü megjelenési anomália megszüntetését ideiglenesen egy workaround-al megoldottam, így a nyelvi csomag frissült. Telepítés a már leírt módon.
Szerk.: aki már korábban felrakta a csomagot, nyugodtan telepítheti az újat az előző eltávolítása nélkül.
[ Szerkesztve ]
Alex
-
vargalex
Topikgazda
válasz SteveBeard #25222 üzenetére
Hi!
Ez most rakta be Gábor (küldött is róla nekem e-mailt, illetve korábban elküldte nekem patch-ban) az svn-be. Konkrétan a miniDLNA-hoz is megírta az UCI config-ot és hozzá az init scriptet, valamint csinált egy LuCI oldalt is hozzá:
Így ezentúl a trunk build-ekben, valamint a saját build-jeimben is ez lesz megtalálható.
Alex
-
vargalex
Topikgazda
válasz energiezolee #25230 üzenetére
Hi!
Nyilván lehet, ha van elég hely a flash-ban (config-nak, init script-nek és LuCI oldalnak). Egyébként azóta a magyarra fordítását megcsináltam.
[ Szerkesztve ]
Alex
-
vargalex
Topikgazda
válasz Kris87 #25229 üzenetére
Hi!
Hogy távolítottad el? Mert, ha csak az openVPN csomagot, akkor nem jó, mert a kmod-tun kernel csomag nem jó verziójú. Sőt, így lehet, hogy az egész kernel összekavarodott már.
A telepítéskor a függőségek miatt feltelepített összes egyéb csomag is eltávolításra került voltna, ha így szeded le:
opkg remove openvpn --autoremove
Most mindenképpen le kell szedned:
openvpn
libopenssl
liblzo
kmod-tunMajd újratelepíteni ezeket (elég az openvpn csomagot, mert a függőségek miatt a többi automatikusan települ).
Egyébként ezen leírás alapján könnyen telepíthető az openVPN.[ Szerkesztve ]
Alex
-
vargalex
Topikgazda
válasz energiezolee #25241 üzenetére
Hi!
Még nincs ilyen link. Én sem buildeltem. Egyébként már használod a minidlna-t? Ha igen, akkor gondolom be van már állítva...
Alex
-
vargalex
Topikgazda
válasz energiezolee #25243 üzenetére
Hi!
A minidlna configot Juhos Gábor csinálta. Majd jövő héten buildelek és akkor megadom a csomagok elérhetőségét.
Alex
-
vargalex
Topikgazda
-
vargalex
Topikgazda
válasz SteveBeard #25252 üzenetére
Hi!
Egy Wiki oldalt valóban nem egy ember szokott írni. Folyamatosan bővítik, javítják.
Viszont az IP alias PPPoE esetén is megjelenik:
Egyébként a Wiki oldalon éppen egy D-Link DSL-360R modem hozzáférés képe látszik (SpeedModem alkalmazással).
Alex
-
vargalex
Topikgazda
válasz tobias40 #25263 üzenetére
Hi!
Az 1.1-es build-ben alapból találsz egy ilyen szabályt kikapcsolva. Ezt leírtam a blog-ban, illetve a publikáláskor a változásoknál:
"tűzfal config-ban példa (inaktív) a WAN hozzáférés időbeni korlátozására"
Ha módosítottad a tűzfal configot és már nincs benne, akkor megnézheted a /rom/etc/config/firewall-ban (ez az 1.1-es default config-ja), vagy itt megtalálod.
Alex
-
vargalex
Topikgazda
válasz dragon1993 #25267 üzenetére
Hi!
Ha egy olyan ddns szolgáltatást használsz, ami nincs előre definiálva, akkor itt tudod megadni a frissítő url-t. A többi része ugyan úgy működik, mint normál esetben.
Alex
-
vargalex
Topikgazda
válasz SteveBeard #25273 üzenetére
Hi!
A REJECT elutasítja a kapcsolatot, míg a DROP nem ad semmilyen választ. Előbbi esetben azt tudják mondani, hogy van ott valamilyen eszköz, csak az adott port zárva van, tehát másik porton érdemes lehet próbálkozni, míg DROP esetén nem lehet kijelenteni, mert ugyan úgy nem kap választ, ha nem élő az IP cím.
[ Szerkesztve ]
Alex
-
vargalex
Topikgazda
válasz tobias40 #25288 üzenetére
Hi!
Akkor Luci-n:
Network->Firewall->Traffic Rules fül (Hálózat->Tűzfal->Forgalmi szabályok):
A képen a pirossal keretezett szabályról beszéltem. A nyíllal jelölt checkbox-ban tudod bekapcsolni. Az edit gombra tudod szerkeszteni a részleteket:
Itt az alsó mezőben (extra arguments - További argumentumok) tudod megadni az idő szerinti korlátozást az ott található formában.
Mivel az alap policy szerint LAN->WAN irányban mindent enged, így itt tiltásnak van értelme. A példában
-m time --weekdays Mon,Tue,Wed,Thu,Fri --timestart 10:00 --timestop 22:00
szerepel. Ezzel hétköznap 10:00-22:00 között tiltani fogja a hozzáférést.
Alex
-
vargalex
Topikgazda
válasz Callmaster #25314 üzenetére
Hi!
Gondolom trunk-ot raktál rá, mivel Backfire nincs. Ez nem tartalmaz GUI-t, utólag kell telepíteni. A WAN kapcsolatodat kell először beállítani a /etc/config/network fileban a netednek megfelelően. Majd tudod telepíteni a LuCI-t:
opkg update
opkg install luciAlex
-
vargalex
Topikgazda
Új hozzászólás Aktív témák
- Suzuki Swift 2005 1.3 GLX CD AC - AndroidAuto & CarPlay
- Bomba ár! HP Elite X2 1011 G1 - m5 I 8GB I 256GB SSD I 11,6" FHD Touch I CAM I W10 I Gari
- Bomba ár! Lenovo ThinkPad T490 - i5-8GEN I 8GB I 256GB SSD I 14" FHD I Cam I W10 I Garancia!
- 8db GeForce RTX 3090 Egyben
- VAST AI - VAST AI - VAST AI - GeForce RTX 3090
Állásajánlatok
Cég: Alpha Laptopszerviz Kft.
Város: Pécs
Cég: Ozeki Kft.
Város: Debrecen