Hirdetés
- Klaus Duran: HP wifi nyomtatás+ win11.
- sziku69: Fűzzük össze a szavakat :)
- Luck Dragon: Asszociációs játék. :)
- sziku69: Szólánc.
- Brogyi: CTEK akkumulátor töltő és másolatai
- Gurulunk, WAZE?!
- Sub-ZeRo: Euro Truck Simulator 2 & American Truck Simulator 1 (esetleg 2 majd, ha lesz) :)
- ubyegon2: Airfryer XL XXL forrólevegős sütő gyakorlati tanácsok, ötletek, receptek
- Magga: PLEX: multimédia az egész lakásban
- eBay-es kütyük kis pénzért
-
LOGOUT
OpenWrt topic
Új hozzászólás Aktív témák
-
janos666
nagyúr
válasz
janos666
#19111
üzenetére
Hazahoztam, 740N v4.23. Miközben az UART-ot forrasztogattam, beugrott, hogy létezik ezekhez custom web-failsafe U-Boot is. De ezen úgy látszik, hogy nem az van. Ha nyomva tartott reset-el kapcsolom be és várok pár másodpercet (míg abbamarad a villogás), mielőtt felengedem, akkor semmi sem jön a terminal-ba (ha hamar felengedem, akkor végül ugyan az történik, mint ha nem is nyomtam volna).
Ha csak simán bekapcsolom, akkor zagyvaság van a terminálban, de itt [link] írtak alapján ez normális. Ugyanakkor hiába küldözgetem neki a tpl parancsot, bootloop-ban van, és 7E1 beállítással is zagyvaságot látok a terminálban (másfélét, de még mindig nem felismerhetőt, viszont ugyan az ismétlődik, így gondolom nem elektromos probléma). -
janos666
nagyúr
válasz
dethroner
#19110
üzenetére
Na, csodás. Leforgattam a friss 23.05.2-ből a régi konfigot, ami 23.05.0-rc3 verzióval működött a kütyün, de most sysupgrade után nem érem el a dobozt távolról. Most már valószínűleg kifutott a szabad helyből, hogy elférjen az overlayfs. Hozhatom haza és piszkálhatom UART-on.
-
janos666
nagyúr
válasz
dethroner
#19108
üzenetére
Ha visszaolvasol itt a nevem alatt, nemrég összeszenvedtem egy OpenWRT 23.05.0 "buta AP" build-et. Nem őriztem meg, miután telepítettem a dobozra, mert úgy voltam vele, hogy "életemben utoljára piszkáltam ezt az öreg dobozt" (így is drukkolgattam neki, hogy működjön frissítés után, mert veszélyesen kevés szabad terület marad a flash-en).
De linkeltem a build config-ot, ha tudsz/akarsz magadnak forgatni 23.05.2 forrásból.
Nincs benne se tűzfal, se dnsmasq, stb, szóval csak AP-nek jó, router-nek nem. -
janos666
nagyúr
válasz
vargalex
#19087
üzenetére
A reklámok is videók, úgyhogy igen. (Azt hiszem sima statikus/GIF reklámok nincsenek.)
Lehet, hogy nem próbáltad mostanság a YouTube-ot blokkolók vagy Premium nélkül.
Akár reklámal indul, félbeszakít vagy 10 percenként, aztán reklámmal zárul.
Bekeményítettek, mert csökken a bevételük (szívogatja el a TickTock, stb). Egyrészt több a reklám, másrészt panaszkodik a blokkolókra.
Én végső esetben yt-downloader MPC-HC kiegészítővel fogom használni, vagy sehogy, de fizetni tuti nem fogok, mert úgymond "háttértévézés" szerűen használom (elindítom, aztán közben netezgetek / babrálgatok, és néha nézek rá, ha grafikont/táblázatot mutatnak, vagy visszatekerek, ha érdekes volt valami pár percig). Ha minden ilyen hülyeségre előfizetne az ember, az simán elvinne egy magyar minimálbért. -
janos666
nagyúr
válasz
kiborg
#19077
üzenetére
Nekem ez van a router (nem OpenWRT) dnsmasq-jához: [link], de inkább azért, hogy mobiltelefonokon se nagyon legyenek reklámok (egy böngésző plugin jóval több mindent tud tiltani, mint egy IP/URL alapú blacklist a router-en).
A PC-men van uBlockOrigin a Chrome-hoz (mobil verzión nincs rá lehetőség, csak pár más mobil böngészővel), és feldobálta a reklámszűrő figyelmeztetést a YouTube úgy egy héten át. Aztán nemrég valamiért abbahagyta, és működik. Nem tudom, hogy az uBlockOrigin frissült, vagy a Google adta fel, hogy úgysem fizettem elő, mikor pár napra teljesen letiltott már (akkor egyszerűen átugrottam a tartalék FireFox-ba, amiben nincs semmi plugin). -
janos666
nagyúr
I. Miért látom ezt ˇ a top listán, ha így van beállítva az időszinkronizáció LuCi-ban?
/usr/sbin/ntpclient -i 600 -s -l -D -p 123 -h 0.openwrt.pool.ntp.org
(A DHCP szerver is 192.168.1.11-et hirdet. A RouterOS AP-k el is fogadja tőle és működik.)
A LuCi esetleg valamilyen más ntp klienst konfigurál? (Ez egy custom build forrásból.)II. A másik, hogy (ugyan ezzel a custom build-el) segfault-ol a DAWN.
(Amúgy kell ez manapság bármire azon kívül, ha szeretném látni a listáját LuCi-ban?)III. Leforgattam a hAP AC^2-kön már futóéból kiindulva átszabott .config-al SXT Lite 5 r2-re is az OpenWRT-t (csak átállítottam a target-et, és kicseréltem az ath10-et ath9-re, de kb. ennyi), de nem éledt fel a ramdisk-ről boot-olva.
Eleve másképp nézett ki a pxserver log. AC2-kön kiírta, hogy küldi az initramfs file-t, aztán feléledt a kütyü. Itt pedig csak spam-elte, hogy kéri tőle a kütyü a bootp-t és ACK-zza, de a filenév elő sem jött a log-ban. Előbb-utóbb leállt a pxserver-ben a sok bootp sor spam, de nem értem el az OpenWRT-t, viszont a RouterOS sem jött vissza, amíg nem áramtalanítottam (a "try-ethernet-once-then-nand" beállítással bootolni szokott a RouterOS, ha nem talál bootp-t).
Ez egy kényes oszlopon van, úgyhogy a serial log olvasás kizárt (ha boot-olna az OpenWRT ramdinsk, még akkor is hezitálnék, hogy merem-e flash-elni is, de ki azért ki akarom próbálni, mert ROS-al van egy rakat radardetect minden csatornán).Mondjuk kicsit zavarban vagyok afelől, hogy pontosan mi is a target és a CPU arch.
A AR9344 CPU elvileg mips 74k, de a .config-ban ezt látom:CONFIG_DEFAULT_TARGET_OPTIMIZATION="-Os -pipe -mno-branch-likely -mips32r2 -mtune=24kc"
Én ezt felülbíráltam azzal, hogy-O2 -pipe -mtune=74kc
Talán ettől nem boot-ol? (Bár ahogy értem, az mtune-tól még futnia kéne máson is.) -
janos666
nagyúr
válasz
vargalex
#19044
üzenetére
Ilyesmire gondolok (de még szebb lenne LuCi-ban 3D grafikon formában, vagy akár 3.5D waterfall grafikonként). Mi a csomag neve, ami hasonló?
-
-
janos666
nagyúr
Valami fura és komoly bug-ba futottam. Hozzáadtam a WLAN_IoT interfészeket ugyan úgy, mint a korábbiakat (egyelőre csak LAN-ra bridge-elve, semmi VLAN), és azóta mindkét AP elérhetetlen a web interfészen és ssh-n is, viszont az új SSID-khez is tudok csatlakozni.
Próbáltam áramtalanítani őket, de nem változott semmi. Ebből szerintem már csak nyomógombos reset-el jövök vissza (ami gáz, mert patch-elnem kellett kézzel hostap beállító script-et is az eszközön a /lib mappában, és nem forrásból forgattam ezekre).Szerk.: Ah! Meg vannak. Más IP címet kaptak a DHCP szervertől. De hogy miért...?
-
janos666
nagyúr
válasz
vargalex
#19020
üzenetére
Kösz, ez elsőre tényleg egyszerűnek tűnik.
Viszont a "dumb AP" nálam azt jelenti, hogy a Firewall/DHCP/DNS/stb nem fut, vagy még csak telepítve sincs az AP-re, illetve nincs WAN interfész se, minden csak össze van bridge-elve. Tehát ezt igazából talán tovább tartana beállítani és az AP CPU/RAM terhelését növelné, nem a router-ét (ami egy x86 gép, szóval ott halál elenyésző bármi).A másik megoldás akkor szétszedni egy (vagy akár több) ethernet interfészt a router-en és az AP-(ke)n is két VLAN interfészre: _main és _IoT.
Az AP-(ke)n hozzáadni egy(-egy) új WLAN_IoT interfészt a rádió(k)hoz. A régi WLAN megy a VLAN_main-re, WLAN_IoT a VLAN_IoT-re bridge-be. Semmi Firewall/DHCP/DNS...Router oldalon a VLAN_main megy a régi LAN bridge-bre, ha több VLAN_IoT is van, akkor ezek mennek egy új bridge-be (előrelátóan akkor is, ha egyelőre egy csak egy szál VLAN_IoT megy rá, mert ki tudja, hogy sikeresen lefedi-e a ház összes IoT eszközét egy AP/rádió 2.4GHz-en "legacy B" módban, főleg, hogy a padlástér egyik sarkára tervezem, hogy az 5GHz a kertet fedje).
Annyi kérdés marad, hogy mi kezeli router oldalon a br_IoT-t, mert jelenleg stateless tűzfalszabály NAT-ol amiatt, hogy a belső hálózatról is elérhető legyen a gép a WAN címekkel is (így meg lehet adni fixen mindennek egy aha.ddns.net címet, és működik kint is, bent is). Erre talán van más megoldás is, de ez volt a legegyszerűbb, hogy:-A POSTROUTING -j MASQUERADE
Amíg benne volt az-i br0, addig bentről nem működött az aha.ddns.net címzés. Bár tudom, hogy a fentitől valami elegánsabbal kellett volna megoldani. Amíg ez a fenti opció él, addig végül is NAT-olni fog a router mindenhonnan mindenhova, ahová kell. Egyedül egy új tűzfalszabály kéne, hogy pl. 192.168.2.0/24-ből nem érhető el más, csak a WAN.
Valami ilyesmi ezekhez?-A INPUT -i br_IoT -j REJECT-A FORWARD -s 192.168.2.0/24 -i br_IoT -j ACCEPTMondjuk lehet, hogy inkább a router-en fogok IoT-ket DHCP-vel ellátni, mert egyszerűbb, mint két dnsmasq-ot futtatni a router-en (miután megnéztem, nem tudok egyetlen dnsmasq folyamattal egyszerre két LAN-t is ellátni, ha nem ugyan abban a tartományban vannak).
Sőt, lehet, hogy hagyom őket ugyan abban a tartományban, mint a br0, és azt a két eszközt külön kezelem, tehát pl. kizárólag ennyit szúrok be:-A INPUT -i br_IoT -j REJECTés kész. Gondolom már így sem lesz elérhető a br0 a br_IoT-ről akkor sem, ha mind192.168.1.0/24, vagy ebben tévedek?De még rugalmasabb lehetne, ha a WLAN_main a fizikai interfésszel lenne bridge-elve router-en és AP-n is, és csak egy szál VLAN lenne, ami a router-en és AP-n is a WLAN_IoT-re bridge-el. Így akkor is működne a WLAN_main, ha ezt a tartalék AP-t átviszem bármi más tetszőleges helyre (jelenleg erre használom). Ez így működne?
-
janos666
nagyúr
Az "Otthoni hálózat és internet megosztás" topic-ban több kérdést kaptam, mint választ.
Ha akarok egy új AP-t, amin van két SSID (az egyik csak 2GHz, a másik csak 5GHz-en):
- egy elszeparált link a buta "okoseszközöknek" (amiknek rövid jelszó / WEP kell)
- egy, ami az elsődleges LAN-t szórja
Akkor 1 vagy 2 kábelt kell húznom a router és a WiFi AP közé? (Az AP-n OpenWRT fut.)
Minél kevesebb újdonság nélkül akarom összehozni, lehetőleg a leg alapabb dolgokkal (iptables, bridge config, stb, nem mindenféle x-level tunneling, ha nem muszáj). -
janos666
nagyúr
válasz
janos666
#18978
üzenetére
Nagy nehezen csak sikerült összehozni TP-Link TL-WR740N v4-re a 23.05.0-rc3 verziót úgy, hogy még a LuCi is működik és a konfiguráláshoz is maradt elég szabad terület. Még a memória is elég. Viszont csak "buta AP" módban működik (nincs routing, de még FT se).
LuCi státusz, .config, kernel diff + make fix. (Ha 0.01% kell valakinek, tölthetek fel .bin-t is.)
Nem próbáltam ki, hogy az LTO tényleg segít-e méretet csökkenteni (emiatt kell belenyúlni pár Makefile-ba is), de -Os mellett elvileg igen (és akár teljesítményt is javíthat: win-win).
Viszont ez így elsőre nem fog lefordulni az OpenWRT hülyeségei miatt. Kidob egy libustrem-mbedtls hibát. Átmenetileg engedélyezni kell a libustream és libmbedtls-t, leforgatni mindent, aztán visszaállítani a .config-ot (amiben ez nincs benne), és akkor jó.
Sysupgrade-et nem próbáltam, de nem hiszem, hogy ehhez még valaha hozzányúlok.
-
janos666
nagyúr
válasz
stopperos
#18977
üzenetére
Nekem a
make kernel_menuconfig CONFIG_TARGET=subtarget
után ki volt választva az arch/cpu, és az mbeded opciók, de valamiért a -O2 -t küldött volna a GCC-nek és ki volt pipálva az összes NIC driver, ami x86_64-en is.
Most így néz ki a kernel és a project .config diff-em, de a LuCi így nem fér be.
De
#kikommentelve rakta be a sok "not set" sort. Miért mutatott *-ot?
A kernel subtarget helyett target kellett volna aCONFIG_TARGET-be? -
janos666
nagyúr
válasz
stopperos
#18975
üzenetére
Eszembe jutott min lehet legtöbbet spórolni gond nélkül: a kazalnyi ethernet driver a kernel konfigban (még a 10+ Gbps szerver NIC-ek driver-ei is benn vannak alapból, ez még az x86_64 gépemen is zavart, hogy minek, ott is kigyomláltam, ami nem kell).
Ha még a busybox-os paramétered is átveszem, akkor talán LuCi is befér majd.
A make menuconfig-ban engedélyezni kell a Base system / bridge-t, vagy azért van alapértelmezésben kikapcsolva, mert más csomag/script kezeli? (Bocs, hogy másodjára kérdem.)
-
janos666
nagyúr
válasz
stopperos
#18970
üzenetére
Ha a 22.03-ba még a LuCi is befér, akkor lehet, hogy inkább azzal próbálkozok.
Sikerült a 23.05.0-rc3 -at is beszorítanom úgy, hogy a kernel_config-ban is kikapcsoltam pár dolgot (pl. IP forwarding), ami nem kell egy "buta AP"-re (LuCi-ról nem is álmodtam már erre). Viszont attól félek, hogy ha felrakom, akkor nem fogom tudni konfigurálni, mert nem lesz elég szabad hely elmenteni a konfigurációs file-okat, vagy már eleve ott megáll a firstboot, hogy létre sem tudja hozni a jffs2 filrendszert (valamikor ~10 éve, mikor legutóbb magamnak forgattam kódból történt már ilyen). Mivel a meglévő conf verzió nem kompatibilis, így azt sem tudom beleégetni.
Tényleg... a make menuconfig-ban engedélyezni kell a Base system / bridge-t, vagy azért van alapértelmezésben kikapcsolva, mert más csomag/script kezeli? (A kernelben meghagytam a Q bridgeing-et).
-
janos666
nagyúr
válasz
xabolcs
#18965
üzenetére
Persze, nagyjából azt csináltam, mint itt is. Pontosabban végiglépkedtem a menuconfig-on, majd a kernel_menuconfig-on, és kikapcsoltam mindent, amit lehetett és valószínűleg nem kritikus, aztán újra átfésültem, hogy felszabadult-e valami, hogy azt is ki lehessen kapcsolni.
Azt hiszem esélytelen, mert ugye még az overlayfs-nek is hagyni kéne némi helyet, hogy el tudja menteni a config file-okat (hacsak "be nem égetem" azt is valahogy, de...).
-
janos666
nagyúr
válasz
janos666
#18960
üzenetére
Megvan: az uhttpd-t nem rántotta be semmi, amit bepakoltam. Persze az opkg whatdepends a telepítése után is azt mondja, hogy az uhttpd-től semmi sem függ. Csak úgy jöttem rá, hogy diffmerge-ben összevetettem a referencia és custom manifest-eket, és gyanús volt, hogy hiányozhat az az uhttpd. (az uhttpd-mod-ubus-t fel sem raktam).
Így működik a Luci, egyedül a firewall oldal üres, de nem fagy le, mikor megnyitom. -
janos666
nagyúr
válasz
vargalex
#18949
üzenetére
Hú, de jó lenne ehhez az ImageBuilder-hez egy manuconfig a dependenciák miatt.
Vagy legalább kezelhetne * karaktert a PACKAGE listából (pl. PPP egyszerű kiirtásához).
Legalább egy órán át nyálaztam a referencia manifest file-t és az opkg depends 'akármi' listákat, hogy miként tudom a legrövidebb PACKAGE listával összehozni, hogy működjön a Luci firewall nélkül. Feldobtam az AP-kre, és nem működik. (ssh, wifi megy, Luci nem)
Már a luci-light is berántaná a firewall-t, de nem minden luci-app-*, vagy luci-mod* ránt be mindent, ami ahhoz kell, hogy egyáltalán működjön a Luci.
Ha már alapértelmezésben tűzfalazva van a WAN port, akkor igazán egyszerűbb lehetne kigyilkolni a firewall-t.
Szerk.: Oh, most megtaláltam a DISABLED_SERVICES-t. Ez talán jó lesz úgy indítani, hogy ki van kapcsolva a tűzfal.
(Most azon is gondolkozom, hogy egy 4MB tárhelyes WDR740N-et is frissítések 2018-as verzióról távolról, amin nem lehet már továbbvinni a config-ot, ezért akartam inkább kivizsgálni, hogy ki is gyaluljam a tűzfalat, mert 4MB nem sok...)Már nem emlékszem: Alapértelmezésben ugye minden interfészen hallgat az ssh, illetve dropbear, és csak a tűzfal tiltja le WAN felé?
-
janos666
nagyúr
Na akkor még egy... Hogy lehet kigyilkolni a tűzfalat ImageBuilder-el?
Mert hogy ez nem elég: -firewall4 -luci-app-firewall Pedig:opkg whatdepends firewall4Root set:firewall4What depends on root setluci-app-firewall git-23.208.40260-9504081 depends on uci-firewallluci-light git-23.024.33244-34dee82 depends on luci-app-firewall
és a luci-light nincs se kiválasztva, se valami más által berántva a csomagba.
Azt már próbáltam, hogy átrendezem a PACKAGE= sorrendjét, de nem segített, hogy előbbre hoztam a luci szót, mint a fenti két minuszos szót.
(Abba már bele se menjünk, hogy miért firewall4 és nem csak firewall.) -
-
janos666
nagyúr
válasz
vargalex
#18945
üzenetére
Igen, pont most jöttem rá, mikor ránéztem a méretére, és újra elolvastam a leírását más hostapd csomagoknak is (összeállt, hogy a hostapd-common az csak apró kiegészítő).
Ettől még kicsit kesze-kusza így elsőre.Viszont már abban sem vagyok biztos, hogy a wpad-mbedtls jó-e a .11 k,r,v,w set-hez.
Azt sem értem, mi a különbség a wpad és a wpad-XXXssl közt. Mit használ a "sima"?
A wpad méretben nagyobb, így gondolom abban is van "valami" TLS/SSL képesség...? -
janos666
nagyúr
válasz
janos666
#18943
üzenetére
Na, szóval beszúrtam jó helyre a log_level-t, de a system log-ban nincs nyoma a 'sae-mixed'-el problémás táblagép MAC címének, mikor az AP-k 'sae-mixed' módban vannak.
De kezd már kicsit felbőszíteni az OpwnWRT és a seamless roaming...
Ugye lecseréltem a wpad mini verzióját full-ra az OpenWRT WiKi / DAWN leírása szerint. Most pedig látom a log-ban, hogy ügyesen a hostapd-t használja a rendszer.
Az alapcsomagban benne van a hostapd-common és wpad-mini, egyik AP, másik station módhoz.
Szóval lényegében hiába cseréltem le a wpad_mini csomagot full-ra, nem is használta az AP egyik wpad csomagot sem.A másik, hogy a LuCi engedte bepipálni a "Generate PMK locally" opciót, mikor a sae-mixed módot választottam (ott WPA2/WPA3-mixed néven), az OpwnWRT fórumon pedig azt írja valaki, hogy ez SAE módban nem is működhet, mert nem ismeri minden AP a PMK-t. [link] -> Szóval ez most egy dilemma számomra, hogy mi is történik ilyen beállításokkal.
Most szerintem törlöm a hostapd-common csomagot és visszaállok psk2-re, hogy ne kelljen foglalkoznom a PMK generálással (de közben azért megnézem, hogy mit alkot a táblagép sae-mixed módban hostapd-common helyett wpad-al).
-
-
janos666
nagyúr
válasz
Archttila
#18941
üzenetére
Semmit. Fogalmam sincs mit ronthattam el, mert most már semmi sem csatlakozik, mióta megint visszaraktam 'sae-mixed'-re. Egyedül az /etc/config/wireless file-t piszkáltam terminálból vi-vel. Most átnézem, és minden korreknek tűnik. A LuCi szerint fut minden rádió, de egyetlen eszköz sem ugrik fel rá.
Bedobtam a két AP tartalmát DiffMerge-be, és csak a csatornaszámok és txpower térnek el, amivel kizártam a véletlen elgépelést.
Komplett reboot nyilván megvolt. -
janos666
nagyúr
Friss OpenWRT-ben mi áll legközelebb a RouterOS "bridge" + "station bridge" módhoz?Állítottam már be relayd-t ismerősnek, de csak azért, mert ráfanyalodtam (két inkompatibilis TP-Link router, ami gyári FW-vel nem tudott repater/bridge lenni, és az egyikre nem volt OpenWRT elérhető). Régen használtam WDS-t, de azt sem leányálom belőni. Melyik most a javasolt viszonylag korlátolt erőforrású N-es eszközökhöz?
Már meguntam, hogy a kültéri Mikrotik SXT-k állandóan radart detektálnak, pedig megnéztem a térképet, és nem néznek radarra (legalább is publikus polgári radarra) a specifikált nyílásszöggel. Régen "super-channel" módban voltak (éveken át sohasem jöttek ki panaszkodni hatóságok), de valamikor frissítettem, és nem emlékszem, hogy melyik verzióra kéne visszamenni, hogy legyen super-channel (ha le lehet még tölteni egyáltalán azt a verziót). De amúgy is tisztább lenne, ha üzemelne a radar detect, csak nem túlérzékenyen.
-
janos666
nagyúr
válasz
vargalex
#18910
üzenetére
Mivel dual-band, és konkrétan az egyik olyan AP orra alatt sem csatlakozik, ami alacsonyabb számú 2GHz csatornán van, így ezt tartom legvalószínűtlenebbnek.
Nem paranoiából van engedélyezve a WP3 is (úgysem számít, ha vannak aktív eszközök WPA2-vel), hanem azért, mert úgy rémlik, mint ha valahol azt olvastam volna, hogy bizonyos roaming feature-ök csak WPA3-al (így nyilván csak az azt használó eszközökkel) működnek. De lehet, hogy rosszul emlékszem.
Szerintem valamelyik roaming feature-el van baja. Talán a .11r-el. De azt nem akarom letiltani, mert pont emiatt váltottam RouterOS-ről (az AC^2-höz nem adtak ki wawe2 driver-t).
Nem tudom, hogy le lehetne-e valahogy tiltani külön feature-öket MAC-enként. -
janos666
nagyúr
válasz
vargalex
#18908
üzenetére
Ó, de hülye vagyok!
A WUI-t néztem el, és még azután sem jöttem rá, hogy ránéztem a saját post-omra, hogy az overlayfs tágas és majdnem üres. Kösz a segítséget rájönni a hibámra.Összesen 2 AP-n 4 rádió van, ugyan azzal az SSDI-vel, minden aktiválva a 11.k, 11.v, 11.r, mind 'sae-mixed' titkosítással (avagy WPA2-PSK / WPA3-SEA mixed-mode).
2GHz: N, HT40, csatornák: 13 és 6 (a 'legacy' mód nincs engedélyezve)
5GHz: AC, VHT80, csatornák: 36, 52
(Az egyik AP a földszinten, a másik az 1. emeleten van, egyenes vonalban nézve egy vasbeton födém és egy téglafal van köztük.)A táblagép elvileg dual-band AC-s: [link] Most LineageOS van rajta, de pont emiatt, hogy a Samsung OS-el nem működött a WiFi (csatlakozott, de aztán leszakadt és úgy maradt).
A 13 és 52 csatorn opciós AP-hez közel szokott lenni a táblagép (közvetlen rálátással). -
janos666
nagyúr
válasz
vargalex
#18906
üzenetére
df -hFilesystem Size Used Available Use% Mounted on/dev/root 4.5M 4.5M 0 100% /romtmpfs 57.8M 64.0K 57.8M 0% /tmp/dev/mtdblock8 7.7M 356.0K 7.3M 5% /overlayoverlayfs:/overlay 7.7M 356.0K 7.3M 5% /tmpfs 512.0K 0 512.0K 0% /dev# mount/dev/root on /rom type squashfs (ro,relatime,errors=continue)proc on /proc type proc (rw,nosuid,nodev,noexec,noatime)sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,noatime)cgroup2 on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate)tmpfs on /tmp type tmpfs (rw,nosuid,nodev,noatime)/dev/mtdblock8 on /overlay type jffs2 (rw,noatime)overlayfs:/overlay on / type overlay (rw,noatime,lowerdir=/,upperdir=/overlay/upper,workdir=/overlay/work)tmpfs on /dev type tmpfs (rw,nosuid,noexec,noatime,size=512k,mode=755)devpts on /dev/pts type devpts (rw,nosuid,noexec,noatime,mode=600,ptmxmode=000)debugfs on /sys/kernel/debug type debugfs (rw,noatime)bpffs on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,noatime,mode=700)Egyébként talán nagyobb gond az, hogy egy régi Galaxy Tab A nem tud csatlakozni (minden más igen, még vendégek régi alsó-kategóriás telefonjai is), de semmi nyomát nem látom a log-ban, mikor csatlakozni próbál, pedig debug level van (már alapból, mert ugye RC verzió, de a korábbi stable verzióval sem működött jól).
-
janos666
nagyúr
válasz
vargalex
#18904
üzenetére
Most 372Kb szabad 7.69Mb-ból. Mikor a kész image-re rátelepítettem a "dawn luci-app-dawn wpad-mbedtls" csomagokat, akkor azok az overlay-en valószínűleg valamivel többet foglaltak, mint most a squasfs-ben, és nem csökkent a squashfs mérete a "-dnsmasq -firewall -luci-app-firewall -wpad-basic-mbedtls" csomagok méretével. Mégis volt szabad hely.
A dnsmasq 138KiB, a firewall 47, az lici-appja 17, a wpad-basic 417 ipk-ban mérve. Ezeket most szerintem fel sem tudnám tuszkolni az overlay-re.Az viszont igaz, hogy az 23.05.0-rc2 volt, ez pedig 23.05.0-rc3, de valószínűtlennek tartom, hogy két rc verzió közt hízott volna ennyit az OpenWRT (bár nem lehetetlen). Ilyenkor már nem csak bugfixek mennek be RC időszakban?
-
janos666
nagyúr
válasz
janos666
#18902
üzenetére
Most már csak azt nem értem, hogy miért számottevően kevesebb a szabad terület, mint mikor felraktam a kész képfile-t és az overlay-re telepítettem a minimal helyett a full mbed wpad-ot és a DAWN-t (ugyebár kimaradt a squashfs-ből pár default cucc, és az extrák is ide kerültek, ahol elvileg tömörebbnek kéne lenniük, mint az overlay-en).
Bepakol olyat az Image Builder, ami nincs benne a készen tölthető képfile-ban...? -
janos666
nagyúr
válasz
janos666
#18901
üzenetére
Megtaláltam a manifest parancsot. Alapból semmi Luci-t nem pakol bele (fura, mert a készen letölthető képfile-ban van Luci).
Telepítettem ssh terminálból a Luci nevű csomagot, és működik a webinterfész.
Ezek szerint hozzá kell adni a Luci-t a PACKAGES listához akkor is, ha már van benne luci-app-*. -
janos666
nagyúr
Készítettem egy saját sysupgrade képfile-t az alábbi Image Builder paranccsal:
make image PROFILE="mikrotik_hap-ac2" PACKAGES="-dnsmasq -firewall -luci-app-firewall -wpad-basic-mbedtls dawn luci-app-dawn wpad-mbedtls"Flash-eltem a Luci webinterfészen át a config megtartását bepipálva.
Most ssh-n tudok csatlakozni (először azt hittem, hogy nem, de csak fura, hogy Linux-os gépről nem sikerült, Windows-osról igen, viszont ezt most nem igazán izgat), de a webinterfész látszólag nem működik (a Chrome azt mondja "This site can’t be reached").Fogalmam sincs, hogy ha a PACKAGE opció nélkül futtattam volna, akkor alapértelmezésben belepakolta volna a Luci-t, vagy sem, de így, hogy beleraktam egy Luci-s csomagot, feltételeztem, hogy a Luci működéséhez minimálisan szükséges csomagok mind bekerülnek. A futó OpenWRT-n listázva a telepített csomagokat ezek kerültek bele:
lua luci-app-dawn luci-base luci-compat luci-lib-base luci-lib-ip luci-lib-json luci-lib-jsonc luci-lib-nixio luci-lua-runtimeVajon mi hiányzik, vagy mi más okból nem működik a Luci webinterfész?
-
-
janos666
nagyúr
válasz
janos666
#18810
üzenetére
Amit elfelejtettem mondani, hogy a frissítés megoldotta a régi eszközökkel való kompatibilitási problémákat, mikor aktív a .11r (seamless roaming). Szóval ezért mondom azt, hogy megérte. (A Microtik úgy döntött, hogy a RouterOS-el nem hozza el erre a wave2 eszközre el a wave2 feature-öket, de az OpenWRT-vel most már végre működnek ... még ha a korábbi OpenWRT verzióval voltak is visszafelé-kompatibilitási gondok...) Szóval 3-4 évvel vásárlás után OpenWRT-vel végre megkaptam azt, ami miatt ezeket a kütyüket megvettem.
![;]](//cdn.rios.hu/dl/s/v1.gif)
-
janos666
nagyúr
válasz
janos666
#18803
üzenetére
Végül reset-eltem, de az új verziót érzésre kicsit könnyebb volt beállítani, mint a régit.
A legnagyobb nehézség az volt benne, hogy létrát és 220V hosszabító kábelt + 12V adaptert kellett használnom, mert a szűz OpenWRT (de ugyan úgy, mint a szűz RouterOS) nem engedett be a PoE WAN porton (pedig mindkét "buta AP" a PoE porton kapta az áramot és a LAN-t).Ez amúgy egy érdekes kérdés, hogy mit ért a tűzfalazott WAN por, mint PoE port RouterOS-ben és OpenWRT-ben is... Ha valaki "buta AP"-ket akar csinálni, akkor oda kell vinnie a 220->12V adaptert a dobozokhoz, míg bridge-eli a WAN és LAN portokat, vagy ilyesmi....
És a mai internet sebességekkel ki akar ilyen kütyüt valódi router-nek? HW offload NAT nélkül (ami nincs az alap OpenWRT-ben) nem tudja kiszolgálni a 300+ Mbps internetet...
Ezek szerintem egyértelműen csak "buta AP"-k, és nem router-ek...
De ha csak az alapértelemészben WAN-nak tűzfalazott port a PoE, akkor a PoE kényelmét ülik meg, legalább is a kezdő konfiguráció erejéig (ami úgy látszik, hogy nem mindig migrálható dolog az OpenWRT-nél... de a fene se tudja, talán még a RouterOS-nél sem....). -
janos666
nagyúr
válasz
janos666
#18802
üzenetére
Na végül nekiestem és bekonfigultam őket nulláról. Ami azt illeti, egyszerűbb volt, mint a korábbi verziót. Szimplán hozzá tudtam dobni a PoE-s WAN portot és a WiFi interfészeket a meglévő bridge-hez (swconfig-al úgy rémlik, hogy ez kicsit komplikáltabb volt), letiltottam a firewal és dnsmasq csomagokat, feldobtam a DAWN-t (most elsőre települt, a korábbi verzión szenvedtem a wapd verziócserével), bepipáltam a .11r-t is, és egyelőre úgy néz ki, hogy minden működik (az előző verzióval egy táblagép nem volt hajlandó csatlakozni, ha engedélyeztem a .11r-t. - bár lehet, hogy idővel, vagy ha mozogni fog a házban, akkor megint "kiakad", de most az első csatlakozást se kellett kézileg kérni tőle). Az LG TV is szépen átállt 2.4 helyett 5.2 GHz-re (régen ezt erőltetni kellett vagy külön SSID-vel, vagy MAC filterrel).
-
janos666
nagyúr
válasz
vargalex
#18794
üzenetére
Köszönöm, hogy jobban beleástad magad, ilyen szinten én már bizonytalanul bóklásztam csak a részletes changelog-ban és a forrásban.
De a kérdésem azért még áll: Van valaki workaround, ami nem full system-wide config-wipe? Pl. feltelepíteni package manager-el a DSA-t, bekonfigolni, letiltani az swconfig-ot, aztán sysupgrade config-wipe? Nélkül?
Vagy hasonló megközelítésekkel kizárom magam az eszközről akkor is, ha a WiFi-n és ethernet-en is tudok rá csatlakozni?
Tehát mi lesz egy forced upgrade után? "Papírnehezék" egy safemode resetig, vagy félig működő cucc, ami még "menthető?
-
janos666
nagyúr
Nagyjából úgy fél éve lecseréltem a RouterOS-t OpenWRT-re két Mikrotik hAP AC2-n.
Eleve valamelyik 22.xx.x verziót telepítettem és azóta frissítettem egyszer-kétszer, most 22.03.5-ön vannak.
Szeretnék frissíteni 23.05.0-rc2 verzióra, de azt írja ki piros háttérrel, hogy:Image check failed:Thu Jul 6 00:28:17 CEST 2023 upgrade: The device is supported, but the config is incompatible to the new image (1.0->1.1). Please upgrade without keeping config (sysupgrade -n). Thu Jul 6 00:28:17 CEST 2023 upgrade: Config cannot be migrated from swconfig to DSA Image check failed.És felkínálja ugyan, hogy:
Force upgradeSelect 'Force upgrade' to flash the image even if the image format check fails. Use only if you are sure that the firmware is correct and meant for your device!De nem tudom, hogy ennek mi lenne a következménye.
Google keresgéléssel olyat találtam, akinek már 21.xx.x-re frissítéskor is kiírta ezt, de olyan régi verzió ezen az eszközön sohasem volt. Szóval téves hibaüzenetnek tűnik.
Még annyit tudtam kibogozni, hogy a switchconfig a gond, de miért vagyok most "legacy" verzión? A csomagkezelő keresőjét használva se az swconfig, se a DSA kulcsszó nem hoz elő semmit.
Nem használok VLAN-t, egyszerű "buta WiFi AP" mind a kettő (mindkettő ethernet kábellel bekötve). -
janos666
nagyúr
válasz
xabolcs
#18321
üzenetére
Belenéztem a syslog-ba, de nyomát sem láttam (az alapértelmezett log level-el) annak, hogy csatlakozni akar a táblagép. Viszont most kikapcsoltam a .11r-t minden rádión, és így gond nélkül csatlakozik (azt még korai lenne megmondani, hogy a telefonom fog-e szakadozni).
Csak épp így gyakorlatilag csökkent a funkcionalitás a ROS-hoz képest (ahol a CAPsMan csinált valamiféle roaming gyorsítást).
Egyedül a mobility domain-nek adtam hasraütésre egy számot a 11.r beállításoknál (persze mind a 4 rádión ugyan azt), mert a többiről ötletem sincs, hogy mi alapján lehetne jobb értéket találni az alapértelmezettől. Szükséges lehet azokat is piszkálni, vagy egyszerűen felejtsem el a .11r-t, míg kiöregednek a viszonylag öreg készülékek (legalább 2-3 év). -
janos666
nagyúr
válasz
janos666
#18312
üzenetére
Katasztrófa az OpenWRT. Egy Samsunk Galaxy Tab A (N-es dual-band WiFi) egyáltalán nem tud csatlakozni, a Samsung S9 telefonom pedig random eldobálja a WiFi-t internetes hanghívás közben (olyan helyen a házban, ahol effektíve csak az egyik AP-ra lát rá a telefon, mert 3 fal és 1 födém van a másik AP és a szobva közt).
-
janos666
nagyúr
válasz
xabolcs
#18311
üzenetére
Kösz, de ehhez ugye már OpenWRT-nek kell futnia a dobozon...
Érdekes módon, ha a bridge-hez adom hozzá az eth1-et, akkor működik a PoE WAN portról is a DHCP-s LAN (mióta utoljára OpenWRT-t láttam, azóta máshol van a bridge config, de közben megtaláltam).
Kíváncsi leszek, hogy működik ezt a .11r roaming a CAPsMAN-hez képest.
Kár, hogy a web interfészen nem írja, hogy melyik kliens milyen titkosítást használ (most mixed módba tettem). Bár nem hiszem, hogy elhagyhatnám a WPA2-t. -
janos666
nagyúr
válasz
janos666
#18309
üzenetére
Na csodás, átraktam az interfészt a "br-lan"-ról eth1-re (az eth0-nak ugyan az volt a MAC címe, mint az alapértelmezett br-lan bridge-nek, ennek viszont más), és most elérhetetlenné vált (legalább is nem találom a DHCP szerverem listáján, hogy kért és kapott volna IP-t).
[Igen, "DHCP Client"-re volt állítva a br-lan interfész már korábban, és az egyik LAN porton át ez már működött is így, míg le nem cseréltem az interfész alatt az eszközt.]Kezd derengeni, hogy miért hagytam hátra örökre az OpenWRT-t pár éve, és lett minden ROS...
-
janos666
nagyúr
válasz
janos666
#18308
üzenetére
Reddit-en olvastam egy random üzentben (nem igazán bízom a hitelességében, de mindegy...), hogy az OpenWRT driver-e tudja a wawe2 funkciókat, úgyhogy telepítettem az OpenWRT-t az egyik AP-re.
Ugyanakkor az OpenWRT-s wiki oldal tartalmával ellentétben (legalább is miután kitöröltem az alapértelmezett WAN és WAN6 interfészeket, mert nem router-nek, hanem csak WiFi AP-nek használom ezeket a dobozokat) nincs két VLAN, csak egy, és a Switch konfig oldalon csak 0-4 portok konfigurálhatóak, az 5-ös PoE-s (eredetileg mindkét firmware-ben WAN) port nincs listázva, ami komoly probléma, mert a PoE porton át kap áramot (és nyilván nem akarok most nekiállni szerelgetni, és vagy külön vinni oda az áramot, vagy behúzni még egy UTP kábelt).
Hogy tudnám bridge-be tenni az összes portot?
-
janos666
nagyúr
Feladtam a várakozást, hogy a Mikrotik hAP ac^2 router-ek megkapják-e végül az új "wifiwawe2" driver-t (a Qualcomm adatlap szerint a chipset AC wawe2-es, és valószínűleg elférne a kis 16Mb-os ROM-ban is az új driver, ha nem a ROS7 alapcsomag mellé kéne telepíteni, hanem eleve csak ez lenne a ROS7-ben, vagy lenne külön "mini" csomag a wawe2-ből, amiben nincs 10-20 driver, csak ami az adott eszköznek kell), így elkezdtem nézelődni, hogy mit tud ma az OpenWRT, de a google-el nem nagyon találtam rá választ, hogy az OpenWRT IPQ-4018 driver-e mit tud (MU-MIMO, stb...).
-
janos666
nagyúr
válasz
Pepe1984
#1644
üzenetére
Én az openwrt-18.06.2-ar71xx-tiny-wnr2000v3-squashfs-factory.img file-t próbáltam feltenni a gyári updater-el, és azóta bootloop-ban van: kivillan minden egy pillanatra, ég a sárga másodperceken át, kigyullad a 2-es sárga LAN és a zöld (valami?) LED egy másodpercre, aztán kezdi elölről.
Esetleg az NA végződésű IMG kellett volna, vagy másik gyári firmware-ből kellett volna indulni? (Fogalmam sincs, mikori kiadás volt rajta, nem tudom frissítgette-e a régi tulaj. Nem hiszem.)
Te megoldottad végül? -
janos666
nagyúr
Itt most én vagyok hülye, vagy a menuconfig?
Balra oldali verzió úgy állt elő, hogy átmenetileg áthelyeztem másik mappába a .config file-t, a jobb pedig úgy, hogy bennhagytam a régit, amit korábban már módosítgattam.
Valahogy nem látom át, hogy baloldalt miért van kötött módon kijelölve ez a modul, miközben ugyan azok a "selected by" kapcsolóállások láthatóak a jobboldalon is, ahol nincs kijelölve még kézileg sem.
Azért kezdtem el így átlapozni, mert hibásan kezdett működni a rendszer, ha a régi config file-ommal forgatok egy képfile-t.
-
#6053
janos666
nagyúr
sesomaru1989
#6052
janos666
nagyúr
válasz
sesomaru1989
#6052
üzenetére
Bocs, félreérthető ez a hozzászólásom az előző nélkül.
Csak akkor nem működik az 5Ghz-es WiFi, ha kézileg állítok össze egy egyedi kernel konfigurációt (make kernel_menuconfig). Tehát a fordításhoz használt kernel beállításaimban van valahol a hiba. Azt a paramétert keresem, ami hiányzik vagy nem kéne odatenni, ha minden más jó, csak az 5Ghz-es WiFi nem (és nem a PCI-E driver az, mert látja és kommunikál a chip-el a SoC, csak nem tudja rendesen konfigurálni/működtetni).
Ilyenkor nem is igazán tudom Auto-ra tenni, mert nem engedi konfigurálni, hanem magától hullik vissza Auto módra, miután a korábbi csatornát érvénytelennek tekinti, de nincs miből válogatni, mert egyetlen csatorna sem érhető el. -
janos666
nagyúr
válasz
vargalex
#6040
üzenetére
Helo.
Igen, WDR4300 és a gyárilag NYÁK--ra épített PCI-E 5Ghz rádió (AR9580).
Lehet, hogy más a gond. Most csak abból következtetek, hogy mikor először megjelent ez a DFS opció a menuconfig-ban, akkor tapasztaltam, hogy enélkül nem működött az 5Ghz-es WiFi. Persze lehet, hogy ez csak egy fura bug volt, azóta nem próbáltam letiltani. A kernel konfigot pedig nem piszkáltam akkoriban, csak még korábban, illetve most futottam volna neki ismét.
Azért gondolom, hogy ez a gond, mert az a hibaüzenet, hogy nem támogatott a csatorna, amit a régi beállítás kér (40-es), ahogy gyakorlatilag egyetlen csatorna sem, csak auto mód mehet, ami kiválasztja a "semmi" listából a semmit, így lényegében leáll a rádió, a Wiki pedig írja, hogy sok 5Ghz-es rádiónak kell a DFS.
-
janos666
nagyúr
Próbált és esetleg sikerült is már valakinek egyedi kernel build konfiggal (OpenWRT buildroot-ból "make kernel_menuconfig", nem a sima menuconfig-on belül élerhető néhány kernel build beállítás) működésre bírni olyan 5Ghz-es Atheros WiFi rádiót, ami csak akkor hajlandó üzemelni, ha az OpenWRT menuconfig-ban be van pipálva a DFS (Dynamic Frequency Scaling) támogatás? Találtam a kernel_menuconfig-ban a debug opciók közt DFS-re vonatkozó dolgot, de annak a leírása azt mondja, hogy az egyelőre még nem csinál semmit, csak debug célokból és a jövőre készülve van ott (alapvetően elrejtve) és ugyan úgy nem indul el az 5Ghz rádió, ha bepipálom. Ettől eltekintve minden működik az így forgatott kernellel, a 2Ghz-es WiFi is, ami alapvetően ugyan azt az Atheros driver-t használja (TP-Link WDR4300).
-
janos666
nagyúr
A másik oldali készülék is tud 2.4GHz-en 40MHz módot?
Az Intel 4-es sorozatú WiFi kártyái például csak 5GHz-en tudják.
Jelerősség milyen? router közvetlen közelébe vitt eszközzel is teszteltél már?Amúgy én sem szoktam elérni 2.4GHz-en sehogy a névérték felét sem, Atheros-os router és azintén Atheros-os aptop közt, egymás mellé tett eszközökkel sem.
Az 5GHz viszont hasít még két fallal arrébb is. -
janos666
nagyúr
válasz
dash17291
#707
üzenetére
Köszönöm.
Közben megoldottam a problémát: Lementettem egy 741 v2.1-ről az mtd4-et, ami "minden az uboot és az art közt", felírtam az egészet, aztán ráküldtem a 64kb-al kisebb hagyományos firmware-t is és üzemel. Még a rádió kalibráció sem veszett el, csak az egyedi MAC címek.Viszont mostanában balszerencsét balszerecsére halmozok. Egy másik routerrel kizártam magam valahogy WAN-on át, pedig kétszer is ellenőriztem, hogy kézileg ki van nyitva a tűzfalon a 22-es port SSH-nak, mégis csak timeout-okat kapok csatlakozáskor (pingelni lehet az IP-t, arra válaszol).
Amúgy rakott már valaki össze apróbb féle 802.11s hálózatot?
Ahol kizártam magam, ott épp egy ilyet készültem összedobni WDS helyett.
Először megkockáztattam a firmware frissítést régi bacfire RC5-ről friss barrier breaker-re WAN-on át, ami simán ment. Aztán mikor LuCi-ban mondtam neki, hogy 802.11s módot kérek, akkor egyszerűen leállt a WiFi, nem látott SSDI-t a másik router, amit így már nem is érek el itthonról (de a terepen még WiFi-n igen, mert abba WAN nem megy, csak WDS kliens volt, amit még nem állítottam 802.11s-re, így fut rajta egy sima AP is).Ekkor néztem át minden más beállítást, és ezalatt szemetelgettem kicsit a tűzfal szabályokon. Valahogy ez alatt sikerült kizárnom magam WAN-on át még SSH-ról is. Így viszont már kénytelen leszek fizikailag megközelíteni azt a routert (ami eddig WDS AP volt), ami problémás.
Így nem tudom kisérletezzek-e még a 802.11s-el, vagy csak állítsak vissza egy backup konfigot. -
janos666
nagyúr
Nem is az ART, hanem az NVRAM partíciót töröltem!
64 blokkal indulunk, amiből 2 blokk az uboot
Töröltem 61 blokkot, ami eddig 63, és maradt 1 érintetlen blokk
És ahogy most csináltam egy atr backupot egy WDR4300-ason, az csak 64kb, tehát 1 blokk méret.Akkor nincs is akkora baj, mert nem az egyedi kalibrációs adatok vesztek el...?
NVRAM particiót viszont honnan tudok pótolni?
Az mit tartalmaz? Erről nem nagyon találtam leírást. Mindenhol úgy tüntetik fel, hogy uboot-firmware-art és kész, ennek a 64kb-nak nyoma sincs a wikipédiás leírásokban. -
janos666
nagyúr
válasz
vargalex
#704
üzenetére
Meg tudom még szakítani a bootolást és kapok parancssort tlp-t gépelve.
Nem erre készültem, így nem volt naplózás se, de úgy láttam végül 61 blokkot törölt ki 60 helyett. De ez sem biztos, mert akkor láttam már mindenfélét a terminál ablakban a zaj miatt. Csak tipp, hogy inkább az art-ba piszkítottam bele, mert a bootloader látszólag jó.Eredetileg ezt akartam csinálni:
erase 0x9f020000 +0x3c0000Itt az utolsó nulla helyett már kriksz-kraksz jelent meg és mire észbe kaptam, hogy baj van, már ment a törlés.
Aztán megigazítottam a kábelt, felírtam a képfilet a RAM-ból és "imádkoztam", de nem bootol többé.
-
janos666
nagyúr
válasz
janos666
#701
üzenetére
Mondjuk fura, hogy a wiki azt írja, hogy art partíció nélkül még bootolnia kéne az OpenWRT-nek, és csak a wifi nem működne. Akkor talán mindkét irányban tágabb lett a törlendő tartomány, mint szándékomban állt...?
Talán a legjobb lenne ha szereznék egy teljes 4Mb-os képfilet, amit felírnék faltól falig.
-
janos666
nagyúr
válasz
vargalex
#700
üzenetére
Gondoltam rá, hogy próbálkozzak ilyesmivel.
Egy v4.21-es 740 szállt el és van kéznél egy v2.1-es 741.
Aztán kicsit továbbgondoltam, hogy ha megoldható, akkor talán inkább egy default állapotot kéne betölteni, amiből kiindul a gyári kalibráció. Az talán biztonságosabb, mint egy másik router egyedi kalibrációja, ami talán a rossz irányba mutat.Vagy akad itt esetleg valakinél egy v4.21-es 740N router?
Gondolom még mindig közelebb lenne, mint a régi v2.1-es 741, amiben a CPU is más. -
janos666
nagyúr
válasz
vargalex
#689
üzenetére
Kösz az ifót, de ma végre meghozta a postás az adaptert.
Viszont azt is megtanultam ma, hogy nem éri meg trükközni, hogy csak szigetelőszalaggal fogatok oda egy csupasz kábelvéget forrasztás helyett (sokszor sok eszközzel csináltam már ilyet - nem azért mert nem tudok forrasztani, csak így nem látszik a beavatkozás...). Így csináltam ma papírnehezéket egy TP 740N-ből, mert hibásan kapta be az uboot parancssor, hogy meddig is akarom törölni a flash-t (zajos lett az átvitel a rossz érintkezés miatt), így szépen lekaptam róla az art partíciót is.
Itt ugye azért nem érte meg, mert az art partíció hiánya épp olyan egyértelmű, mint hogy volt-e valami felforrasztva a com pinekre, vagy sem, szóval nem csak erkölcsösségből nem próbálom majd így legariztatni (meg szerintem a számlája sincs már meg ennek).
-
janos666
nagyúr
Tudok valahogy etherneten át BusyBox parancssorból egy terminát nyitni a router soros portrtjára?
Bedöglött az USB-serial adapterem, így arra gondoltam, hogy talán a tartalék routerem soros portját használhatnám a bootloaderes felélesztéshez. (Rendeltem egy újat, de mire ideér Hong-Konból.) -
#512
janos666
nagyúr
SteveBeard
#511
janos666
nagyúr
válasz
SteveBeard
#511
üzenetére
Én port forward-al csináltam LuCi alól, de már nem is vagyok benne biztos, hogy végül elértem-e a kábelmodemet.
-
janos666
nagyúr
A yffs2 is tömörít, csak nem mindent solid archívumként, hogy egyszerűen írható legyen (végül is a squashfs-t is ki lehetne olvasni RAM-ba, frissíteni a fileokat, újratömöríteni és visszaírni, csak kevés RAM mellett lassú CPU-val nem hangzik túl praktikusnak). Ebből is jöhet az ilyen anomáliák egy része. (Nem lehet előre megmondani, hogy mekkora lesz egy file, illetve az az érték is -bár ez nem törvényszerűen, de megeshet, hogy- helytelen lehet, hogy kibontva mekkora az, ami ott most x helyet foglal.)
-
#492
janos666
nagyúr
SteveBeard
#491
janos666
nagyúr
válasz
SteveBeard
#491
üzenetére
Egyébként hogy kell beállítani a build configot, hogy legyen yffs2 képfileom?
Adta volna magát, hogy leveszem a csillagot a squasfs elől és hagyom a yffs2 előtt, de az úgy nem nyert (nem hozott létre factory és sysupgrade fileokat). -
janos666
nagyúr
válasz
Peter789
#484
üzenetére
Nekem a jffs2 lenne szimpatikusabb, ha maga a kernel is azon lenne, nem külön particionálatlan területre íródna fel LZMA-ba tömörítve. Nem tudom ezt miért nem oldották még meg, hogy mehessen így. Nekem pl. ~1.6Mb mega szabad helyem van, így szerintem elférne az a kernel ott is, és úgy sokkal szebb lehetne, ha mindent, még a kernelt is tudná frissítgetni a csomagkezelő, mint az asztali linux rendszereken. Még a flash memóriát is kímélné így, hogy a jffs2-ben van wear leveling, és nem kéne minden frissítéshez újraírni az egész területet.
Na jó, mondjuk én is csak azért frissítgetek heti szinten, mert ez az első OpenWRT-s routerem, és kisebb hobbi lett belőle, hogy játsszak a build konfiggal, csiszolgassam magamnak, stb. És ami azt illeti ebben a verzióban amúgy is mindig újraírnám a flash-t, hisz minden csomagot más GCC beállításokkal fordítok, mint ahogy a snapshot mappában vannak (saját online repót pedig csak nem csinálnék azért, hogy utána onnan frissítgethessen a csomagkezelő...).
-
janos666
nagyúr
válasz
Peter789
#481
üzenetére
Én mondjuk egy viszonylag erősen babrált konfiggal forgatok magamnak, de nekem is volt olyan AA trunk-al (még a Barrier Breaker szétválás előtt), hogy mtd-vel tettem fel (a sysupgrade-et már nem használom, mert az én build-jeimmel szerintem nem is megy rendesen), és elakadt bootolás közben (nekem egy másik csomag betöltésénel, de ugyan ilyen módon, ahogy leírtad). A QSS gombbal indított failsafe ment, de a jffs2 formázása nem oldott meg semmit (ami amúgy eleve üres volt még).
És már csak kíváncsiságból is ugyan azt a képfilet tettem fel TFTP-vel, és csodálatos módon működött, illetve legközelebb mtd-vel is sikerült a frissítés.
Amúgy meg volt egy komolyabb szerverhiba, így elképzelhető, hogy változtak a fileok. (Ha nem sikerült őket visszaállítani, akkor újraforgathatták őket, ha volt recovery, akkor lehet, hogy nem ellenőriztek minden checksumot, stb.)
Most is fura, hogy a snapshot mappa is üres, de az AA beta is beta1, pedig már beta2-nél járnak a forráskóddal... -
#479
janos666
nagyúr
fulopmartin
#478
janos666
nagyúr
válasz
fulopmartin
#478
üzenetére
Saját tapasztalataim alapján elég nagy.
-
#477
janos666
nagyúr
fulopmartin
#476
janos666
nagyúr
válasz
fulopmartin
#476
üzenetére
Ha van serial port, akkor bizonyára visszajön hibás flashelés után.
Akkor van gáz, ha ha elszáll a boot partíció is, mert akkor már JTAG kell, de első körben a gyári software-nek beadott factory képfile-os flashelés szerintem nem igyekszik majd piszkálni azt a paírtíciót. Ha bedöglik, mert hibás a build, vagy rosszul sül el valami a képfile felíráakor, a boot loader még elvileg menni fog, ami használható soros portos konzollal újbóli flasheléshez. -
janos666
nagyúr
válasz
janos666
#470
üzenetére
Körbesakkoztam: a CONFIG_USE_MKLIBS működik rosszul. A többi binary stripping mehet, de ez (strip libraries) nem. Kell valami a Transmission-nek, amit ez véletlenül kivág. (Korábban gondolom valami más programnak is kellett ugyan ez, aminél felismerte, hogy szükséges, de mióta azt kiszedtem, a transmission-nél már nem látja szükségét.)
-
janos666
nagyúr
r33174 környéről AR91xx-es routeren transmission megy nálatok?
Csak szétszórtan érek rá babrálni vele, de már egész közel voltam egy olyan konfighoz, amit szerettem volna, most viszont be van dögölve a transmission és / vagy legalábbis a web interfésze, de fogalmam sincs így hogyan tovább.
Minden olyan csomag benne van a képfileban, ami az openwrt-s wiki page és a forráskódos makefile szerint kell a transmission-nek.
Most a kernel_menuconfig-ot sem használtam, csak a sima menuconfig-ot és végignéztem már azt is, hogy a routeren futtatva is listázza az opkg a csomagokat, amik a transmission-nek hivatalosan is kellenek.Próbaképp újrafordítottam mindent az extra compiler optimalizációk nélkül is, de a transmission így sem megy (látszólag minden más működik, amit használok).
Ha frissen újraindítom, akkor bejön a webinterfész, de üres a torrentlista akkor is, ha a syslog-ba kinaplózza, hogy betöltött 8-at. Ha kiűrítem a torrents és resume mappákat, és új torrentet adnék hozzá, akkor feltölti a torrents-be, de nem jelenik meg a listán. Tehát használhatatlan, és ha kicsit babrálom, akkor le is fagy az egész.Releváns hibaüzenet nincs a syslog-ban, csak annyi még induláskor, hogy nem kapott akkora UDP buffert, amekkorát kért. - Ezt próbáltam orvosolni, de hiába adtam hozzá a javasolt változót a konfig filehoz, továbbra is kiírta.
Később, mikor teljesen megszűnik működni a web interfész, akkor sem naplóz el semmit. -
janos666
nagyúr
válasz
vargalex
#439
üzenetére
Igen, azóta sikerült is lefordítani egy működő build-et, hogy kivettem a CFLAGS-ből az msoft-float paramétert és bepipáltam a konfig menüben, hogy használjon szoftveres floating point emulálást alapértelmezettként.
De ez nem egy és ugyan az lenne elvileg?
Viszont ahogy most nézem, nem hogy javulást nem értem el az -O3 CFLAG-el, de első teszteredményre még lassabb is lett a Samba megosztás.
-
janos666
nagyúr
Megjött végre az új USB-RS232 adapterem, de ez sem az igazi, mert a Win8 ehhez sem talált drivert és csak úgy működik, ha adok neki külső tápot (ami mondjuk épp van is kivezetve a WRD4300-on, de az előző vacak ment enélkül is).
Itt van az U-boot napló, ameddig elmegy bekapcsolás után:[link]
Felfedez benne valaki egyértelmű hibát? -
janos666
nagyúr
Egyszer mikor egy WDS hálózatot csináltam, és még nem tudtam hogy kell, akkor én is belefutottam ebbe, mikor a próbálkozások idejére piszkáltam a tűzfalat.
Nekem akkor úgy tűnt, valahogy a tűzfalhoz tartozik a DNSmasquarade is, amit ha letiltasz, az ehhez hasonló problémákkal jár. -
janos666
nagyúr
válasz
vargalex
#392
üzenetére
Fasza, hogy sehol nincs még leírva hogy melyik érintkező a GND, RX, TX.
Ezzel én mindig bajban vagyok még akkor is ha itt a multiméter.
Nem akarom felégetni az utolsó mentsvárat is.
(Ja, az utolsó üzi óta háromféleképp próbáltam úgy felrakni virtuláis gépként egy XP-t, hogy lássa az RS232 adapterem, amihez nincs Vista+ x64 driver, csak XP x86, sőt, a linux kernelbe 2.6.x óta integrált driver sem hajtja meg a valóságban, csak elméletben...)
Lassan több a károm, mint az a minimális hasznos, amit reméltem, ha saját képfilet készítek. -
janos666
nagyúr
válasz
vargalex
#390
üzenetére
És erre mi a megoldás? (Akár arra, hogy feltehessem a saját képfileomat, de egyelőre elég, ha újra üzembe állhat a router.)
Nemrég linkelted Juhos Gábor adatlapját és egy régi postot a TP-LINK ethernet recovery-ről, de nem úgy néz ki, hogy ez menne most nálam.
(Végső esetre van itt elfekvőben egy RS232 adapter, de ha nem muszály inkább nem szedném szét.) -
janos666
nagyúr
Sikerült végül képfilet generálnom.
Kicsit jobban utánaolvastam a mips16 AES kiterjesztésnek, és rájöttem hogy egyrészt nagyon problémás lehet, másrészt nem is olyan jó dolog az, mint amilyennek a mips.com-on reklámozzák, így inkább letiltottam. Azóta hiba nélkül lefordult a toolchain és a képfileok is.Na de most mehetek is megtanulni az U-Boot debrick-et.
LuCi-ból akartam frissíteni vargalex csomagjáról a sajátomra. Le OK-éztam, hogy jó a checksum, mehet a menet, aztán látszólag semmi sem történt úgy 5 percig. Akkor kapott egy ki-be kapcsolást a főkapcsolóval, ami után nagyon hamar kivillan minden LED, és ennyi. Nem oszt IP az ethernet portra kötött gépre, és fix IP mellett sem nyitható sem SSL, sem Telnet kapcsolat. Vagyis szépen hazavágta.Ezt azért reméltem, hogy nem lehetséges hogy hibaüzenet nélkül elkészül a képfile, de hazavágja a routert.
Egyébként ez volt a konfig fileom és WDR4300-asra tettem fel: [link]
És ami azt illeti, én direkt úgy forgattam, hogy make -j4
-
janos666
nagyúr
válasz
janos666
#386
üzenetére
Ahh. Érdekes. Simán csak ennyi CFLAG-el lefordult:
-O3 -march=74kc
Most akkor állhatok neki egyesével visszapakolni a többi paramétert.
Arról meg nem is beszélve, hogy az ember azt hinné a march amúgy is hozzáadja a megadott CPU-hoz használható kiterjesztéseket, tehát elvileg mindegy is, hogy most utánaírkálom-e még az AES paramétereket.
Lehet, hogy a pipe zavart be valahogy az -O3-al és/vagy a -march-al együtt? -
janos666
nagyúr
Azt hiszem megvan a hiba.
A célom elsősorban a teljesítmény növelése, így az alap:
-Os -pipe -mips32r2 -mtune=mips32r2 -fno-caller-saves
helyett ezeket a CFLAG-eket adtam meg a menuconfig-ban:
-O3 -pipe -march=74kc -mips16 -mdspr2 -msoft-float
(Nem tudom, hogy a két AES kiterjesztést automatikusan is használná-e a GCC a march=74kc miatt, de elvileg baj sincs belőle, ha ideírom. A float-ot pedig csak a biztonság kedvéért írtam át kézzel a "use software floating point emulation by default" bepipálása helyett, ha esetleg az az automatika becsődölne a többi CFLAG modósítása miatt.)
Viszont úgy tűnik, hogy ezzel nem békül ki a toolchain. És ahogy nézem talán az uClibc könyvtár miatt (ki van belőle vágva olyan, ami így már kéne), de az eglibc könyvtárral is vannak egyéb gondok (ami mondjuk nem csoda, hisz a készítői szerint is erősen félkész).Fura, hogy mások nem igazán tolonganak azért, hogy a lehető leghatékonyabban fusson a kódjuk ezeken a kis CPU-kon és ne a hellyel spóroljanak. Pedig akinek sok csomag kell, az használhat extroot-ot (akár egy régi apró reklámpendrive-ra is megteszi...). Jelen esetben nekem pedig nem kell kazalnyi vacak, csak luci, torrent és samba, csak ez fusson minél gyorsabban!
Most állhatok neki kisakkozni, hogy melyik CFLAG-ről kell lemondanom.
-
janos666
nagyúr
válasz
janos666
#381
üzenetére
Még megnézem 32-bites Ubuntu 12.04.1 alól is.
Nem, még nem jöttem rá és az Ubuntu topicban sem súgták meg nekem hogy lehet Windows 8 x64 mellé UEFI módban feltenni a 32 bites Ubuntu-t (aminek a képfilejában nincs is EFI mappa, tehát UEFI boot kapa), de arra rájöttem, hogy ha felrakom a telepítőjét az egyik pendrive-omra, akkor arról telepíthetem a másik pendrive-omra MBR-el, aztán az OpenWRT mappát ugyan úgy tehetem az SSD-n már leszakított ext4 partícióra (hogy ne legyen lassú a sok apró file-al végzett művelet USB2-es pendrive-on szöszmötölve).
Remélem így jutok valahova. -
janos666
nagyúr
válasz
vargalex
#376
üzenetére
Ma megint volt időm foglalkozni vele egy kicsit.
Úgy nézem, hogy a toolchain-t, azon belül is talán MIPS-es GCC compiler-t nem sikerül lefordítani.uClibc-vel ezeket a hibaüzeneteket kapom:
libc/sysdeps/linux/mips/crt1.S: Assembler messages:
libc/sysdeps/linux/mips/crt1.S:91: Error: illegal operands `la'
libc/sysdeps/linux/mips/crt1.S:92: Error: illegal operands `move'
libc/sysdeps/linux/mips/crt1.S:102: Error: illegal operands `and'
libc/sysdeps/linux/mips/crt1.S:105: Error: illegal operands `subu'
libc/sysdeps/linux/mips/crt1.S:108: Error: illegal operands `la'
libc/sysdeps/linux/mips/crt1.S:110: Error: illegal operands `sw'
libc/sysdeps/linux/mips/crt1.S:112: Error: illegal operands `sw'eglibc-vel pedig ezt:
configure: error: the assembler must support TLS
-> És hiába állítom be (vagy épp kapcsolom ki), hogy "Enable Thread-local storage (TLS) support", ezt mindig elmondja.Próbáltam már 4.7+linaro helyett sima 4.6-os compilert választani, de azzal sem jobb a helyzet.
Tehát látszólag C könyvtár körül bibis a dolog. Azon belül az uClibc-ben nincs meg pár hívás, ami kéne nekem ide, az eglibc-nél pedig a TLS funkció hiányzik, de azzal nem tudok mit kezdeni.
(Ja, bocs ha tele van hülyeségekkel a technobaba. Sohasem tanultam programozást, csak ilyen "do it yourself" módon próbálok néha ezt-azt összehozni. Azt is inkább Windows alatt és Windows-ra...)
-
janos666
nagyúr
While the OpenWrt Buildroot was intended mostly for developers, it is still simple enough that an inexperienced end user can easily build his or her own customized firmware!
Ezt ki kéne venni a WiKi-ből, mert én most debilnek érzem magam tőle.
Igaz, hogy produkáltam már ugyan képfilet a routeremhez, de csak a szűz alap Atheros beállításokkal. Már a snapsots ftp mappából kiszedett config file-al is hibaüzeneteket kapok, amiket nem tudok kezelni: unused-but-set-variable, először a floating point emulátorra, de ha azt kiszedem, akkor valami másra, pedig egyiket sem szabadna kiszedni, illetve a GCC-nek sem szabadna beriasztani, mert nem szabadna "unused"-nek lennie (pl. nincs FPU a CPU-ban, amire fordítok). -
janos666
nagyúr
Na igen, addig azért még nem jutottam.
Kb. a konfig felét túrtam át tegnap. De ma szakítok még 5Gb-ot a Linux-nak (vagy inkább újrarakom, mert amúgy sem jó, hogy teleszemeteltem össze-vissza mindenféle pre-release csomaggal is, míg a megoldást kerestem) aztán kiderül.Olyan előfordulhat, hogy hiba nélkül elkészül a képfile, de a router megdöglik tőle?
-
janos666
nagyúr
Minden esetre van még OpenWRT-s kérdésem is.
A trunk/target/linux/ar71xx/makefile alatt átírtam a CFLAG-s részt, hogy -mips32r2 helyett -march=74kc paraméterre (vagyis kifejezetten erre a CPU-ra optimalizálja a kódot a GCC, ne csak általánosságban 32-bites MIPS-re).
Ugyan ezt el kéne még végeznem külön-külön minden olyan csomag makefile-jában is, amit hozzá szeretnék adni a képfilehoz és CPU intenzív (például samba és transmission), vagy ezután automatikusan mindenhez ezek a CFLAGS paraméterek lesznek használva?
Illetve a -march=74kc egyben lefedi a többi lehetőséget is, mint például a mips16e és DSP kiterjesztések is automatikusan használva lesznek ilyenkor, vagy ezeket még külön is adjam hozzá a CFLAGS részhez?
Amúgy... most kiadtam neki, hogy make, és szorgosan nekiállt fordítgatni nem tudom milyen konfigurációval. De érdekes, hogy csak a konfig menü nem működik, minden más lefordul...?
És hoppá! Kínomban annyi csomagot telepítettem már, hogy a 10Gb nem lesz elég. -
janos666
nagyúr
Ja, tudom, hogy az efi filenek kell 64-esnek lennie, de ezt nem tudtam, hogy a grub és kernel meg kell-e hogy egyezzen.
Ha csak úgy lerántok egy 32-bites Ubuntu ISO-t és elindítom a GUI-s telepítőt, akkor az le akarja majd cserélni a már meglévő grub2-efi x64 verzióját a CD-n lévő 32 bitesre? Vagy erre is gondoltak már, hogy a gyakorlatban szinte minden EUFI 64 bites és ezért a 32-bites ISO-ban is 64-bites grub-efi van?
-
janos666
nagyúr
64-biten hasonló hibába ütköztél, mint én?
Az a gond, hogy nekem UEFI boot módban lett telepítve egy Win8, GPT pratícióra és csak utólag szakítottam le 10Gb-ot az Ubuntu-nak (kifejezetten csak ebből a célból, hogy OpenWRT-t fordíthassak magamnak
). És az UEFI csak 64-bites EFI bootloadert tud indítani. Itt kezdődnek a problémák, hogy vajon akkor a 64-bits grub-efi is tud-e 32-bites kernelt indítani vagy sem, arról nem is beszélve, hogy az automata telepítő felülírná a grub-ot, úgyhogy manuálisan kéne telepítenem a 32-bitest, megtartva a 64-bites grub-efi loadert.
Szóval az sem lenne egyszerű, hogy intézzek egy 32-bites Linux-ot.
Esetleg Win8 alól HyperV-vel VHD-ból...? -> Az sem gyerekjáték azért... -
janos666
nagyúr
Sikerült már valakinek OpenWRT-t fordítania Ubuntu 12.04 AMD64 OS alatt?
(Frissítgetve, most már a pre-release forrásokból is kínomban.)Elszórakoztam már jó pár órát, de még sohasem jutottam el az ncurses konfig menüig.
Bénáztam pár prereq csomag beszerezésével, majd még tovább beleragadtam a csomagkezelőbe, mert vannak WARNING-ok pár csomagról, mint pl. a python-gtk (így próbáltam ezt újrarakni, régi és újabb béta verzióra cserélni, stb), aztán nagy nehezen rájöttem a google-el, hogy ezekről a WARNING-okról már volt bugreport, ami "wontfix"-el zárult, illetve hogy a hivatalos trunk mappás *.bin fileok build-txt-jében is ott vannak az én WARNING-jaim is (sőt, még több is), de láthatóan ettől függetlenül elkészülnek a képfileok, szóval itt elakadtam, mert nincs értékelhető hibaüzenet, amit kövessek.
Tehát beírom a terminálba, hogy make menuconfig, kidob pár WARNING-ot (python és dpf csomagokra) és ennyi, nem jön elő semmi konfig ablak. Az utolsó sor annyit ír, hogy nem lettek mentve a változtatásaim.
Néztem már az eredeti 4.6-os és egy 4.7-es GCC-vel is. Utóbbival csak több a hibaüzenet.
-
#335
janos666
nagyúr
Speeedfire
#334
janos666
nagyúr
válasz
Speeedfire
#334
üzenetére
Végül is a hozzászólásom megírása közben azt hiszem megfejtettem, hogy a filerendszeren kívülre van felírva "nyersen" a tömörített kernelkód. (Így nyilván nem tudja lecserélni a csomagkezelő.)
Csak azt nem tudom, hogy ezt miért lenne nehéz áthidalni, és a jffs2 képfileok miért nem eleve így kerülnek kialakításra a 8+ Mb-os tárhellyel rendelkező modellek esetén.
Gondolom azért van ez így, hogy egyrészt védettebb a kernel, de még inkább azért, hogy minimalizálják a méretet és be tudják préselni a teljes OpenWRT firmware-t 4Mb-ba is (és még maradjon is valami).
De ugye vannak már routerek 16 vagy elszórtan még sokkal nagyobb ROM-al is, amikhez szerintem megérhetné a kernelt is jffs2-re tenni az egyszerű update lehetősége miatt. (Akik nem akarnak sokféle csomagot telepíteni, azoknak kényelmes lehetne.)Vagy ha szimplán jffs2-n nem is férnének el a kernel fileok még 8Mb ROM-ban sem, akkor lehetne egy szem kernel.gz file a jffs2 felirendszerű partíción, ami így nem foglalna lényegesen több helyet (szemben azzal, mint ha sok-sok apró file lenne rajta), és ezt olvasná be a boot loader, nem RAW olvasási mód helyett.
Nem vagyok akkora szaki, hogy ezt most (főleg csak így fejben elmélkedve) megmondjam, hogy lehetséges-e, de nekem, mint "intelligens laikus" elvben nagyon is lehetségesnek tűnik. Olyannyira, hogy nem értem miért nem dolgozott még rajta senki, legalább annyit, hogy próbálkozott és kiderítette, hogy miért nem lehetséges a gyakorlatban, vagy leírta volna, hogy miként oldhatta volna meg, de szerinte közel sem ér annyit az egész, mint ami munkába került volna befejezni és inkább csinált valami hasznosabbat.
-
janos666
nagyúr
Most olvasgattam az OpenWRT wiki filesystems lapját, és belebotlottam ebbe:
"It is possible to contain the entire root filesystem on a JFFS2-Partition only, instead of a combination of both." (Eddig is tudtam, viszont szinte mindig 4Mb ROM-on kellett elférnem, tehát nem nagyon kísérletezhettem vele. Most kezdtem ezen gondolkodni, hogy a következő routeremben 8Mb ROM lesz.)
" [...] while it would allow you to upgrade the contents of the filesystem you would still be unable to replace the kernel (outside of the filesystem), meaning that a seamless upgrade between releases is still not possible!"Miért?
(Én pont ezt reméltem ettől a megoldástól...)
Van már azóta valami változás ez ügyben, mióta megírták ezt a linkelt wiki oldalt?
Lehetséges már egyszerűen csomagkezelővel frissíteni az összes komponenst, a kernelt is beleértve?Ohh...
Most, hogy ezt írom jutottam el fejben idáig (beugrott, hogy ilyet is olvastam):
"the Kernel image is first packed with LZMA, then the obtained file is packed with gzip and then this file will be written onto the raw flash without being part of any filesystem"Gondolom akkor ezért nem lehet újraírni a kernelt...?
Na, de erre van már azóta valami okos megoldás? Pl. 8+ Mb ROM-hoz optimalizált factory upgrade image, ami már a kernelt is jffs2 filerendszerben tárolja, nem RAW módban írja fel?Olyan szép lenne automatizálni, hogy rendszeresen frissítsem minden csomagot, amit tud. Pl. végigfuthatna minden hajnak 4-kor egy katalógus, majd szükség szerint csomag frissítés.
#kikommentelve rakta be a sok "not set" sort. 
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
- Sweet.tv - internetes TV
- Nem kilincselhet tovább a Tesla Kínában
- LG LCD és LED TV-k
- Okosóra és okoskiegészítő topik
- Cseresznyepiros és mokka barna Redmi Note 15-ök az újévre
- Futás, futópályák
- Philips LCD és LED TV-k
- One mobilszolgáltatások
- Canon MILC: EOS R és M topik
- One otthoni szolgáltatások (TV, internet, telefon)
- További aktív témák...
- Eredeti Microsoft termékek - MEGA Akciók! Windows, Office Pro Plus, Project Pro, Visio Pro stb.
- Vírusirtó, Antivirus, VPN kulcsok GARANCIÁVAL!
- Humble szökevények 500-2500Ft
- Számlás!Steam,EA,Epic és egyébb játékok Pc-re vagy XBox!
- Adobe Előfizetések - Adobe Creative Cloud All Apps - 12 Hónap - 15% AKCIÓ
- í kilenc! AKCIÓS PRECÍZIÓS KÉSZÜLÉK! 7670 i9-12950HX 32GB RAM 1TB SSD Nvidia RTX A3000 12GB 1 év gar
- BESZÁMÍTÁS! ASUS A620M R7 7700X 32GB DDR5 1TB SSD RX 7900 XTX 24GB ZALMAN I3 NEO EVGA 850W
- magyar billentyűzet - 172 - Lenovo Legion Pro 7 (16IAX10H) - Intel Core U9 275HX, RTX 5080
- Autós kamera eladó
- GYÖNYÖRŰ iPhone XR 128GB Black-1 ÉV GARANCIA - Kártyafüggetlen, MS3985, 100% Akkumulátor
Állásajánlatok
Cég: Laptopszaki Kft.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest