- Az NVIDIA szerint a partnereik prémium AI PC-ket kínálnak
- Két Zen 5-ös dizájnjának mintáit is szállítja már az AMD
- A Colorful "fagyosan kompakt" alkatrészekkel megy elébe a nyárnak
- A Keychron ismét egy űr betöltését vállalta magára az egerek szegmensében
- Az átlagnál vaskosabb ventilátorok kandikáltak ki a Corsair vitorlája mögül
- Modern monitorokra köthető 3dfx Voodoo kártya a fészerből
- Milyen billentyűzetet vegyek?
- Fujifilm X
- Azonnali informatikai kérdések órája
- Gaming notebook topik
- Nvidia GPU-k jövője - amit tudni vélünk
- OLED TV topic
- A Keychron ismét egy űr betöltését vállalta magára az egerek szegmensében
- Házimozi haladó szinten
- Xiaomi Pad 5 - hatásos érkezés
Hirdetés
-
AMD Radeon undervolt/overclock
lo Minden egy hideg, téli estén kezdődött, mikor rájöttem, hogy már kicsit kevés az RTX2060...
-
Kapnak egy rakás reklámot a Roblox játékosai
it Videohirdetésekre készülhetnek ezentúl a virtuális világokban a Roblox játékosai.
-
VR játék lesz az Batman: Arkham Shadow (Meta Quest 3)
gp Egyelőre csak egy teaser trailert kaptunk a teljes leleplezésre a Summer Game Festen kerül sor.
-
PROHARDVER!
ASUS WL-500G Premium
Új hozzászólás Aktív témák
-
ecaddict
senior tag
válasz mgrincs #9494 üzenetére
OK, feltettem a WL500 fórumra egy olyan verziót ami teljes eléréssel hivatkozik a dir/basename-re.
Egyébként eredetileg itt nem is volt dir/basename csak miután találtam a busybox-ban egy olyan hibát, hogy az ékezetes fájlneveket nem mindig tudja átirányításnál kezelni kénytelen voltam ezt a megoldást betenni.
Bár a hibát villámgyorsan (kb. egy nap alatt) kijavították és a be is tették a legújabb Oleg-be, még ebből sincs hivatalos verzió és biztos jó idő el fog telni amíg minden fimrware-be beszivárog, ill ezeket a felhasználók felteszik.
Ez sajnos elég bosszantó mert a megoldás hátránya, hogy szerkesztés után alapértelmezett lesz a szerkesztett fájl attribútuma, így pl. a futtathatóság el fog veszni. E miatt viszont nem szeretném hosszú ideig fenntartani ezt az alternatív megoldást. Remélem a Tomato környezetben is beteszik a busybox javítást minél hamarabb.
A böngésző problémákról tudok, ezért javasoltam, hogy a köztes vonalakat ki kell kapcsolni. A javascript-es rész annyira intenzíven használja a javascript motort ill. a canvas támogatást, hogy akár ennek a legjobb tesztjének is felfogható.
Ha van elég memória egyébként nem szokott gond lenni. Linux (Fedora) alatt sok memóriával soha nem tapasztaltam ilyet. Windows alatt már igen, de a vonalak kikapcsolása segített.
A Chrome motorja el is szállt bekapcsolt vonalakkal, így aztán egyből tesztelhettem az összeomlás elleni védelmet is.
Kikapcsolt vonalakkal a Chrome viszont hihetetlen, kb. tízszer annyi könvvtárt megnyitva mint a Firefox-ban még mindig kevesebb memóriát evett mint a Firefox és interneten keresztül is szinte olyan gyors mint LAN-on (csak a hálózati késleltetés érződik).
A Chrome javascript motort tényleg nagyon jól megcsinálták (csak lenne rendesen befejezve).
Más böngészővel is próbáltam, felejthető eredménnyel.Röviden: Windowson intenzív használatnál kikapcsolt vonalakkal Chrome egyébként meg Firefox-al érdemes használni.
### RT-N16, WL-500 Oleg optware script ami majdnem mindent feltesz ### ===========> http://wl500g.info/showthread.php?t=23684 <===========
-
Laca 012
őstag
Ha a RAM a hibás, az könnyen kideríthető egy memtest-el:
cd /tmp
wget http://oleg.wl500g.info/bin/memtest
chmod +x memtest
./memtest 16m (32MB-nál)
./memtest 64m (128MB-nál)
(Kilépés: Ctrl +c)Érdemes 2x-3x lefuttatni.
Ha az órajelet nem bírná, akkor először is hibát fog írni memtest közben és akkor nyílván lefuttatod a tesztet normál órajelen!Én különben ezt nem hinném, mert alapban 400MHz-es ramokkal jön ki a router, ami 200MHz-es órajelet kell hogy bírjon.
Ram upgrade szintén nem megoldás(csak ha tényleg a chipek rosszak), mert általában a Samsung chipek amit beleteszünk, 333MHz-esek, tehát órajel szempontjából gyengébb mint a gyári (166MHz)!!! (Próbáltam, de nem sikerült 400MHz-es Hynix chipet szerezni)
A procit 300 MHz-re húzva 150MHz-es órajelet ad a RAM-oknak, amit a 333MHz-es RAM-ok is kényelmesen el kell bírjanak!Egyébként csak az órajelet állítottad, vagy a ramok elérési idejét is? Mert azt viszont lehet nem mindegyik ram bírja!! Illetve hibázhat akkor is, ha Túlmelegszik a Proci vagy a RAM! Hűtés nélkül semilyen tuningot nem ajánlok!!!
-
CS_D
senior tag
Köszönöm az ötleteket, de sajnos egyik sem segített.
Most visszatettem a default értékekre a procit és a ramot, de ez sem segített.
Annyi változott, hogy most nagyjából 1 perc múlva dobja a hibaüziket (eddig kb. 20 másodperc után), de utána sorban egymásután elég sokat.
Sep 11 18:41:42 kernel: __alloc_pages: 0-order allocation failed (gfp=0x20/0)
Sep 11 18:41:42 kernel: vlan: failed to unshare skbuffMost már foglamam sincs, hogy mi lehet a megoldás. A proci gyáriórajelre állításában bíztam, de ez sem segített.
Hűtve is van/volt rendesen, közepes méretű hűtőbordával, ami sosem volt vészesen forró.
Úgyhogy továbbra is szívesen veszek minden használható ötletet. Előre is köszönöm!
-
CS_D
senior tag
válasz ecaddict #9505 üzenetére
De. Flashdrive-ot használok, viszont, ha kikapcsolom, akkor is ugyanezt produkálja sajnos.
ÁÁÁÁÁÁ... Megőrülök. Minden eddig felvetődött ötletet kipróbáltam. Már a legújabb 473-as build van fent. Ha visszaveszek a torrent sebességéből, akkor csak sok idő után, de szintén van hibaüzenet.
-
ecaddict
senior tag
Ha kikapcsolod a swap-ot, ha gondok vannak a flash-el az mind egyre megy-> elfogy a memória. Próbálj ki valami jobb cuccot ideiglenesen a swap-ra használni.
### RT-N16, WL-500 Oleg optware script ami majdnem mindent feltesz ### ===========> http://wl500g.info/showthread.php?t=23684 <===========
-
kiskz
csendes tag
Sziasztok!
Ha egy rövid ötletet adtok, hogy merre kereskedjek FTP szerver ügyben már azt is megköszönném. -
Intruder2k5
MODERÁTOR
Szia!
Egy rövid ötlet: Itt keresgélj :-)
-
kiskz
csendes tag
válasz Intruder2k5 #9509 üzenetére
köszönöm MASTER!
Ha kérdésem van jöhetek ide? -
CS_D
senior tag
válasz ecaddict #9507 üzenetére
Egy másik pendrive-ra áttettem a cuccost, és azon csináltam neki 128 mega swapot, és még mindig ugyanez a hiba.
Szóval úgy tűnik, hogy nem a pendrive a beteg. Kb 10-szer használt pendrivera került rá most a rendszer, szóval az nem létezik, hogy annyitól megsérüljön a flash szerkezete. Mert az előző flashdriveról elhittem volna, mert egy noname cuccos, és már vagy másfél hónapja van a routeren 24/7.
Sep 11 18:41:42 kernel: __alloc_pages: 0-order allocation failed (gfp=0x20/0)
Sep 11 18:41:42 kernel: vlan: failed to unshare skbuffÚgyhogy ez még továbbra is kérdéses...
Memtest azóta 7-szer lefutott egymás után hibátlanul.
-
Intruder2k5
MODERÁTOR
Először is hagyjuk ezt a masterezést, nem vagyok én senki...
Másodszor, természetesen jöhetsz ide, bizonyára lesz is aki segít majd, de az nem én leszek sajnos... Sosem raktam fel OLEG-ra vsftpd-t. Nekem Tomato-m van jelenleg, és abban a webes felületen konfigoljuk az ftp-t. :-) -
AtHoS
nagyúr
No szembesültem az első támadással:
Nemrég a tűzfal többször egymás után blokkolta a 192.168.1.1 címet, ami ugye a router lenne. Közben látom, hogy a tűzfal packet log-jában folyamatosan ilyen sorok jelennek meg: (csak egy részlet kiemelve belőle)
0:56:35 Block IN TCP 192.168.1.1 443 192.168.1.172 52987 ACK Blocked by the Attack Detecton component
0:56:35 Block IN TCP 192.168.1.1 443 192.168.1.172 52989 ACK Blocked by the Attack Detecton component
0:56:35 Block IN TCP 192.168.1.1 443 192.168.1.172 52990 ACK Blocked by the Attack Detecton component
0:56:34 Block IN TCP 192.168.1.1 443 192.168.1.172 53025 PSH ACK Blocked by the Attack Detecton component
0:56:34 Block IN TCP 192.168.1.1 443 192.168.1.172 53028 PSH ACK Blocked by the Attack Detecton component
0:56:32 Block IN TCP 192.168.1.1 443 192.168.1.172 53027 ACK Blocked by the Attack Detecton component
0:56:31 Block IN TCP 192.168.1.1 443 192.168.1.172 53025 PSH ACK Blocked by the Attack Detecton component
0:56:30 Block IN TCP 192.168.1.1 443 192.168.1.172 53028 PSH ACK Blocked by the Attack Detecton component
0:56:30 Block IN TCP 192.168.1.1 443 192.168.1.172 53027 ACK Blocked by the Attack Detecton component
0:56:30 Block IN TCP 192.168.1.1 443 192.168.1.172 52988 ACK Blocked by the Attack Detecton component
0:56:29 Block IN TCP 192.168.1.1 443 192.168.1.172 53027 ACK Blocked by the Attack Detecton component
0:56:29 Block IN TCP 192.168.1.1 443 192.168.1.172 53025 PSH ACK Blocked by the Attack Detecton component
0:56:29 Block IN TCP 192.168.1.1 443 192.168.1.172 53027 ACK Blocked by the Attack Detecton component
0:56:29 Block IN TCP 192.168.1.1 443 192.168.1.172 53028 PSH ACK Blocked by the Attack Detecton component
0:56:28 Block IN TCP 192.168.1.1 443 192.168.1.172 53027 ACK Blocked by the Attack Detecton component
0:56:28 Block IN TCP 192.168.1.1 443 192.168.1.172 53027 ACK Blocked by the Attack Detecton componentrouter logban pedig ezek olvashatóak (csak kiemeltem egy részt)
Sep 11 18:12:56 dropbear[30655]: Child connection from 116.113.178.27:48581
Sep 11 18:13:00 dropbear[30655]: login attempt for nonexistent user from 116.113.178.27:48581
Sep 11 18:13:01 dropbear[30655]: exit before auth: Disconnect received
Sep 11 18:13:01 dropbear[30658]: Child connection from 116.113.178.27:48968
Sep 11 18:13:04 dropbear[30658]: login attempt for nonexistent user from 116.113.178.27:48968
Sep 11 18:13:05 dropbear[30658]: exit before auth: Disconnect received
Sep 11 18:13:06 dropbear[30659]: Child connection from 116.113.178.27:49354
Sep 11 18:13:09 dropbear[30659]: login attempt for nonexistent user from 116.113.178.27:49354
Sep 11 18:13:10 dropbear[30659]: exit before auth: error reading: Connection reset by peer
Sep 11 18:13:11 dropbear[30660]: Child connection from 116.113.178.27:49730
Sep 11 18:13:14 dropbear[30660]: login attempt for nonexistent user from 116.113.178.27:49730
Sep 11 18:13:15 dropbear[30660]: exit before auth: Disconnect receivedrtorrentet webui-ról egyáltalán nem tudtam elérni, mert folyamatosan csak töltötte be az oldalt és a router logban közben ilyen hibaüzenetek jelentek meg:
kernel: __alloc_pages: 0-order allocation failed (gfp=0x20/0)
Aega-val lelőttem az rtorrentet, aztán nekiláttam a router webadmin felületén megkeresni a védelmi részeket. Találtam is pár dolgot:
- Wireless - Misc-nél Enable Radio kikapcsolva, tehát vezeték nélküli rész letiltva
- IP config Misc részen bekapcsolva hagytam az uPnP-t Report WAN address beállítással
- NAT Setting - Virtual Server be van kapcsolva
- Internet Firewall - Basic Config: engedélyeztem a tűzfalat és és a DoS védelmet, Enable Web Access from WAN nincs engedélyezve LPR és Ping request kikapcsolva ill. bekapcsoltam a bruteforce védelmet SSH és FTP Server-re
- Internet Firewall - WAN & LAN Filter: WAN to LAN szűrő bekapcsolva alapértelmezett DROP-pal és PortForwardingra ACCEPT beállítva (úgy emlékszem ez az alapértelmezés)
- Internet Firewall - MAC Filter kikapcsolva
- System Setup - Services-nél Telnet engedélyezve, SSH Server nincs engedveEzek jók így vagy valamelyiket módosítani kellene? Illetve esetleg van még olyan amit talán még meg kellene néznem?
Most a beállítások mentése után újraindítva a routert nem tapasztaltam a tűzfalban azóta blokkolt csomagokat.
Remélem ez így is marad. Az rtorrent lelövése magával hozta, hogy ellenőrzött pár torrentet. Már az utolsót ellenőrzi, de azzal el lesz még egy darabig, mert 60gigás a torrent és a felénél járt kb. letöltésben.
Mod:
Oleg FW van a routerben[ Szerkesztve ]
read-only mode on the forum
-
CS_D
senior tag
Régebben nekem is tele volt a log-om ilyen dropbeares üzenetettel (valaki távolsról próbálkozott ssh-n belépni bruteforce módszerrel), a végén már a felhasználónevemet már tudták, viszont még belépni nem tudtak. Egyelőre úgy sikerült áthidalni a problémát hogy az ssh portját áttettem a 22-esről máshova. Azóta nem próbálkoznak ssh-n belépni.
ha a 2222-es portra akarod tenni az ssh-t, akkor
a post-boot-ban így állítsd be:
/usr/sbin/dropbear -p 2222
a post firewallban pedig a 22-esre voantkozó szabályokat át kell írni a 2222-esre.
Az allokációs hibával én is küzdök még...
kernel: __alloc_pages: 0-order allocation failed (gfp=0x20/0)
[ Szerkesztve ]
-
AtHoS
nagyúr
Egyelőre megszűntek a támadások, vagyis log-ba nem kerül bele, ha van is ilyen. Gondolom a bruteforce bekapcsolásával a router automatikusan eldobja és ezért.
Az allokációs hiba nálam picit másképp néz ki:
kernel: __alloc_pages: 3-order allocation failed (gfp=0x20/0)
Az éjszakai újraindítás után is van jó pár ilyen sor, de ahogy észreveszem ez csak abban az időben jelentkezett, mikor webui-val (ruTorrent) néztem gépről az rtorrent adatokat. Közben ugye az rtorrent gőzerővel ellenőrizte a 60gigás torrentet. Miután lekapcsoltam a gépet megszűnt a log-ban a fentebbi hibaüzi. Sajnos nem tudom, hogy újraindítás előtt 3-order vagy 0-order volt az üzenetben, mivel nem mentettem le azt a log-ot és újraindítás után törlődik. Viszont emlékeztem, hogy Te is hasonlót tettél be, így bemásoltam onnan, hogy nálam is volt ilyen gond.
Most kicsit tüzetesebben megnéztem a log-ot és feltűnt ez a sor:
/opt/sbin/cron[98]: (*system*) BAD FILE MODE (/opt/etc/cron.d/vnstat.sh)
Mit takarhat a BAD FILE MODE ?
Na meg itt is van érdekes dolog:
smbd[112]: [1970/01/01 01:00:11, 0] param/loadparm.c:map_parameter(1681)
smbd[112]: Unknown parameter encountered: "host allow"
smbd[112]: [1970/01/01 01:00:11, 0] param/loadparm.c:lp_do_parameter(2223)
smbd[112]: Ignoring unknown parameter "host allow"A dátum nem érdekes, mert még itt nem volt lekérve a helyi idő
Mondjuk azt nem értem, hogy a nálam nincs is engedélyezve a net felőli belépés, mivel a router konfig felületén a tűzfal rész alap konfig résznél az Enable Web Access from WAN? - NO-ra van állítva.
Nálam az SSH Server a System Setup - Services részen nincs engedélyezve. Így át kellene írnom az SSH portját?
Meg a csatlakozási kísérletnél sem 22-es portot próbáltak meg használni. Bár ebből nekem nem derül ki, hogy SSH vagy semdropbear[22214]: Child connection from 67.232.30.200:49590
read-only mode on the forum
-
CS_D
senior tag
Ha dropbear, akkor elvileg ssh, és az IP mellett a port az pedig az általa használt portot jelenti szerintem.
Az, hogy az alap ssh le van tiltva, attól még a dropbear telepítve van, és fut is. Szóval a dropbear látja el az ssh szerepét.
Én is bekpacsoltam a bruteforce elleni védelmet, de az csak mondjuk a második támadás után dobja el. Mert egyszer minimum meg kell engedni a logint, hiszen, akkor Te sem tudnál belépni.
Az allokációs dolognál nekem 0-order hiba van.
@ecaddict: megpróbálok valami hdd-t rátenni swapként. De addig még egy gyors kérdés: az rtorrentnek mennyi memória szükséges? Mert nekem csak az rtorrent van feltéve, semmi lighttpd, semmi egyéb, csak a torrent futtatásához szükséges dolgok, és nTorrent-es windowsos java alkalmazást használok a kezeléséhez. Ha fut az rtorrent, akkor olyan 18 mega foglalt a ramból, majd szépen megtölti mindenféle cachelni való állománnyal, és a swapból konstans 4 mega szokott lefoglalva lenni. Ennyit számítana az a nyomorult 4 mega swap? És kikapcsolt swap meleltt is fellép a hiba.
-
ritkamadár
tag
Sziasztok!
Köszi mindenkinek a segítséget, sikerült mindent belőni Tomato alatt.
Már csak egy gondom van, szeretnék ip címhez mac címet hozzárendelni a forgalom szabályzás miatt. De a gépek egy része wifi kliensen kapcsolódik a router-re és 3-4 gépnek ugyanaz a mac címe. Erre valami megoldás esetleg? -
ecaddict
senior tag
BAD FILE MODE:
ls -la /opt/etc/cron.d/vnstat
-rw------- 1 admin root 119 Sep 27 2008 /opt/etc/cron.d/vnstat-> chmod 600 /opt/etc/cron.d/vnstat.sh
rtorrent memória használat,
egyszer:top -n 1 | egrep 'rtorrent|%MEM'
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
18810 admin 16 10 18764 18m 6988 R 1.7 14.7 262:00.03 rtorrentmáskor:
top -n 1 | egrep 'rtorrent|%MEM'
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
18810 admin 17 10 38192 37m 25m R 7.2 30.0 262:16.85 rtorrentmost kb. két hetes uptime-al.
Mivel 32M felé is tud menni ezért kell a swap (nálam 128M RAM-al is be van kapcsolva, bár mondjuk használva nem nagyon van).### RT-N16, WL-500 Oleg optware script ami majdnem mindent feltesz ### ===========> http://wl500g.info/showthread.php?t=23684 <===========
-
tlac
nagyúr
válasz ritkamadár #9518 üzenetére
Már csak egy gondom van, szeretnék ip címhez mac címet hozzárendelni a forgalom szabályzás miatt. De a gépek egy része wifi kliensen kapcsolódik a router-re és 3-4 gépnek ugyanaz a mac címe.
nem kevered a mac és ip cím fogalmát?
mac címet lehet változtatni a gépeken -
nandris
aktív tag
válasz ritkamadár #9521 üzenetére
Szia
Valami kányaság lehet a gépeidnél szerintem, mert nem létezik, hogy kétszer két gép mac címe is megegyezzen. (Bár vannak furcsa dolgok.) Amikor nézed a device list-át akkor az összes gép legyen bekapcsolva, (gondolom úgy csináltad) mert az is előfordulhat, újraindítás után másik ip-címet kap,de a régi is látszik még. -
nandris
aktív tag
válasz ritkamadár #9521 üzenetére
Most néztem, nem is a br0-n kellene látnod, hanem az eth1-en. Elméletileg az lenne a wifi.
-
ritkamadár
tag
válasz nandris #9522 üzenetére
Gépek fix ip-t kaptak dhcp kikapcsolva, a wifi a router-en le van tiltva. A router-re az wireless eszköz a lan-on csatlakozik. A wifi klienseknél az állomás listában láttom a tényleges mac címüket a gépeknek, de a router felé valamiért a wifi eszközök mac címe jelenik meg.
-
mgrincs
tag
válasz ritkamadár #9524 üzenetére
A gondod az, hogy a wireless bridge/client módban(ahogyan a wireless eszközöd az routerhez kapcsolódik) a MAC cím átírásra kerül, ami ugyan bridge módban nem kellene, hogy megtörténjen, de úgy tűnik szabadon értelmezték a (transparent)bridge definícióját, amikor ezeket a módokat implementálták a vezetéknélküli hálózatokban. Így a bridge mögött csak a bridge MAC címe látszódik.
Ahogy utánanéztem a WDS módban ez nem történik meg, szóval, ha van lehetőséged, próbáld azt belőni, két eszközzel nem egy ördöngősség. Cserébe lemondhatsz a vezetéknélküli sávszeled feléről.http://www.youtube.com/watch?v=HkTa3-ZZbD8
-
nothin
tag
Sziasztok,
egy telepített csomagot szeretnék downgradelni a routeren, van mentett image-m csak azt nem tudom hol vannak a telepitett programok azaz hogy mit kellene felülírnom a régi fileokkal.
Kösz
-
nandris
aktív tag
válasz ritkamadár #9524 üzenetére
Szia
Nem tudom mit értesz wifi eszközön, amikor a wifi ki van kapcsolva a routereden, ha nem úgy csatlakozol, akkor nem wifi eszköz! ( pl: laptopban van wifi rádió, de te a lan kábellel csatlakozol, akkor az nem wifi eszköz.) Menetközben nem adtál véletken a routerhez statikus dhcp-t? Nézd meg a basic/static dhcp fülön, ha van valamim töröld ki, és save. A gépeiden azon az adapteren, amelyikkel csatlakozni szeretnél (wifi vagy lan) állítsd fixre az ip-t ( Pl: 192.168.1.30 Maszk 255.255.255.0 átjáró 192.168.1.1 és az elsődleges dns 192.168.1.1 ) Ha más az átjáró, és a dns akkor azt írd be, a routert indítsd újra, és a gépeidet is. Elméletileg helyre kellene kerülni a gépeknek. -
ecaddict
senior tag
### RT-N16, WL-500 Oleg optware script ami majdnem mindent feltesz ### ===========> http://wl500g.info/showthread.php?t=23684 <===========
-
mgrincs
tag
Kiadod a
ipkg files <downgrade-elendő csomag neve>
parancsot, és a kimenetében levő fájlokat visszamásolod.
(A Successfully terminated. -et ne rakd vissza )
Ekkor még mindig nem ez fog látszani az "ipkg list_installed" kimenetén, de valójában a régebbi progi fog futni.http://www.youtube.com/watch?v=HkTa3-ZZbD8
-
AtHoS
nagyúr
válasz ecaddict #9528 üzenetére
Ha felrakom az új Oleg FW-t, akkor a most jól működő rendszeren mit kell újrapakolnom?
Mod:
Illetve mit kellene elmenteni a frissítés előtt?Mod2:
Eszembe nem jutott volna, hogy a Bad file mode a jogosultságokra vonatkozik Azt hittem valami gond van a tartalmávalMod3:
Most belenéztem a system log-ba és egy új sorra lettem figyelmes:Sep 12 15:35:02 /opt/sbin/cron[2307]: (root) MAIL (mailed 54 bytes of output but got status 0x0001 )
Van több ilyen is. Mi a fene akar levelet küldözgetni és hova?
[ Szerkesztve ]
read-only mode on the forum
-
mgrincs
tag
Mire vannak a szkriptek?
Ha visszamásolod az image-ből az egész opt-ot mondjuk a /mnt/share/ könyvtárba, utána:ipkg files <csomag neve>|grep ^/opt>tmp.file
for i in `cat tmp.file`
do
mv /mnt/share/$i $i
doneígy a gép dolgozik , elvégre azért van!
http://www.youtube.com/watch?v=HkTa3-ZZbD8
-
CS_D
senior tag
Én most tettem fel a legújabb oleg buildet, és minden beállítás (nvram, post-boot, post-firewall) megmaradt.
Szerintem, ha új olegről frissítesz, akkor a beállítások megmaradnak, de azért a biztonság kedvéért mentsd el az nvramot, és a post-os dolgokat. A telepített csomagokat nem kell félteni, azokat nem érheti baj.
-
AtHoS
nagyúr
válasz ecaddict #9519 üzenetére
Közben rájöttem miért akar levelet küldözgetni.
Miután beállítottam ezt a jogosultságot:
chmod 600 /opt/etc/cron.d/vnstat.shkezdett jelentkezni a hiba. Ráadásul onnantól kezdve a webes vnstat frontend csak addig az időpontig jelezte a statisztikát amikor a fenti jogosultságot beállítottam. Az utánalévőket nem jelezte, mindaddig, míg
MC-ben nem adtam futtathatósági jogot a vnstat.sh-ra. Ezután megszűntek a levélküldési kezdeményezések és a vnstat frontend is rendben jelzi azóta a forgalmat.
AEGA kezdőoldalán olvasható egy Terhelés sor. Gondolom ez a router prociterhelését mutatja. Ezt milyen mértékegységben kell érteni illetve mennyi a max terheléshez tartozó érték?
Ráadásul egyből két értéket is ír: average:0.70,0.44,.Az első gondolom az átlagos terheléslesz , de milyen időszakra viszonyítva?
A másodiknál az aktuálisat jelzi gondolom.CS_D
Gondolom, hogy a winyóra telepített csomagokkal nem lesz gond, de amik a flashbe kerülnek azok sejtésem szerint a frissítéssel elvésznek. Admin felületnél van lehetőség a flash tartalmának mentésére, de nem tudom hogy a különböző FW verzióknál nem-e változtatnak a Flashben tárolt adatok szerkezetén, mert ilyenkor ugye a flash visszatöltése nem lesz elegendő.Mod:
Ja, hogy írod az nvram megmarad Szóval akkor a flasht nem bántja a FW frissítés. Bár még akkor is felmerül a kérdés, hogy az adatszerkezetekben nem-e történt változtatás.[ Szerkesztve ]
read-only mode on the forum
-
nothin
tag
Esetleg van valahol egy file ami tartalmazza a telepitett csomagokat és ha onnan kitörlöm az adott csomagot nem próbálná meg sosem frissíteni?
-
AtHoS
nagyúr
AEGA-nál a terhelésre most már három érték olvasható: 1.24,1.58,1.66
Melyik mit takarhat?Közben észrevettem, hogy délutánra az rtorrent forgalma erősen visszaesett, köszönhetően UPC priorizálásos tevékenységének. A múltkoriban már kezdtem kicsit pedzegetni az UDP portok megnyitását, de azt hiszem még nem sikerült maradéktalanul beállítgatnom.
Gondoltam majd most megint bepróbálkozom illetve az rtorrent forgalom titkosítását is meglestem mit lehet kezdeni vele.
Titkosításra a következőket találtam. rtorrent.conf vagy .rc fájlban kell matatni a encryption = sort, ahol a következő paramétereket lehet kombinálni:
• allow_incoming (elfogadja a bejövő titkosított kapcsolatokat)
• try_outgoing (használja a titkosítást kimenő kapcsolatokhoz)
• require (nem fogadja el titkosítatlan kapcsolat kezdeményezést (handshake) másik klienstől)
• require_RC4 (letiltja a sima szöveges (plaintext) adat továbbítást titkosított kapcsolat kezdeményezés (handshake) létrejötte után)
• enable_retry (ha a kimenő kapcsolat létrejötte sikertelen volt, akkor kikapcsolja a titkosítást, ha az be volt kapcsolva vagy bekapcsolja azt ha előtte ki volt kapcsolva)
• prefer_plaintext (sima szöveges adattovábbítást (plaintext) választ ki, amikor a többi kliens (peer) felkínálja a választást sima szöveges adattovábbítás és RC4 titkosítás között. Minden egyéb esetben RC4 titkosítást használ)Na egyből kreáltam egy ilyen sort hozzá:
encryption = allow_incoming,try_outgoing,enable_retry,prefer_plaintextA use_udp_trackers = yes sort azért nem árt aktivizálni hozzá.
Közben leállítottam az összes rtorrent folyamatot ruTorrent webui-n keresztül. Most hagytam neki elég időt a leállításhoz, mivel közben álltam neki szerkeszteni a konfig fájlt illetve gondoltam, hogy az S99rtorrent fájllal fogom leállítani az rtorrent-et. MC-vel kicsit belenéztem az S99rtorrent-be és meglepetten tapasztaltam, hogy IPTABLES részt is tartalmaz. Egyből feltűnt, hogy csak TCP-re van benne sor:
iptables -I INPUT -i "$1" -p tcp --syn --dport $P -j ACCEPT
itt a $P az rtorrent.conf fájl-ból kinyert port tartomány egy eleme, amit egy FOR ciklussal futtat végig a script. Tehát már itt beállításra kerül az rtorrenthez szükséges port.
Gondolom a postfirewall-ban emiatt nincs szükségem külön megnyitni az rtorrent-hez rendelt portokat, mivel az rtorrent indító script ezt ugye megteszi.Nos az UDP működéséhez beszúrtam közvetlen a másik sor alá egy
iptables -I INPUT -i "$1" -p udp --syn --dport $P -j ACCEPT
sort.
Az előbbi fwopen() részhez tartozott, így a fwclose() részt is hasonlóan szerkesztettem át.
Elindítva az rtorrentet az S99rtorrent segítségével viszont arcomba dobott
/opt/etc/init.d/S99rtorrent start
Starting rtorrent
iptables v1.3.8: Unknown arg `--syn'
Try `iptables -h' or 'iptables --help' for more information.
iptables v1.3.8: Unknown arg `--syn'
Try `iptables -h' or 'iptables --help' for more information.
iptables v1.3.8: Unknown arg `--syn'
Try `iptables -h' or 'iptables --help' for more information.Nem tudom mit tesz a --syn, de ha jól veszem ki, akkor nem kellene, hogy ott legyen az iptables sorokban.
Mindenesetre a délután tapasztalt 8-10KB/s le- és feltöltés kicsit megugrott 200KB/s le és 70-80KB/s körüli feltöltésre. Jelenleg 1 torrent van letöltés alatt, ennél 15 peerhez és 3 seed-hez kapcsolódott. A többinél csak feltöltés van, ezeknél 2-3-hoz kapcsolódik.
AEGA-ban megnézve a terhelést 1.29,1.40,1.28 környékén van.Talán most már rendben lesz az UDP és a titkosítás használata is.
A post-firewall fájlhoz most nem nyúltam, de úgy érzem pár sort ki kellene törölni belőle, mivel teljesen fölöslegesen szerkesztettem bele a múltkor.
Így néz most ki a post-firewall fájlom:#!/bin/sh
iptables -I INPUT -m tcp -p tcp --dport 6880:6882 -j ACCEPT
iptables -I INPUT -m udp -p udp --dport 6880:6882 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j ACCEPT
iptables -A INPUT -p udp --dport 443 -j ACCEPT
iptables -t nat -A PREROUTING -i "$1" -p tcp --dport 6880 -j DNAT --to-destination "$4":6880
iptables -t nat -A PREROUTING -i "$1" -p tcp --dport 6881 -j DNAT --to-destination "$4":6881
iptables -t nat -A PREROUTING -i "$1" -p tcp --dport 6882 -j DNAT --to-destination "$4":6882
iptables -t nat -A PREROUTING -i "$1" -p udp --dport 6880 -j DNAT --to-destination "$4":6880
iptables -t nat -A PREROUTING -i "$1" -p udp --dport 6881 -j DNAT --to-destination "$4":6881
iptables -t nat -A PREROUTING -i "$1" -p udp --dport 6882 -j DNAT --to-destination "$4":6882
iptables -t nat -A PREROUTING -i "$1" -p tcp --dport 443 -j DNAT --to-destination "$4":443
iptables -t nat -A PREROUTING -i "$1" -p udp --dport 443 -j DNAT --to-destination "$4":443amiből a 6880-tól 6882-ig terjedő port tartományhoz tartozó PREROUTING sorokat kellene eltávolítani és csak a 443-hoz tartozót meghagyni.
Ha jól sejtem, akkor a PREROUTING oldja meg a portforward-ot, aminél ugye az rtorrent-hez rendelt 6880-6882 portok-at fölösleges forwardolni.
read-only mode on the forum
-
csibor
őstag
Egyszerű kérdésem lenne Azt látom torentezéshez is alkalmas a gép,de mennyire ~9500 hsz közt még kereséssel is elvesztem.Előre is köszönöm a válaszokat
-
Intruder2k5
MODERÁTOR
CPU Load Tomato-ban:
Így már érthetőbb? :-)
1, 5, és 15 perces átlagos értékek ezek...A UPC-s dologra annyit, hogy én szerencsére nem vagyok az előfizetőjük, de töltök egy torrentet, ahol össz-vissz két seeder van, az egyik UPC-s, és ma nagyon gyengén jönnek a byte-ok tőle... Tegnap sokkal gyorsabb volt. Jó, jó, tudom, hogy ennek ezer más oka is lehet, de mindenesetre érzem a sebességcsökkenést. Amúgy ha érdekel bővebben, és még nem olvastad, itt is szó van a UPC korlátozásairól.
[ Szerkesztve ]
-
Intruder2k5
MODERÁTOR
Hát 30-50 torrentet nem fogsz egy időben futtatni rajta, mint ahogy nem igazán szereti a 100 GB-os torrenteket sem. :-) Az átlagos torrent felhasználónak tökéletesen megfelel, 10-20 db torrenttel vígan megbirkózik. Nagyjából ez az, amit várni lehet egy ~250 MHz-es, 32 RAM-mal felszerelt géptől. Cserébe viszont 24/7 üzemel és töltöget, teljesen csendben, és az áramfogyasztása is elhanyagolható. Az USB-je ugyan kicsit lassú, nagyjából egy PenDrive sebességével egyezik meg (~3500 kbyte/sec), dehát ennyi pénzért ne akarjon senki egy bivalyerős home-szervert. Én mindenesetre nem bántam meg, hogy megvettem, és gondolom, hogy sokan egyet értenek velem.
-
AtHoS
nagyúr
válasz Intruder2k5 #9542 üzenetére
Kösz így érthetőbb, de még mindig nem tudom mekkora a skála amit itt megjelenít az AEGA. Ahogy látom Tomato-val 1 lenne a FULL ehhez mérten pl. a 0.05 az 5%-nak felel meg. Nade itt, igaz AEGA felületén ilyen értékeket lehet látni: 0.77...1.38 stb., tehát nem 1 a Full Load. Szép, hogy le lehet olvasni a terheltséget csak nincs mihez viszonyítani ugyanis ezt lehagyták ügyesen az AEGA felületről
Kösz a linket, majd átlesem hátha összeszedek arrafelé is 1-2 hasznos információt.
tlac
"ha titkosítani akarsz, akkor ez minek? prefer_plaintext"Gondoltam előbb megtesztelem ezzel, hátha kevesebb terhelést okoz illetve nekem úgy jött le, hogy ez a titkosítási eljárást befolyásolja csak. Tudom, hogy az RC4 jobb titkosítás, de gondolom nagyobb az erőforrásigénye is a használatának.
Eddig úgy tűnik jó lesz plaintext-tel is, de majd pár nap alatt úgyis megmutatja magát.
read-only mode on the forum
-
Intruder2k5
MODERÁTOR
-
CS_D
senior tag
Sziasztok!
Keresnék olyan válallkozó szellemű egyént, aki már csinált 128 MB-os RAM upgrade-et WL500gP v1 routeren, és elvállalná az enyém forrasztását is. Helyileg Budapest, vagy Csepel-sziget lenne megfelelő.
Annak örülnék a legjobban, ha a kedves jelentkező rendelkezne olyan memóriamodullal, amire nekünk szükségünk lesz a forrasztáshoz. De ez nem feltétel, csak így sokkal egyszerűbb, és olcsóbb lenne (hiszen akkor nekem rendelnem kell egy ilyen RAMot, amit szétdarabolunk, viszont nem használunk fel teljesen).
Az árban remélhetőleg meg fogunk tudni egyezni, úgyhogy, ha van kellő tapasztalatod, kérlek írj! Főleg privátban, de jöhet e-mail is (az adataimnál vannak a részletek).
A segítséget előre is köszönöm!
[ Szerkesztve ]
-
Kitakat
aktív tag
Sziasztok
Mennyiben más az eredménye a következö 2 sor iptable ben??
iptables -A INPUT -p tcp -m tcp -j TARPIT
iptables -A INPUT -p tcp -j TARPITElöre is köszi.
Kitekat
-
ambipur
tag
Halihóóó emberek!
A router web-es konfiguráló felületén el van indítva az nfs szerver, de pl. top-al úgy látom, hogy nem fut. Hogyan lehet kézzel elindítani? Köszönöm!
Új hozzászólás Aktív témák
● Olvasd el az összefoglalót!
- Eredeti játékok OFF topik
- Modern monitorokra köthető 3dfx Voodoo kártya a fészerből
- Rezsicsökkentés, spórolás (fűtés, szigetelés, stb.)
- iRacing.com - a legélethűbb -online- autós szimulátor bajnokság
- Milyen billentyűzetet vegyek?
- Fujifilm X
- Óra topik
- Mindenki AI-t akar, már 2025-re is eladták a HBM chipeket
- Xiaomi 11 Lite 5G NE (lisa)
- Telekom otthoni szolgáltatások (TV, internet, telefon)
- További aktív témák...
- Újszerű - ASROCK B450 Fatal1ty Gaming K4 AMD AM4 alaplap + Windows 10/11 HOME digitális licensz
- Újszerű - ASROCK B450 Pro4 AMD AM4 dobozos alaplap
- HP Elitedesk 800 G4 DM I5-8500T 16GB 256GB SSD (1 USB sérült, de működik)
- Dell 7060 Micro I5-8500T 8GB 500 GB SSD WIFI
- DELL LATITUDE 7390 I5-8250U/8GB/256GB SSD/1920X1080