- Szívós, szép és kitartó az új OnePlus óra
- Samsung Galaxy S24 Ultra - ha működik, ne változtass!
- Samsung Galaxy S23 Ultra - non plus ultra
- Samsung Galaxy Watch4 és Watch4 Classic - próbawearzió
- Amazfit Active 2 NFC - jó kör
- Samsung Galaxy A56 - megbízható középszerűség
- Magyarított Android alkalmazások
- Telekom mobilszolgáltatások
- Samsung Galaxy Watch (Tizen és Wear OS) ingyenes számlapok, kupon kódok
- Samsung Galaxy S25 - végre van kicsi!
-
Mobilarena
Xiaomi AX3600 WiFi 6 AIoT Router
Új hozzászólás Aktív témák
-
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...
-
-
Rick4
félisten
válasz
xabolcs
#6925
üzenetére
Azt írtam, "akkor is" plusz még az is ott van, kinek írtam, tehát nem egy harmadik hozzászóló esetére reagáltam, hanem mano42 hozzászólására, mivel a két eset nem csak hogy a hozzászólók, hanem a probléma esetén is más jellegű, talán Érthető elsőre, hogy nem az első, hanem a második esethez írtam. Hogy mire fel akarod összemosni az elsaő esettel, ahol a router rebootos sztori van, azt nem tudom...
-
#6901
mesmat1993
újonc
xabolcs
#6900
mesmat1993
újonc
válasz
xabolcs
#6900
üzenetére
Közben szerintem rájöttem, hogy nálam mi volt a gond. Be volt kapcsolva a telefonon az alacsony töltöttségű mód és ha ilyen módban van a csatlakozáskor, akkor router restartol. Ha kikapcsoltam az akkukímélő módot és úgy csatlakoztam fel vagy ha már a wifi-n vagyok és úgy kapcsoltam be, akkor nem indult újra.
-
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
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
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
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).
-
Norbi.Sz
senior tag
válasz
xabolcs
#6529
üzenetére
Egy régebbi robimarko féle build van most rajta.
De van még egy AX3600-os router a hálózatban (a két AX3600 meshben van).Egyébként van valami csomag az Openwrt-hez, amivel azt tudom figyelni, hogy melyik eszköz mikor volt felcsatlakozva, mikor csatlakozott le a routerről?
-
Norbi.Sz
senior tag
válasz
xabolcs
#6526
üzenetére
Sajnos már nem emlékszem, hogy honnan töltöttem le, kb. fél éve ez van a routeren.
Most szeretném megnézni egy újabbal, mert olyasmit csinál, hogy az Áttekintés-nél nem mutatja néha bizonyos eszközök jelenlétét. Ez elég fontos lenne Home Assistant integráció miatt... Ha érdekel, meg tudom majd nézni otthon, hogy meg van-e még a file, és fel tudom dobni valahová. -
Doky1988
senior tag
válasz
xabolcs
#6498
üzenetére
Meglett közben
US-re kell állítani a WIFI Country -t, és 161-es csatornán remekül muzsikál! Köszi, meginn tanultam valamit
DFS support almost triples the available channels in the 5 GHz ISM band. This allows for higher densities of APs, more Wi-Fi devices, and faster data transfer rates. For the U.S., there are nine non-DFS channels: 36, 40, 44, 48, 149, 153, 157, 161, and 165. There are 16 DFS channels: 52, 56, 60, 64, 100, 104, 108, 112, 116, 120, 124, 128, 132, 136, 140, and 144.
-
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
-
wwenigma
Jómunkásember
válasz
xabolcs
#6214
üzenetére
ath11k visszajelzős oldalon is a 24111-re panaszkodtak utoljara hogy memleak van.
OpenWrt SNAPSHOT r24154-6f31941d38 / LuCI Master git-23.266.27574-7744ad0 nagy nehezen csak lejött, feltettem, eddig jobban néz ki memóriaügyileg pedig a nagygépet kábel mellett ráküldtem egy AX200-as kártyával had szokja. 
Kicsit hagyom pihengessen aztán port továbbítást ráküldöm....
-
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
xabolcs
#6183
üzenetére
Ez volt az, Tuya. És nézzenek oda: crash-el is neki.
wwenigma:
Ismert probléma ezekkel a Tuya eszközökkel, a xabolcs által linkelt alternatív SW talán segíthet, érdemes lehet megpróbálni. Mivel egyetlen más eszközzel sem láttunk hasonlót, így azt mondanám a probléma a Tuya oldalán van (bár nem egészen tartom normálisnak, hogy egy kliens olyasmit tudjon csinálni, amitől az AP bekakál). Hogy érthetőbb legyen: ilyenkor a wifi firmware omlik össze, ez nem driver probléma így megjavítani sem tudjuk, hátha a QCA egyszer csak rájön a megoldásra...
-
llll
senior tag
válasz
xabolcs
#5994
üzenetére
Ez volt az:
[kép]
Közben írtam a Xiaominak (és másnap válaszoltak is). Sajnos ők is azt mondták, hogy a routeren nem lehet régiót váltani, a xiaomi home appban kell kínaira váltani.
Úgyhogy ezzel teszek majd még 1 próbát, miután lenyuxom.
Másra úgysem tervezem használni az appot. -
Tim82
félisten
válasz
xabolcs
#5971
üzenetére
Köszönöm, ez hasznos volt.
Másoknak egy kicsit rövidebben összefoglalva (mert esetleg riasztóan pilótavizsgásnak tűnhet a történet, pedig nem az):
1.) SSH-val belépsz a routerbe;
2.) kiadod a következő parancsot:
vi /etc/openwrt_release(vagyis mivel a vi nevű "szövegszerkesztő" elérhető, azzal megnyitod szerkesztésre az openwrt_release nevű fájlt -> átírod a DISTRIB_TARGET értéket: ipq807x/generic értékről -> qualcommax/ipq807x értékre;3.) a vi esetében úgy mentesz és lépsz ki, hogy nyomsz egy Esc-et, majd beírod, hogy
:wqés Enter (ez a "write" és a "quit" egyszerre kiadva, tehát mentés-kilépés);3/A.) (opcionális) Szükséges lehet, de pl. nálam nem kellett az
aucparancs kiadása előtt:service wpad stop
(ennek megfelelően javasolt persze kábelen csatlakozni a routerhez azzal a géppel, amiről mókolod épp az SSH-n keresztül a routert)4.) ízlés szerint utána kiadod az
aucparancsot SSH-n belül, vagy kilépsz SSH-ról és a GUI-s admin felületen végzed el a frissítést. -
mano42
aktív tag
válasz
xabolcs
#5905
üzenetére
Sejtettem, hogy valami ilyesmi, hisz a kek csik kb instant lefutott, mig a xiaomi rom esteben latszott, hogy tortenik valami, es tenyleg, tortent is. Csak azert remeltem, hogy ha mar openwrt van rajta akkor mukodik az ujabb openwrt bin mert qrvara uncsi az osszes STOK izet kicserelni. Na de szerencsere nem oli meg az ember a routert gyakran. Apropo, mi a velemenyed a WRX36-rol? Euban ha jol latom meg nem lehet kapni, de a lenyeges elonye, hogy van usb-je es nas-kent is lehet hasznalni, ami nagyon vonzo hisz egy osregi zyxel nasom van amire qvazi mar nem elerheto semmi custom... a gyarival a regi samba inkabb nyug. Szerencsere a tv androidos, igy a NSA egy kodival meg mukodik, torrentek kipipalva egyelore.
Apropo, most latom, hogy az opkg update jelez egy firmware updatet, bar a sysupgrade szerint minden naprakesz. Merjem frissiteni? ath11k-firmware-ipq8074 2023-03-31-a039049a-1 » 2023-06-02-210d1a72-1
-
mano42
aktív tag
válasz
xabolcs
#5900
üzenetére
Nos, legujabb tapasztalatok.
- MTD torolve, sysupgrade = halott router. (mar megint)
- Tftp Recovery az openwrt binnel (eselytelen, vagy en csinalom rosszul)
- Tftp recovery a kinai binnel - siker
- Ujracsinalni mindent az openwrt telepitesere (STOK, ssh, ubi, stb)
-legujabb snapshot bin telepitese
-restore backup... eees minden muxik.
-
-
mano42
aktív tag
válasz
xabolcs
#5872
üzenetére
Azután nincs gond. Érdekes, hogy például a Xiaomi eszközök nem okoznak galibát. És ez már a második tuya cucc ami ezt csinálja, de az elsőnél azt hittem, hogy a build még nem stabil. De azóta n frissítés jelent meg. Még nincs tasmota, viszont a tuya cloud apival már integrálva van a HA-ba.
-
wwenigma
Jómunkásember
válasz
xabolcs
#5833
üzenetére
Egyelőre nézegetem csak az OpenWRT-t és hogy hogy megy a kütyün. A recovery sikerült amugy. Nem téglázom újra.
Vodás koaxos net van és sokszor nem tudom hogy az hülyéskedik vagy a router miatt nem megy ez az, pl hogy wifin neha nehezen tolt be oldalakat és a Speedtest alkalmazás nem igazan mukodik a telefonon, kiesik hibával ha el is indul csak nagyon ritkan fut végig. -
-
tlala
addikt
válasz
xabolcs
#5658
üzenetére
Köszi az infót.
A firmware selector oldalon, a "Testreszabás"-ra kattintás után a megnyíló mezőben a telepítendő csomagok listájának a végére pontosan mit is kell hozzáírni, ha azt szeretném, hogy legyen a friss csomagban alapból Luci, illetve sysupgrade is?
A mostani fw-emben még van sysupgrade (r22084-c0683ec458). -
#5663
Davebowman
senior tag
xabolcs
#5662
Davebowman
senior tag
válasz
xabolcs
#5662
üzenetére
Most nézem a Firmware-selectort, és az normális, hogy csomó minden hiányzik a SNAPSHOT verzióból, a stabil buildek meg nincsenek fent? 22.03 volt az utolsó? Például nem vehető ki a wolfssl...
Ami miatt kérdezem, hogy frissítettem volna a kmod-okat de hibába ütközik: A(z) kernel csomag telepített verziója nem megfelelő. 5.15.94-1-2236b4bd........ -
dchard
veterán
válasz
xabolcs
#5651
üzenetére
Először is a gond az, hogy össze-vissza beszélnek és teljesen különböző platformokról van szó.
A magas CPU terhelés és az ebből következő lassulás számos okból áll össze, ha nem haragszol akkor koncentrálnék a 807x-re, mert a többi ezer éves szar itt pont off topik
Arról nem beszélve, hogy van aki szerint a VLAN+PPPoE szar (nekünk nem releváns), van aki szerint a sima sem működik. SZokás szerint panaszkodnak, kevés konkértummal...Tehát, vannak a hagyományo soffload technológiák mint GRO, GSO vagy a checksum , ezeket az ethernet driver csinálja, és jellemzően az adott chip dolgozik. Egyelőre ez is szarul működik, mert az ethernet driver kaka. Robi dolgozik rajta.
Ez után jön az SW offload, de mivel a PPPoE már önmagában szopat, így nehéz megállapítani, hogy az SW offload nem működik, vagy csak a GSO/GRO/checksum offload nem működése miatt tűnik kevésnek a nyereség.
És erre jönne rá a HW offload, ami a mi platformunkon PPE/NSS lenne.
Tehát szokás szerint nem olyan egyszerű ez sem, és nagyon sok a platform specifikus rész.
-
tlala
addikt
válasz
xabolcs
#5643
üzenetére
Köszi (és neked is a visszajelzést Tonyk).
Kipróbáltam, nem változik semmi.
Azért is az openwrt-re/routerre gyanakszom, mert a korábbiakhoz képest a Luciban is túl sokáig látom a "Loading view" feliratot (kb. 4 mp), amikor váltok az egyes menüpontok között.
Szóval mintha a router okozná a lagot. -
tlala
addikt
válasz
xabolcs
#5640
üzenetére
Az openwrt topikban olvastam, hogy "pppoe-vel nem megy a software flow offloading, bugos".
Lehet, hogy ennek köszönhető az az észrevételem, hogy kb. amióta "hivatalos" a Robimarko fw, azóta van a weboldalak betöltésének a legelején egy fagyós "várakozós késleltetés", mielőtt görgethető, stb. használatható lesz a weboldal?
-
Tonyk
veterán
válasz
xabolcs
#5614
üzenetére
Nem routerfüggő. Mindennel így viselkedik ha kirugod alóla szabálytalanul a PPPoE-t. A digi szervere nem értesül arról, hogy te le akartál jönni róla. 5 percig agyal azon, hogy hová lettél, aztán rájön, hogy elszálltál mint a győzelmi zászló és utána beenged. Sok éve így van ez már. Az ifdown vagy a dchard által említett stop-olás nekem sem jutott el a tudatomig... Mint ahogy az sem, hogy szabályos rebootok után mindig volt net.
Örgeszem na...
(ma meg akartam szivatni egy kilencedikes osztályt egy "bonyolultabb" feladattal, erre kiderült, hogy magamat sikerült, mert a kis büdösök egy pillanat alatt találtak -bár nem teljesen tökéletes- megoldást, ami nekem eszembe sem jutott...Úgy csináltam mintha evidens lett volna számomra. Persze belül jót röhögtem magamon, hogy miért kell mindig mindent bonyolítani.) -
Tonyk
veterán
válasz
xabolcs
#5567
üzenetére
Namármost wolfssl-ből van három is:
libwolfsslcpu-cryptolibustream-wolfsslwpad-basic-wolfsslOpenssl esetében ezek a cserék (leginkább a devcrypto érdekel, hogy jó lehet-e vagy kellhet-e)?
libopenssl-devcryptolibustream-opensslwpad-basic-opensslEzek így megfeleltethetők egymásnak?
mbedtls esetében pedig?
?
libustream-mbedtls
wpad-basic-mbedtlsSzerk: Most látom a logokban, hogy pár perce került be a wolfssl javítás, ezek szerint a következő verzóban már benne lesz ("wolfssl: fix build with make < 4.2"):
https://git.openwrt.org/?p=openwrt/openwrt.git;a=shortlog -
#5565
Davebowman
senior tag
xabolcs
#5551
Davebowman
senior tag
-
Tonyk
veterán
-
dchard
veterán
válasz
xabolcs
#5307
üzenetére
Ha valaki rajatd és rajtam kívül használt saját maga által fordított változatot:
Robi azt kéri váltsunk mi is openwrt master branch-ra. Az "ipq807x-5.15-pr-final" -t már törölte is, tehát ott ne kereseen senki semmit. Ha lesznek új fícsörök, annak majd csinál külön branch-et, de egyelőre a javasolt út az openwrt master.
Mégvalami: az openwrt master-nél a compat verzió újra visszaáll 1.0-ra, tehát a Tlala által korábban érzékelt probléma sysupgrade-nél újra jelentkezni fog. A megoldás ismét ugyanaz mint akkor.
-
Norbi.Sz
senior tag
válasz
xabolcs
#5275
üzenetére
Egyébként akkor a fix IP beállításokat sem veszi át a második router??? Csak látja egymást wifin a két router, és egy hálózatként tudnak működni (vagy nem tudom, hogy írjam)?
Ki kell kapcsolni a DHCP-t egyáltalán a második routeren??? A mesh hálózatnak épp az lenne a lényege, hogy csak a fő routeren kell beállítani bármit is, vagy nem jól gondolom?
-
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.
Új hozzászólás Aktív témák
Hirdetés
trance89- OLED TV topic
- sziku69: Fűzzük össze a szavakat :)
- Szívós, szép és kitartó az új OnePlus óra
- Azonnali fotós kérdések órája
- Elektromos cigaretta 🔞
- Samsung Galaxy S24 Ultra - ha működik, ne változtass!
- HiFi műszaki szemmel - sztereó hangrendszerek
- Posta, csomagküldés
- PlayStation 5
- Nintendo Switch 2
- További aktív témák...
- T14s Gen4 14" FHD+ IPS i7-1365U 16GB 512GB NVMe magyar bill IR kam gar
- Gopro hero 7 black
- ThinkBook 16p Gen3 16" QHD+ IPS Ryzen 5 6600H RTX 3060 16GB 512GB NVMe ujjlolv gar
- ThinkBook 16p Gen3 16" QHD+ IPS Ryzen 5 6600H RTX 3060 16GB 512GB NVMe ujjlolv gar
- HP Probook 640 G2 (14FHD/i3-G6/8GB/256SSD/Magyar/Win11) - Szép!
- MikroTik CCR1009-7G-1C-1S+ Cloud Router
- Huawei P20 Lite 64GB, Kártyafüggetlen, 1 Év Garanciával
- ÁRGARANCIA!Épített KomPhone Ryzen 7 5800X 32/64GB RAM RX 7800 XT 16GB GAMER PC termékbeszámítással
- LG 32SQ700S-W - 32" VA Smart - 3840x2160 4K UHD - 62Hz 5ms - WebOS - Wifi + BT - USB-C - Hangszórók
- BESZÁMÍTÁS! Intel Core i9 14900KF 24 mag 32 szál processzor garanciával hibátlan működéssel
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: CAMERA-PRO Hungary Kft
Város: Budapest