- Xiaomi 15 - kicsi telefon nagy energiával
- Samsung Galaxy A54 - türelemjáték
- Keretmentesít a Galaxy S25 FE
- Motorola Edge 50 Fusion - jó fogás
- Samsung Galaxy S25 Ultra - titán keret, acélos teljesítmény
- Eltűnhet a Dinamikus Sziget
- Google Pixel topik
- Milyen okostelefont vegyek?
- Redmi Note 13 Pro 5G - nem százas, kétszázas!
- iPhone topik
-
Mobilarena
Xiaomi AX3600 WiFi 6 AIoT Router
Új hozzászólás Aktív témák
-
dchard
veterán
válasz
Doky1988
#7205
üzenetére
Nálam semmi ilyesmi nincs Openwrt-vel. Heti több 10 órát telefonálok vowifin ezen a routeren keresztül, és soha nem volt még vele gondom, pedig a vowifi meglehetősen érzékeny ha csak egy kis csomagdobás vagy jitter van már vissza is vált VoLTE-ra. Szóval ez valami egyéni probléma lehet.
-
dchard
veterán
Alapvetően a RAM a kevés benne. Nekem AX6 van ami tulajdonképpen az ax3600 512MB-os változata., és már az AX rádiók (lassan 5 évvel ezelőtt) is rohadtul ették a memóriát, valahogy nehéz elképzelnem hogy a BE-vel csökkent volna a memória igény. Akármilyen routert is vegyél, leginkább erre érdemes figyelni. És pont ez az oka annak is, hogy bár a SoC benne támogatott, kicsi az esély hogy egy dev nekiáll megcsinálni rá az eszköz szintű támogatást.
-
dchard
veterán
Az összes a topikban tárgyalt Xiaomi router Qualcomm alapú, és mind támogatott. Honnan veszed ezt a butaságot? Az IPQ 5-6000-rel szerelt termékek is heti szinten bukkannak fel a támogatási listában. A BE3600 pro-val az a gond, hogy kevés benne a RAM, a nem Pro verzióban még kevesebb.
-
dchard
veterán
A legfrisebb Openwrt (master) verziót használók figyelmét felhívnám, hogy pont 7 perce váltottak az új 6.12-es kernelre:
https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=ba923ee5aec5db1f91b54a6fd24b58ad98df0b6f
Ismerve a korábbi évek tapasztalatát, a nem "bátoraknak" azt javaslom hogy pár napig ne frissítsenek, mert ilyenkor azért lehet bőven probléma.
-
dchard
veterán
válasz
xabolcs
#7157
üzenetére
Engem aztán nem lehet azzal vádolni, hogy a Qualcomm vagy a SW stack amit kiizzadnak, a szíven csücske volna.
De azért meg kell látnunk ennek az egész szarhalmaznak az eredőjét: ez pedig az offload infrastruktúra hiánya a linux kernelben. jelenleg nincs olyan elérhető API amin keresztül szabványos módon az egyes gyártók bedrótozhatják a saját offload infrájukat a network stack-be. Ennek pedig látjuk az eredményét: mivel ugyanezt a szopást amit az Openwrt-nél átélnek a devek, megtapasztalták a QCA-s mérnökök is, ezért szinte soha nincs kernel főverzió váltás --> ezer éves bugos kerneleket tákolnak, minden gyártó a saját megoldását turmányolja.Erre írtam, hogy előbb-utóbb meg kell ezt oldani kernel oldalon, mert pusztán erőből (CPU) a beágyazott HW-ek nem fogják tudni ezt megugrani, méghozzá nagyon nem...
-
dchard
veterán
-
dchard
veterán
válasz
xabolcs
#7141
üzenetére
Mondjuk az egy nagy kérdés, hogy mi lesz a következő generációval, mert az ARM magok messze nem fejlődnek annyira, hogy tisztán SW-ből ki tudjanak nyomni 5-10gigabitet, ráadásul az NSS azért a bridge és wifi forwardingot is gyorsítja. Én teljesen értem, hogy az NSS-ből sosem lesz semmi upstream oldalon, de valamit mostmár ki kell majd találni, mert itt szétszakad a történet... És sajnos semmi ami netstack oldalon az elmúlt években történt, abból nem látszik, hogy lenne a csőben valami erre a problémára... Platform szinten nincs se DPDK, se semmi...
-
dchard
veterán
Az NSS offload működéséhez szét kell túrni a kernel network stack-jét, méghozzá jó mélyen. Ezt ép eszű kernel fejlesztő soha nem fogja beengedni a kódba. Ezt egyébként fel is fogják a QCA-as devek, mert kísérletet sem tettek erre, ebből látszik hogy tisztában vannak a szituációval
Szóval nem valószínű. -
dchard
veterán
válasz
Doky1988
#7119
üzenetére
Nem. A master az master, ahol éppen a git tart:
https://git.openwrt.org/?p=openwrt/openwrt.git;a=summary
A stable az az utolsó stabil kiadás jellemzően több hónappal a master mögött. A master naponta akár többször is frissül --> nagy a kockázat arra hogy van benne hiba, vagy nem várt működés.
-
dchard
veterán
válasz
trance89
#7117
üzenetére
Arról nem beszélve, hogy azért a master az elmúlt hetekben átélt pár érdekességet. IPsec kliens nem fordul le napok óta, ergó aki frissít az utána nem tudja telepíteni. A sokak által használt ddns-scripts nem frissül normálisan, csak ha kézzel törlöm a konfigot és újra beállítom. Ennek az eredője az hogy most váltanak GC15-re és ilyenkor csomósodnak a hibák. Most biztosan érdemes várnia annak aki master-en van.
-
dchard
veterán
válasz
Doky1988
#7115
üzenetére
PPPoE-vel 940megát mérek vanilla Openwrt-n. Tök jól kihajtja. A probléma inkább akkor van, amikor PPPoE-n kéne nagy sebességgel de wifin keresztül forgalmazni. Ilyenkor a PPPoE a NAT és a Wifi is eszi az erőforrást (a három közül a wifi a leginkább). Ebben az extrém esetben megtörténhet, hogy 600megánál kikoppan. Ha ebből a háromból bármelyiket elhagyod, például nem arra élvezkedsz hogy mennyit mér a telefonod wifin speedtest-tel, akkor már nincs is probléma.
NSS-nek sajnos van számos hátránya is a nyilvánvaló előnyén túl, ezt sokszor kiveséztük már. Tökéletes megoldások nincsenek, dönteni kell.
-
-
dchard
veterán
válasz
Doky1988
#6916
üzenetére
Minden, amit nem az openwrt.org-ról töltesz le, az nem tiszta (vanilla) Openwrt, hanem valaki által módosított Openwrt. Hogy ezek a módosítások mit takarnak, azt sok esetben nehéz ellenőrizni. Ebben a konkrét esetben van hozzá forrás, más esetekben nincs. Agustin Lorenzo megpróbálta a korábbi QSDK-ból készült backport-ok alapján megalkotni az IPQ807x platformhoz tartozó NSS támogatást, hogy működjön a SoC-ban lévő hardveres gyorsítás. Ezen a funkción többen többször dolgoztak az elmúlt években, de nem véletlenül nem került be sohasem a "tiszta" verzióba, és jelen állapotában valószínűleg soha nem is fog: túl sok ponton kell a működéséhez belenyúlni a kernel network stack-jébe, számos nem triviális hálózati funkciót rendszeresen tönkretesz, és folyamatosan borzalmas nagy terhet jelent annak aki naprakészen akarja tartani mivel szinte minden kernel frissítés megtöri a működését. A vonatkozó NSS topikban (és az előd 806x NSS topikban) bárki visszaolvashat, hogy mekkora szenvedés volt eljutni a jelenlegi többé-kevésbé stabil állapotig, de még most is minden egyes kernel frissítésnél hozzá kell nyúlni....
A nem ellenőrzött forrásból letöltött Openwrt-nek tűnő valamikben bármi lehet: jobb esetben csak nem megfelelően működnek, rossz esetben kártékony kód is lehet bennük.
-
dchard
veterán
Network --> Firewall menüpont alatt a "Software flow offloading"-ot kapcsold be (de csak azt!), majd alul alkalmaz&mentés, majd jraindítás. És mérd meg újra a sebességet.
Openwrt-n a wifi azért lassabb valamivel, mivel a SoC által megvalósított HW gyorsítás nincs implementálva a "tiszta" openwrt-ben, ennek okait már kitárgyaltuk itt korábban.
Nekem 750-800Mbit ki szokott jönni (160MHz-es csatornán) Speedtest felé, míg a routerig 1.1-1.2Gbit megy Iperf3-mon.
Az sem mindegy, melyik Openwrt verziót futtatod: a stabil kiadások eléggé le vannak maradva.
-
dchard
veterán
"Van pár Tuya okoseszközöm, OpenWrt alatt sohasem tudtam előcsalni az emlegetett wifi hibát."
És gyári FW-n előjött?
"hiába patchelt, akkor is"
A patch-elés biztosan nem vonatkozik sem a WIFI mikrokódra, sem a driverre, csak annyit jelent hogy a kínai hazatelefonálós funkciókat megpróbáltk kiszedni belőle. De a stack ugyanolyan ezeréves mindegyik gyárira épülő FW-ben.
Most megnéztem, és Október 17-én frissült a wifi mikrokód utoljára OpenWRT-n:
A gyáriban ugye 2.1 vagy talán 2.2 van. És minden főverzióban több ezer változtatás volt... Szóval el lehet képzelni, mennyivel van lemaradva a gyári verzió
-
dchard
veterán
válasz
xabolcs
#6881
üzenetére
Pedig nem router specifikus az biztos. Régóta jelen van a hiba, számos QCA FW iteráción keresztül (és az is látszik, hogy a mikrokód kakálja el magát, nem a driver). Én sem tudom reprodukálni, mert nincs Tuya okos eszközöm, azokkal jött elő stabilan (ez nem jelenti azt, hogy csak és kizárólag ezekkel lehet előidézni). A gyári AX3600 FW-ben a mikrokód ezer éves, érdemes lenne megpróbálnia Openwrt-vel pusztán a számottevóen frissebb mikrokód miatt. 2.9-ből most adtak ki talán két hete újabb verziót, és ott a 2.12 is ami "nem hivatalos". Én utóbbit használom pár hónapja sima AP módban (nincs MESH, sem több router), és még nem láttam összedőlést, sebesség is jó.
-
dchard
veterán
válasz
xabolcs
#6791
üzenetére
Csak hogy a többiek is értsék: ezeket a FW-eket nem lehet licensz nélkül terjeszteni, eddig sok hónapos csúszással a Qualcomm saját githubjáról húztuk be ezeket. Aki figyelmes azt is láthatja, hogy a QUIC repóban van mellékelve licensz, míg a 2.12-nél nincs, ez nem véletlen. A forrás emögött valójában BrainSlayer, akinek van chip code hozzáférése, de nem terjesztheti azt ő sem licensz nélkül, itt most mégis megtette. Annak tükrében meg különösen vicces ez, hogy pár hónapja még azt állították, hogy ath11k-ra a 2.9-es volt az utolsó főverzió, csak kisebb bugfixek jönnek maximum. Erre itt van nekünk ez
Ezért nincs még ez a verzió benne az aktuális Openwrt master-ben: alapvetően licenszelési okok vannak, nem műszakiak. Persze minnél többen tesztelnek és jeleznek vissza, annál jobb.
-
dchard
veterán
válasz
trance89
#6788
üzenetére
Meg lehet próbálni.
@xabolcs
Annyi probléma azért van, hogy a sokkal újabb firmware-ek nem minden esetben kompatibilisek 100%-ban az ilyen régi SDK-ra épülő verziókkal, meg a BDF_ből is hiányozhat ez-az. Ha feltölti és nem indulnak az interfészek, vagy kernel logban fúrcaság van, esetleg rögtön crash akkor lehet tudni, hogy nem nyert
Tudnád hogy került ki ez a verzió githubra... Megnevezése is elég megtévesztő "testing", szó nincs béta verzióról, a legújabb stabil QSDK-val ezt szállítja a Qualcomm.
-
dchard
veterán
Ha valakinek van kedve tesztelni, akkor itt a számottevően új "soha nem adjuk ki ath11k-ra" Wifi firmware verzió:
A Qualcomm megint füllentett, remélem nem lepődött meg senki
A wifi firmware a router /lib/firmware/IPQ8074/ mappájában van. Ha valaki tesztelésre adná a fejét, egyszerűen nevezze át a fenti mappát mondjuk "IPQ8074_old"-ra, majd hozza létre az IPQ8074 mappát és töltse bele a fenti linken lévő összes file-t, és indítsa újra a routert. Így ha gáz van, könnyű visszaállni a régi verzióra.
Nálam pár napja megy, gond nincs vele, kis javulást látok DL sebességben. ha valaki tesztelné MESH-ben, az nem volna rossz
-
dchard
veterán
Beszéltünk már erről ebben a topikban is. Ha táplálási hiba van (ami sajnos nem csak a külső kocka tápot jelentheti: a router belsejében is vannak különböző tápsínek), akkor először a legérzékenyebb részeken jelentkezik, ami a wifi. Mondjuk az érdekes, hogy azt írod: csak a 2.4-et érinti a hiba. Ha Openwrt fut a routeren, a stress vagy a stress-ng-vel meg tudod tolni a procit hogy van-e hiba, esetleg újraindul-e a router nagyobb terhelésen. Soros porton bootloader alatt alán van beépített memória teszt is. De a legegyszerűbben kivitelezhető valóban a külső táp cseréje.
-
dchard
veterán
A legfrissebb snapshot-on olyan csoda történt amit még nem láttunk: PPPoE mellett úgy is kijön a gigabit WAN <--> LAN irányban, hogy a CPU alap órajelen megy. Úgy tűnik a GRO patch-ek javítottak bő 10-15%-ot ha nem többet, különben ez nem jönne ki... Az egy szálas CPU load még mindig magas, de a javulás azért jól látható és következetes.
-
dchard
veterán
válasz
xabolcs
#6665
üzenetére
Nekem csak az eleje volt meg, de hát a vége az ismét parádés:
"Now they are (indirectly) claiming that WLAN.HK.2.9.0.1-* is for ath12k."
Ez nyilván nonszensz, hiszen lassan fél éve a 2.9.0.1-*-es FW-rel megy ki az összes Openwrt image ath11k eszközökre, ami egy elég széles és sokak által használt pool...
Az már csak hab a tortán, hogy ezek után azt állítják publikusan, hogy az ath11k-ra nincs tovább maintenance, miközben belülről látszik, hogy van sokkal frissebb verzió a 2.9.0.1es vonalon is, amit b@sznak publikálni (nagyjából ezer commit a difi a jelenlegi 1977-eshez képest...). És mindezt úgy, hogy folyamatosan jönnek ki új eszközök ath11k HW-rel úgy, hogy nincs maintenance sem? Össze-vissza hazudoznak...
-
dchard
veterán
Hogy bővítsem azt amit xabolcs írt. Az Openwrt olyan mint a kernel: nem lehet akármilyen trágyadomb kódbázist belerkani, mert a fejlsztők kidobják a fenébe. Ellenben a cég a saját SDK-jába (a gyári FW forrásaként szolgáló fejlesztői környezet) olyan szart tákol bele, amilyet akar. És itt tetten is érhető a nagy különbség "linux" és linux között: a gyári FW hiába linux alapú, olyan értelemben nem linux, hogy a gyártó beletákolt a kernelbe, amit senki nem tudott ellenőrizni. A probléma pont ez: ahhoz hogy a HW offload működjön, olyan mélyen belenyúlkáltak - sok esetben minden fejlesztési irányelevet félredobva - a QCA "fejlesztői", amit soha az életben nem fognak ilyen formában se az OWRT-be, és ami ebben az esetben a nagyobb kihívás: a kernelbe befogadni.
Jogosan teheted fel a kérdést: hogy van az, hogy a HW offload MediaTek targeten meg jól működik. Nos ez azért lehet, mert a MediaTek ún. PPE engine-je viszonylag sok feladatot saját maga kezel, és sokkal kisebb a footprint, amit a kernellel interfészelnie kell. Sajnos a QCA más utat válaszott, persze az is igaz, hogy a QCA megodlása a komplexitása mellett sokkal kiterjedtebb: tud(na) offload-olni IPsec-et, egozitkus VPN és egyéb tunneling megoldásokat is.
Azt mindenesetre nem érdemes várni, hogy vanilla openwrt-ben valaha is lesz HW offload.
-
dchard
veterán
válasz
Doky1988
#6654
üzenetére
"Még mindig azt mondom hogy a gyári firmware sokkal stabilabb sebességileg."
A 940/320-nál többet mérsz dróton gyárival?
![;]](//cdn.rios.hu/dl/s/v1.gif)
De akkor még egyszer: a gyári FW HW offload-dal tud többet, ami - ahogyan korábban leírtam - erőteljesen tud hiányozni, főleg PPPoE WAN <--> Wifi irányokban. Ha például a WAN nem PPPoE hanem sima IP, már sokkal jobb a helyzet, mivel a PPPoE egymagos CPU zabálását ugye el lehet felejteni, a többi data path pedig több szálú, és az SW offload is jobban működik. Ezt kár lenne tagadni.
-
dchard
veterán
válasz
Doky1988
#6647
üzenetére
Giten látom:
30 hours ago Felix Fietkau netifd: add flow steering mode to the packet steering... commit | commitdiff | tree | snapshot
30 hours ago Felix Fietkau netifd: add a packet steering mode matching the old... commit | commitdiff | tree | snapshot
30 hours ago Felix Fietkau kernel: improve GRO performance commit | commitdiff | tree | snapshot
30 hours ago Felix Fietkau kernel: backport flow offload pppoe fix commit | commitdiff | tree | snapshotMeg ki is próbáltam
Egyébként nekem sebességileg, stabilitásilag stabilabb a gyári kínai szoftver valamiért..
Ízlés dolga. Én szeretem ha tudom hogy mi fut a routeremen. Pár megabitért (meg a teljes app és networking ökoszisztémáért) biztosan nem adnám fel. Nyilván a HW offload (különösen wifi <--> wan irányban) érezhetően hiányzik, de ezzel nem nagyon lehet mit csinálni: ezt a Qualcomm barmolta el... Szerencsére SW offload mellett elég erős a router hogy a gigabitet kinyomja dróton. Wireguard mostmár használja a kernel UDP tunnel offload engine-jét, ha az ember jól választ ciphert akkor a SoC azt is ki tudja nyomni HW-ből. Én elégedett vagyok.
-
dchard
veterán
válasz
gyulank
#6635
üzenetére
Az akkumulátoros üzemidő miatt nincs így. A mobilhálózatoknál a probléma hasonló, annyi különbséggel hogy ott a bázisállomás oldalán lévő HW sokkal érzékenyebb mint ami egy Wifi AP-be valaha is be tud épülni, és a telefon is nagyobb teljesítménnyel tud adni, képes a frekvencia szelektív ütemezésre, képes összehúzni a kimenő teljesítményt 1-2 RB-ra "koncentrálni", így kis sebesség mellett tudja javítani az UL lefedettséget, pontosan tudja szabályozni mérés alapján a kimenő teljesítményt (zárt hurkú teljesítmény szabályozás). Ezeket a wifi mind nem tudja. Ráadásul a sávszélesség növekedésével ugyanazt a kimenő teljesítményt egyre szélesebb sávban kell elosztani, így a PSD csökken. Nem mindegy, hogy az a 100mW 40, 80 vagy 160MHz-en oszlik el.
-
dchard
veterán
válasz
bzolika10
#6633
üzenetére
Az állítás önmagában igaz, de. Ha egyrészt ezt úgy éred el, hogy másokat a környezetedben elnyomsz (a nagyobb teljesítménnyel), az egy pofátlan csalás akárhogy is nézzük. És az 1 wattozással pontosan ez a helyzet. Ha pedig mindenki csinálná, akkor ugyanott vagyunk: a nagyobb teljesítményyel megnöveltük a zajküszöböt. Másrészt meg a már számtalanszor tárgyalt uplink-downlink arány miatt hiába tolod ki mondjuk 3-6dB-vel a downlink lefedettséget, az uplinked marad ott ahol van. A legtöbb mobil eszköz (laptop, telefon, tablet) még 100mW-tal sem tud adni, csupán 32mW-tal. Ergó amikor a legális 100mW-on megy az AP, már akkor sincs párban az előre és a vissza irány (sokan azt képzelik, hogy minden eszköz tud 100mW-tal adni, ez nincs így), ergó már így is a praktikus lefedettség határa nem a 100mW lesz AP oldalon, hanem a 32mW lesz a kliens oldalon, amit nem tudsz meghekkelni.
-
dchard
veterán
válasz
gyulank
#6628
üzenetére
Nem, a kliensek semhol sem 1 wattosak, és a vevők sem érzékenyebbek. AP <--> kliens relációban sehol nincs értelme az 1 wattnak, de például AP <--> AP relációban már lehet értelme MESH-nél. Persze olyan országban, ahol ez legális. Azért azt tegyük hozzá, hogy a topik témáját adó AX3600-nál az 1 watt EIRP úgy jön ki, hogy a 4 darab 5GHz-es antenna ágon egyenként csak 23dBm jön ki (250mW), és mivel ebből négy darab van, így jön ki a szumma 1watt tx diversity (vagy beamforming) mellett.
-
-
dchard
veterán
válasz
Doky1988
#6599
üzenetére
Ki tudja ki és mit módosított az eredeti kódbázison. Nem mondom hogy sokat keresgéltem, de forrást nem találtam. Ezt így Openwrt-nek nevezni minimum költői túlzás. Valakinek a házi forkja főleg source tree nélkül nem Openwrt, csak egy házi fork. Ahogy látszik, még a vanilla verzióba is be-becsúsznak hibák...
-
dchard
veterán
válasz
xabolcs
#6580
üzenetére
A wifi HW gyorsításban mennyire vagy biztos?
LAN-ról wifire másolás közben kéne nézni CPU-t. Pár hónapja próbáltam, akkor még a wifi offload nem ment, a LAN bridge offload és a PPPoE viszont ment.Robi pár napja állt át a 6.6-os kernelre. Várható hogy snapshot-on lesznek problémák.
-
dchard
veterán
Na ez jó hír.
Érdekes egyébként, hogy a wifi mikrokódot a qualcomm milyen szinten késve frissíti. Pár napja rakták ki az 1977-es verziót ami 2023-10-12-ai (ez már benne van az Openwrt-ben), miközben a belsős rendszerükben már 2509-nél járnak.... Bár a gyári romokhoz képest ez is hiperűr sebesség
-
dchard
veterán
válasz
Vigyorka
#6575
üzenetére
Ha úgy sysupgrade-elsz, hogy beállítod a beállítások megtartását (kis pipa), akkor nem kell visszaállítan mentésből semmit. Csupán a sysupgrade után az esetlegesen hiányzó extra csomagokat feltenni.
Nagyobb frissítéseknél különösen nem javasolt a korábbi mentések visszaállítása, mivel az esetlegesen változó paramétereket a sysupgrade lefrissíti, amit aztán jól visszaírsz a régire amikor visszatöltöd a beállításokat.
Mentést visszaállítani csak akkor érdemes, ha ugyanaz a verzió van amiről a mentés készült. -
dchard
veterán
Érzkezett új wifi FW, akinek volt korábban TUYA okos eszközökkel problémája vagy MESH-t használ, érdemes lehet kipróbáni. Nálam két napja fut AX6-on hiba nélkül.
Ha valaki tart az attended sysupgrade-től (ami a korábbi problémák után érhető), akkor a másik megoldás az, hogy tölt az ember snapshot-ot (ott legalább látszik hogy mikori), azt szokásos módszerrel a beállítások megtartásával felfrissíti, majd újriandulás után SSH-n telepíti a luci-t ("opkg update" és "opkg install luci" parancsok), majd a webes felületen visszarakja az esetlegesen hiányzó extra csomagokat. Így nem kell semmit újra beállítani, csak a hiányzó csomagokat kell egyszerűen telepíteni és a végén újraindítani.
-
dchard
veterán
válasz
Doky1988
#6562
üzenetére
Hacsak nem NZ-ben élsz, magyaron is kéne használni. A DFS nagyon leegyszerűsítve radar érzékelést jelent. Ennek egyértelmű jele van a logban. Ahogyan korábban már számtalanszor leírtuk: magas csatornán is megy, 10 perc után, addig tart a DFS radar érzékelés (minden EU országban egyébként).
-
dchard
veterán
válasz
xabolcs
#6540
üzenetére
Na az vicces lenne, ha az AX6 tudna 1000mW-ot, tekintve hogy nincs rajta olyan erősítő, ami ki tudna ennyit izzadni. 250mW-ot tud az AX6 max. És a kimenő teljesítmény elsősorban attól függ, hogy milyen FEM van az adott modellen. Utána pedig jön a regulatory data (BDF).
-
dchard
veterán
Gyorsan beírom ide dokumentarista jelleggel, hátha máson is segít, meg én sem felejtem így el.
Ha van TTL soros a routeren és brick lett (Openwrt):
1. U-boot-ba belép.
2. A "tftpboot" paranccsal be kell tölteni a "......initramfs-uImage.itb" végű openwrt initramfs binárist.
3. A "bootm" paranccsal indítható a kettes pontban betöltött image.
4. Majd a már futó Openwrt alól lehet sysupgrade-del felrakni a "......squashfs-sysupgrade.bin" végű fájlt.Ha a korábbi Openwrt installációnk amúgy jó volt, csak az utolsó upgrade után szaródott el valami, így vissza lehet frissíteni a router olyan módon, hogy nem kell a gyári FW-re visszaállni közbülső lépésként, megmaradnak a beállítások is. Nyilván ilyenkor a sysupgrade-et a beállítások megtartásával kell futtatni.
Sajnos TTL soros nélkül ezt nem lehet elvégezni, a reset gombos recovery mindenképpen a gyári (aláírt) FW-t hajlandó csak beírni a flash-be.
-
dchard
veterán
válasz
Vigyorka
#6489
üzenetére
TFTP recovery-vel csak a gyári image-et lehet visszarakni, az Openwrt-t nem. Én is beszívtam, szüttyögni kellett egy darabig mire visszamászott. Az az irritáló, hogy a U-boot nem eszik meg semmit még boot-ra sem, kizárólag a gyári image-et. Nem lehet megcsinálni azt, hogy egy initrd image-et betölt az ember és onnan visszaflash-eli.
Attended sysupgrade hiba volt amit elég hamar javítottak, de a build botok lassan dolgoznak, így simán bele lehetett futni ebbe hosszabb ideig is.
-
dchard
veterán
válasz
trance89
#6469
üzenetére
Broadcom témában két szakdolgozatot is írtam. Igaz xDSL fronton, de közelről láthattam, hogyan csesznek ki tudatosan az open source közösséggel. Szóval nem a szívem csücske, azt elhiheted
Éppen ezért nagy ívben elkerülöm, nálam is QCA és Intel rádiók vannak, azokkal nincs gond. Bár az Intel AX211-et a Xiaomi 11 Lite 5G NE-m lekörözi Iperf3 alatt, ami azért nem teljesen nyugtat meg.Ha valakit érdekel, van egy gyanús patch tegnapról a kernel listán, amire felhívtam Robi figyelmét, amitől elvileg megjavul a nem működő TX beamforming. Ez komoly javulással kecsegtet. Hamarosan lesz backport az érintett és az összes többi kimaradt patch kapcsán is, érdemes figyelgetni az Openwrt master git-et
Nyilván nagy mennyiségű driver kód beemelésekor fokozottan megtörténhet a javulás mellett az is, hogy valmai szar lesz, ezért aki nem akar tesztelgetni az ne frissítsen rögtön. -
dchard
veterán
-
-
dchard
veterán
-
dchard
veterán
A beszélgetés nem úgy működik, hogy te állítasz valamit, mindenki más pedig legyen kedves ezt elfogadni. Stilizálás helyett inkább maradjunk a műszaki résznél.
A DFS alapvetően radar érzékelésre van, és nem csinál mást, mint csatornát vált ha radart érézékel. Nincs köze a kimenő teljesítményhez. Azt csak halkan jegyzem meg, hogy a DFS sajnos nem működik megfelelően még a legújabb QCA féle mikrokóddal sem: német kolléga fedezte fel hogy az eszköze működő átlapolt sávban lévő meteorológiai radar mellett sem jelzett. Ezek után az ETSI által kiadott radar mintákkal teszteltünk, és valóban nem érzékelt radart. Ezt a QCA felé jeleztük, vizsgálják... A legutóbbi LNA problémát másfél év után egyszer csak megcsinálták minden előjel nélkül...
Power control-ból két féle van: egyrészt path loss alapján próbálja visszahúzni a közeli STA-k szintjét, hogy az AP vevőjére közel azonos teljesítmény jusson, ellenkező esetben a közeli STA-k szaturálnák a vevőt. Ez open loop, tehát simán path loss-ból számol az RF környezethez képest jól vagy kevésbé jól (nicns "beszélgetés"). Nem véletlen, hogy a 4G/5G hálózatok a különböző kontrol és adat csatornákon többnyire closed loop power controlt használnak, és csak a RACH-nál van open loop (amit máshogy nem lehetne megoldani). Az open loop power control az AP-t veszi referenciának, tehát ha te feltolod kézzel a power-t, akkor azzal a power control sem tud mit csinálni. És ez még mindig csak STA power control, az AP ettől nem fog kevésbé sugározni. A másik 802.11ax által bevezetett megoldás az, hogy az AP vevőjénél mért SINR alapján tudja azt mondain az AP az STA-nak, hogy adjál kevesebbel, mert elég jó a SINR így is. Ugye ez is csak STA power control, ráadásul ez nem kötelező eleme a szabványnak.
A band steering egyrészt nem kötelező része a szabványnak, másrészt megint csak nem kommunikál jelszintekről és nem is állít jelszintet.
És ha ez nem lenne elég, mindezek a fícsörök akkor működnek megfelelően, ha a kedves user nem hekkeli mondjuk a BDF-et és a benne lévő regulatory adatokat, mert a TPC például ezekből is dolgozik (esetünkben csak dolgozna).
"és a többi ehhez kapcsolódó kifejezés... "
A topik színvonalának fenntartása érdekében azt javaslom, hogy ha vita van, akkor fejtsd ki kellő mélységben az álláspontodat, 3-4 kifejezés idecitálása nem lesz ehhez elég.
A kérdező kérdésre a válasz: az egészségügyi hatásait nem ismerjük, a fölöslegesen nagy jelszintek használata viszont egyrészt illegális, másrészt rontja az környezete RF teljesítményét, és sok esetben még csak nem is eredményez gyorsabb kapcsolatot vagy nagyobb lefedettséget.
-
dchard
veterán
Változtatgatod az állításaidat, amiknek ráadásul a kimenő teljesítmény kérdéséhez semmi közük. De igen: a router válthat csatornát mindkét sávon, eltérő mechanizmussal és eltérő okokból, kimenő teljesítményt viszont nem vált, és a csatorna váltást sem "beszéli meg" senkivel.
-
dchard
veterán
"Az amúgyis csak azelérhető max, mivel a készülék a kliensekkel beszélget a csatornákról, jelszintekről, ez egy elméleti max."
Nem beszélgetnek ilyesmiről, és a max teljesítmény bizony kijön belőle. Az, hogy ha elveszíti az 5GHz-es kapcsolatot utána lemegy 2.4-re az megint nem "beszélgetés" kérdése, ez utóbbin a 802.11r mint nem kötelező kiegészítés tud segíteni, bár ez is csak reselection és nem handover, és a teljesítmény kérdéshez nem sok köze van.
-
dchard
veterán
A 802.11ax-ben csak STA power control van, az is olyan amilyen (open loop). AP power control pedig nincs benne, úgyhogy az 1000mW forgalom függvényében ki fog menni belőle, a beacon meg ugye folyamatosan sugározva van 100ms-onként forgalom mentes időszakban is. Ne képzeljünk bele olyan technológiát az 50 eurós wifi AP-ba, ami az 50ezer eurós 4G/5G bázisállomsokra jellemző
-
dchard
veterán
-
dchard
veterán
-
dchard
veterán
Alkalmas a wifi7-re, a kérdés csak az volt, hogy milyen wifi7-re alkalmas, mert az nem mindegy. 6GHz-et nem tud, 320MHz-et sem tud, ugyanúgy 4T4R 5GHz-en mint az AX3600, és a kolléga úr link sebességéből látszik is, hogy ezek mellett a sebesség növekedés elhanyagolható (2400 vs. 2800Mbit).
Ha valaki az AX3600 helyett veszi mert azt már nem árulják, annak oké. De ha valaki kifejezetten a wifi7 miatt venné az csalódni fog.
-
dchard
veterán
válasz
Doky1988
#6316
üzenetére
A qualcommax/ipq807x később lett bevezetve, ezért van még belőle "csak" snapshot. Én biztosan a qualcommax/ipq807x-ot hazsnálnám, rengeteg javítás van már benne ami a stabilban nincs. A platform még mindig sok javítást kap, és az Openwrt release cycle miatt ezek lassan érkeznek meg a stabil kiadásokba.
-
#6289
dchard
veterán
Black&White
#6288
dchard
veterán
válasz
Black&White
#6288
üzenetére
Nagyon köszönöm! Ezek alapján a 6GHz-et el lehet felejteni, a FEM nem tud ilyet kinyomni magából, és wifi7- upgrade után sem fog tudni 160MHz-nél többet, nekem ez így felejtős. A 320MHz nem is annyira érdekelt, de a 6GHz támogatás hiányát már nem tudom lenyelni.
De tekintve hogy az AX3600-at már nem nagyon lehet kapni, aki azt akart venni, annak ez jó lesz helyette. Hogy mikor lesz rá Openwrt azt nehéz megmondani, Robinál egyelőre nincs hasonló chipsettel szerelt router.
-
#6287
dchard
veterán
Black&White
#6282
dchard
veterán
válasz
Black&White
#6282
üzenetére
Nem tudom hogy végül is csak Te vettél ebből routerből, vagy Rick4 is rendelt belőle.
Ha annyit megtennétek, hogy engedtek belenézni a routerba SSH-n (gyári SW), aztért hálás lennék. Azt már meg sem merem említeni, hogy ha készülnének képek a belsejéről (különösen a rádió és FEM IC-kről) az megint sokat segítene. A jelenlegi routerekkel ellentétben a Xiaomi 7000-ről nem találtam egy képet sem meglepő módon...
-
#6283
dchard
veterán
Black&White
#6282
dchard
veterán
válasz
Black&White
#6282
üzenetére
Van hozzá hivatalos kalkulátor? Megáll az eszem, hogy má forrasztani sem kell. Mivé lesz a világ
Ez amúgy egy szimpatikus húzás. Már csak az a kérdés, hogy vajon a digitális aláírás ellenőrzését a BL-ben ki lehet.e ütni. Nem ártana megtudni mielőtt elköltök ennyi pénzt. Az igazság az, hogy semmi szükségem rá, inkább csak mozgatja a fantáziámat. -
#6280
dchard
veterán
Black&White
#6279
dchard
veterán
válasz
Black&White
#6279
üzenetére
Köszönöm a a részleteket a nép nevében!
Ez a 11.11-es buli mit takar és hogyan lehet csatlakozni? Vagy csak nézni kell hogy esik-e az ára?
A másik inkább ide vágó kérdés: azt jól láttam a linkelt videóban, hogy a csávónak sikerült SSH-n belépnie a gyári firmware-en? Linkelt videódban itt: [link]
-
#6278
dchard
veterán
Black&White
#6269
dchard
veterán
válasz
Black&White
#6269
üzenetére
Erre még rájön az ÁFA+import eljárás? 66 ezerért van Bangood-on ÁFA-val mindennel. ALin 58.000 az alja, azt írják ÁFA és szállítás benne van.
Az lesz még a kérdés a wifi7 mellett, hogy legalább wifi6e-t tud?
-
#6268
dchard
veterán
Black&White
#6266
dchard
veterán
válasz
Black&White
#6266
üzenetére
Mennyi volt? IPQ proci van benne, szóval akár még jöhet is rá Openwrt, kérdés hogy meg lehet-e hekkelni, nincs-e digitális aláírás kikényszerítve stb...
-
dchard
veterán
válasz
xabolcs
#6252
üzenetére
Azért annyit pontosítanék, hogy bár az igaz hogy működik (mivel az Openwrt kizárólag a szabványos MESH protokolt támogatja), de hogy aztán mennyire működik optimálisan a chipset vendorok között (QCa vs. Broadcom vs. MediaTek), na az már más kérdés, mivel az nagyban múlik a zárt forrású mikrokódon ami az összes modern wifi chipsetben létezik, és arra nulla ráhatása van a fejlesztőknek sajnos. Bár tény, hogy a megfelelő működésre még akkor is az Openwrt-vel van a legjobb esély, ha több különböző vendor rádióját keverjük egy MESH hálózatban
-
#6230
dchard
veterán
DougButabi
#6229
dchard
veterán
válasz
DougButabi
#6229
üzenetére
Az a probléma, hoyg a routered LAN lába ugyanabban a subnet-ben van, mint amit a WAN lábon a DHCP kliens összeszed, így a NAT nem működik. Nem az Openwrt a szar
Az Openwrt router LAN ipj-t vltoztasd meg 192.168.1.1-ről 192.168.2.1-re, utána mentés és alkalmazás, és menni fog.
-
#6228
dchard
veterán
DougButabi
#6227
dchard
veterán
válasz
DougButabi
#6227
üzenetére
Lássuk a konfigurációt is:
"cat /etc/config/network" parancs kimenetét ugyanígy töltsd fel a pastebin-re.
-
#6226
dchard
veterán
DougButabi
#6225
dchard
veterán
válasz
DougButabi
#6225
üzenetére
pastebin.com
-
#6224
dchard
veterán
DougButabi
#6223
dchard
veterán
válasz
DougButabi
#6223
üzenetére
A teljes logot (syslog --> kernel log) legyél kedves bemásolni.
-
dchard
veterán
Ajánlani továbbra sem ajánlom, én is csak annyi időre raktam fel, hogy gyorsan a bitthief féle NSS modokat leteszteljem. Ha beválik, forgatok a bitthief repo-ból saját verziót, eszemben nincs ezt megtartani. De egyelőre nem látszik, hogy megéri vanilla Openwrt-ről váltani, hacsak nem valaki gigabites telekom optikán ül és mindkét irányt nagyon erősen használja foylamatosan. Amiben reménykedtem hogy a wifi picit javul, de úgy néz ki az sem CPU limites.
-
dchard
veterán
válasz
xabolcs
#6214
üzenetére
Én most a poén kedvéért kipróbálom a Dimfish féle verziót NSS-sel, kíváncsi vagyok hoz-e valamit a konyhára... Egyelőre annyi látszik, hogy komoly forgalom mellett a PPPoE terhelésen meg a bridge-en sokat segít, de gyorsabb nem lett tőle semmi. Wifi-n nagy sebességnél nyertem 10-15%-ot. Egyelőre nem érzem, hogy megéri feladni a vanilla OWRT-t ezért.
-
dchard
veterán
válasz
wwenigma
#6209
üzenetére
Ráadásul owrt alatt a tcp timeout csak 120 sec...
Mieőtt váltottam volna Rtorrent-re, nekem is volt hasonló problémám Transmission-nel, mióta Rtorrent-en vagyok azóta kizárólag akkor van "túl sok" nyitott socket, ha valamelyik torrentet nem teljesen töltöm le, ilyenkor ugyanis a kliens nem tekinti befejezettnek a letöltést és sok peer-hez csatlakozva marad, hiába nincs már semmi forgalom (de csak ebben a speciális esetben).
Délután készült új snapshot, Attended sysupgrade még nem látja, de kézzel már tölthető.
-
dchard
veterán
válasz
wwenigma
#6207
üzenetére
Valami pedig csinálja (vagy nem zárja le) azokat a kapcsolatokat.
Lehet a torrent kliens sok kapcsolatot nyit és nem zár le, ezért nem lépi túl a limtet amit beállítottál, de közben nem zárja le a kapcsolatokat, linuxon pedig a tcp timeout meglehetősen hosszú, 7200 másodperc általában.
-
dchard
veterán
válasz
wwenigma
#6204
üzenetére
Azok fesz értékek, nem jelölnek külön CPU órajelet. Ráadásul mivel ezeken a CPU-kon sem a binning, sem a turbo nincs engedélyezve, ez meg is magyarázza hogy miért két féle órajel van, amit már eddig is láttunk.
A torrentes gépen próbáld a
ss -s-t és másold be a kimenetet. -
dchard
veterán
válasz
wwenigma
#6202
üzenetére
A router biztosan nem csinál neked nem létező kapcsolatokat, azt valamilyen szolgáltatás (a torrent) kezdeményezi és/vagy nem zárja le. Amin fut a qbittoreent linuxon nézd meg hogy hány kapcsolat van (conntrack tábla) és ki fog derülni, hogy ezt bizony a torrent kliens csinálja...
"Rendszer logban 4 szerepel, onnan vettem"
Hol látsz a rendszer logban 4 állapotot?
-
dchard
veterán
válasz
wwenigma
#6200
üzenetére
A kapcsolatokat alapvetően a torrent kliens kezeli, ezzel a routerben nem tudsz mit kezdeni, hacsak azt nem, hogy a TCp dile session timeout-ot lejjebb veszed, persze a rossz torrent kliensre nem pont ez a jó megoldás. Kliensben per torrent és global szál limtet is be lehet állítani, érdemes vele jtszani. Nálam 2-300 kapcsolat van.
De azért meg kell látnunk ennek az egész szarhalmaznak az eredőjét: ez pedig az offload infrastruktúra hiánya a linux kernelben. jelenleg nincs olyan elérhető API amin keresztül szabványos módon az egyes gyártók bedrótozhatják a saját offload infrájukat a network stack-be. Ennek pedig látjuk az eredményét: mivel ugyanezt a szopást amit az Openwrt-nél átélnek a devek, megtapasztalták a QCA-s mérnökök is, ezért szinte soha nincs kernel főverzió váltás --> ezer éves bugos kerneleket tákolnak, minden gyártó a saját megoldását turmányolja.
Valójában ez is azt igazolja, hogy a rádiós kapcsolat sosem lesz olyan megízható mint a drótos, ami igaz is, ennél fogva nagyon is logikus.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
Hirdetés
- Sony MILC fényképezőgépcsalád
- S.T.A.L.K.E.R. 2: Heart of Chornobyl
- Motorolaj, hajtóműolaj, hűtőfolyadék, adalékok és szűrők topikja
- sziku69: Fűzzük össze a szavakat :)
- Path of Exile (ARPG)
- BestBuy topik
- Kerékpárosok, bringások ide!
- Nintendo Switch 2
- Xiaomi 15 - kicsi telefon nagy energiával
- Linux kezdőknek
- További aktív témák...
- Ryzen 9 7900 /// Bontatlan // Üzletből, számlával és Garanciával!
- Ryzen 7 5700X3D /// Bontatlan // Üzletből, számlával és Garanciával!
- Ryzen 7 8700G /// Bontatlan // Üzletből, számlával és Garanciával!
- Ryzen 5 9600X /// Bontatlan // Üzletből, számlával és Garanciával!
- IdeaPad 3 15ACH6 15.6" FHD IPS Ryzen 5 5500H RTX 2050 16GB 512GB NVMe magyar vbill gar
- Bomba ár! Lenovo ThinkBook 14s Yoga - i5-1135G7 I 16GB I 256SSD I 14" FHD Touch I Cam I W11 I Gari
- 4 év gari - magyar bill. - Lenovo ThinkPad Z13 G1 - AMD Ryzen R7 Pro 6850U, 13.3" 2.8K OGS érintő
- BESZÁMÍTÁS! MSI Crosshair 17 HX Gamer notebook - i7 14700HX 64GB RAM 1TB SSD RTX 4060 8GB WIN11
- Menő retró konfig: Q9550, Gigabyte P43, 4GB RAM, ASUS GT730,
- ÁRGARANCIA!Épített KomPhone Ryzen 9 5900X 16/32/64GB RAM RTX 5070 12GB GAMER PC termékbeszámítással
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: CAMERA-PRO Hungary Kft
Város: Budapest