OpenWrt/LEDE-ből elmúló hardware

 ( locsemege | 2018. február 18., vasárnap - 19:09 )

Csinálnék image-et TL-WR841ND routerhez, de nem tudok már nagyjából másfél hónapja. Ezt mondja:

Profile "tl-wr841-v10" does not exist!

Néztem a létező profilokat, tényleg nincs. Megszűnt ennek a router-nek a támogatása? Jelenleg 4.9.76-os kernel van rajta, de már a 4.9.77-est, s most a 4.9.82-est sem tudom feltenni. Szerencsére nekem TL-WR842N-esem van, ahhoz van még támogatás, de ehhez is nagyon jó volna. Bárki - pl. wigyori - rendelkezik erről infóval?

Másik kérdésem, hogy készül az ar71xx-hez 4.14-es kernel?

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

https://wiki.openwrt.org/toh/tp-link/tl-wr841nd
Erről van szó? Itt úgy tűnik, van működő link...

Igen, erről van szó. A hivatalos kiadások két ok miatt nem hoznak lázba. Egyrészt azok régebbiek annál, mint amit utoljára, talán január 12-én feltettem rá. Másfelől saját csomaglista és konfiguráció alapján szoktam image-et csinálni, amelyet aztán felteszek a router-re. Most az az ijesztő, hogy megszűnt a snapshotban a router támogatása, s ez némi nyugtalansággal tölt el. Elsőre betudtam annak, hogy talán elszúrtak valamit, mondom jó, megvárom, amíg lesz újabb kernel. Lett, most 4.9.82-vel csinálnám az image-et, de továbbra is ki van irtva ez a hardware. Szerencsémre a TL-WR842N-v3 routerre tudtam csinálni friss image-et, működik is. De szeretném frissíteni a 841-est is, csak nem tudom. :(


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Bocs, az nem esett le, hogy neked nem a kész bináris kell.

No, ez a tiny már jónak tűnik, lefordult, most izgulok, hogy elérem-e a tőlem néhány km-re lévő router-t...

És igen! Azt mondja, 4.9.82-es kernele van. :)


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

A 841 ultragagyi hulladék, szerintem ne sajnáld. Bruttó 5ért kapsz használt 1043nd -t, magasabb minőségi kategória.

--
debian,libreelec,openmediavault,ubuntu,windows,arch,lineageOS
zbook/elitebook/rpi3/nexus5_hammerhead

Most 842-t használok, ennek van USB host interface-e. Amikor nem recseg a hang - mint pl. ebben a pillanatban éppen -, akkor élvezhető rajta a zene. Csak ez nincs mindig így.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Az a gyanúm, megtaláltam a commitot. Olybá tűnik, él ez, csak a kevés memóriájú eszközök közé került:

ar71xx: create new ar71xx/tiny subtarget for 4MB flash devices

This new subtarget sets the small_flash flag and removes unused kernel
configuration.

small_flash removes KERNEL_KALLSYMS, which saves ~107KB in the default
configuration; removing unneeded hardware support from ar71xx/tiny saves
another ~18KB (both after LZMA).


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Lényegében megoldva. Marad a második kérdésem: várható-e hamarosan ar71xx-re 4.14-es longterm kernel?


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Ajaj, highlight. :)

ar71xx a kovetkezo (18.03) release-ben 4.9-en marad, a 4.14 pedig egy devicetree migralassal egyutt lesz megcelozva. Szerintem az utobbibol lesz me'g anyazas, de most ez a terv.

-w-

