Hirdetés
- gban: Ingyen kellene, de tegnapra
- Luck Dragon: Asszociációs játék. :)
- Brogyi: CTEK akkumulátor töltő és másolatai
- ricshard444: iPhone 17 Pro Max - Kedves téglám
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Magga: PLEX: multimédia az egész lakásban
- Meggyi001: Kuponok....
- Gurulunk, WAZE?!
- bambano: Bambanő háza tája
- Rap, Hip-hop 90'
-
LOGOUT
Xiaomi AX3600 WiFi 6 AIoT Router
Új hozzászólás Aktív témák
-
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.
-
dchard
veterán
Nem tudsz ilyet csinálni házilag, azon gondolkodom hogy egyáltalán én tudnék-e... L2-t tudnék, L1-et minden valószínűség szerint nem, és a látottak alapján itt L1 probléma lehet...
MOd: a memória nálam is szivárog mióta az új verzión vagyok, 20%-on ketyeg most a szabad ram, a korábbi 35-40%-hoz képest.
-
-
dchard
veterán
válasz
wwenigma
#6191
üzenetére
"wifiről speedtest + speedtest gépen + kisgépről helyi hálón másoltam"
A korábbi mérésednél ha jól sejtem csak a drótos speedtest ment, azért nem ugrott fel a proci abban az esetben, mert a CPU ki tudta nyomni magából az 500megabitet alap órejelen is. A wifi és a helyi hálózaton történő másolás is más kategória ha közben még nyomod a speedtest-e dróton is. Főleg a wifi lan- lan, és lan-wan irányokban is számmottevő CPU terhelést tud produkálni.
"reméltem hgoy a masik két cpu freki is mukodik majd"
Melyik "másik kettő"? Én nem tudok arról, hogy lenne az 1000-1382MHz-en kívül bármi más használható órajel.
-
dchard
veterán
válasz
wwenigma
#6188
üzenetére
Legfrissebb elérhető változat attended sysupgrade-del:
Nálam pedig szépen felmegy 1382MHz-ig, PPPoE mellett, de nem végig marad ennyin. Schedutil mellett is megtörénhet - mivel nincs per mag skálázás csak az összes mag tud váltani egyszerre - hogy egyetlen mag akár maxra való kitekerése nem eredményezi a frekvencia megugrását.
PPPoE nélkül jellemzően jobban tud működni a SW offload és több magra is tud terhelni korlátozott mértékben. Valami nálad a látottak alapján nem kerek, de mivel nem tudjuk hogy az adguard-on kívül vajon még mi egyéb van ami nem vanilla és csúnyán megeheti az erőforrást, így nehéz lesz megfejteni hogy mi lehet a gond....
-
dchard
veterán
válasz
wwenigma
#6186
üzenetére
"Eddig nem is jött elő, az r24111 build stabil volt (IoT antennán) és most az r24124 alatt problémázik ugyanott."
Nem volt sem driver sem firmware váltás ezen verziók között, ebből látszik hogy szerencse kérdése mikor jön elő Tuya eszközökkel. A hiba ismert, de nincs ráhatásunk, ezt csak a QCA tudja megoldani, bár ha eddig nem tették, nehéz elhinni hogy ez majd egyszer csak megoldódik, bár volt olyan hiba ami minden előzetes értesítés nélkül egyszer csak javításra került, másfél évvel a bejelentsé után...
"CPU 1017600 KHz problémára tudsz esetleg valamit mondani, nem úgy tűnik hogy kozmetikai lenne a hiba mert a terhelés felmegy és nem osztódik el a többi proci között sem igazán"
Fogalmak keverednek. A CPU frekvencia skálázási probléma tisztán kozmetikai mindenkinél, ez javítva van már, 1-2 nap és attended sysupgrade-del lehet majd frissíteni. A terhelés amit speedtest közben látsz egy magon, annak semmi köze az előző problémához, az teljesen normális: a PPPoE nem többszálasítható, és CPU intenzív. A SW offload segít rajta valamennyit, de azt írtad az be van kacpsolva. Nálam minden nélkül tisztán dróton elérhető a gigabit, ilyenkor egy szálon közel 100% az első mag, az órajel pedig 1000-1400MHz között mozog. A CPU ütemezőt állíthatod még át "schedutil"-ra, akkor kicsit gyorsabban lépked felfelé a freki terhelés hatására.
"Kivettem adblockot, statisztikát és vpn-t mert előfordult hogy 90% fölé ugrott a memória használat és beállt mint a szög, majd OOM és valamit leölt, ami szembe jött. "
Ezek a routerek 512MB memóriával nem alkalmasak ilyesmire. Eleve az 512MB-ból valójában csak 410 az ami effektíve használható és abből a router alap funkciója + a wifi megeszik minden nélkül 200-210MB-ot. Az Adblock eszik ezek közül a legtöbb memóriát, azt nyugodtan el lehet felejteni 1GB RAM alatt ezeken a routereken.
-
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...
-
dchard
veterán
válasz
wwenigma
#6180
üzenetére
"az egyik okosaljzatom ugy nezem valamit bekever"
Egy ismert konkrét gyártó termékével van tudomásom hibáról, de az mintha nem így nézne ki. Látatlanban ennyit tudok mondani, az "AIOT" rádiót meg el kell felejteni, ahogyan azt már jópárszor megbeszéltük.
Került be megint bőven javítás, 1-2 nap múlva érdemes frissíteni.
-
dchard
veterán
A memória fogyasztásnak és a logban látható üzenetnek semmi köze egymáshoz.
Én az elmúlt időszakban nem láttam hasonlót utoljára bő egy éve volt szerencsém ilyenhez. De az normális hogy minden egyéb szolgáltatás nélkül a két rádióval eltűnik a szabad memória 60%-a. Régóta ismert, hogy az AX rádiókat inkább egy giga ramra tervezétk, nem fél gigára. olyannyira hogy külön memória profil van az 512MB-tal szerelt eszközökre.
-
dchard
veterán
Mindenkinél működik, csak annál nem, aki nem várja meg, hogy az 5Ghz-es rádió megcsinálja a DFS-t. Számtalanszor volt már erről szó itt is, máshol is. Ki kell várni a DFS-t, ami akár 10 perc is lehet az első indítás után, illetve a helyes országkódot sem árt beállítani. Az Openwrt mindezt a rendszernaplóban jelzi is, hogy mikor kezdte el a DFS-t és az meddig fog tartani.
-
dchard
veterán
Valakinek a házi gányolása nem lesz Openwrt. Mivel Robin kívül senki nem dolgozik az IPQ6000-en, ezért megkockáztatom, hogy amit belinkeltél, a gyári QSDK alapú firmware tákolása, attól hogy úgy tűnik ez Openwrt, még nem lesz az csak azért mert valaki odaírta. Újabb jó példa arra, hogy kizárólag a hivatalos forrásból érdemes tájékozódni, ami az openwrt.org
MOD:
És nézzenek oda: elég volt csak belenézni a feeds-be hogy kiderüljön, pontosan úgy van, ahogy gondoltam...
-
dchard
veterán
válasz
wwenigma
#5966
üzenetére
Tegyük hozzá, hogy az attended sysupgrade sem működik addig, amíg legalább egyszer a "kézi" frissítést meg nem teszi valaki, hiszen az adott target már kvázi nem létezik. Így az átnevezés előtti verzión lévőknek mind kézzel kell frissíteni, ha úgy döntenek hogy frissíteni akarnak.
-
dchard
veterán
A korábbi hozzászólásodban ezt írod:
"Az első router a modem (már ha ez bridge módban van) mögött legyen a "router" minden szükséges szolgáltatással."
Akkor ezen hogy jön át a szolgáltatói VLAN?
A kérdésre a válasz: ha szolgáltatói IPTV-t akar ahhoz nem VLAN kell, hanem az hogy a 3 darab AX3000-ből álló hálózat minden eleme "AP/Mesh" módban legyen, működjön az IGMP snooping, egyik se viselkedjen routerként, így a telekomos STB el tud jutni a HGW-ig, ami intézi a többit. Valójában a szolgáltatói HGW-n ér véget az IPTV VLAN-ja, ahhoz az előfizetői LAN-nak nincsen köze.
-
dchard
veterán
Ha elég perverz lennél azt mondanám: meg kell próbálni egy olyan AP-n ami nem dől össze és megnézni hogy ugyan mi a tökömet küld ami nem tetszik, de van egy olyan sanda gyanúm, hogy valamit alacsony réetegen (WLAN MAC) szar el az eszköz, különben nem a wifi fw dőlne össze, hanem a driver vagy a mac80211 rész.
Amit tudok még ajánlani: adok debug kódot, azzal elindítod a routert wifi részét debug módban, minden más létező eszközt kikapcsolsz a közeledben, és megpróbálsz egy debug logot generálni miközben a szar eszköz (és csak az) megpróbál konnektálni és összedől a cucc. Azt még kiagyalom hogy a FW debug dumpot valahogy ki tudnád-e nyerni. Mi nem megyünk vele semmire, de a Qualcomm-tól talán ránéz valaki.
Ha visszaemlékszel, az AX6 vs. wifi FW témában 4 hónapig baszogattam őket, 3 hónapig nem válaszoltak, majd a 2.9.0.1-ben megoldották a gondot. Tehát ehhez abszolút kitartás kell. Ha rá tudunk mutatni arra, hogy több különböző eszköz is érintett (tudni kéne hogy nem ugyanaz a kommunikációs modul/chip van mindben ami szar), akkor talán hamarabb reagálnak. Akárhogy is: nem két pillanat egy ilyen javítás.
-
-
dchard
veterán
Mindig van lehetőség kiválasztani valami olyan országot, ahol engedve van a 30dBm, európában nem fogsz ilyet találni, mivel itt 250mW a maximum. A cél az, hogy a BDF-ek megfeleljenek az adott ország előírásainak, ez ugye ETSI területen meglehetősen egységes.
Meg is kérek mindenkit, hogy csak akkor jelezzen ezzel kapcsolatban problémát, hogy ha a HU országkóddal valamelyik csatornák nem elérhetőek, vagy túl restriktívek az érvényes szabályozáshoz képest.
-
dchard
veterán
Bizony, ezért is írtam le. Európában a primer radar sávokkal akár csak kis mértékben átlapolódó csatornáknál kötelező a 600 sec. passzív "hallgatózás", és 160MHz-nél majdnem minden csatorna ilyen. Kivétel ezalól csak a 36-64--es (tehát a legalacsonyabb) részben lévő 160MHz, ott 60 sec. a várakozás. Ugye eleve csak két 160MHz széles csatorna lehetséges a jelenlegi 6GHz alatti tartományban, ebből az alsó jellemzően tele van, tehát fölötte minden esetben 600 sec. lesz.
-
dchard
veterán
Fogalmi zavar van. Ha a 160MHz nem működne más hálózatok mellett vagy azokkal átfedésben, nagy bajban lennénk.
A 160MHz működéséhez CAC és DFS kell, ez ETSI területeken 600 másodpercnyi (10 percnyi) passzív radar keresés jelent, ezt meg kell várni, és csak utána indul el a rádió. Ez teljesen normális. Nyilván kliens oldali támogatás is kell hozzá, feltételezem hogy ez rendelkezésre áll.Openwrt alatt a rendszer naplóban világosan látszik amikor a CAC/DFS elindul és látszik az is hogy meddig fog tartani, és hogy sikeres volt-e:
phy0-ap0: DFS-CAC-START freq=5640 chan=128 sec_chan=-1, width=2, seg0=114, seg1=0, cac_time=600s
.....
phy0-ap0: DFS-CAC-COMPLETED success=1 freq=5640 ht_enabled=0 chan_offset=0 chan_width=5 cf1=5570 cf2=0 -
dchard
veterán
Tekintve, hogy az Intel 2-3 havonta ad ki javított firmware-t az újabb (elmúlt 1-2-3 éves kártyáihoz), ez simán lehet Intel oldali hiba. Nekem is van egy Intel AX201-es kártyám, de nem 30 megabitet mérek felfelé.
De természetesen igen, van rá esély hogy megjavul ha az AP oldal is megkapja az új FW-t. Én használom már pár napja, nem tapasztaltam vele semmi fúrcsaságot.
-
dchard
veterán
Hamarabb berakta mint gondoltam. Ez a váltás 2.5-ről 2.9-re ezres naygságrendben javít kisebb-nagyobb bugokat, tehát mindenképpen érdemes lesz a frissítés.
Különösen érdekes lenne hallani a frissítés után olyanoktól, akiknek valamilyen mesh konfigban működik a routerük, hogy változott-e valami.
-
dchard
veterán
Némi jó hírt tudok mondani: korábbi problémák miatt lassan bő egy éve viszonylag régi (persze a gyártói verzióhoz képest még így is sokkal frissebb) WIFI firmware verzión ragadtunk. Az egyik probléma a regdb hiánya volt, a másik hogy például az AX6-on minden korábbi főverzió (2.6, 2.7 és 2.8) egyszerűen a betöltés során összeomlott.
Pár napja a Qualcomm kiadta az első publikus tesztelésre szánt változatot a legfrissebb 2.9-es verzióból, amiben végre megoldották a regdb nélküli töltést (visszafelé kompatibilis), és úgy tűnik minden eddig tesztelt eszközön (AX6, AX3600, AX9000, QNAP 301w, és DynaLink) jól működik. Nyilván most pár hét tesztelés következik, de minden jel arra mutat, hogy végre tudunk majd frissíteni belátható időn belül.
A 160MHz-es problémát is sikerült egyelőre kezelni azzal, hogy QCA által kiadott hibás commit-ot Robi visszaállította.
-
-
dchard
veterán
Az a baj, hogy nem érted, ezek a csomagok mit is tartalmaznak pontosan, a nevéből pedig téves következtetést vonsz le.
Sem a firmware, sem a BDF, sem a driver nem frissült az elmúlt 2-3 hétben. A BDF nem is fog, az ath11k-t Robi 2-4 hetente behúzza de ott sem volt semmi számottevő. FW-ből majd a 2.7-es fog látványos eredményt hozni, de egyelőre a Qualcomm nem publikálta az új regdb-t, addig pedig nem tudjuk használni értelmesen a 2.7-es verziókat.
-
#5733
dchard
veterán
tha_answer
#5732
dchard
veterán
válasz
tha_answer
#5732
üzenetére
Én biztos nem tenném fel egyiket sem, mert tartalmi változás biztosan nincs egyikben sem, viszont esetleg azokat a "hibákat" javíthatták, amitől lehetséges a root. Még valamit mókolnak a bootloader-en aztán a downgrade se játszik majd, az lesz az igazi szopó... Ezt pont kinézem a gyártóból.
-
-
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.
-
dchard
veterán
Ezeket hol olvasod? Nálam PPPoE+SW offload és tökéletesen működik minden. Nem érzékelem, hogy bármi is lassú lenne: ha rányomok egy URL-re, rögtön ott a tartalom.
Ami valóban vacak, azok az Európán kívüli taralmak, de hát az sajnos a Digi nemzetközi iránya... Akár YT-nél is látszik, hogy ha olyan tartalmat akarsz nézni, ami mondjuk Új zélandi, vagy Ausztrál (értsd: nincs becache-elve valamelyik EU-s szerveren) az gyatra szar, főleg ha mondjuk 2x-es lejátszási sebességgel néznéd.
-
dchard
veterán
A megoldás: wpad stop előtt nyomsz egy Stop-ot az interfészen. Vagy kivárod
Nálam is ugyanez van, az érdekesség az, hogy ha nyomsz egy reboot-ot, akkor elbontja a kapcsolatot rendesen, és rögtön visszaenged. Valahol a sysupgrade-ben lehet a probléma és ez mindenkit (értsd: minden openwrt felhasználót) érinthet... -
dchard
veterán
Mivel számtalan panasz jön itt a frissítések és az AuC kapcsán, elmondom én hogyan frissítenék:
1. Letöltöd az éppen aktuális "sysupgrade.bin"-t.
2. Felrakod a "beállítások megtartása" opcióval.
3. Felrakás után "opkg update" majd "opkg install xyzd" az xyzd-t temrészetesen a hiányzó csomagokkal helyettesíted.Minden beálítás megmarad, az "opkg install" parancs kimenetét elmentheted következő alkalomra, és biztosan jól működik, míg az AuC láthatóan még szenved némi gyerekbetegségben. Én sosem használtam az AuC-ot, de nem is futottam bele ilyen hajmeresztő hibákba, mint amikről itt néhányan beszámolnak.
-
dchard
veterán
válasz
netcore
#5518
üzenetére
Egyikből sem látszik semmi, az meg főleg nem, hogy menet közben csak olvashatóra váltott a file rendszer, ez lényegében kizárt, főleg úgy hogy a kernel log tök üres.
A "mount" parancs kimenetét másold be (amikor fennáll a hiba), és ahogyan írták is: legközelebb hosszú log-ra ott a pastebin. Illetve az "opkg update" kimenetét is.
-
dchard
veterán
-
dchard
veterán
Ding-ding-ding, megvan a nyertes.
Persze a file-rendszer abszolút írható marad ettől még, az opkg panaszkodik telepítés közben összeférhetetlenségre. Különösen a kernel moduloknál jön ez elő, mert ha jön az új kernel, az összes modul frissül és a korábban telepített verzióval értelemszerűen nem konpatibilisek.netcore:
Újabb panasz, de napló, log, vagy képkivágás sehol. Jó lenne már rászokni, hogy ha valami probléma van, akkor legyen már hozzá adat. Nem véletlenül nem reagál az ilyen jellegű panaszokra senki.
-
dchard
veterán
A második problémát már javították is, az elsőt még nézzük. Valszeg az utolsó iwinfo csomag frissítésében lehet valami kaka... Hacsak nem a "visszatöltöm a korábbi mentést" okoz problémát
Ha ilyen fúrcsaság jelentkezik, visszaállnék alapra, aztán újra beállítanék mindent. Ha úgy is rossz, akkor tényleg bugzik valami. -
dchard
veterán
válasz
Doky1988
#5439
üzenetére
Az AuC-os wolfssl probléma ismert, meg fog oldódni.
Az usoló képeden pedig a hiba azért állt elő, mert egy korábbi frissítés után visszatöltöttél egy korábbi mentést, így a compat_version is visszaállt a korábbi (2.0) értékre. Többször leírtam az elmúlt egy hétben, hogy ha valaki visszaállít egy régebbi mentést, ez fog történni, és minden alkalommal megtörténik a jövőben is, amíg régi mentést állítgat vissza a felhasználó. Ezt kétféle képpen lehet elkerülni: 1. azt csinálod amit a piros felírat ír: lenullázod a konfgiot, frissítesz, majd mindent kézzel visszaállítasz és csinálsz erről az állapotról egy mentést, amit a jövőben gond nélkül vissza tudsz majd állítani. 2. Ha biztos vagy abban hogy kompatibilis verzión vagy (összevont partíció, új interfész elnevezések), akkor a compat_version visszaállítása mellett frissítesz, majd a frissítés után csinálsz mentést az új állapotról, amit később majd gond nélkül vissza lehet állítani. Akinek ez a második lehetőség nem teljesen világos, vagy nem tudja/akarja megérteni a mögötte megúhzódó logikát: semmi baj, csinálja az első pontnak megfelelően.
-
dchard
veterán
Nem tetszés kérdése, pontosan kell fogalmazni és akkor nem érti félre senki amit írsz. Ilyen egyszerű. Az meg nem tom hogy jön ide, hogy miben vagy az első ötben, és mi köze ennek ahhoz ami a topik témája. Bár ha jobban meggondolom, nem is olyan régen láthattunk ilyet nagyban is: amikor a retek klub azzal kedzi a magyarázkodást, hogy "Piacvezető televízióként...." mintha ettől éppen nem még kínosabb lenne az, ami miatt magyarázkodniuk kell...
De visszatérve: számos ismert bug van a jelenlegi "legfrissebb" verzióban is, amin dolgozunk. Ha valaki fúrcsa hibát tapasztal, különösen a wifi háza táján az jelezze. Kernel és syslog csatolásával, ha egy mód van rá
-
dchard
veterán
Openwrt-ből nincs és nem is lesz végleges változat. Pontosan az a lényeg a gyári trágyával ellentétben, hogy rendszeresn kapjon frissítést az eszköz a rendszer fő komponensei (kernel, driver, firmware), és programjai (webes felület és webszerver, valamint bármi amit telepítesz) tekintetében.
Nem egészen egy hete van bent a platform támogatás, senki nem gondolhatja komolyan, hogy itt a munkának vége, kész passz. Ami jelenleg van, leginkább bétának nevezehtő, bár abból egy meglehetősen jó minőségű és stabil verzióról van szó.
Két napona nem kell frissítgetni, de érdemes figyelni a változás naplót, és ha javításra kerül valami ami értinhet, akkor érdemes firssíteni.
-
dchard
veterán
"Ahogy ertem, a wireguard egyelore nem tamogatott ... vagy igen?"
Már hogyne lenne támogatott. Ráadásul ha jól rémlik már megy a crypto gyorsítás is, mert a routebren lévő ARM magok már tudnak bizonyos cypher-eket gyorsítani. Nyilván ilyet érdemes választani. Ráadásul a Wireguard azér tis sokkal jobb mint az Openvpn, mert saját kernel driveren végződteti a forgalmat, így sokkal kevésbé terheli a CPU-t.
-
dchard
veterán
1. Mit takar a snapshot? Gondolom nem a stabil verzió hanem esetleg RC?
Az RC-nek RC a neve, hogy a következő RC-ben benne lesz-e az ipq807x target azt még nem lehet tudni. Mivel az egész 3 napja került be masterbe, ne kérdezgesse senki, hogy mikor lesz belőle stabil kiadás, az minimum hónapok kérdése. Várhatóan 6.1-es LTS kernelre való átállással fog ez eljönni, amiben egyébként rengeteg hibát javítanak, ezek jó része most backport-ként van jelen. A legjobb, ha mindenki egyfajta "béta"-ként fogja fel a jelenlegi helyzetet.
2. A sysupgrade ezentúl fog működni alapból vagy továbbra is le kell kapcsolni a wifit?
Ez a probléma nincs megoldva, a wifi driver az interfész lelövését nem végzi el elég gyorsan, tehát továbbra is service wpad stop kell a sysupgrade előtt.
Pillanatnyilag azon megy a munka, hogy hogyan lehetne mégis az NSS-t hozzáadni a történethez úgy, hogy várhatóan el is fogadják upstream. Pillanatnyilag ott tartunk, hogy a forgalom át tud haladni az NSS magokon, nem kakálja össze magát, és némi gyorsulás így is látható, PPPoE-nél kb. 30%, bridge-en ennél több, és a WLAN <--> LAN load is számottevően javult. De hogy ez mikorra lesz elérhető átlag usereknek, arra nem tennék ígéretet.
-
dchard
veterán
/etc/network/configszerkesztése és/etc/init.d/network restartPontosan így.
Ezt a részt kell hozzáadni:
config interface 'tetszőleges_név'
option proto 'pppoe'
option username 'felhasználó_név'
option password 'jelszó'
option delegate '0'
option ipv6 '0'
option device 'wan' -
dchard
veterán
Ebben semmi érdekes nincs. Az openwrt master-ben nincs luci, azt le kell tölteni "opkg update" majd "opkg install luci" parancsok kiadásával. Ha valaki frissített és nincs luci, ne pánikoljon. Minden beállítás ott van minden korábban telepített programhoz, csak újra kell őket telepíteni.
-
dchard
veterán
Ez valóban fúrcsa. Érdekes lett volna nézni a hibás állapotban egy UART naplót, de ennek már gondolom utána vagyunk.
Én a magam részéről elég sok adott esetben nagyon különböző verzió között váltogattam az elmúlt hónapokban, de csak akkor tudtam téglásítani az AX/-omat, amikor valamit nem úgy cisnáltam, ahogy az elő volt írva. Olyan egyszer sem volt, hogy tégla lett és nem én rontottam el valamit
-
-
dchard
veterán
válasz
csabi10
#5320
üzenetére
Nem, ha nem akarod megtartani akkor nem fontos, mehet fel, beállítások megtartása mellől kiveszed a pipát és lefrissül egy szűz rendszerre. Ez egyébként az ajánlott minden olyan esetben amikor feljön a piros felirat frissítés előtt.
MOD: az első image-ek még mindig nem fordultak le, szóval türelem rózsát terem. Vagy estére, vagy holnap reggelre készülnek el.
-
dchard
veterán
Nem. Visszaállítod a compat verziót, frissítesz a beállítások megtartásával, és kész.
De ez csak akkor működik, ha már eleve egy partíciós verzióról akarsz frissíteni.
MÉg egyszer: ha a compat verzió változik, az alapvetően azt jelzi, hogy a két verzió között NEM lehet frissíteni (a compat verzió hekkelésével sem, meg a régi mentés visszaállításával sem). Ez most egy speciális eset.
-
dchard
veterán
Úgy érzem ez a
compat_versionnevű paraméter további magyarázatra szorul.Ez a paraméter az, amivel az Openwrt ellenőrzi, hogy ha valaki a beállításk megtartása mellett frissíteni akar, akkor az induló és az új állapot kompatibilis lesz. Az esetek nagy részében a frissítésnek nincs akadálya, van viszont amikor a belső architektúra olyan mértékben változik meg, hogy a frissítés nem lehetséges. Ilyenor a fejlesztő szándékosan megváltozatja a compat_version paramétert, és felugrik a piros hibaüzenet frissítéskor, ami jelzi, hogy nem kompatibilis verziók között próbál a felhasználó frissíteni.
Mivel az eddigi verziók fejlesztői verziók voltak, most pedig hivatalosan is bekerül az Openwrt-be ez a target, ezért a compat_version 1.0-ról indul.
A te esetben vissza kell állítani a compat_version-t 1.0-ra, és utána megkísérelni a frissítést, mivel te már kompatibilis verzión vagy.
Természetesen ha valaki frissít, és visszaállít egy korábbi mentést, amiben régi compat_version van, az legközelebb megint nem lesz jó. Nem véletlenül írja a nagy piros felirat, hogy ne csináld
-
dchard
veterán
Pont ugyanúgy, mint eddig, igen. A compat verziót (megint) vissza kell majd állítani 1.0-ra, ahogy korábban:
uci set system.@system[0].compat_version="1.0"
uci commit systemUgyanaz érvényes erre is: már eleve egy partíciós verzión kell lenni, ellenkező esetben brick lesz a vége.
Ha nem jön semmi közbe, akkor holnap reggelre lesz elérhető image a fenti linken.
-
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.
-
dchard
veterán
Nincs mit. És félre ne érts: nem rád haragszom, de olyan mérékben öntötte el az internetet az ilyen-olyan hekkelt, tákolt, turományolt "openwrt" változatok száma, ami lassan kezelhetetlen. És amikor valaki megszívja (ami csak idő kérdése) vele, aztán jön a hivatalos topikokba panaszkodni, hogy az "openwrt" szar, és várja a segítséget, aki meg a kókány változatot rászabadította a világra, szépen felszívódik. És ez rengeteg erőforrást elvisz.
-
dchard
veterán
És a hülye Redalert bele is hekkelte ezt a wikibe...
Az összes ilyen külső "megoldást" le kell felejteni. Abban a pillanatban, hogy a build továbblép, ami akár naponta megtörténhet, ezek nem követik le és megtörik a kompatibilitást.
A mai naptól bent van master-ben, valamikor éjszaka várhatóan le is fordulnak az első image-ek, szóval holnap reggeltől mindenki használja a hivatalos forrást:
https://downloads.openwrt.org/snapshots/targets/ipq807x/generic/
-
-
dchard
veterán
Ha a jan. 9-ei verzión vagy és ezt írja: this image is incompatible for sysupgrade based on the image version (1.1->2.0), az csak egy féleképpen lehetséges: az egy partíciós upgrade után visszaírtál egy korábbi mentést.
Ha a jelenlegi verziód már összevont partíciós (de csak akkor!), akkor:
uci set system.@system[0].compat_version="2.0"
uci commit systemÉs újrapróbálod.
-
-
dchard
veterán
Kellemetlen, hosszadalmas és szükség lesz hozzá egy linux virtuális gépre. Még mindig akarod? Akkor: [link] Nyilván Robi megfelelő repoját kell klónozni az elején, kiválasztani a megfleelő branch-et, a többi már ugyanaz. Legalább 20GB szabad hely legyen a virtuális gépen szabadon.
Nehogy valaki rossz helyen keresse a hibát.
Új hozzászólás Aktív témák
Hirdetés
trance89- ÚJ OMEN Transcend 14 - 14"2.8K OLED 120Hz - Ultra 7 155H - 16GB - 1TB - RTX 4060 - Win11 - 3 év gari
- Gamer PC-Számítógép! Csere-Beszámítás! I5 14400F / RTX 3060Ti / 32GB DDR5 / 512GB SSD!
- HIBÁTLAN iPhone 13 mini 128GB Blue -1 ÉV GARANCIA - Kártyafüggetlen, MS3846, 94% Akkumulátor
- Apple iPhone 13 Pro max 512GB,Újszerű,Dobozával,12 hónap garanciával
- Gombászkönyvek egyben
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: NetGo.hu Kft.
Város: Gödöllő