Akkor vélhetően ez okozza, hogy június 17-e óta nincs devel snapshot sem ar71xx architektúrára. A routeremen 4.14.125-ös kernel van, a vanilla pedig már 4.14.131-nél jár. Meg is lepődtem, mert gyakran fél-kétnaponta van build, most meg 12 napja semmi.
Közben kicsit körüljártam a problémát. Az ar71xx már csak forrásban létezik, nem csinálnak belőle buildet. Az egészet ath79-re migrálták, ott viszont már van 4.19-es sorozatú kernel, s ha jól értelmeztem, patchelni sem kell nagyon, a vanilla tartalmazza, amit kell.
3)
>> cd openwrt/
>> ./scripts/feeds update -a
>> ./scripts/feeds install -a
>> make defconfig
(ez eddig nem fordít semmit, csak "letölti" a makefile-okat, előkonfigurálja a cuccot, ha ezeket kihagyod, a csomagválasztás során meglepetéseket fogsz tapasztalni)
4)
>> make menuconfig
(ez a csomagválasztó, itt szépen kiválasztod ami kell, de ami a legfontosabb:
--> Target System: Atheros AR7xxx/AR9xxx
--> Subtarget: Generic
--> Target Profile: TP-Link TL-WR842N/ND v3 <--
ez, utóbbi a legfontosabb, ha kihagyod, akkor az összes létező routernek legenerálja az image-t, ha eltéveszted, téglásít(hat)ja a dobozodat!)
5)
>> make download
>> make -j 8 <---vagy_ahány_cpu_szálad_van
(ekkor lefordul, a keletkezett image az openwrt/bin/ könyvtárban van, a neve ...sysupgrade.bin -re végződik.
ezt valahogy feljuttatod a dobozodra, ha van Luci, akkor ott feltöltöd, ha nincs, akkor máshogyan.
[pl: felrakod egy lokális webszerverre, és a dobozon wget-tel lehúzod a /tmp/-be ] )
6)
>> sysupgrade -kapcsoló openwrt....sysupgrade.bin <---image_neve
(Itt a kapcsolókra érdemes figyelni, ha már régóta (kb: 2-4 kiadás óta) nem volt frissítve,
akkor nem ajánlom a config fájlok (/etc/) megtartásást, mert nekem (tapasztalatból mondom)
sokszor elhasalt a visszatöltésnél, tehát a kapcsoló "-n" (No), ha ugyanaz az új builden a kiadás,
mint a dobozon lévő, akkor maradhat a config, vagyis "-c" kapcsoló. (bár nekem még ekkor is volt néhány meglepetés)
7)
>> ssh root@router_ip
Vagy Weben eléred, ha van Luci az image-ben.
Ezután jön a konfigurálás, és a scriptjeid, beállításaid visszatöltése/visszamásolása.
(ide értve az ssh root tiltását/szabályozását is)
Ha Nagyon bátor vagy:
Van egy olyan opció, hogy, ha az image fordítása előtt, te elhelyezel egy "files/" könyvtárat
az "openwrt/" -ben (git gyökérkönyvtár), akkor, az ide elhelyezett fájlokat bemásolgatja
(akár lehet config is) a megfelelő helyekre:
Pl: openwrt/files/etc/sajat.conf ---bekerül_az_image-be--> (router_gyökér)/etc/sajat.conf fájlba.
De ez utóbbit csak akkor javaslom, hogyha az adott config/script már lepróbált, és helyesen működik,
ha ez nem így van, akkor inkább appllikáld rá föl kézzel, mert akkor menet közben kiderülnek a hibák.
+1 Hasnos:
menuconfig --> Image Configuration --> Preinit configuration... mellé tedd be az X-et!
(ez azért jó, mert ha valami hiba (szar konfig/script) van a rendszeren, akkor a következő indításkor
lesz 2másodperced, hogy egy gomb lenyomásával megállítsd a boot folyamatot, és (a dobozra kapcsolt)
RS232 porton keresztül visszanyerd az irányítást a jószágod felett.
Ekkor egy "butított" konzolt kapsz, hogy Pl: sysupgrade-vel felhúzz egy új, működőképes image-t.)
Nagyon bátor vagyok, a konfig file-jaimat belegyógyítom az image-be. Igen, ennek az a hátránya, hogy ez lesz a factory default, így ha el van szúrva, kizártam magam. Tipikus példa a root ssh tiltása. Nem akadtam le, helyesebben szólva mégis: Az új ath79 architectúrára készített image olyan, hogy egyrészt nem megy a wifi, másrészt van ugyan ssh lehetőségem, de valaki megeszi a standard outputomat, így jelenleg például így tudok kernel verziót lekérdezni:
uname -r >&2
Eléggé frusztráló, de még nem záródtam ki végleg. Kérdés, mitől beteg, s hogyan lehet ezt megoldani.
1. Nekünk vannak / voltak olyan routereink amik simán RC ből lettek buildelve, nem volt velük gond, valszeg nem futottunk bele bugba.
2. Hát openwrt ben nagyon sok csomag van mi az ami nincsen benne ?
3. Amennyire tudom, ha fixen beleteszed akkor benne lesz a komplett imageben, ha csak modul, akkor buildeli de csak letölthető package ként, azaz nem lesz belerakva a készülő image fájlba.
A fentebb elhangzó "van benne wireguard", és egyéb hasonló kijelentéseket érdemes körültekintően kezelni, ugyanis nem mindegy, hogy az ténylegesen bele van-e fordítva és magával az image-vel jön, vagy csak a System/Software oldalon listázzva látod, mint telepíthető csomag.
Tulajdonképpen ez ugyanaz a különbség, amire te is kérdezel, mivel az openwrt által közzétett image készítő scriptgyűjtemény az kb. 1-1 megfelelője annak, amit ők is futtatnak éjjelente, és aminek az eredményét látod a neten, letölthető csomagok formájában.
A lényeg ott van, hogy az OverlayFS miatt, ha valamit ténylegesen belefordítasz, az 20-30%-kkal kevesebb helyet foglal el a flash-on, mint, ha ugyanazt a csomagot az image telepítésétől külön telepítenéd. (akár a System/Software oldalon, akár kézzel, a keletkező xxx.ipk fájlt)
Ebből kifolyólag az ilyen nagyobb csomagokat, érdemes egybefordítani, és legföljebb a config fájlokat másolgatni kézzel, de persze, ha tárhelybőségben vagy, (Raspberry/SD kártya) akkor mindegy.
2.)
Ha a config fájlok érdekelnek, akkor pl. az: https://openwrt.org/downloads oldalon.
Letöltöd az xxx.ipk csomagot, kitömöríted, (hasonló, mint egy .deb csomag) és benne van(nak) a "gyári" configok,
(A mc kinyitja neked, ha más nem akarná.)
de, mivel a legtöbb csomagot a fejlesztője eredeti git repójából tölt és fordít az image készítő script, ezért általában érdemes körülnézni az eredeti helyén is.
Viszont, ha érzel magadban bátorságot, akkor lehet saját package repository-t is készíteni a gyári repók mellé, saját makefile-kkel, ha más kapcsolókkal akarod fordíttatni az adott programot, mint amit az openwrt makefile-ben alapból ad. (Azon felül, hogy a fent említett ./files könyvtárba teszel-e saját configot, vagy sem.)
(Nekem pl kellet, mert a VIM (de a többi, nano, joe is) szerkesztő syntax-highlight csak fekete-fekér változatban van benne, és kellett volna színesben is, de ehhez az kell, hogy más kapcsolókkal forduljon.)
1.)
A Szerencse kérdése.
Tényleg!
Én, általában a legutolsó stabil kiadást szoktam használni, de még a stabil verziók közötti váltást is gyakran komolyabb hajveszteséggel tudom csak átvészelni, mert olyan szerencsétlen hardware van, amit még a stabil verziókkal sem képesek normálisan kezelni. ((atheros), hasonló, mint lentebb a kolega panasza, ahol az ar71xxx-en még jól működő ledkiosztást is képtelenek voltak helyesen átvinni az ath79xx-re...)
Ugyanakkor vannak itt többen is, akik snapshot-ot használják, és még nem tapasztaltak hibát.
A saját scriptemet mutattam meg, ami működik. Értelemszerűen évekkel ezelőtt LEDE doksiból néztem ki, hogyan kell paraméterezni a make-et. A letöltést, a *.tar.xz kibontását, a saját konfigok bemásolását manuálisan szoktam csinálni, ezek nincsenek a scriptben, pár másodperc az egész.
Azt az: ./openwrt/scripts/feeds install -a kiadása után a ./openwrt/feeds/packages/ könyvtárban találod.
Ui.: Au OverlayFS miatt az image-ból törölt csomagok tárhelye nem szabadul fel, ezért is érdemes saját image-t buildelni.
Igen, ha image-ben volt, viszont, ha külön telepítetted, akkor ki lehet *gyomlálni.
*(A triviális, opkg remove parancs nem fogja teljesen leszedni, mert ez nem dpkg, ezért, a függőségeket, csak a (fel)telepítési irányba veszi figyelembe, törlésnél fent hagyja a függőségként felrakott lbeket, mert már "nem emlékszik" rá, hogy miért tette föl, de ésszel+kézzel kigyomlálható.)
Az Openwrt csapattól azóta sem volt hivatalos bejelentés. Nem tudom mi lehet az oka annak, hogy már .4-es verzió is van amikor a .3-as verzió sem lett bejelentve. Erről nincs infó a levlistán.
Aki jót akar magának szépen megvárja amig bejelentik. Lehet még mindig valami gond van a build folyamatban.
Azt nálatok is csinálja, hogy ha a wifi "kliens" módban van (sta), és elveszti a jelet az Ap-val (pl: másik szobába viszem), akkor a router egy kicsit vár, majd teljesen reboot-ol, nem pedig csak a wifit indítja újra.
Ez valami bug, vagy fícsör?
Nem bírok rájönni.
TP-Link (és társai) routerekkel próbáltam, mindkettőben AR9331-es CPU van.
Nekem úgy tűnik, mintha az újrapróbálás közben lefagyna a kernel, és valami watchdog újraindítja az egész routert
(ami ez esetben kevésbé baj, de mitől fagyhatna le a kernel?)
Próbáltam Lede 17.01.3-mal, és a legújabb OpenWRT 18.06.4-gyel, viszont ami irtó szar, hogy 18.06.4-esen, van, hogy ez a "lefagyás" a rendszer teljes felállása előtt történik, és ilyenkor nem következik reboot, hanem ott marad teljesen kifagyva a rendszer.
Van itt valaki fejlesztő, aki meg tudja ezt erősíteni?
A szituációt kétféleképpen szimulálom:
1) Az Ap több szobával arrébb van, ezért, ha az adott kliensen letekerem az antennát, akkor elveszti a jelet.
2) Az Ap-re bejelentkezve ssh-val, és a wifi up / wifi down parancsok kiadásával, az antenna a helyén marad
Három készüléken tesztelem:
TL-WR740N/v4 és 8devices Carambola2 (devboard) és 8dveices Centipede
Mindháromban AR9331-es cpu van, a flash és RAM méretei eltérőek csak.
Egyelőre gyári openwrt-vel próbálkozok, sajátmagam forgatott image-vel nem.
A TP-linket egy 12V/1.5A tápról, a 8dev.-eket pedig egy 5V/10A-re beállított labortápról hajtom.
Három kiadással próbálkoztam: lede-v17.01.4, openwrt-v18.06.01, openwrt-v18.06.04
Amit eddig észrevettem: TL-WR740N/V4
1) esetén ha letekerem az antennát, akkor egy idő után (15-45 perc) rebootol.
itt csak ssh-val vagyok belépve, de ott a logread-ból nem jön ki semmi érdekes, csak az "associated"..."authenticated"..."deauthenticated" üzenetek jönnek, annak megfelelően, hogy éppen mi van a jelszinttel.
Majd egy ilyen szekvencia végén: [ 7485.214174] wlan0: authenticate with b0:48:7a:xx:xx:xx [ 7485.229669] wlan0: send auth to b0:48:7a:xx:xx:xx (try 1/3) [ 7485.288274] wlan0: send auth to b0:48:7a:xx:xx:xx (try 2/3) [ 7485.341778] wlan0: send auth to b0:48:7a:xx:xx:xx (try 3/3) [ 7485.399774] wlan0: authentication with b0:48:7a:xx:xx:xx timed out
(több perc elteltével, minden változatlanul hagyva) egyszerűen csak lefagy a router, azaz hiába nyomok bármilyen gombot, nem reagál, majd kb 5mp múlva a ledek kialszanak, és újraindul a rendszer, wifi, lan ledek újra világítanak, és minden megy előről. Újraindulás után elkezdi keresni a wifit, nem találja, nem csatlakozik, de ezt követően csak kb egy óra elteltével van újabb újraindulás, ha van, de elég ritka a többihez képest.
A 2)-es esetben, viszont nincs újraindulás, a rendszer fut rendben tovább, ha visszaadom a jelet az Ap-n, akkor visszaáll minden, dhcp-n kap ip-címet, ping megy, stb.
----------------------------------------------------------------------------------------------------------------------
UPDATE:
Van újraindulás ebben az esetben is, csak még ritkábban 2-3 óra után.
----------------------------------------------------------------------------------------------------------------------
8devices Centipede/Carambola2
Itt van serial konzolom, így több mindent látok.
Ez itt szinte kész halál, a Carambola2-n van RP-SMA, tekerhető antenna, de szinte nem számít, hogy fent van-e vagy lent, apró különbség van csak.
- Ha fent volt, majd letekertem, akkor a fentivel megegyező log bejegyzések után kb 5mp-vel már lefagy (sehol nem reagál), és indul is újra. A újraindulás közben, ha nincs jelszint, akár az antenna, akár a kikapcsolt Ap miatt, akkor két eset van, az egyik, hogy egy 20mp működést követően indul is újra, és ez ismétlődik 30-40másodpercenként, a másik, hogy lefagy, egyszerűen kialszik a ledek (összes, ami nem fixen a tápra van kötve), és úgy marad, nincs többé újraindulás.
- Ha fent marad az antenna, és az a Ap kapcsol, akkor az újraindulások gyakorisága halványan csökken, 30-40mp működé helyett 60-90mp működéseket produkál.
Viszont a slusszpoén az, hogy ha az IPv6-ot mindenhol akkurátusan kikapcsolgatom, (wan, wan6, lan, wwan interfészeken) akkor az újraindulások gyakorisága drasztikusan lecsökken, de még mindig nem szűnik meg, 5-15perc működés van, lefagyás előtt, függetlenül, hogy az 1) vagy 2)-es szituáció áll-e fent.
Nézegettem a hardvert, egyetlen egy szembetűnő különbség volt, a TP-Link a 3v3 ágba egy 470uF/16V kondit tesz, a 8devices csak 22uF/16V, ezért ide is beforrasztottam egy 470uF/16V-osat párhuzamosan, de lényegi változás nem történt.
Ezen kívül még jó lenne tudni, hogy a cpu-ban a rádiós ágon A/B/C vagy F osztályú végerősítő van, mert az befolyásolhatja a letekert antenna miatti RF "visszarúgást".
Ide tartkozik, hogy TP-Link max outputnak 17dBm-et, a 8devices 20dBm-et enged, de nem lehet egyértelműen visszavezetni RF problémára a fentieket, mert ha Ap módba kapcsolom, akkor mindhárom eszköz tökéletesen, stabilan üzemel, a fentiek csak kliens (sta) módban jönnek elő.
Kernel pánikot szinte képtelen voltam elkapni, de a nap során kb 2x, random módon mégis előfordult.
Az eszköz egy Carambola2 volt, nyomta a reboot loop-ot, én lestem, hogy mi sül ki belőle, konfighoz nem nyúltam, nem változott semmi közben.
A dolog úgy nézett ki, hogy először fölcsatlakozott az Ap-re, rendben ment minden, ekkor lekapcsoltam az Ap-t, emiatt, a "szokásos" kb: 40mp után fagyott, majd újraindult, de az Ap-t nem kapcsoltam vissza, így nem tudott mihez csatlakozni, emiatt megint fagyott, megint újraindult, és ez ment körbe-körbe, majd kb a harmadik újraindulás után kernel pánik, majd ismét úraindulás, pánik nélkül, sokszor.
A kernel panic utáni indulásnál látszik, hogy az alábbi sornál akad meg, és fagy le a dolog: [ 30.570555] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
(nem volt felkapcsolva az Ap)
És, ha laszedem az IPv6-ot az interfészekről, akkor az, mint írtam jelentős javulást eredményez, akkor már csak 60-90 percenként van a reboot.
-------------------------------------------------------------------------------------------------------------------
Update:
Itt van még egy log, ennél többet nem bírok kipréselni belőle.
Mindig itt áll meg, innen még kb 10-15 másodpercig, él, ha entert ütök, akkor válaszol, utána vagy egy reboot következik, vagy kialszanak a cpu-vezérelt (nem fix tápra forrasztott) ledek, és annyi.
Tápfesz ki-be után újra mindez előről. https://pastebin.com/eFTR2Qhh
-------------------------------------------------------------------------------------------------------------------
Update #2:
Megfigyeltem közben, hogy az újraindulás után a webes (luci) felületen hiába kattintok a wifi scan-ra,
nem talál semmit, kézzel kiadva >> iw wlan0 scan kiírja a hálózatokat, de sokszor resource busy-t dob.
A lede-v17.01.1 -el tesztelve kevesebb az újraindulás.
Ezután az Ap-n nyílttá tettem a wifit, és most szinte 0-ra lecsökkent az újraindulások száma.
(kb: óránként van 3db)
-------------------------------------------------------------------------------------------------------------------
Update #3:
Ha lekapcsolom a watchdog-ot
>> ubus call system watchdog '{"magicclose": true}'
>> ubus call system watchdog '{"stop": true}'
Akkor a wifi jel elvesztése után végleg lefagy, nem indul újra.
(tehát az újraindítást valóban a watchdog csinálja)
-------------------------------------------------------------------------------------------------------------------
Update #4:
Egyértelműen megfigyelhető a különbség, aközött, hogyha az Ap-n beállítok egy WPA2 jelszót, vagy nyitottá teszem a hálózatot, ha nyitott, akkor kb. tizede az újraindulási-gyakoriság a jelszóval védetthez képest.
Ezen kívül van egy pici különbség a SNAPSHOT (r10486-98d04dc4cf) és a v18.06.4 között, a SNAPSHOT javára.
------------------------------------------------------------------------------------------------------------------
Nem lehet, hogy árnyékot kergetsz, és simán csak a RAM-od fogy el? Szerintem csinálj magadnak egy webes felület nélküli image-et, tedd fel rá, ssh-n keresztül tudod szerkesztgetni a config file-okat. Editor sem kell, kimásolod a host-ra, ott megszerkeszted a kedvenc editorodban, majd visszamásolod a router-re.
Lehet, de nem bírok rájönni, hogy hol, ezért sem jelentettem be eddig az openwrt-nél, mert lehet, hogy én rontok el valamit.
A hiba röviden összefoglalva, ha kliens/sta módban egy Ap-hez volt csatlakoztatva, és elveszti a jelet, akkor a 8devices eszközei 1-2 percen belül újraindulnak.
Ilyenekkel, hogy image-csere, csak azt tudtam befolyásolni, hogy az újraindulás mikor történjen meg, de azt, hogy elmúljon, azt nem. Újraindulás után/közben, ha ismét nem találja, akkor 1-10 percen belül egy újabb újraindulás következik be. Az újraindulás előtti 5-15 másodpercben pedig teljes fagyás, semmire sem reagál, még serial consolon sem. A TP-link-nél is bekövetkezett újraindulás, de "jóval (15x) ritkábban" a 8dev-hez képest.
Lehet, hogy kifogy a memóriából, de hiába nézem top-pal, ott nem látni semmit, egyszerűen lefagy és újraindul.
Ugyanakkor nem hiszem, hoyg a Luci ezt befolyásolná, a tp-linken ugye, nincs luci, a 8dev-en van, de ott több flash-om is van.
Egyetlen állapot hozott változást, mégpedig, ha nyitottá tettem a wifit, de az újraindulás akkor sem szűnt meg, csak nagyon megritkult.
Én arra tudok gondolni, hogy ezek a wifi-scriptek, amik az OpenWRT-ben a wifi kezelését végzik túl sokszor, vagy hibásan, és az akasztja ki.
Összehasonlításképpen a hardverek: TP-Link: 740N/v4 4MB flash, 32MB RAM, AR9331-AL3A cpu 8devices: Carambola2: 16MB flash, 64MB RAM, AR9331-AL1F cpu 8devices: Centipede: 16MB flash, 64MB RAM, AR9331-AL1A cpu
Próbáltam forgatni egy image-t a 8devices github repójából, de mindenféle C-ben írt hibától kihal a fordítás.
Az lényegtelen, hogy hol. Ahol a kernel sarokba szorul, s az out of memory killer kinyír egy létfontosságú process-t kétségbeesésében. Egyfelől lehet az, hogy a titkosításhoz lefoglalt RAM miatt valahol már nem tudott adni a kernel, de akár lehet valóban bug, például egy memory leak. Mindig foglal, de amikor már nem kell, elfelejti felszabadítani azt.
Nekem amúgy a TL-WR842N-v3 akkor fagyott meg, ha az f2fs-re formázott pendrive-ot felcsatoltam. Nem mindig, de olykor. Biztos, hogy a RAM fogy el. Onnan tudom, mert ha nézem, mondjuk van 18 MB szabad hely. Felcsatolom a pendrive-ot, kevesebb lesz, úgy 12 MB. Utána lecsatolom, s a szabad hely a RAM-ban 30 MB lesz. Innen sejthető, hogy nem 6 MB kellett neki, csak a kernel felszabadított buffereket, hogy legyen még RAM. Ezt most végigcsináltam, ezek valós adatok. Viszont ez csak mount majd umount volt. Az az érzésem, ha használom is a filerendszert, foglal még RAM-ot, s ha az elfogy, összedől az egész.
A LuCi-ról azért beszélnélek le, mert szerintem kevés feleslegesebb dolog van a földkerekségen, mint router-re grafikus interface, viszont viszi a RAM-ot a webszerver, meg a kiszolgált tartalom, RAM-ból meg épp nagyon kevés van ezekben a szappantartókban.
Én ezt értem, de annyit azért hozzá tennék, hogy ha a kernel sarokba szorul, akkor azért szokott valami pánikot dobni, és itt az csak egyszer volt. (Egy ilyen újraindulás után egyszercsak hopp, pánik, ismét újraindult, és azóta pánik nem volt, csak rengeteg újraindulás, egyébként azt a pánikot mellékeltem feljebb.)
Kipróbálom majd luci nélkül, de mivel +32MB ram van a luci-s verzióban, kevéssé hiszem, hogy emiatt lenne.
Örülnék, ha valamelyik kernel-es kolega megmondaná, hogyan lehet a kernelt debug módba kapcsolni, hogy midnen nyűgjét kiírassa konzolra, a logread-ban nincs érdemi információ.
A másik gondolatom, hogy használj devel ágat, ahogyan én is. Ezekhez a kicsikhez a korábbi ar71xx helyett ath79 alatt elérhető már a 4.19.57-es kernel, amiben az a pláne, hogy nem kell az ópenvéertéseknek agyonpatch-elniük a kernelt, mert ismereteim szerint a vanilla tartalmazza azokat a drivereket, amelyek kellenek ezek hardware-eihez.
Nem patchelés nincsen, hanem DTB (DeviceTree Blob) van, ahol leírhatod, hogy milyen hardvered van a dobozban.
Kipróbáltam.
Ez még rosszabb, mint az ar71xx-es.
Kezdődik azzal, hogy a gpio-k fel vannak cserélve, illetve a ledek is, az eth0 led, az eth1 csatlakozón villog.
(Mondjuk a múltkor is rosszul jelentették le a gpio-t ezek az okos Litvánok...)
A wifi Ap-módban kb 20mbps-el kevesebbet tud átpaszírozni, az ar71xx 40mbps körül volt, ugyanazon a telefonon speedtesteltem.
Viszont Client (sta) módba még csak átraki sem lehet a wifit, azonnal lefagy az egész rendszer, és nem is indul újra.
Nem jár erre véletlenül @kaloz, vagy @wigyori koléga?
Hátha ők tudnának segíteni.
A LED-ek cseréje nekem is feltűnt. Egyrészt nem érdekelt, mert nem szoktam nézegetni, másrészt úgy emlékszem, konfigurációs file-ban lehet nyilatkozni, hogy melyik LED mi legyen, így szerintem ez minden nehézség nélkül javítható.
Wifiről csak annyit tudok, hogy működik, speed tesztet nem csináltam előtte és utána. Annyi bizonyos, hogy online zenehallgatás, hírek olvasgatása, oprendszer frissítése megy, a többi megint csak nem érdekel, nem töltök át Wifin petabyte-okat.
Hogymondjam, a gpio-k felcserélésén még csak-csak túl tudja tenni magát az ember, oké, kézzel kijavítom, de ez akkor is egy vicc.
Mikor megvettem a Centipede-t, a hozzávaló pdf alapján megterveztem egy hardvert, ami a gpio-n kapcsolgatja a locsolót, de amikor bekapcsoltam, kiderült, hogy egyáltalán nem azokon a lábakon vannak ahol a rendszer gondolja...
(A gyárból a Barrier Breaker (OpenWRT 14.7)-rel érkezik.)
Viszont frissítettem a LEDE 17.01.1-re, ott már nagyjából stimmeltek a gpio-k, viszont ezt a wifi-klienses kalamajkát már akkor kezdte, így akkoriban inkább LAN-on használtam.
De újabb 2 év elteltével az ember már úgy elvárná, hogy az ilyen alap dolgok, mint a wifi működjön...
Persze, én sem petabájtokat akarok továbbítani, de azért mégis, eleve egy 150megás rádiós chip-ből örülök, ha a 75Mbit/s-es sebességet ki tudok préselni, ehhez képest az OpenWRT tudott 40-et, amiből az ath79xx, pedig 25 körül koppan...
Engem egyáltalán nem zavar, ha nincs apache, vagy egyéb szofisztikáltabb szoftver az oprendszerben, de az igenis elvárható, hogy az ilyen alap dolgok, mint a Wifi működjön stabilan! Óriásléptekkel rohanunk az IoT világába, mostantól majdhogynem fontosabb az ilyen beágyazott lapkákon a wifi-kliens mód, mint az Ap.
Ezen felül, pedig kifejezett pofátlanság a LEDE részéről hogy önmagát "beágyazott operációs rendszer"-nek titulálja.
(Emlékezzünk vissza, anno azért forkolódott LEDE névre, mert a fejlesztők úgy gondolták, hogy ki akarnak lépni az IoT világába, a "router-os" szintjéről...)
(Na, hát ez így, pont nem fog menni.)
Ugyanakkor nem kizárólag a 8devices problémája ez az újraindulás, mert mint mondtam, a gyári hardverű TL-WR740N is csinálja, csak ritkábban.
(Emlékezzünk vissza, anno azért forkolódott LEDE névre, mert a fejlesztők úgy gondolták, hogy ki akarnak lépni az IoT világába, a "router-os" szintjéről...)
(Na, hát ez így, pont nem fog menni.)
Na, de azóta újra fuzionáltak, és lett megint OpenWrt. :D
Én csak azért szerettem volna, ha marad a LEDE név, mert a szétválás után a mocsárban dagonyázó, semerre sem fejlődő ág maradt az OpenWrt, a LEDE viszont haladt a maga útján, fejlődött. Tudom, hogy a fúzió feltétele az volt, hogy a LEDE dinamizmusa, managelése, fejlesztési modellje érvényesül, és azt is, hogy az OpenWrt név szavazás eredménye, mert ismertebb, bejáratottabb brand, mégis nekem a dinamizmusa miatt tetszik jobban a LEDE. A mai napig legtöbbször úgy hivatkozom rá, hogy OpenWrt/LEDE, s nem tisztán az OpenWrt névvel.
Talán az egész szakításra nem került volna sor, ha felüti a fejét soraikban a rugalmasság, kompromisszumkészség. Egy nyílt forrású projectben előadni a beképzelt kiskirályt, majd meglepődni a forkoláson és a többség távozásán nem igazán érthető dolog.
Őszintén szólva annál kényelmesebb vagyok, nem fordítok forrásból, csak saját csomagválogatás alapján csinálok image-et, ezzel egyrészt nem kell mindig opkg-val telepítgetni, illetve az overlayfs-en sem fogy a hely, ha az image-ben épp az van, ami kell.
Mondjuk abban igazad van, hogy egy pökhendi, égig érő f@szok vannak köztük.
A következő történt:
bejelentettem a hibát, rendes bug-reportban,
erre közölték, hogy az nem hiba,
erre én megírtam, hogy oké, de a ledek is rosszak,
erre elküldtek a gyártóhoz, hogy hardver hiba,
és letiltották a felhasználónevemet, nehogy legközelebb is jelezhessek...
(Merthogy nála a ledek, a ping-nél stimmelnek, de arra már nem képes, hogy rendesen letesztelje, mondjuk kihúzza a másik (eth1) kanócot, és máris világossá válna, hogy nem a levegőbe beszélek, vagy elindít egy "gyorsabb" pinget.)
Így már mindent értek. Én csak a Fedora közösségnek szoktam bugreportolni, de ők nem viselkednek destruktívan. A legrosszabb, ami történhet, hogy nem reagálnak a hibajegyre. Viszont rengeteg általam jelzett bugot javítottak, volt, amikor fordítottak kernelt, amelyet nem tettek publikusan elérhetővé, s megkértek, teszteljem. Valami wifis történet volt. Aztán amikor jeleztem, hogy hurrá, megjavult, betették a teszt repóba, majd az update repóba.
Az elképzelhetetlen a Fedoránál, hogy tiltják az account-omat - már feltéve, hogy nem kezdek trollkodni.
Az ember azért segít, mert azt hiszi, hogy jobb lesz tőle a világ, az oprendszer.
Lehet ezt korrekt módon is kezelni, nem megsértődni attól, hogy banális elírás van a kódban (a led pin-je felcserélve 14 helyett 13 van írva), de azt is elfogadom, hogy ezt a gyártónak kell javítania, mert ő küldte be rosszul, és megegyezéssel lezárjuk a hibajegyet.
De ezt a hozzáállást nem fogom elfogadni, és már csak azért is folytatom.
Debian-nak is szoktam beküldeni hibajelzéseket, érdekes ők képesek korrektül kezelni, sőt még meg is köszönik a segítséget.
Hozzászólások
Nem érdemes letölteni onnan semmit amig nem jelentik be a release-t. Pl. emiatt is:
http://lists.infradead.org/pipermail/openwrt-devel/2019-June/017808.html
Akkor vélhetően ez okozza, hogy június 17-e óta nincs devel snapshot sem ar71xx architektúrára. A routeremen 4.14.125-ös kernel van, a vanilla pedig már 4.14.131-nél jár. Meg is lepődtem, mert gyakran fél-kétnaponta van build, most meg 12 napja semmi.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
https://downloads.openwrt.org/releases/
18.06.3 és a 18.06.4 elérhető!
Inkább arról beszélj nekem, mikor lesz legközelebb ar71xx-re devel daily snapshot. Valahogy az a június 17-e nagyon réginek tűnik.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Ahelyett, hogy itt siránkoznál, forgass magadnak egyet gitből!
Tökéletesen fordul AR7xxx-re a 18.6.3, 18.6.4, és a devel is.
A forrást valószínűleg le tudom fordítani, de cseppet szomorú lennék, ha magába fordulna a routerem.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Közben kicsit körüljártam a problémát. Az ar71xx már csak forrásban létezik, nem csinálnak belőle buildet. Az egészet ath79-re migrálták, ott viszont már van 4.19-es sorozatú kernel, s ha jól értelmeztem, patchelni sem kell nagyon, a vanilla tartalmazza, amit kell.
https://forum.openwrt.org/t/snapshots-for-ar71xx-are-not-generated/39643
Lezuhanyzom, megreggelizem, aztán csinálok belőle image-et.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Nem világos, hol akadtál el, viszont, ahogy egy ilyen build-et illik levezényelni:
(A másik topikodból kiindulva)
(Pl: Ubuntu 18.04)
1)
>> apt-get install build-essential libncurses5-dev zlib1g-dev gawk gcc-multilib flex git-core gettext libssl-dev unzip python
2)
>> git clone https://git.openwrt.org/openwrt/openwrt.git
(A build során kell neki kb 10GB hely, 4-5GB RAM)
3)
>> cd openwrt/
>> ./scripts/feeds update -a
>> ./scripts/feeds install -a
>> make defconfig
(ez eddig nem fordít semmit, csak "letölti" a makefile-okat, előkonfigurálja a cuccot, ha ezeket kihagyod, a csomagválasztás során meglepetéseket fogsz tapasztalni)
4)
>> make menuconfig
(ez a csomagválasztó, itt szépen kiválasztod ami kell, de ami a legfontosabb:
--> Target System: Atheros AR7xxx/AR9xxx
--> Subtarget: Generic
--> Target Profile: TP-Link TL-WR842N/ND v3 <--
ez, utóbbi a legfontosabb, ha kihagyod, akkor az összes létező routernek legenerálja az image-t, ha eltéveszted, téglásít(hat)ja a dobozodat!)
5)
>> make download
>> make -j 8 <---vagy_ahány_cpu_szálad_van
(ekkor lefordul, a keletkezett image az openwrt/bin/ könyvtárban van, a neve ...sysupgrade.bin -re végződik.
ezt valahogy feljuttatod a dobozodra, ha van Luci, akkor ott feltöltöd, ha nincs, akkor máshogyan.
[pl: felrakod egy lokális webszerverre, és a dobozon wget-tel lehúzod a /tmp/-be ] )
6)
>> sysupgrade -kapcsoló openwrt....sysupgrade.bin <---image_neve
(Itt a kapcsolókra érdemes figyelni, ha már régóta (kb: 2-4 kiadás óta) nem volt frissítve,
akkor nem ajánlom a config fájlok (/etc/) megtartásást, mert nekem (tapasztalatból mondom)
sokszor elhasalt a visszatöltésnél, tehát a kapcsoló "-n" (No), ha ugyanaz az új builden a kiadás,
mint a dobozon lévő, akkor maradhat a config, vagyis "-c" kapcsoló. (bár nekem még ekkor is volt néhány meglepetés)
7)
>> ssh root@router_ip
Vagy Weben eléred, ha van Luci az image-ben.
Ezután jön a konfigurálás, és a scriptjeid, beállításaid visszatöltése/visszamásolása.
(ide értve az ssh root tiltását/szabályozását is)
Ha Nagyon bátor vagy:
Van egy olyan opció, hogy, ha az image fordítása előtt, te elhelyezel egy "files/" könyvtárat
az "openwrt/" -ben (git gyökérkönyvtár), akkor, az ide elhelyezett fájlokat bemásolgatja
(akár lehet config is) a megfelelő helyekre:
Pl: openwrt/files/etc/sajat.conf ---bekerül_az_image-be--> (router_gyökér)/etc/sajat.conf fájlba.
De ez utóbbit csak akkor javaslom, hogyha az adott config/script már lepróbált, és helyesen működik,
ha ez nem így van, akkor inkább appllikáld rá föl kézzel, mert akkor menet közben kiderülnek a hibák.
+1 Hasnos:
menuconfig --> Image Configuration --> Preinit configuration... mellé tedd be az X-et!
(ez azért jó, mert ha valami hiba (szar konfig/script) van a rendszeren, akkor a következő indításkor
lesz 2másodperced, hogy egy gomb lenyomásával megállítsd a boot folyamatot, és (a dobozra kapcsolt)
RS232 porton keresztül visszanyerd az irányítást a jószágod felett.
Ekkor egy "butított" konzolt kapsz, hogy Pl: sysupgrade-vel felhúzz egy új, működőképes image-t.)
Nagyon bátor vagyok, a konfig file-jaimat belegyógyítom az image-be. Igen, ennek az a hátránya, hogy ez lesz a factory default, így ha el van szúrva, kizártam magam. Tipikus példa a root ssh tiltása. Nem akadtam le, helyesebben szólva mégis: Az új ath79 architectúrára készített image olyan, hogy egyrészt nem megy a wifi, másrészt van ugyan ssh lehetőségem, de valaki megeszi a standard outputomat, így jelenleg például így tudok kernel verziót lekérdezni:
uname -r >&2
Eléggé frusztráló, de még nem záródtam ki végleg. Kérdés, mitől beteg, s hogyan lehet ezt megoldani.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
bookmarked
-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…
Szia!
Jó ez a leírás, pár kérdésem volna csak:
1. Nekünk vannak / voltak olyan routereink amik simán RC ből lettek buildelve, nem volt velük gond, valszeg nem futottunk bele bugba.
2. Hát openwrt ben nagyon sok csomag van mi az ami nincsen benne ?
3. Amennyire tudom, ha fixen beleteszed akkor benne lesz a komplett imageben, ha csak modul, akkor buildeli de csak letölthető package ként, azaz nem lesz belerakva a készülő image fájlba.
Fedora 38, Thinkpad x280
Itt is RC lenne, a 21.02 jelenleg RC3-nál tart: https://openwrt.org/releases/21.02/start
Alapból jók nekem a gyári image-k, de tennék bele wireguard-ot, illetve mindig van néhány dolog, ami nekem nem szükséges.
Nekem 19.07.7 vertió van és van benne wireguard. Ami meg nem szükséges nem rakod fel. Szerintem használd a default gyári imageket.
Fedora 38, Thinkpad x280
3.)
A fentebb elhangzó "van benne wireguard", és egyéb hasonló kijelentéseket érdemes körültekintően kezelni, ugyanis nem mindegy, hogy az ténylegesen bele van-e fordítva és magával az image-vel jön, vagy csak a System/Software oldalon listázzva látod, mint telepíthető csomag.
Tulajdonképpen ez ugyanaz a különbség, amire te is kérdezel, mivel az openwrt által közzétett image készítő scriptgyűjtemény az kb. 1-1 megfelelője annak, amit ők is futtatnak éjjelente, és aminek az eredményét látod a neten, letölthető csomagok formájában.
A lényeg ott van, hogy az OverlayFS miatt, ha valamit ténylegesen belefordítasz, az 20-30%-kkal kevesebb helyet foglal el a flash-on, mint, ha ugyanazt a csomagot az image telepítésétől külön telepítenéd. (akár a System/Software oldalon, akár kézzel, a keletkező xxx.ipk fájlt)
Ebből kifolyólag az ilyen nagyobb csomagokat, érdemes egybefordítani, és legföljebb a config fájlokat másolgatni kézzel, de persze, ha tárhelybőségben vagy, (Raspberry/SD kártya) akkor mindegy.
2.)
Ha a config fájlok érdekelnek, akkor pl. az: https://openwrt.org/downloads oldalon.
Letöltöd az xxx.ipk csomagot, kitömöríted, (hasonló, mint egy .deb csomag) és benne van(nak) a "gyári" configok,
(A mc kinyitja neked, ha más nem akarná.)
de, mivel a legtöbb csomagot a fejlesztője eredeti git repójából tölt és fordít az image készítő script, ezért általában érdemes körülnézni az eredeti helyén is.
Viszont, ha érzel magadban bátorságot, akkor lehet saját package repository-t is készíteni a gyári repók mellé, saját makefile-kkel, ha más kapcsolókkal akarod fordíttatni az adott programot, mint amit az openwrt makefile-ben alapból ad. (Azon felül, hogy a fent említett ./files könyvtárba teszel-e saját configot, vagy sem.)
(Nekem pl kellet, mert a VIM (de a többi, nano, joe is) szerkesztő syntax-highlight csak fekete-fekér változatban van benne, és kellett volna színesben is, de ehhez az kell, hogy más kapcsolókkal forduljon.)
1.)
A Szerencse kérdése.
Tényleg!
Én, általában a legutolsó stabil kiadást szoktam használni, de még a stabil verziók közötti váltást is gyakran komolyabb hajveszteséggel tudom csak átvészelni, mert olyan szerencsétlen hardware van, amit még a stabil verziókkal sem képesek normálisan kezelni. ((atheros), hasonló, mint lentebb a kolega panasza, ahol az ar71xxx-en még jól működő ledkiosztást is képtelenek voltak helyesen átvinni az ath79xx-re...)
Ugyanakkor vannak itt többen is, akik snapshot-ot használják, és még nem tapasztaltak hibát.
Nekem konfigban nem az egyes csomagok érdekel, hanem az, amit a make menuconfig összerak a buildhoz.
Nem szeretnék nulláról indulni, alapvetően megfelelne a buildhoz a hivatalos release beállításai és csomagjai, csak pár dolgot módosítanék.
Ui.: Au OverlayFS miatt az image-ból törölt csomagok tárhelye nem szabadul fel, ezért is érdemes saját image-t buildelni.
Példa:
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
https://forum.openwrt.org/t/how-to-build-with-the-official-release-conf…
https://openwrt.org/docs/guide-developer/build-system/use-buildsystem#c…
A saját scriptemet mutattam meg, ami működik. Értelemszerűen évekkel ezelőtt LEDE doksiból néztem ki, hogyan kell paraméterezni a make-et. A letöltést, a *.tar.xz kibontását, a saját konfigok bemásolását manuálisan szoktam csinálni, ezek nincsenek a scriptben, pár másodperc az egész.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Azt az: ./openwrt/scripts/feeds install -a kiadása után a ./openwrt/feeds/packages/ könyvtárban találod.
Igen, ha image-ben volt, viszont, ha külön telepítetted, akkor ki lehet *gyomlálni.
*(A triviális, opkg remove parancs nem fogja teljesen leszedni, mert ez nem dpkg, ezért, a függőségeket, csak a (fel)telepítési irányba veszi figyelembe, törlésnél fent hagyja a függőségként felrakott lbeket, mert már "nem emlékszik" rá, hogy miért tette föl, de ésszel+kézzel kigyomlálható.)
Ez érdekes. Már, hogy a release url az ar71xx -es, a snapshot pedig ath79-es.
A 18.06.4 branchelése után változtatták és a snapshotból buildel újabb megoldással vagy csak kompatibilitási okokból a régi helyre buildeli?
https://openwrt.org/toh/hwdata/tp-link/tp-link_tl-wr842n_v3
Az Openwrt csapattól azóta sem volt hivatalos bejelentés. Nem tudom mi lehet az oka annak, hogy már .4-es verzió is van amikor a .3-as verzió sem lett bejelentve. Erről nincs infó a levlistán.
Aki jót akar magának szépen megvárja amig bejelentik. Lehet még mindig valami gond van a build folyamatban.
De mi van a WPA2, WPA3 gyengeséggel? Azokkal lesz valami?
Most van hivatalos release és magyarázat arra, hogy miért hagyták ki a .3-as verziót:
http://lists.infradead.org/pipermail/openwrt-devel/2019-July/017896.html
Azt nálatok is csinálja, hogy ha a wifi "kliens" módban van (sta), és elveszti a jelet az Ap-val (pl: másik szobába viszem), akkor a router egy kicsit vár, majd teljesen reboot-ol, nem pedig csak a wifit indítja újra.
Ez valami bug, vagy fícsör?
Nem bírok rájönni.
TP-Link (és társai) routerekkel próbáltam, mindkettőben AR9331-es CPU van.
Nekem úgy tűnik, mintha az újrapróbálás közben lefagyna a kernel, és valami watchdog újraindítja az egész routert
(ami ez esetben kevésbé baj, de mitől fagyhatna le a kernel?)
Próbáltam Lede 17.01.3-mal, és a legújabb OpenWRT 18.06.4-gyel, viszont ami irtó szar, hogy 18.06.4-esen, van, hogy ez a "lefagyás" a rendszer teljes felállása előtt történik, és ilyenkor nem következik reboot, hanem ott marad teljesen kifagyva a rendszer.
Van itt valaki fejlesztő, aki meg tudja ezt erősíteni?
Kernel panic esetén rebootol az OpenWrt. A panicot kéne elkapnod (`logread -f` vagy remote logging), abból okosabb lehetsz.
Pont ez az, amit szinte képtelen vagyok.
A szituációt kétféleképpen szimulálom:
1) Az Ap több szobával arrébb van, ezért, ha az adott kliensen letekerem az antennát, akkor elveszti a jelet.
2) Az Ap-re bejelentkezve ssh-val, és a wifi up / wifi down parancsok kiadásával, az antenna a helyén marad
Három készüléken tesztelem:
TL-WR740N/v4 és 8devices Carambola2 (devboard) és 8dveices Centipede
Mindháromban AR9331-es cpu van, a flash és RAM méretei eltérőek csak.
Egyelőre gyári openwrt-vel próbálkozok, sajátmagam forgatott image-vel nem.
A TP-linket egy 12V/1.5A tápról, a 8dev.-eket pedig egy 5V/10A-re beállított labortápról hajtom.
Három kiadással próbálkoztam: lede-v17.01.4, openwrt-v18.06.01, openwrt-v18.06.04
Amit eddig észrevettem:
TL-WR740N/V4
1) esetén ha letekerem az antennát, akkor egy idő után (15-45 perc) rebootol.
itt csak ssh-val vagyok belépve, de ott a logread-ból nem jön ki semmi érdekes, csak az "associated"..."authenticated"..."deauthenticated" üzenetek jönnek, annak megfelelően, hogy éppen mi van a jelszinttel.
Majd egy ilyen szekvencia végén:
[ 7485.214174] wlan0: authenticate with b0:48:7a:xx:xx:xx[ 7485.229669] wlan0: send auth to b0:48:7a:xx:xx:xx (try 1/3)[ 7485.288274] wlan0: send auth to b0:48:7a:xx:xx:xx (try 2/3)[ 7485.341778] wlan0: send auth to b0:48:7a:xx:xx:xx (try 3/3)[ 7485.399774] wlan0: authentication with b0:48:7a:xx:xx:xx timed out(több perc elteltével, minden változatlanul hagyva) egyszerűen csak lefagy a router, azaz hiába nyomok bármilyen gombot, nem reagál, majd kb 5mp múlva a ledek kialszanak, és újraindul a rendszer, wifi, lan ledek újra világítanak, és minden megy előről. Újraindulás után elkezdi keresni a wifit, nem találja, nem csatlakozik, de ezt követően csak kb egy óra elteltével van újabb újraindulás, ha van, de elég ritka a többihez képest.
A 2)-es esetben, viszont nincs újraindulás, a rendszer fut rendben tovább, ha visszaadom a jelet az Ap-n, akkor visszaáll minden, dhcp-n kap ip-címet, ping megy, stb.
----------------------------------------------------------------------------------------------------------------------
UPDATE:
Van újraindulás ebben az esetben is, csak még ritkábban 2-3 óra után.
----------------------------------------------------------------------------------------------------------------------
8devices Centipede/Carambola2
Itt van serial konzolom, így több mindent látok.
Ez itt szinte kész halál, a Carambola2-n van RP-SMA, tekerhető antenna, de szinte nem számít, hogy fent van-e vagy lent, apró különbség van csak.
- Ha fent volt, majd letekertem, akkor a fentivel megegyező log bejegyzések után kb 5mp-vel már lefagy (sehol nem reagál), és indul is újra. A újraindulás közben, ha nincs jelszint, akár az antenna, akár a kikapcsolt Ap miatt, akkor két eset van, az egyik, hogy egy 20mp működést követően indul is újra, és ez ismétlődik 30-40másodpercenként, a másik, hogy lefagy, egyszerűen kialszik a ledek (összes, ami nem fixen a tápra van kötve), és úgy marad, nincs többé újraindulás.
- Ha fent marad az antenna, és az a Ap kapcsol, akkor az újraindulások gyakorisága halványan csökken, 30-40mp működé helyett 60-90mp működéseket produkál.
Viszont a slusszpoén az, hogy ha az IPv6-ot mindenhol akkurátusan kikapcsolgatom, (wan, wan6, lan, wwan interfészeken) akkor az újraindulások gyakorisága drasztikusan lecsökken, de még mindig nem szűnik meg, 5-15perc működés van, lefagyás előtt, függetlenül, hogy az 1) vagy 2)-es szituáció áll-e fent.
Nézegettem a hardvert, egyetlen egy szembetűnő különbség volt, a TP-Link a 3v3 ágba egy 470uF/16V kondit tesz, a 8devices csak 22uF/16V, ezért ide is beforrasztottam egy 470uF/16V-osat párhuzamosan, de lényegi változás nem történt.
Ezen kívül még jó lenne tudni, hogy a cpu-ban a rádiós ágon A/B/C vagy F osztályú végerősítő van, mert az befolyásolhatja a letekert antenna miatti RF "visszarúgást".
Ide tartkozik, hogy TP-Link max outputnak 17dBm-et, a 8devices 20dBm-et enged, de nem lehet egyértelműen visszavezetni RF problémára a fentieket, mert ha Ap módba kapcsolom, akkor mindhárom eszköz tökéletesen, stabilan üzemel, a fentiek csak kliens (sta) módban jönnek elő.
Kernel pánikot szinte képtelen voltam elkapni, de a nap során kb 2x, random módon mégis előfordult.
Az eszköz egy Carambola2 volt, nyomta a reboot loop-ot, én lestem, hogy mi sül ki belőle, konfighoz nem nyúltam, nem változott semmi közben.
A dolog úgy nézett ki, hogy először fölcsatlakozott az Ap-re, rendben ment minden, ekkor lekapcsoltam az Ap-t, emiatt, a "szokásos" kb: 40mp után fagyott, majd újraindult, de az Ap-t nem kapcsoltam vissza, így nem tudott mihez csatlakozni, emiatt megint fagyott, megint újraindult, és ez ment körbe-körbe, majd kb a harmadik újraindulás után kernel pánik, majd ismét úraindulás, pánik nélkül, sokszor.
Íme a log:
https://pastebin.com/1jUjPqaD
A kernel panic utáni indulásnál látszik, hogy az alábbi sornál akad meg, és fagy le a dolog:
[ 30.570555] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready(nem volt felkapcsolva az Ap)
És, ha laszedem az IPv6-ot az interfészekről, akkor az, mint írtam jelentős javulást eredményez, akkor már csak 60-90 percenként van a reboot.
-------------------------------------------------------------------------------------------------------------------
Update:
Itt van még egy log, ennél többet nem bírok kipréselni belőle.
Mindig itt áll meg, innen még kb 10-15 másodpercig, él, ha entert ütök, akkor válaszol, utána vagy egy reboot következik, vagy kialszanak a cpu-vezérelt (nem fix tápra forrasztott) ledek, és annyi.
Tápfesz ki-be után újra mindez előről.
https://pastebin.com/eFTR2Qhh
-------------------------------------------------------------------------------------------------------------------
Update #2:
Megfigyeltem közben, hogy az újraindulás után a webes (luci) felületen hiába kattintok a wifi scan-ra,
nem talál semmit, kézzel kiadva >> iw wlan0 scan kiírja a hálózatokat, de sokszor resource busy-t dob.
A lede-v17.01.1 -el tesztelve kevesebb az újraindulás.
Ezután az Ap-n nyílttá tettem a wifit, és most szinte 0-ra lecsökkent az újraindulások száma.
(kb: óránként van 3db)
-------------------------------------------------------------------------------------------------------------------
Update #3:
Ha lekapcsolom a watchdog-ot
>> ubus call system watchdog '{"magicclose": true}'
>> ubus call system watchdog '{"stop": true}'
Akkor a wifi jel elvesztése után végleg lefagy, nem indul újra.
(tehát az újraindítást valóban a watchdog csinálja)
-------------------------------------------------------------------------------------------------------------------
Update #4:
Egyértelműen megfigyelhető a különbség, aközött, hogyha az Ap-n beállítok egy WPA2 jelszót, vagy nyitottá teszem a hálózatot, ha nyitott, akkor kb. tizede az újraindulási-gyakoriság a jelszóval védetthez képest.
Ezen kívül van egy pici különbség a SNAPSHOT (r10486-98d04dc4cf) és a v18.06.4 között, a SNAPSHOT javára.
------------------------------------------------------------------------------------------------------------------
Nem lehet, hogy árnyékot kergetsz, és simán csak a RAM-od fogy el? Szerintem csinálj magadnak egy webes felület nélküli image-et, tedd fel rá, ssh-n keresztül tudod szerkesztgetni a config file-okat. Editor sem kell, kimásolod a host-ra, ott megszerkeszted a kedvenc editorodban, majd visszamásolod a router-re.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Lehet, de nem bírok rájönni, hogy hol, ezért sem jelentettem be eddig az openwrt-nél, mert lehet, hogy én rontok el valamit.
A hiba röviden összefoglalva, ha kliens/sta módban egy Ap-hez volt csatlakoztatva, és elveszti a jelet, akkor a 8devices eszközei 1-2 percen belül újraindulnak.
Ilyenekkel, hogy image-csere, csak azt tudtam befolyásolni, hogy az újraindulás mikor történjen meg, de azt, hogy elmúljon, azt nem. Újraindulás után/közben, ha ismét nem találja, akkor 1-10 percen belül egy újabb újraindulás következik be. Az újraindulás előtti 5-15 másodpercben pedig teljes fagyás, semmire sem reagál, még serial consolon sem. A TP-link-nél is bekövetkezett újraindulás, de "jóval (15x) ritkábban" a 8dev-hez képest.
Lehet, hogy kifogy a memóriából, de hiába nézem top-pal, ott nem látni semmit, egyszerűen lefagy és újraindul.
Ugyanakkor nem hiszem, hoyg a Luci ezt befolyásolná, a tp-linken ugye, nincs luci, a 8dev-en van, de ott több flash-om is van.
Egyetlen állapot hozott változást, mégpedig, ha nyitottá tettem a wifit, de az újraindulás akkor sem szűnt meg, csak nagyon megritkult.
Én arra tudok gondolni, hogy ezek a wifi-scriptek, amik az OpenWRT-ben a wifi kezelését végzik túl sokszor, vagy hibásan, és az akasztja ki.
Összehasonlításképpen a hardverek:
TP-Link: 740N/v4 4MB flash, 32MB RAM, AR9331-AL3A cpu8devices: Carambola2: 16MB flash, 64MB RAM, AR9331-AL1F cpu8devices: Centipede: 16MB flash, 64MB RAM, AR9331-AL1A cpuPróbáltam forgatni egy image-t a 8devices github repójából, de mindenféle C-ben írt hibától kihal a fordítás.
Az lényegtelen, hogy hol. Ahol a kernel sarokba szorul, s az out of memory killer kinyír egy létfontosságú process-t kétségbeesésében. Egyfelől lehet az, hogy a titkosításhoz lefoglalt RAM miatt valahol már nem tudott adni a kernel, de akár lehet valóban bug, például egy memory leak. Mindig foglal, de amikor már nem kell, elfelejti felszabadítani azt.
Nekem amúgy a TL-WR842N-v3 akkor fagyott meg, ha az f2fs-re formázott pendrive-ot felcsatoltam. Nem mindig, de olykor. Biztos, hogy a RAM fogy el. Onnan tudom, mert ha nézem, mondjuk van 18 MB szabad hely. Felcsatolom a pendrive-ot, kevesebb lesz, úgy 12 MB. Utána lecsatolom, s a szabad hely a RAM-ban 30 MB lesz. Innen sejthető, hogy nem 6 MB kellett neki, csak a kernel felszabadított buffereket, hogy legyen még RAM. Ezt most végigcsináltam, ezek valós adatok. Viszont ez csak mount majd umount volt. Az az érzésem, ha használom is a filerendszert, foglal még RAM-ot, s ha az elfogy, összedől az egész.
A LuCi-ról azért beszélnélek le, mert szerintem kevés feleslegesebb dolog van a földkerekségen, mint router-re grafikus interface, viszont viszi a RAM-ot a webszerver, meg a kiszolgált tartalom, RAM-ból meg épp nagyon kevés van ezekben a szappantartókban.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Én ezt értem, de annyit azért hozzá tennék, hogy ha a kernel sarokba szorul, akkor azért szokott valami pánikot dobni, és itt az csak egyszer volt. (Egy ilyen újraindulás után egyszercsak hopp, pánik, ismét újraindult, és azóta pánik nem volt, csak rengeteg újraindulás, egyébként azt a pánikot mellékeltem feljebb.)
Kipróbálom majd luci nélkül, de mivel +32MB ram van a luci-s verzióban, kevéssé hiszem, hogy emiatt lenne.
Örülnék, ha valamelyik kernel-es kolega megmondaná, hogyan lehet a kernelt debug módba kapcsolni, hogy midnen nyűgjét kiírassa konzolra, a logread-ban nincs érdemi információ.
A másik gondolatom, hogy használj devel ágat, ahogyan én is. Ezekhez a kicsikhez a korábbi ar71xx helyett ath79 alatt elérhető már a 4.19.57-es kernel, amiben az a pláne, hogy nem kell az ópenvéertéseknek agyonpatch-elniük a kernelt, mert ismereteim szerint a vanilla tartalmazza azokat a drivereket, amelyek kellenek ezek hardware-eihez.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Nem patchelés nincsen, hanem DTB (DeviceTree Blob) van, ahol leírhatod, hogy milyen hardvered van a dobozban.
Kipróbáltam.
Ez még rosszabb, mint az ar71xx-es.
Kezdődik azzal, hogy a gpio-k fel vannak cserélve, illetve a ledek is, az eth0 led, az eth1 csatlakozón villog.
(Mondjuk a múltkor is rosszul jelentették le a gpio-t ezek az okos Litvánok...)
A wifi Ap-módban kb 20mbps-el kevesebbet tud átpaszírozni, az ar71xx 40mbps körül volt, ugyanazon a telefonon speedtesteltem.
Viszont Client (sta) módba még csak átraki sem lehet a wifit, azonnal lefagy az egész rendszer, és nem is indul újra.
Nem jár erre véletlenül @kaloz, vagy @wigyori koléga?
Hátha ők tudnának segíteni.
A LED-ek cseréje nekem is feltűnt. Egyrészt nem érdekelt, mert nem szoktam nézegetni, másrészt úgy emlékszem, konfigurációs file-ban lehet nyilatkozni, hogy melyik LED mi legyen, így szerintem ez minden nehézség nélkül javítható.
Wifiről csak annyit tudok, hogy működik, speed tesztet nem csináltam előtte és utána. Annyi bizonyos, hogy online zenehallgatás, hírek olvasgatása, oprendszer frissítése megy, a többi megint csak nem érdekel, nem töltök át Wifin petabyte-okat.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Hogymondjam, a gpio-k felcserélésén még csak-csak túl tudja tenni magát az ember, oké, kézzel kijavítom, de ez akkor is egy vicc.
Mikor megvettem a Centipede-t, a hozzávaló pdf alapján megterveztem egy hardvert, ami a gpio-n kapcsolgatja a locsolót, de amikor bekapcsoltam, kiderült, hogy egyáltalán nem azokon a lábakon vannak ahol a rendszer gondolja...
(A gyárból a Barrier Breaker (OpenWRT 14.7)-rel érkezik.)
Viszont frissítettem a LEDE 17.01.1-re, ott már nagyjából stimmeltek a gpio-k, viszont ezt a wifi-klienses kalamajkát már akkor kezdte, így akkoriban inkább LAN-on használtam.
De újabb 2 év elteltével az ember már úgy elvárná, hogy az ilyen alap dolgok, mint a wifi működjön...
Persze, én sem petabájtokat akarok továbbítani, de azért mégis, eleve egy 150megás rádiós chip-ből örülök, ha a 75Mbit/s-es sebességet ki tudok préselni, ehhez képest az OpenWRT tudott 40-et, amiből az ath79xx, pedig 25 körül koppan...
Engem egyáltalán nem zavar, ha nincs apache, vagy egyéb szofisztikáltabb szoftver az oprendszerben, de az igenis elvárható, hogy az ilyen alap dolgok, mint a Wifi működjön stabilan! Óriásléptekkel rohanunk az IoT világába, mostantól majdhogynem fontosabb az ilyen beágyazott lapkákon a wifi-kliens mód, mint az Ap.
Ezen felül, pedig kifejezett pofátlanság a LEDE részéről hogy önmagát "beágyazott operációs rendszer"-nek titulálja.
(Emlékezzünk vissza, anno azért forkolódott LEDE névre, mert a fejlesztők úgy gondolták, hogy ki akarnak lépni az IoT világába, a "router-os" szintjéről...)
(Na, hát ez így, pont nem fog menni.)
Ugyanakkor nem kizárólag a 8devices problémája ez az újraindulás, mert mint mondtam, a gyári hardverű TL-WR740N is csinálja, csak ritkábban.
(Emlékezzünk vissza, anno azért forkolódott LEDE névre, mert a fejlesztők úgy gondolták, hogy ki akarnak lépni az IoT világába, a "router-os" szintjéről...)
(Na, hát ez így, pont nem fog menni.)
Na, de azóta újra fuzionáltak, és lett megint OpenWrt. :D
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Mondjuk az OpenWRT, nekem is jobban tetszik, mint az, hogy "LEDE" :)
Én csak azért szerettem volna, ha marad a LEDE név, mert a szétválás után a mocsárban dagonyázó, semerre sem fejlődő ág maradt az OpenWrt, a LEDE viszont haladt a maga útján, fejlődött. Tudom, hogy a fúzió feltétele az volt, hogy a LEDE dinamizmusa, managelése, fejlesztési modellje érvényesül, és azt is, hogy az OpenWrt név szavazás eredménye, mert ismertebb, bejáratottabb brand, mégis nekem a dinamizmusa miatt tetszik jobban a LEDE. A mai napig legtöbbször úgy hivatkozom rá, hogy OpenWrt/LEDE, s nem tisztán az OpenWrt névvel.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
No jó vicc, de ha a kb. 25 fejlesztőből 20 elmegy a fork-kal, akkor a megmaradt 5 mitől lett volna "dinamikusabb" ?
Talán az egész szakításra nem került volna sor, ha felüti a fejét soraikban a rugalmasság, kompromisszumkészség. Egy nyílt forrású projectben előadni a beképzelt kiskirályt, majd meglepődni a forkoláson és a többség távozásán nem igazán érthető dolog.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Kicsit offos hozzászólás, de neked lefordul most a dev verzióban a Dropbear ECC funkcióval?
Őszintén szólva annál kényelmesebb vagyok, nem fordítok forrásból, csak saját csomagválogatás alapján csinálok image-et, ezzel egyrészt nem kell mindig opkg-val telepítgetni, illetve az overlayfs-en sem fogy a hely, ha az image-ben épp az van, ami kell.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Szerintem Én is erre gondolok.
Make menuconfig-ba szoktam én is válogatni.
Kiválasztanád az ECC támogatást Dropbear-heZ?
Nem. Szerintem te fordítasz, én csak a már lefordított binárisból csinálok egyetlen image-et, amellyel upgrade-elem a router-t. Emígyen:
#!/bin/bash
PACKAGES='
alsa-utils
at
coreutils-base64
ddns-scripts
etherwake
f2fs-tools
f2fsck
fdisk
findfs
kmod-fs-btrfs
kmod-fs-ext4
kmod-fs-f2fs
kmod-fs-fscache
kmod-fs-vfat
kmod-ifb
kmod-ipt-ipopt
kmod-nf-nathelper
kmod-sched
kmod-sched-core
kmod-usb-audio
kmod-usb-printer
kmod-usb-storage
libsoxr
mailsend
mc
mpc
# mpd-full
nano
p910nd
pulseaudio-daemon
pulseaudio-profiles
pulseaudio-tools
shadow-su
sox
tc
uhttpd
xz
xz-utils
'
make clean
make image PROFILE='tplink_tl-wr842n-v3' PACKAGES="`sed '/^[\\t ]*#/ d' <<<\"$PACKAGES\" | tr \\\\n ' '`" FILES=files/
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Mondjuk abban igazad van, hogy egy pökhendi, égig érő f@szok vannak köztük.
A következő történt:
bejelentettem a hibát, rendes bug-reportban,
erre közölték, hogy az nem hiba,
erre én megírtam, hogy oké, de a ledek is rosszak,
erre elküldtek a gyártóhoz, hogy hardver hiba,
és letiltották a felhasználónevemet, nehogy legközelebb is jelezhessek...
(Merthogy nála a ledek, a ping-nél stimmelnek, de arra már nem képes, hogy rendesen letesztelje, mondjuk kihúzza a másik (eth1) kanócot, és máris világossá válna, hogy nem a levegőbe beszélek, vagy elindít egy "gyorsabb" pinget.)
Így már mindent értek. Én csak a Fedora közösségnek szoktam bugreportolni, de ők nem viselkednek destruktívan. A legrosszabb, ami történhet, hogy nem reagálnak a hibajegyre. Viszont rengeteg általam jelzett bugot javítottak, volt, amikor fordítottak kernelt, amelyet nem tettek publikusan elérhetővé, s megkértek, teszteljem. Valami wifis történet volt. Aztán amikor jeleztem, hogy hurrá, megjavult, betették a teszt repóba, majd az update repóba.
Az elképzelhetetlen a Fedoránál, hogy tiltják az account-omat - már feltéve, hogy nem kezdek trollkodni.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Az ember azért segít, mert azt hiszi, hogy jobb lesz tőle a világ, az oprendszer.
Lehet ezt korrekt módon is kezelni, nem megsértődni attól, hogy banális elírás van a kódban (a led pin-je felcserélve 14 helyett 13 van írva), de azt is elfogadom, hogy ezt a gyártónak kell javítania, mert ő küldte be rosszul, és megegyezéssel lezárjuk a hibajegyet.
De ezt a hozzáállást nem fogom elfogadni, és már csak azért is folytatom.
Debian-nak is szoktam beküldeni hibajelzéseket, érdekes ők képesek korrektül kezelni, sőt még meg is köszönik a segítséget.
Különben meg engedd el, a
/etc/config/systemfile-ban tudod konfigurálni, hogy melyik LED hol van a GPIO porton.tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE