- Samsung Galaxy Watch (Tizen és Wear OS) ingyenes számlapok, kupon kódok
- Milyen okostelefont vegyek?
- Samsung Galaxy Watch6 Classic - tekerd!
- Samsung Galaxy S25 Ultra - titán keret, acélos teljesítmény
- Poco F3 - a mindenes, de nem mindenkinek
- Honor Magic V5 - méret a kamera mögött
- Samsung Galaxy Z Fold7 - ezt vártuk, de…
- Yettel topik
- Samsung Galaxy A52s 5G - jó S-tehetség
- 165 Hz-es panelt tesztel a OnePlus
Hirdetés
-
Mobilarena
Xiaomi AX3600 WiFi 6 AIoT Router
Új hozzászólás Aktív témák
-
dchard
veterán
Tehát. Az utolsó változatba bekerült a két rootfs partíció "összevonása", így több hely lesz a routeren további alkalmazások telepítésére. Ezt csak úgy lehet elvégezni, hogy a meglévő beállításokat elveszítjük.
Az 5. lépésben ráformázod az új initramfs image-et a passzív partícióra, majd bebootolsz rá.
Majd a 9-es lépésen ráfrissítesz arra a változatra, amit az előbbiben felraktál, a normál (nem initramfs) változattal. NIics elírás: az 5-ös lépésben az "initramfs" nevű fájlt írod fel, a 9-esben a "sysupgrade" nevűt.
-
dchard
veterán
Na akkor mondom mit kell csinálni:
1. A /etc/config/network fájlt módosítjuk e szerint:
eth0 -> wan
eth1 -> lan1
eth2 -> lan2
eth3 -> lan32. Terminálban kiadjuk a következő két parancsot:
uci set system.@system[0].compat_version="1.1"
uci commit system3. Nem mulasztjuk el a wpad megállítását:
service wpad stop
Majd (akár webes felületen) frissítünk ahogy szoktunk ("Keep settings and retain the current configuration" maradjon bepipálva).
Fontos, hogy a frissítés után nálam legalább is a PPPoE kapcsolat nem működött (egy nem létező wan0 nevű interfészre mászott a beállított PPPoE kapcsolat, ezt a Network --> Interfaces --> Edit (a PPPoE kapcsolat mellett), majd a Device legördülő menüből válasszuk ki a "wan" (szám nélkül) nevű lehetőséget, és nyomjuk meg a Save majd a Save & Apply gombokat. Ezután mindennek működnie kell.
-
dchard
veterán
Később majd kipróbálom, elvileg működik de nincs erről tapasztalatom. Aki siet az csinálja teljes törléssel, ha elég magabiztos vagy akkor írd át a konfig fájlt (sysupgrade előtt a wpad-t ne felejtsd el megállítani). Mindenki saját felelősségre csinálja temrészetesen, amíg nincs kézzelfogható tapasztalat amódszer működőképességéről.
-
dchard
veterán
válasz
netcore #5142 üzenetére
Ez teljesen normális. Ez egyébként sem update hanem upgrade. Van egy csomó rendszer komponens, amik kereszt függésben vannak, de nincsenek mind benne ebben a 11megás fájlban értelemszerűen. Ha mondjuk a kernel frissül, de a hozzá szervesen kapcoslódó kernel modulok nem, akkor nagy baj lenne a következő indításnál. De egy "opkg update", majd egy "opkg upgrade" meg tudja oldani ezt a kérdést, mivel mostmár ha jól emlékszem a modulokat is leforgatja a Robi hozzá (sok volt a panasz az egyszeri userektől).
Nyilván ha magadnak fordítanád az image-et, akkor nem lenne ez a probléma, mivel akkor minden olyan szoftver újabb változata is benne lenne amit a korábbi verzión is használtál, tehát akkor valóban lefrissülne minden rész a sysugrade során.
-
dchard
veterán
Értelemszerűen ez az üzenet akkor van ott, amikor a rádió elindul és rögtön érézkeli a problémát, ritkább esetben ha menet közben jön fel egy átlapolódó hálózat.
Namost felteheted a kérdést, hogy (ha nem változott semmi körülötted), akkor hogy van az hogy a gyárival "jó" volt, ezzel meg nem az? Ez úgy fordulhat elő, hogy a kínai verziók javarészt szarnak minden szabályozásra, vagy nagyon nagyon könnyen megkerülhető bennük a szabályozás.
-
-
dchard
veterán
válasz
netcore #5123 üzenetére
Akkor:
fw_setenv flag_last_success 0
fw_setenv flag_boot_rootfs 0És reboot után az mtd12 fog indulni, már Openwrt-vel. Ahol már az mtd12 lesz az akítv, így rá tudod formázni az mtd13-ra is. Utána
fw_setenv flag_last_success 1
ésfw_setenv flag_boot_rootfs 1
, reboot és mtd13-mon leszel szintán Openwrt-n. Innentől a webes felületen a sysupgrade működni fog (wpad megállítás után), nem muszály SSH-val csinálni. -
-
dchard
veterán
20MHz 2x2 MIMO mellett is 144mbit lesz a kapcsolat sebessége. De ha semmi nem változott és most csak 20MHz-en megy és 40-re van állítva, akkor is lehet hogy valami belelóg a történetbe. Amit még megpróbálnék, hogy nem automatikus csatornakiosztást állítok be, hanem kipróbálod a 3-as vagy a 11-es csatornákat 40MHz-es módban.
Telefonon valamelyik wifi analyzerrel meg kell nézni, nincs-e a közelben hálózat ami belelóg a 40MHz-edbe, ha van ilyen akkor vissza fog váltani 20megára.
MOD:
Ha belenézel a Status --> System log-ba és ezt látod:
daemon.notice hostapd: 20/40 MHz operation not permitted on channel pri=13 sec=9 based on overlapping BSSes
Az azt jelenti, hogy nem tudsz 40MHz-re állni, mert a router átlapolódó hálózatot érzékel.
-
dchard
veterán
"Bár a fenti képen 1-es csatorna van, ami ugye nem átlapolódó."
Bármelyik csatorna átlapolódhat. Összesen 65MHz sávszélesség van (ez 13 csatorna). Ha te 40Mhz-ez szeretnél, az azt jelenti, hogy a 13 rendelkezésre álló csatornából 8-at használni akarsz. Ez a te esetedben 1-8-at jelent. Ez azt jeleneti, hogy a router nem érzékelhet hálózatot az 1-es és a 8-as csatorna között sehol sem, ellenkező esetben visszavált 20MHz-re.
Ennek oka az, hogy több hálózat esetén korlátozzák a hálózatok egymásra gyakorolt interferenciáját, illetve azt hogy senki ne használhassa el a rendelkezésre álló kevéske szabad kapacitás nagyobbik részét. Ezt hívják 40MHz co-existence mode-nak, ami minden routerre kötelező. Mivel régen ezt is hekkelték (mint a kimenő teljesítményt), a legtöbb modern chipset ennek a kikényszerítését elzárta a felhasználók elől (nagyon helyesen), és a viszonylag könnyen manipulálható driver-ből a chipsetet működtető belső firmware-be rakta. Akárcsak a DFS-t és a CAC-ot, vagy a TPC-t.
-
dchard
veterán
Ennek egyszerű az oka: a 40MHz minden esetben coexistence mode, ha a router átlapolódó csatornát érzékel, visszavált 40-ről 20MHz-re. Pontosan azt csinálja ami a dolga. Az Openwrt alatti 40MHz a gyári 20/40-nek felel meg: ha a körülmények alkalmasak akkor 40MHz, ha nem akkor visszavált 20MHz-re.
-
dchard
veterán
Pontosan. Nem fog ilyen történni. Mint ahogy olyan sem, hogy ha az egyikől nem indul el, akkor majd a máskról elindul. Az ok prózai: mi lenne erre a trigger? Honna fogja tudni a bootloader, hogy az előző indítás sikertelen volt és váltania kell? Egyáltalán miért volt sikeretlen az indítás? Konfig gond? Vagy elhasalt a kernel? Túl sok olyan hibalehetőség van, aminek a kezelésére ezzel a módszerrel nincs lehetőség.
Ezért is megy az agyalás a két partíció összevonásán, de egyelőre bőven van nagyobb gondunk is, ráadásul alaposan tesztelni kell, hogy a partíció összevonás nem cseszi-e szét a gyári recovery-t, és üzembiztosan tud-e működni egy átlag user számára is.
-
dchard
veterán
Amikor olyanok írkálnak a wiki-be, akiknek lövése nincs semmiről... Mint ez a redalert nevű idióta... Látom a logból, hogy ő editálgatja megállás nélkül az AX3600 wikijét... A vonatkozó topikban is olyna ötletekkel áll elő, amitől már a hozzám képest brika türelmű Robinak is ketté áll a füle... Persze soha életében nem commit-tel soha semmit egyetlen projektbe sem, de ötletelni azt tud... Szeretet ünnepe ide vagy oda, de ettől már a tököm kivan
Mindkét partíciót meg kell írni a sysupgrade-hez, hacsak nem akarsz kézzel szerencsétlenkedni a parítcióváltásokkal.
"mindkettőre kell a konfig visszaállítás ugye"
Nem, csak arra kell amivel felindult (aktív). Utána majd a sysupgrade intézi a többit a legközelebbi upgrade-nél. Nem szabad az aktív és a passzív partícióra úgy tekinteni, hogy ott a routeren egy tartalék vagy ha úgy tetszik "backup" rendszer, mivel ez sosem működött jól alapvetően amiatt, mert a Xiaomi szarul implementálta ezt (a bootloaderben).
-
dchard
veterán
Poén kedvéért megpróbáltam a mai legfrissebbel és működik.
Azt tudom tanácsolni, hogy egymás után frissíts rá kétszer wpad lelövés mellett természetesen. Ha ez nem elég, akkor meg kell nézni a partíció váltásra vonatkozó NVRAM beállításokat. Lehet valamiért nem vált partíciót (bár ha kétszer frissítesz egymás után akkor ennek mennie kellene).
-
-
dchard
veterán
Először is nem tesz oda senki semmit sehova
Automatika forgatja ezeket a githubon, és mivel a fordítás sikeres, így kimentek ezek az állományok is. Az ath11k-ban szarták el a kisebb memória kezelésére vonatkozó részt. Néha előfordul az ilyen.
Másodszor, mint látod itt nem egy típusra, hanem egy komplett paltform összes routerére fordul szoftver, és bizony vannak 1GB-tal szerelt routerek ugyanezzel a SoC-cal. Azokat nem is érintette a probléma. Mi több, vannak ugyanezzel a SoC-cal szerelt routerek, amik akár 10Gbitet is tudnak (pl. QNAP 301w), amire ugyanúgy ez a verzió fordul.
Az AX3600 csak egy részhalmaza a munkának ami folyik.
-
dchard
veterán
Oda van írva a release notes ba hogy:
DO NOT USE ON 512MB DEVICES!!
They will bootloop!!Tekintve hogy az AX3600-on 512MB RAM van, így záros időn belül elfogyhat a sazabad memória.
Az tulsó nem érintett release a ipq807x-2022-12-14-1132 amíg a probléma nem oldódik meg, addig azt tudom ajánlani.
-
dchard
veterán
Ha nem éred el a routert se SSH-n se weben, akkor már mindegy. Újraindítás és ima. Ha újraindítás után sem éred el, akkor kipróbálhatod a Xiaomi recovery tool-t. Utána gyári állapotból kell ismét átmenni Openwrt-re.
Tegnap volt egy hibás kiadás, többeknek is szar lett, lehet ebbe futottál bele?
-
dchard
veterán
válasz
Black&White #5041 üzenetére
A dizájn borzalom, nem tudjuk milyen SoC (nagyon nem mindegy, 4 magos ARM-ból van 3 féle QCA is, de ebből csak egy az ami használható, és hát... borzalmas nagy. Ja és nem 6E képes... Ennél többet vártam, hogy mit ne mondjak...
-
dchard
veterán
Binwalk és unsquashfs segedelmével lehet kibányászni a szükséges állományt. Nem éppen egyszerű, már ha még nem csináltál ilyet.
De ha ehhez nem füllik a fogad, akkor használhatod a Xiaomi reocvery tool-t is a gyári verzióra való visszaálláshoz. Feltéve hogy a partíciós tábla még gyári.
-
-
dchard
veterán
válasz
iloilo2000 #5027 üzenetére
Az Openwrt fejlesztéshez tudnék vele mit kezdeni, az elmondottak alapján javíthatónak tűnik.
-
dchard
veterán
-
dchard
veterán
Na az király. Nekem laptoppal sikerül kitekerni gigabites sebességet (2x2, 160MHz), telefonnal 80MHz-en is stabilan kijön 7-800Mbit, de az enyém AX6, amiben gyengébb a FEM mint az AX3600-ban.
A 2.7-es wifi FW is lassan éledezik, attól is várható némi javulás, a changelog két A4-es oldal a jelenlegi 2.5-öshöz képest, ami két évvel újabb a gyárinál... Szóval el tudod képzelni.
-
dchard
veterán
Nincs mit.
Hogy legyen ehhez egy kis magyarázat is: az Openwrt frissítő rutinja a tmpfs-re tölti fel a fájlt, ami a memória része. Azért hogy a kisebb memóriával rendelkező eszközök is működjenek, a sysupgrade jellemzően leálltja a wifit és más egyéb nem létfontosságú szolgáltatásokat, hogy legyen elég szabad RAM a frissítéshez. A probléma az, hogy az ath11k (a wifi driver) nem áll le kellően gyorsan és ez okozza a problémát. Ha a wpad szolgáltatást leállítod a frissítés előtt, akkor ezzel megkerülted a hibát.
De most jövök rá, hogy ezt a Luci alatt is meg tudod csinálni:
System --> Startup és itt a WPAD mellett nyomsz egy stop-ot. Így SSH-zni sem kell
-
dchard
veterán
"És nem tudom visszatenni a gyárit, majd onnan a hivatalosra frissíteni? Dehogynem! "
Ezt többen képzelték a QSDK alapú "változatoknál" is, aztán némelyeknél hard brick lett belőle. Az, hogy a gyári recovery tool pontosan mit csinál, és milyen mértékű változtatás az, amit még tolerál, nem ismerjük pontosan, és ezek a túlzóan magabiztos kijelentések, amik azt sugallják az átlagos usernek, hogy akármekkora szart csinál, a recovery tool majd mindig ott lesz hogy megoldja, egyszerűen hamis illúziók, alapos tesztelésükre soha nem került sor...
-
dchard
veterán
Ez majd akkor lesz probléma, amikor megpróbálsz a két változat között váltani... 1-2 hónap múlva elkészül a PR, bemegy master-be, a Dimfish féle verzió eltűnik a sülyesztőben, és amikor majd megpróbálod a Dimfish-re ráfrissíteni a valódi OWRT-t na majd akkor lesz gond...
" Van szerinted értelme ezen túl ragozni a dolgot az én szintemen? "
Persze hogy van: felvilágosítani másokat, hogy ne kövessék el ők is ezt a hibát.
-
dchard
veterán
Azt hiszem jobb ha távolabbról indítok.
Tehát, jelenleg azon dolgozunk, hogy a platform szintű támogatás az IPQ807x-hez végre bekerüljön az Openwrt master-be. Ezt alapvetően Robimarko, Ansuel és kis mértékben jómagam végezzük. Ez nem egy, hanem számos eszköz támogatását jelenti, nem csak az AX3600-ét. Az összes ezzel kapcsolatos muknát Robimarko fogja össze, és a saját github account-ján található "a" változat, amit tesztelni kell. Ez segíti a fejlesztési munkát, minden más viszont nem. Vannak ilyen vadhajtásk, mint a Dimfish féle verzió, ami egyébként a Robi féle fork-ra épül, de belenyúlt a partíciós táblába. Hogy ezt helyesen tette-e vagy sem, az nem derül ki, mert akinek lenne hozzá esze, annak fontosabb dolga van. A partíció tábla összevonás ugyanis sokadlagos kérdés. És ha valaki (és volt már rá példa) egy ilyen vadhajtással elrontja a saját routerét, az magára fog maradni.
Tehát továbbra is ez az egyetlen forrás amit használni érdemes:
https://github.com/robimarko/openwrt/tree/ipq807x-5.15-pr
Persze mindenki azt rak fel a routerére amit akar, csak aztán nem szeretném hallgatni a "szar az openwrt" című nótát, meg téglásodott a routerem című örökzöldet
-
dchard
veterán
Az Iperf3 szerver nem a routeren futott, remélem. A router a DUT (device under test), az nem vehet részt a forgalom generálásban. Láthattad, hogy nálam is egy NAS és egy PC között ment az Iperf3, a routeren csak áthaladt a forgalom. A flow offload alap kernel fícsör, olyan nincs hogy nem működik. Gondolom azért a flow offload bekapcsolás után újraindítottad a routert.
-
-
dchard
veterán
Na ennek örülök. És hamarosan jön az új wifi FW is , ott még várjuk hogy a Qualcomm az új regdb formátumot publikálja, ez hamarosan megtörténik, ígéret is van rá. Egyelőre az ütemező "schedutil"-ra van állítva, nekem az a tapasztalatom, hogy "ondemand" módban kicsit jobb a helyzet, különösen ha PPPoE-n van hajtva a technika és valakinek kell minden bit sávszélesség.
-
dchard
veterán
Az IoT rádiót felejtsd el, a maradék kettőn tudsz. Tőzfalnál csak a SW flow offload legyen kiválasztva, más ne. Nálam a LAN-LAN 940/940, WAN-LAN pppoe-n 920/320 (Digi), de a terhelés alapján bőven bírnia kell a gigabites feltöltést is, ha monjduk Telekom optikád van. Wiifnél azt az országot kell kiválasztani ahol használod :-) A CAC timout 600 másodperc, tehát 5gigán 10 percig kell várni adott DFS csatronán, hogy a rádió elinduljon, türelem rózsát terem (nem, nem az OpenWRT szar, ez az EU-s előírás minden DFS csatornára ami radar közelben van).
-
dchard
veterán
válasz
KilgoreTrout #4793 üzenetére
Ha ezt szeretnéd akkor egy rádió, két BSSID és AP szeparáció a megoldás, nem egy külön rádió. Bár hogy ettől mitől lesz a hazatelefonálós kínai kütyüd biztonságosabb, azt nem nagyon értem...
-
dchard
veterán
Nem vagy egyedül ezzel, már ketten nem értjük. Ha valaki vidéken él és üres a 2.4 akkor jobban jár egy 40MHz-es csatornával, ha meg annyira tele van a 2.4, akkor pont lófütyire nem fog menni a külön IoT rádióval, de kapacitás szempontjából sincs értelme, mivel az IoT ugye alapvetően kis sávszél igényű eszközöket jelent...
-
dchard
veterán
válasz
enginev3.0 #4783 üzenetére
A privátban feltett kérdésedre itt válaszolok:
1. Igen, van az ax3600-ra Openwrt.
2. A MiHome app nyilván nem működik vele.
3. Az "IoT antenna" egy pont ugyanolyan rádió, mint a többi, tehát szerintem működnie kell, bár az ég világon semmi értelme nincs a létének. Marketing bullshit. Kipróbálni nem tudom, mert nekem AX6-om van, amiben nincs "IoT antenna", de ha nem működne, sem veszítenél vele semmit.
-
dchard
veterán
válasz
bzolika10 #4782 üzenetére
"Az openwrt topikban olvastam, hogy mergelve lett a robimarko féle build"
Rosszul olvastad, nincs még mergelve. De még csak PR sem készült még rá.
Robi nagyjából hetente húzza be és rebase-eli a saját repo-ját, alapvetően kernel és wifi driver (ath11k) javítások kerülnek be. A git log-ból kiderül hogy mik, aztán el leht dönteni, hogy ez téged érint-e vagy sem.
Most éppen a 2.6/2.7-es új wifi firmware-en megy a munka, a kismadarak már csicseregétk hogy van rá végre megoldás, tehát ez hamarosan várható. Na nem mintha a mostani 2.5-ös verzió ne lenne fényévekkel újabb annál, ami a gyáriban (vagy bármelyik kínai hekkelésben) benne van...
-
dchard
veterán
válasz
woodworm #4703 üzenetére
A/B partíció. A teljes rootfs kettőzve van, hogy amikor upgrade-elsz, legyen egy teljese másolat, és ha "sikeres" akkor partíciót vált. Persze ott a hiba a logikában, hogy az hogy mikor számít sikeresnek az upgrade, azt nehéz "megállapítani", így valójában számos olyan hibás állapot lehet, ahol ez a megoldás nem menti meg az egyszeri user-t, és recovery lesz a vége. OWRT alatt lesz olyan megoldás a teljes kapacitás kihasználására, hogy nem kell újra partícionálni az egészet (overlay), de még azt hiszem nincs benne a kódban.
-
dchard
veterán
válasz
woodworm #4691 üzenetére
Úgy van ahogy mondod: vannak fix partíciók fix funkciókkal (bootloader, BDF, ART stb.) illetve a helytakarékosság jegyében egy nagyobb partíció fel van osztva kernel+rootfs+rootfs data-ra. Ez azért fontos, mert régebben ezeknek fix partíciója volt, viszont ha nőtt a kernel mérete vagy a rootfs-é, akkor sok volt rajta az overhead. Most ez a fordítás során és futási időben dől el, így például a kernel vagy a rootfs partíciók mérete dinamikusan mindig pontosan akkora, amekkora a fordítás végén az elkészült méret.
De nem csak az a fontos, hogy ha összeadod ezeket, az stimmeljen. Az is fontos, hogy a fontos partíciók határa ott legyen ahol a szoftver számít rájuk, ellenkező esetben olyasmit ír felül, amit nem kellene. Ez a baj a QSDK alapú szarokkal, hogy a Xiaomi A/B partíciós struktúráját megváltoztatja és az A/B partíciókat összevonja. Itt ez ránézésre nem áll fenn.
PpenoO:
Pillanatnyilag Robimarko verziója "a verzió", nem fork olyan értelemben, hogy ő fejleszti.
"Jól értem nincs még egy szimpla bin install megoldás?"
Nem is lesz hozzá ilyesmi, mint ahogy az újabb routerekhez egyhez sem lesz, mert a szoftver ellenőrzi a felírt fájl hitelességét. Ezt nem tudjuk replikálni, tehát a webes felületről betallózható két kattintással telepíthető megoldásokra kár várni. De ez nem csak erre a routerre igaz, hanem a legtöbbre.
Majd meg kell nézni, hogy lehetséges-e a beépített recovery-n keresztül mondjuk initramfs-re bootolni, és onnan tovább menni a végleges változatra.
-
dchard
veterán
válasz
csabi10 #4678 üzenetére
Erre nem tudok neked választ adni. Én gyáriról rögtön OWRT-re mentem, az pontosa a leírásoknak (nem itteni) megfelelően működött. Azóta is azzal használom. Ha biztosan nem volt rajta QSDK alapú szar, akkor érdemes lehet a Xiaomi recovery tool-lal visszaállni a gyári állapotra, megcsinálni az SSH elérést, ellenőrizni újra, és utána lehet menni OWRT-re.
-
dchard
veterán
-
dchard
veterán
Összehaosnlítod azzal ami az OEM bootlog-ban van [link] ha egyezik akkor mehet. Ha nem haragszol nem én fogom karakterenként átnézni, annál sokkal fáradtabb vagyok. Még a végén elnézek egy számot aztán én leszek a felelős. A linken egyébként ott a QSDK alapú partíciós tábla is, tehát elég könnyű eldönteni, hogy az van-e vagy a gyári.
Az "mtd: device 12" és a rákövetkező sor norálisnak tűnik, az OEM bootlog-ban is benne van.
Minden szoftver módosításra vonatkozik (beleértve a topikban népszerű "kinaisítást" is), hogy bármilyen módosítás előtt az ART nevű paríciót érdemes kimenteni. Ez tárolja az eszköz egyedi kalibrációs adatait. Ha elrontunk valamit és ez megsérül vagy felülírjuk, pótolhatatlan, és a wifi jelentős romlásával jár.
Kimenteni így lehet:
1. Keressük meg az MTD eszköz nevét:
cat /proc/mtd
dev: size erasesize name
mtd0: 00100000 00020000 "0:sbl1"
mtd1: 00100000 00020000 "0:mibib"
mtd2: 00300000 00020000 "0:qsee"
mtd3: 00080000 00020000 "0:devcfg"
mtd4: 00080000 00020000 "0:rpm"
mtd5: 00080000 00020000 "0:cdt"
mtd6: 00080000 00020000 "0:appsblenv"
mtd7: 00100000 00020000 "0:appsbl"
mtd8: 00080000 00020000 "0:art" <--- ez az ART partíció!
mtd9: 00080000 00020000 "bdata"
mtd10: 00080000 00020000 "crash"
mtd11: 00080000 00020000 "crash_syslog"
mtd12: 023c0000 00020000 "rootfs"
mtd13: 023c0000 00020000 "rootfs_1"
mtd14: 01ec0000 00020000 "overlay"
mtd15: 00080000 00020000 "rsvd0"2. Majd pedig mentsük ki a tartalmát:
dd if=/dev/mtd8 of=/tmp/art.backup
3. SCP segítségével mentsük ki a /tmp mappából a fájlt és tegyük el biztos helyre.
-
dchard
veterán
válasz
bzolika10 #4627 üzenetére
Tudtommal egyelőre nem. Egyébként nem csak a gigabit feletti net miatt lehet érdekes, de a wifi is tud gigabit feletti sebességet. A QSDK-ban (amire a gyári firmware is épül többek között) ha jól emlékszem van bonding modul de hogy pont a 8075-ös switch chip ezt tudja-e, az jó kérdés. Emlékeim szerint nem próbálta még senki, de OWRT-ben is van már bonding modul, tehát akinek kedve van, próbálja ki.
-
dchard
veterán
válasz
trance89 #4620 üzenetére
"Szerinted az openwrt egy tökéletes fw, szerintem pedig egy félkész tákolmány."
Senki nem hiszi, hogy az OpenWRT tökéletes. Ez az állítás pont ugyanakkora tévedés, mint hogy félkész tákolmány. A több évvel ezelőtti rossz tapasztalatod kivetülése látszik a leginkább ezeken a szélsőséges kijelentéseken.
Ha a Wifi teljestmény érdekel, akkor azt tudom neked mondani, hogy egy Xiaomi Mi11Lite 5G-NE-vel (AX, 1x1), és egy Intel AX210 kártyával (AX, 2x2) szoktam tesztelni, a telefonon stabilan 6-700Mbit jön ki lefelé, felfelé 4-500Mbit, az AX210 esetén a gigabit ethernet a szűk keresztmetszet, de ha a teszt a router és a kártya között zajlik, akkor lehet mérni 1.3-1.4gigabitet is stabilan (160MHz-en). Ettől függetlenül nincs NSS offload OWRT alatt, ami azért néha jó lenne. Én crash-t lassan egy éve nem láttam, és biztos lehetsz benne, hogy ha heti újraindulásokat látnék, én sem használnám, az egész háztartásomat ez a router szolgálja ki, nem hobbiból van. Mesh témában én nem tudok nyilatkozni. PPPoE mellett is kijön belőle a gigabit stabilan, ez alapvetően az erős ARM magoknak köszönhető, szerencsére a kernel rengeteget fejlődött itt is. Az ethernet driver butácska, de ebből az átlag user nem igen lát semmit. Itt tart a történet most. Hamarosan elkészül a PR, és hivatalosan is platform szintű támogatás lesz OWRT-ben az IPQ807x-re, ami nem csak az AX3600-at és AX6-ot, de egyéb routereket is jelent. De ha belenézel a hivatalos topikba ott is láthatod, hogy 1-2 szélsőséges konfigot leszámítva (amik a gyári verzióval nem is lehetségesek) stabil a technika.
-
dchard
veterán
válasz
trance89 #4617 üzenetére
"Openwrt nem mindenkinek való"
Ez így van.
"kétlem, hogy belátható időn belül eléri a gyári fw stabilitását de legfőképpen a wifi teljesítményét."
Régen elérte, és a szigniffikánsan újabb wifi FW + driver miatt régen meg is haladta azt... Ha teljesítmény alatt a 30dBm kimenő teljesítményre gondolsz, ugyanazzal a hekkelős módszerrel lehet elérni, mint ahogy kínaisítasz. Pont ugyanannyira illegális is. Gyárilag sosem fogsz olyan OWRT-t kapni, ami ezt támogatja, de ugyanúgy a BDF_ben van a trükk, mint a kínai vagy global esetében, ebből a szempontból semmi különbség nincs. Már csak azért sem, mert ehhez a Xiaomi-nak vagy az OWRT-nek nincsen köze, a QCA így tervezte a rendszert.
"a wifi-t bekapcsolva egyetlen eszközzel sem tudtam csatlakozni rá akármilyen csatornát állítottam be"
Akkor neked tényleg nem való, ilyen hibák bő egy éve nincsenek, nem is láttunk hasonló panaszt pedig elég sokan használjuk napi szinten.
Nem meggyőzni akarlak, mint ahogyan senki mást sem, de a félreinformálásnak jó lenne véget vetni.
-
dchard
veterán
válasz
trance89 #4613 üzenetére
Csak hogy tisztázzuk ezt a kérdést. Mind a kettő baromi öreg, az ipq807x 2.0-ás főverzióján alapul. És rengeteg bug van bennük. És a Xiaomi-ról tudható, hogy soha az életben nem lesz főverzió frissítés: amelyik SDK-ra felépítették a modellt, az lesz amíg van support.
Persze értem én, hogy a két szar közül a kínai a kisebbik szar, de a kínai sem kapott érdemi frissítést meglehetősen régóta, és nem is fog.
-
dchard
veterán
Ha nem találod meg a kivágott részt a dmesg kimenetében, akkor nem biztos hogy váltanod kéne OWRT-re... Amit bemásoltam az a gyári firmware logjából származik, tehát ott kell lennie. Nem beszélve arról, hogy az összes kernel logban mindig benne van az MTD lista, mert anélkül nem tudná felcsatolni a szükséges filerendszereket.
Jozsó:
Csak a "szokásos", nem kell ez neked, maradj a gyárin.
-
dchard
veterán
válasz
trance89 #4578 üzenetére
Én minden esetben a partíciós tábák összehasolítását ajánlom. Nem kerül semmibe, kettő perc alatt elvégezhető, és utána nyugodtan aludhat az ember. Annyi kiegészítés az összefoglalóhoz, hogy láttunk már olyan esetet, ahol a QSDK alapú szar után rárakott OWRT brick-ből TTL sorossal sem lehetett visszahozni az eszközt, kizárólag a NAND direkt írásával, amire nyugodtan mondhatjuk: házilag senki nem tud elvégezni.
-
dchard
veterán
Ez nekem egy sima módosított gyári kínainak tűnik, de sose használtam, így nem tudom neked megondani, hogy ebbe beletúrmányoltak-e vagy sem. SSH-n nézz bele a kernel logba (dmesg parancs), és hasonlítsd össze a partíció kiosztást ezzel:
[ 1.315356] 0x000000000000-0x000000100000 : "0:SBL1"
[ 1.322174] 0x000000100000-0x000000200000 : "0:MIBIB"
[ 1.326989] 0x000000200000-0x000000500000 : "0:QSEE"
[ 1.333487] 0x000000500000-0x000000580000 : "0:DEVCFG"
[ 1.336588] 0x000000580000-0x000000600000 : "0:RPM"
[ 1.341541] 0x000000600000-0x000000680000 : "0:CDT"
[ 1.346316] 0x000000680000-0x000000700000 : "0:APPSBLENV"
[ 1.351193] 0x000000700000-0x000000800000 : "0:APPSBL"
[ 1.357106] 0x000000800000-0x000000880000 : "0:ART"
[ 1.361767] 0x000000880000-0x000000900000 : "bdata"
[ 1.366522] 0x000000900000-0x000000980000 : "crash"
[ 1.371394] 0x000000980000-0x000000a00000 : "crash_syslog"
[ 1.376242] 0x000000a00000-0x000002dc0000 : "rootfs"
[ 1.413274] 0x000002dc0000-0x000005180000 : "rootfs_1"
[ 1.445652] 0x000005180000-0x000007040000 : "overlay"
[ 1.469243] 0x000007040000-0x0000070c0000 : "rsvd0"A neveknek és a tartományoknak pontosan egyeznie kell.
-
dchard
veterán
válasz
trance89 #4574 üzenetére
Gyorsan érdemes tisztázni, hogy bár a bdata-t nem használja az Openwrt, de kizárólag akkor telepíthető, ha a routeren a gyári partíciós tábla van. Minden más esetben tégla lesz az eredmény. Ha "kínai" alatt a gyári kínai verziót érti, akkor mehet rá az OWRT, de ha valami harmadik fél által turmányolt szart, akkor nem. Tekintve hogy hányan jártak már eddig is ezzel pórul én biztosan ellenőrizném mielőtt nekiállok.
-
dchard
veterán
válasz
lenovomen #4564 üzenetére
Sípolnia semminek nem kéne. Kondi vagy tekercs lesz a sípolás. Amit házilag tenni tudsz, hogy a tápot megméred DC és AC komponensre is ha van egy tisztességes multimétered. Rick4 kérdése egyébként arra irányult, hogy ha csak a táp van bedugva, de nincs rajta router, akkor a táp maga sípol-e? Magyarán hogy biztosan a routerből jön-e a síp és nem a tápból?
-
dchard
veterán
Az openwrt AX3600 wikije teljesen jó, de csak akkor, ha gyári szoftverről mész OWRT-re (a valódira és nem valami egyébre ami annak nevezi magát). Ha valami mókolt akármit már felraktál, akkor good luck, bár ha az eredeti BDF-edről csináltál mentést és azt visszaírod, és ezt leszámítva nem változtattál meg semmit (különösen a partíciós táblát), akkor menni fog. Ennyit tudok mondani.
-
dchard
veterán
Aztán majd jönnek az áthekkelt BDF-es, kínaisított figurák akik téglásítják a routerüket... Nem köszönöm
OWRT fórum is tele van ilyenekkel: ráraktak valami kínai szart, aztán jönnek sírni, hogy a valódi OWRT upgrade után tégla lett a technika. Jobb esetben TTL-lel vissza lehet hozni, de ahhoz is forrasztani kell... És a legjobb, hogy a Xiaomi gyári recovery-je szarja el az egészet végérvényesen, ami nem meglepő ha azt nézzük, hogy már elbaszták a partíciós táblát amiről a recovery tool nem tud...
-
dchard
veterán
Nem titok, hogy én Openwrt-vel használom mostmár bő egy éve. Nálam jól működik. Mintha valaki használná VLAN+PPPoE-vel, de ebben most így hirtelen nem vagyok biztos. Egy a léyneg: ha kipróbálod, eszedbe ne jusson valami OWRT-nek tűnő kínai szart rárakni, mert végérvényesen szétcseszi a router partíciós tábláját, és ha megpróbálod visszaállítsani, akkor tégla lesz az eredmény. Tehát gyáriról a leírás alapján a Robimarko által készített (vagy az ő forrásából saját magad által fordított) verziót kell rá feltolni. OWRT wikin minden szépen le van írva.
-
dchard
veterán
-
dchard
veterán
válasz
xabolcs #4046 üzenetére
Robi tegnap betolta a NAPI patch-eket, szóval a wifi sebesség tovább javult. Érdekes módon úgy tűnik, hogy mellékhatásként a memória fogyasztás is érzékelhetően javult. Most még megy a várakozás a 2.6-os wifi és a 11.5-ös NSS firmware-ek megjelenésére, állítólag hamarosan kiadja a QCA. Az NSS egyébként újra visszakerül 5.15 alá, persze upstream nem fog bemenni, mert gyakorlatilag lehetetlen upstreamelni. Az NSS támogatást. De legalább visszakapjuk a gyorsítást, nem mintha nagy szükség lenne rá a jelnelegi teljesítmény mellett
-
dchard
veterán
-
dchard
veterán
válasz
xabolcs #4039 üzenetére
Csak NSS-DP kell, semmi egyéb, mivel 5.15-ből kikerült az NSS accel. Egyébként valami javult a firewall4-gyel is, ami a sebességet illeti, mert SW offload mellett 5-10%-os CPU-val megy az uplink PPPoE-n 320Mbittel. Lefelé 40-50%-kal megy a PPPoE 940Mbittel. Ilyen jó értékeket korábban nem láttam. Ráadásul ez csak egy mag, a maradék 3 üres, ami a wifihez kell is. Összességében se LAN se WAN nem láttam olyan szitut, ahol CPU limitünk lenne.
-
dchard
veterán
Hagyjad, fél éve is ezt a süket dumát tolta. Jó neki a gyári, higgye csak azt, hogy az hibamentes
Az, meg, hogy szerinte a gyári "supportalt" komplett vicc. Az ellentmondás is jópofa hogy évek óta használja, mikörben egy rakás szar. Persze egy konkrétumot nem tudott még eddig mondani.
-
dchard
veterán
Összefogná? Itt valami fogalmi zavar lesz, esetleg fordítási hiba. Tekintve hogy tudtommal nincs valódi CA technológia a 802.11 szabványcsaládban (az AX-et is beleértve). Ez azt jelentené, hogy a 2.4 és 5GHz-es csatornákon egyszerre és párhuzamosan tudsz forgalmazni.
Ha tippelnem kéne, ez az "összefogás" csak annyit jelent, hogy a jelszint függvényében adaptívan vált a két frekvencia között.
-
dchard
veterán
válasz
trance89 #3848 üzenetére
Ismert limitácó gyári FW és OWRT alatt is, hogy akár routerként, akár AP-ként használod az AX3600-at vagy AX6-ot, az uplink portnak mindig a WAN portnak kell lennie. Ezt is fel lehetne venni az összefoglalóba, mert már többen belefutottak, hogy például beállították a LAN1 portot uplinknek, és nem ment a DHCP
-
dchard
veterán
válasz
trance89 #3821 üzenetére
Hogy stabil (értsd: végleges) verzió mikor lesz, azt még Robi sem tudja. Az ethernet részből még semmi sincs upstream-ben, és ha jól láttam a SoC-ból is van ami még nem teljesen upstream. De fullos HW offload valószínűleg sosem lesz, mert az NSS egy fekete lyuk. Azt hiszem az L2 gyorsítást és mondjuk a sima PPPoE/IPoE gyorsítást a PPE engine is meg tudja csinálni, és nem kell hozzá az NSS, akkor arra majd lesz esély, de egyelőre kár ezt várni. Tehát egyelőre ezzel kell beérni.
Egyébként igen: a Robi féle verzióról lehet majd sysupgrade-elni, ha egyszer lesz legalább master támogatás.
-
dchard
veterán
A globál és a "kínai" verziók is gyári szoftverek. A lényeg, hogy a partíciós tábla gyári legyen. Ha már van SSH hozzáférésed, akkor nem bonyolult: [link]
A fájlok itt vannak (lap alján az Asset fül alatt): [link]
Neked értelemszerűen a "openwrt-ipq807x-generic-xiaomi_ax3600-squashfs-nand-factory.ubi" kell.
Én Mesh-t nem próbáltam, asszem hogy WolfSSL teljes csomag kell hozzá, ezt le lehet cserélni telepítés után hogy menjen. -
dchard
veterán
Jelentős frissítésen esett át az AX6 és AX3600-hoz használható openwrt: [link]
Az összes jelenleg elérhető javítás a Wifi drivert illetően backportolásra került, ezáltal AC és AX üzemmódban is jelentősen nőtt a teljesítmény.
Ismét leírom, hogy az egyetlen valódi Openwrt verzió a fenti linken található. Bárhonnan máshonna beszerzett verzióknak semmi köze az Openwrt-hez. Ha valaki frissíteni szeretne, győzödjön meg arról, hogy a routere jelenleg a gyári szoftver verziót futtatja-e, és nem valami Openwrt-nek hazudott QSDK alapú szart. Ennek elmulasztása és a nem gyári verzióról történő frissítés téglát eredményez.
Új hozzászólás Aktív témák
Hirdetés
- Milyen autót vegyek?
- Samsung Galaxy Watch (Tizen és Wear OS) ingyenes számlapok, kupon kódok
- Milyen okostelefont vegyek?
- Jogász topic
- HiFi műszaki szemmel - sztereó hangrendszerek
- Amlogic S905, S912 processzoros készülékek
- Vezetékes FEJhallgatók
- Xbox Game Pass [2025] - Az augusztusi lista
- Korábbi vezetője szerint 40 milliárd dollár kell az Intel versenyképességéhez
- Filmvilág
- További aktív témák...
- Thermaltake Toughpower SFX Platinum 1000W
- Gigabyte B650M Aorus Elite AX ICE + 3 év garancia
- Sony DSC-HX300 digitális fényképező + 3 extra akksi + 8GB memóriakártya + Hama Star 700 állvány
- BESZÁMÍTÁS! LENOVO LOQ 15APH8 15 notebook - R7 7840HS 16GB DDR5 1TB SSD RTX 4060 6GB WIN11
- BESZÁMÍTÁS! ASUS TUF A15 FA507NV 15 notebook - R7 7735HS 32GB DDR5 512GB SSD 1TB SSD RTX 4060 6GB W
- HIBÁTLAN iPhone 13 512GB Starlight -1 ÉV GARANCIA - Kártyafüggetlen, MS3078, 100% Akkumulátor
- LG 45GS95QE - 45" Ívelt OLED / 2K WQHD / 240Hz 0.03ms / NVIDIA G-Sync / FreeSync Premium / HDMI 2.1
- AKCIÓ! ASUS H81M-PLUS H81 chipset alaplap garanciával hibátlan működéssel
- Gamer PC-Számítógép! Csere-Beszámítás! R7 2700 / RX 5500XT 8GB / 16GB DDR4 / 256SSD + 1TB HDD
- Bomba ár! Dell Latitude E7240 - i7-4GEN I 16GB I 256SSD I 12,5" HD I HDMI I Cam I W10 I Garancia!
Állásajánlatok
Cég: FOTC
Város: Budapest