- Karaktere biztos lesz az első Nothing fejhallgatónak
- Apple Watch
- Hivatalos a OnePlus 13 startdátuma
- Apple iPhone 16 Pro - rutinvizsga
- Íme az új Android Auto!
- Samsung Galaxy S24 Ultra - ha működik, ne változtass!
- Samsung Galaxy Watch7 - kötelező kör
- Xiaomi 14T - nem baj, hogy nem Pro
- Samsung Galaxy A56 - megbízható középszerűség
- One mobilszolgáltatások
-
Mobilarena
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
-
#2250
Kisbatyu75
tag
xabolcs
#2247
Kisbatyu75
tag
válasz
xabolcs
#2247
üzenetére
nekem ennyit adott vissza
és se a software se a hardware flow offload nem volt engedélyezve.
Ezeket beállítva már jóval jobb sebességet kaptam.
Te milyen speedtest csomagot telepítettél fel?
Megpróbáltam a python3-speedtest-cli csomagot, de betelt a helyem.
Mit lehet csinálni, ha már az opkg sem működik? -
xabolcs
őstag
válasz
xabolcs
#2247
üzenetére
Tudom nem segit, de teszteltem OpenWrt 22.03.2, r19803-9a599fee93 + D-Link DIR-860L B1 + PPPoE
Vezeteken:
$ speedtest
Speedtest by Ookla
Server: Vodafone Magyarország Zrt. - Budapest (id: 31271)
ISP: Digi TV
Idle Latency: 2.73 ms (jitter: 0.08ms, low: 2.64ms, high: 2.79ms)
Download: 914.86 Mbps (data used: 424.7 MB)
3.23 ms (jitter: 5.81ms, low: 2.55ms, high: 207.08ms)
Upload: 325.48 Mbps (data used: 146.8 MB)
5.28 ms (jitter: 0.75ms, low: 2.12ms, high: 6.22ms)
Packet Loss: 0.0%
Result URL: https://www.speedtest.net/result/c/e797cb07-bac8-4529-9e2b-28f14ab08871 -
#2226
losslessonly
csendes tag
xabolcs
#2209
losslessonly
csendes tag
-
válasz
xabolcs
#2198
üzenetére
Köszi, kipróbálom.
Nekem is csak erre kell, de még az is opció, hogy a pppoe kapcsolat-ot a digis kütyüre bízom majd. Költözés lesz, nem tudom még, melyiket kapom. Majd utánanézek a digis cucc képességeinek. Ez a router meg wifi hotspot + switch módba kerülhet. Majd meglátom, hogy melyik a jobb felállás.
-
-
dchard
veterán
válasz
xabolcs
#2136
üzenetére
Nincs mit mesélni róla. A DSA átállás miatt a 4.14-en bevezetett HW offload-nak annyi, egyelőre SW flow offload van 5.4-en. Ezzel PPPoE mellett 7-800megabitet lehet elérni dróton. De legalább a switch driverből eltűntek a számomra érzékelhető bug-ok, nincsenek napok/hetek után felbukkanó hibák a kernel logban. Nekem a wifi-vel semmi gondom nincs Trunk-on, se 2.4-en, se 5GHz-en.
Mivel a DSA a jelenlegi és a jövőbeni fejesztési irány, és rengeteg ilyen MTK cuccot adtak el, így jók az esélyek a HW offload újra kifejlesztésére, de az látszik, hogy ez nem egy gyors folyamat.
-
dchard
veterán
válasz
xabolcs
#2105
üzenetére
Bootloader source egyáltalán nincs benne, pedig custom U-boot van az eszközön. Egyébként bátran beírom a gyártót: Huawei. Meg azt is, hogy mekkora ívben érdemes elkerülni... A büdös szemetek úgy játsszák ki a GPL licencet, hogy minden (ezer éves) V2-es licencelt SW, majd pedig az egyébként szabvány linux image-et "aláírják", amihez természetesen nem adnak kulcsot senkinek. TTL soros-t letiltják bootloader-ben. Az egyetlen lehetőség a konfig fájl hekkelés, amivel a telnetd elindítható, majd onnan az 5 karaketeres root jelszó megtörése után simán be lehet lépni, és engedélyezni lehet a telnetet meg a TTl-t is (SShd nincs benne természetesen). Soha az életben nem veszünk tőlük többet semmit, mondanom nem kell...
-
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=0Namost 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...
-
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 ... -
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.1Bootlog:
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 -
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.
-
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.
-
válasz
xabolcs
#1903
üzenetére
pont az. ennyire nem súlyos, mint a levelekben (elsőre két napig stabil volt, utána reboot után 4 órán át bírta, most egyelőre négy és fél órája megy), de akkor rápróbálom ezt a snapshotot, köszi
aztán meglátjuk, hogy marad-e egyáltalán ez a router, mert nálam 60 négyzetméteren teljesen jó volt, de a mostani helyén a kétszintes házban sajnos gyengébb az előző telekomos eszköznél. -
suste
veterán
válasz
xabolcs
#1383
üzenetére
nálam mindig sokkal rosszabbul teljesít minden router wifi ügyileg (pl tplink1043v1 használhatatlan volt nálam), mivel elég zsúfolt az elrendezés (Modem, Router, USB3-HDD), és elég sok a saját wifi hálózat
5-6 napja van fent az új fw,
-TM, SAMBA azóta hibátlanul megy,
-a libffmpeg csere óta a minidlna is tökéletes,
-a vsftpd sajnos mégsem tökéletes, alapkonfiggal, user/pass -szal megy, de írási jogokat tartalmazó konfigokkal már nem ..... azért ez is több/jobb, mint amilyen volt2-3 napja költöztettem át a saját wifi SSID-t a dlinkre, azóta semmi hiba nem volt vele, minden egyből kapcsolódik, nem dobál le egyik freki sem
pont olyan amilyennek lennie kell -
suste
veterán
-
suste
veterán
válasz
xabolcs
#1375
üzenetére
megvan, csak kivettem a 17.01 mappából és csináltam egy 18.01-et neki
mindjárt átlinkelem az aktuális verziót (06) a 17.01-be, hogy a 9092-ről is lehessen flashelnipár apróbb hibát találtunk már benne, de mindegyiket meg lehet oldani akár új verzió flashelése nélkül is
a 18.01 mappában van changelog, ami tartalmazza a hibák kézi javítását is
szerintem a következő verzió (07) már a végleges lesz -
suste
veterán
válasz
xabolcs
#1348
üzenetére
én azt várom, hogy végre legyen egy mediaserver és wifi ügyileg is jó fw
de mint látod mindig van valami bug
a következő stabilra még várni kell, így marad a saját build, ha egyéni igényeid vannak és elfogyott a türelem
ha a stabil előtt sikerül összehozni valakinek egy jól működőt, akkor azt szívesen megosztom saját tárhelyen, és használnám is a saját routeren
vargalex és headless is tesztelget..... -
dchard
veterán
válasz
xabolcs
#1275
üzenetére
2.5-3-szoros gyorsulásról írt a fejlesztő ami nagyjából egybe vág az SFE-n mért eredményekkel, kb. ugyanazt és ugyanúgy is csinálja. A linkben még jó esélyt írt a csávó a DSA szerű driverek későbbi merge-elésére, de a fogadnék egy vastagabb összegben, hogy előbb fogjuk látni a netflow megoldást, mint az SFE-t vagy a DSA-t masterben.
Dchard
-
dchard
veterán
válasz
xabolcs
#1264
üzenetére
Megkaptuk a válaszokat a kérdéseinkre:
1. A DSA branch azért nincs még masterben, mert egyelőre csak IPsec-kel működik, de azzal sem tökéletes a buli, mivel a működéséhez nyúlkálni kell a hálózati stack-be így jó eséllyel sosem kerül a master-be. Talán lesz belőle OpenVPN képes változat, de nem mostanában.
2. A netfilter flow offload elég egyszerű téma, mivel csak a 4.14-es kernelre váltás kell hozzá, ez folyamatban van (a ramips jelenleg 4.9-en van). Szerintem max. 1-2 hónap, és látni fogjuk ezt a master-ben. UGyancsak biztató, hogy a patchset mögötti developer a linux kernel netfilter ágának egy legendás alakja.
Gondolom a korábbi nagy üdvöskét, az SFE-t ezért sem erőltetik, mert lett helyette generikus kernel infrastruktúra.
Dchard
-
dchard
veterán
válasz
xabolcs
#1264
üzenetére
Nem próbáltam még, de érdekes, hogy John egyelőre nem gondolta úgy, hogy ez megérett a master merge-re, és elég régen abbahagyta. Engem elsősorban nem is a HWNAT, hanem a hardveres AES motor érdekelne VPN-hez.
A netfilteres megoldást valószínűleg előbb fogjuk látni, mivel az működik a 4.14-es kerneltől felfelé, de egyelőre csak az integrálást készítik elő LEDE oldalon, tehát ez is odébb van még.
Időm nem nagyon van erre, de ha valamelyik ismertebb működképes build-be belerakják, szívesen kipróbálom mindkettőt.
Dchard
-
-
vargalex
félisten
válasz
xabolcs
#1208
üzenetére
ar71xx platformon is volt gond vele, de a TP-Link ilyen szempontból "szerencsés". Ott a factory firmware=0-kkal feltöltött sysupgrade firmware. De a különböző routereknél nem ez az általános. Úgyhogy érdemes úgy megszokni, hogy OpenWrt/LEDE-re sysupgrade, gyárira factory firmware megy.
-
Empotempo
csendes tag
válasz
xabolcs
#1000
üzenetére
Köszönöm. Sikerült a telepítés minden gond nélkül. Már csak be kell lakni az "új" routert. Fogalmam sincs mi lehetett a gond a gyári fw-rel, de mint már írtam egyik-napról a másikra nem tudtam elérni a felületet, sem wifin sem vezetéken. Csak a reset segített és ha már úgyis mindent újra kellett állítani, gondoltam megprópálom a padavant. Vargalexnek külön köszönet és pacsi!
-
kzkz
őstag
Végülis megcseréltem, sőt csak a dlink maradt. Felment rá a stable lede, és később a snapshot is. Hát a wifi rögtön használhatlan is lett, ott volt mellette a laptop és 0,05mbps volt a sebesség.
Kénytelen voltam visszarakni a gyárit, ezzel 50mbps.Viszont itt ha átállítom a dns szervert, hogy ne a 0.1-et ossza, hanem 1.1-től,akkor újraindul kis idő múlva
Ez a gyári fw egy nagy fos. Miért csak max 15 fix ip-t, és 15 port forward-ot lehet beállítani???????
Azt hiszem visszaviszem, és veszek egy TP-LINK TL-WR1043ND v4-et, a v1.1 helyett...
-
vargalex
félisten
Miért ne mondhatná azt az 1043ND-n, hogy a wifi nem a LAN-hoz tartozik, külön hálózatot alkot saját DHCP szerverrel, sávszélesség korlátozással. Akár még NAT-olhat is a kettő között. Külön szabállyal pedig felveheti, hogy a szomszéd tartományból a saját tartomány nem érhető el (kivéve az ott futó DNS szerver), csak a WAN.
-
vargalex
félisten
Nincs ebben semmi érdekes. A jellemzően 1500 byte-os frame-okat szét kell tördelnie, hogy a PPPoE header-el együtt beférjen az ethernet keretbe, újra checksum-olnia kell, stb.. Szerver oldalon természetesen a ugyan ezt el kell játszani, az összetartozó frame-okat egybe kell rakni, stb. Jól látható, hogy ez mindkét oldalon jelentős többlet erőforrás igénnyel jár.
-
suste
veterán
Nekem pont az volt a célom, hogy a valós (átlag)sebességet mérjem. Szóval valamit elkezdesz letölteni az mennyi idő alatt jön le.
De persze gigabites sebességhez már kevés lehet így a router procija, bár a load nem megy fel ilyenkor sem az egekbe.
A speedtestes és hasonló mérések nekem azért nem szimpik, mert igaz hogy nem a csúcsot mutatja, de nem is valós átlagsebességet amivel majd ha letölteni akarsz azt fogod elérni....persze ez már a szerveren is nagyban múlik majd. De ha valaki csak az epéniszre hajt, akkor arra tökéletes
-
-
dchard
veterán
Akkor igazad is lenne, ha a HW NAT pontosan ugyanazt a feladatot csinálná meg hardveres gyorsítással. A probléma az, hogy ez nem így van. A HW NAT az esetek többségében egy csalás, ráadásul megtöri a kompatibilitást a linux kernel hálózati stack-jével, ebből számos limitáció és probléma fakad. Van olyan népszerű implementáció, amely például nem gyorsítja a forwardolt portokat. Tehát baromi jón néz ki a speedtest-es gigabites mérés, de amikor a NAS-ra torrenteznél, vagy FTP-znél, már nem működik a "HW NAT". Egyéb probléma még a késleltetés: például kis méretű csomagokat lassabban tol át magán, mint a normál software stack, különösen terhelés alatt. Vagy hogy mást ne mondjak: egyetlen jól működő QoS motorral sem működnek a jelenlegi HW NAT megoldások, ellenben az SFE működni fog velük.
Tehát bőven van limitáció a HW NAT-ban. Arról nem beszélve, hogy milyen nehéz implementálni driver szinten a különböző gyártók eltérő megoldásait a ki nem adott specifikációk miatt. Ennél sokkal jobb döntés volt az SFE generikus kódja, és az ebbe fektetett munka, amiből viszont mindenki profitál. Nem is emlékszem az elmúlt évekből hasonlóan széles réteget érintő, ennyire látványos méretű előrelépésre, ami egyetlen OWRT/LEDE fejlesztéshez köthető.
Hogy visszatérjek a saját házunk tájára
ebből a szempontból továbbra is a Wifi drivereket kéne tovább reszelni, de ahogy nézem eléggé leült az aktivitás az mt76 repóban.Dchard
-
dchard
veterán
Ennél sokkal érdekesebb a helyzet NAT ügyileg. Úgy tűnik, hogy nem kell majd a HW NAT-tal szórakozni, mert éppen születőben van egy gyors, de nem hardware függő megoldás: a Shortcut Forwarding Engine, vagy SFE röviden. Vargalex és többen már tesztelték, elég látványos 2-3 szorors gyorsulást lehet vele elérni, de láttunk már 3-4-szereset is. És ez generikus megoldás, ha végre betolják LEDE- alá, akkor az összes router profitál majd belőle.
Itt tudsz olvasni róla:
https://forum.lede-project.org/t/qualcomm-fast-path-for-lede/4582
Elég jól állnak már. Ne tévesszen meg a név, nem Qualcomm specifikus, csak a kód egy része tőlük származik.
Nem mintha a 860L ne tudná most is kinyomni LEDE alatt a gigabitet, de sosem baj ha marad processzor idő másra is
Dchard
-
Tyrel
őstag
Erről a HW-NAT-os, új WiFi driveres LEDE-ről majd írtok ide?
Vagy mi ennek a (branchnek??) a pontos neve, hol lehet nyomon követni a fejlődését?@csocsoszán:
Azt végül is nézted hogy nem ütközik-e valamelyik ~router CPU limitbe? (bár a huawei-n nem tudom hogyan lehetne)
Amúgy igen, a digi jóval olcsóbb mint mások, de mint tudjuk olcsó húsnak... Telekom drága és amúgy egy istentelen balfasz banda, sokszor akasztottak már ki (csak így vidékiként nincs más szolgáltató itt, max. még Invitel...), de eddigi tapasztalataim és ismerőseimnél látottak szerint ők jellemzően azt, vagy közel azt adják amiért fizettél nekik. Amúgy egy fejetlen idióta banda, a szoftveres részlegük is béna, de netem 56k modem óta (még Axelero-nak hívták őket) végig tőlük van, és sosem volt vele gond... Ill. egyszer sok éve két napig nem volt net, mert valami részeg vadbarmok május fát állítottak a fő telefon vezetékbe, de hát arról nem a Telekom tehet... (amúgy utána hetekig ezen röhögött a város, konkrétan ott volt a május fa mellett kidöntve a fűben a telefonvezetéket jelölő tábla... biztos nem tudták mi lehet az...) -
woodworm
veterán
Nem akartam a padavan eltérő felosztásával többet foglalkozni, mivel egyes partíciókat egyesíteni, míg a maradékot darabolni kellene, hogy egy lede alatt készített mentést visszarakj. Hogy a csavar teljes legyen, ha az átmeneti fw felületén mentettél, ugyanazt kapod vissza.
Tehát egyesítettem a lede alatt mentett következő három partíciót:u-boot-env.backup
radio.backup
factory.backupA létrejött fájlt felírtam a defaults.backup partícióval egyetemben, az írás végeztével áramtalanítottam a routert és recovery módban indítottam, raktam rá a kívánt fw-t.
Új hozzászólás Aktív témák
Hirdetés
- OLED TV topic
- Karaktere biztos lesz az első Nothing fejhallgatónak
- Motoros topic
- PlayStation 5
- Kevesebb dolgozó kell az Amazonnak, AI veszi át a rutinfeladatokat
- Motorolaj, hajtóműolaj, hűtőfolyadék, adalékok és szűrők topikja
- Végleg lenyomta a tévét a streaming az USA-ban
- Egyéni arckép 2. lépés: ARCKÉPSZERKESZTŐ
- Milyen belső merevlemezt vegyek?
- Xbox Series X|S
- További aktív témák...
- Szép Dell Latitude 7320 -60% "Kis Gamer" Üzleti Profi Ultrabook 13,3" i7-1185G7 32/512 FHD IRIS Xe
- LG NanoCell 50NANO759PR
- Samsung Galaxy S23 256GB (garis)
- i7 8700/ 32GB DDR4/ 512GB gen4 SSD/ R5 430 2GBD5/ HP 400G5 SFF/ garancia/ ingyen foxpost
- HUAWEI WATCH GT5 46 mm Active, két hetes készülék, kb 23 hó garancia, ÜZLETBŐL
- Lenovo S10-2 Intel Atom retró csajszis netbook eladó
- BESZÁMÍTÁS! MSI Crosshair 17 HX Gamer notebook - i7 14700HX 64GB RAM 1TB SSD RTX 4060 8GB WIN11
- AZONNALI SZÁLLÍTÁS Eredeti Microsoft Office 2019 Professional Plus
- ÁRGARANCIA!Épített KomPhone Ryzen 5 4500 16/32/64GB RAM RX 6500 XT 4GB GAMER PC termékbeszámítással
- Turbózd fel géped a jövő RAM-jával!
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: Promenade Publishing House Kft.
Város: Budapest