Ez a devicetree migrálás mi akar lenni? Amúgy nagyon elkeserítettél. Azért kellene a 4.14, mert a 4.9-ben van tudtommal egy USB "hangkártyákat" érintő bug, amit javítottak valamelyik 4.14 és 4.9 közötti kernelben. Így meg ökölbe szorul a fülem, nem igazán tudok zenét hallgatni. :(( Nem lehetne, hogy mégis legyen 4.14?


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Backportolhatod az USB-s fixet, patches welcome. :)

Perpill ugy nez ki, hogy minden (legtobb) supportalt device-hoz van egy mach-foobar54.c (arch/arm/mips/ath79/mach-*), amiben a hw init van (GPIO, eth, stb), es a kernel image-be mindegyik includeolasra kerul - ez olyan 300Kb-t jelent meretben. Az, hogy a DTS-re migralas hogyan tortenne - ath79-hez lenne egy alap DTSI, es arra overlay-ek, vagy minden device-hoz kulon kernel, csak es kizarolag azzal a DTS-sel, ami ahhoz tartozik -, nem tudom, nem en tolom ezt a vonatot elore, de a rendelkezesre allo 4 vagy 8Mb flash-hez kepest minden esetben jelentosen csokkenne a kernel merete.

-w-

Régebben fordítottam x86_64-re vanilla kernelt, de nem ismerem annyira - sőt, egyáltalán -, hogy bátran megkeressem a 4.14-ben a releváns részt, s kernelt patkoljak. Pedig ezért vettem USB host interface-szel rendelkező router-t. Mármint a hálózaton hang miatt. Most elkeseredtem. :( Pedig minden este ránéztem a git shortlogra, hátha van benne olyasmi, hogy ar71xx: switch to 4.14, de ezek szerint ne is várjam.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Nem nagy kunszt megpatchelni. A 4.14 és a 4.9 között nem lehet sok commit főleg nem ilyen routereken, megkeresed az adott commitot rárakod, ha nem megy rá a többit is hogy rámenjen, és fordítasz egy saját imaget.

Valami kozelebbit azert mondhatnal, hogy mi is ez.

-w-

Először írok a tapasztalatomról, utána pedig picit utánanézek, hogy ne csak a szám járjon. :)

Van egy USB host interface-t is tartalmazó TL-WR842N v3-as router-em. Ezen ugyan nem a legfrissebb OpenWrt/LEDE, de már 4.9.82-es kernellel készült snapshot, saját image az image builderrel előállítva. Az USB csatlakozóban egy USB hub (1a40:0101), amelybe egy nyomtató és egy USB-s hangkártya (0d8c:0008) van dugva. Pulseaudioval hálózaton keresztül küldöm a hangot a router-en futó pulseaudio szerverre. Ugyanakkor ez nem PA bug lesz, mert leállított PA mellett futó ALSA interface-en csatlakozó mpd is produkálja a hibát.

A hiba annyi, hogy a hang valamelyest recseg-ropog. Van, hogy hibátlan, van, hogy nagyon recseg, van, hogy még elfogadható mértékben. Valami pointer túlcsordulás, címzés hiba állhat a háttérben az alábbi miatt.

Szól a hang, de recseg, mintha bufferenként hiányozna belőle néhány ms. Ellenben, ha leállítom a lejátszást, majdnem csend lesz, de mintha az addig hiányzó tartalmak késve megérkeznének, azaz nagyon rövid, alig 1-2 ms-os darabkák kerülnek lejátszásra az amúgy már csendben. Épp, ami hiányzott, amikor még szólt a hang. Aztán, ha ezek a buffer szegmensek elfogytak, csend lesz. Így képzeld el:

1111111(0a)1111111(0b)1111111(0c)1111111(0d)0000000a0000000b0000000c0000000d

1-ekkel azt jeleztem, amikor van még lejátszás. 0a, 0b, 0c, 0d az, ami hiányzik a hangból lejátszáskor. 0-val jelöltem, amikor csend van, mert leállítottam a lejátszást. Aztán a, b, c, d-vel jelöltem, ami megjön utólag, de mintha épp ez hiányzott volna a hangból 0a, 0b, 0c, 0d helyen, amikor szólnia kellett volna. Tehát 0a, 0b, 0c, 0d helyeken van a reccsenés, szerintem csend, de azért adtam ilyen neveket, hogy hivatkozhassak arra, hogy ez olyan csend, ami késve épp lejátszásra kerül majd.

Igyekszem rákeresni a neten, de mintha azt találtam volna korábban, hogy ez kernel bug, már javítva van, de csak 4.9 után. Ezt kezeld fenntartással, nem néztem egyelőre alaposabban utána.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Ez a recsegés független a hangerőtől?
Nekem a notebookom produkálja következetesen, hogy a nagyon halk hangok recsegésként jelennek meg.

Független. Hangosabban jobban hallom. :)

A te problémád szerintem kvantálási zaj, de az a gyanúm, erről már beszéltem. Az történhet, hogy software-es a hangerő állítása. Aztán amikor annyira kicsi a hangerő, hogy az egész szinusz jel alig néhány lépcső lesz, hiszen elosztottad minden hangminta értékét mondjuk 30000-rel, de az eredmény ugye, csak egész lehet, akkor erőst kezd az egész négyszög jellel szoros rokonságba kerülni, s lesz egy rakás felharmonikusod. Valamint a halkabb részek kompletten eltűnnek, hiányoznak majd a hangból. Szóval a te problémádat értem, arra a hardware-es hangerő állítás a megoldás. ;)


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Ja, tényleg. Már szóbakerült. Sorry.

Ha azt megtalalod, hogy ezt (hogy javitva van) hol talaltad, mar az segithet.

-w-

Sajnos nyakig vagyok tennivalóval, de a válaszaidba kapaszkodom, mint egy fűszálba, szóval mindenképp írom, ha jutottam valamire!

Amúgy azért nem a desktop gép hangkártyájáról hallgatok zenét, mert így a notebookom hangját is ki tudom tenni a hangfalakra, továbbá akár a gépek kikapcsolt állapotában is tudok online rádiót hallgatni a routeren. Az meg csak script kérdése, hogy valamennyi idő múlva leállítsa a lejátszást.

Most amúgy bemutatási effektus van, tiszta, hibátlan a hang, de nincs ez mindig így. Viszont a top szerint nem a futásidő fogy olyankor el.

Szerk.:
Más: vettem egy 60 GB-os pendrive-ot, f2fs-re formáztam. Ezt is az USB hub-ba fogom dugni, s a router háttértárja lesz, így egyfelől akár zenét hallgathatok róla, de akár a munkáimról is csinálhatok backup-ot úgy, hogy az otthoni desktop gépemet nem kell távolról a routerrel bekapcsoltatnom.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Kevés ennél kínosabb eset van. Tegnap ez a verzió csúnyán ropogott, de legalább is el tudtam rontani. Most egszerre audacious, firefoxon youtube, seren VoIP alkalmazás visszhang elnyomással. Ilyenkor már elviselhetetlen szokott lenni a hang. Erre most hibátlan, egy roppanás sincs benne. Conky-n látom, hogy nagyjából 191 KiB/s-mal megy kifelé forgalom a gépemről. Ez nagyobb részt a hang a router felé. Nézem a routert, 80 % idle, pulseaudio megeszik 12 % CPU időt.

Szerintem válasszatok más szakmát. Nekem is könyvelőnek kellett volna inkább mennem, ott legalább nincsenek misztikumok. Vagy hamburgeresnek. Valahogy az elektronika, számítástechnika rendre lóvá teszi az embert. Csoda, hogy már-már lónak érzem magam? :)

Ha lesz bármilyen infóm, jövök vele, mert ez így egyre kínosabb nekem. A hiba amúgy jellemzően sokkal többször jön elő - szinte mindig -, mint ahányszor nem. Most, hogy foglalkoztam volna vele, „természetesen” hibátlan.

Szerk.: A fentieket azzal fokoztam, hogy a notebook-omról wifi-n is stream-eltem hangot a routerre. Tehát ment zene a desktop gépről UTP kábelen több kliensről is és wifi-n a notebook-ról is. A hang még így sem esett szét, csak esetenként, amikor a wifi kapcsolat átmenetileg gyengélkedett, az a hang elakadt, de ez természetes, ez nem hiba. A rádiós kapcsolat természetes velejárója. A router-en a pulseaudio megevett 25 % CPU időt. Amúgy meggyőződésem, hogy csak véletlenül volt most jó. Tegnaphoz képest annyi a változás, hogy mindkét számítógépen már 4.15.4-es kernel van. De szerintem ez irreleváns.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Mi ez a bug amugy? Mi ar71xx/mips74kc routeren, USB-s stereo hangkartyat hasznalunk, amire shairplay segitsegevel kerul kikuldesre a kontent.

---
Apple iMac 27"
áéíóöőúüű

Nekem mips_24kc. Ez a shairplay micsoda, hogyan működik? Keverni tud több gépről? Hangerőt lehet a desktop-on állítani? Kiváltható vele a pulseaudio?


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Apple Airplay kompatibilis szerver. Lovesem sincs, hogy nem Apple kornyezetben hogyan tudod hasznalni, nalunk ez nem szempont.

---
Apple iMac 27"
áéíóöőúüű

Nem volt még időm, most épp a hűtőmet olvasztom le, kajám az erkélyen a hóban... :)

Viszont 4.9.85-tel ugyanúgy recseg a hang. Hogy ne lehessen a pulseaudio-ra fogni, az most nem fut, mpd-vel alsa interface-en hallgatok zenét. Az előbb elindítottam, recsegett-ropogott, aztán megállítottam, majd újabb play után most jól szól. Keveset kerestem, de nem találtam meg azt a forrást, ami arról szólt, hogy ez állítólag kernel bug, s valamikor 4.9 után javították. Lehet, a commit-okat kellene böngésznem.

Szerk.: további kellemetlenség, hogy valaki kitalálta a fejlesztők között, hogy nem kell az mpd-full csomag, csak ki lett öntve a fürdővízzel a gyerek is. Az mpd-mini viszont csak a leírása szerint tud stream-elt, http és https médiát kezelni, valójában nem. Mivel viszonylag semmitmondó volt a hibaüzenet - nem tudta dekódolni, amit kellett volna -, megnéztem, mp3-at lejátszik-e. S igen, egy f2fs-re formázott pendrive-ról simán játszotta le az mp3 file-okat. De http-n keresztül nem megy neki az mp3. Mellesleg mpd-full még tudta.

Jó, hogy spóroltok a hellyel, de legalább azt tudja a szerkezet, amit a description ígér. És még akkor is rezeg a léc, ha nincs választási lehetőség, és a diétás változat épp azt nem tudja, amit kellene. Az úgy viszont nem jó, hogy diétás, de még azt sem tudja. Lényegében használhatatlan most az mpd-mini. Mpd-full meg nincs. :(


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Mindig ez a verziohajhaszas :D

Van olyan routerem ami meg whiterussian-el megy :D

Fedora 26, Thinkpad x220

S hogy implementaltad az elmult par ev bugjait egy internet facing eszkozon?

Nem troll, kivancsi vagyok.
Backportolsz rendszeresen?

Ez az egesz csak hype. Mikor NSA es tarsai mindent latnak :D Szóval kb sehogy. Ehhez képest senki nem törte meg, senki nem jelzett hibát stbstb. Így ez is csak megerősíti, hogy hype az egész security :D

Fedora 26, Thinkpad x220

Azt kérdezte, hogyan implementáltad a bugokat. Nos, mivel nem implementáltad őket, így neked azok a hibák sajnos kimaradtak :D

Tenyleg :D Akkor azért nincsen hiba :D

Fedora 26, Thinkpad x220

Már legalábbis azt hiszed, hogy senki se törte meg :)
Ezt kijelenteni akkor is elég merész, ha amúgy minden up2date...

Amíg feladatát ellátja, addig annyira nem érdekes, hogy megtörték-e vagy sem. Ebből kifolyólag se érdekes az up2date.

Fedora 26, Thinkpad x220

Hát igen, az ilyen hozzáállás miatt van tele a net botnetekkel, spammer gépekkel...

Ez így van, viszont senki nem fizet az utógondozásért, és mivel senki se szeret ingyen dolgozni a kör bezárult.
Amennyiben beleveszed a karbantartást nyomkövetést stb az árba, azt nem nagyon fogják megfizetni, vagy azt választják ami olcsóbb és értelemszerűen nincsen benne a karbantartás stb.

Ügyfélnek 1 a lényeg minél olcsóbb, legyen és működjön.

Sajna én is szeretném ha nem így lenne, de a gazdasági szempontok sokszor fontosabbak, főleg az kis gazdasági szereplőknél.

Fedora 26, Thinkpad x220

Az utóbbi idők biztonsági problémái kapcsán pont volt egy jó okfejtés erről. Konkrétan a régebbi alaplapokra vajon ki lesz -e adva javított bios.
A következtetés: a felhasználók és a cégek közösen felelősek azért, hogy minden szar.
Mert, ha választani lehet, hogy támogatás vagy olcsóbb ár, akkor a felhaszánlók többsége az olcsóbbat veszi. Innentől kezdve pedig a cégek olcsó szart árulnak támogatás nélkül. Persze az olcsó relatív, hiába drága, ha pici rajta a profit.