ajánljatok hálózati OS-t

Hálózati eszközök

Nagy bőgés,

A VPNfilter-ről mindenki hallott gondolom. Nem értem, hogyan is lehet ilyen mennyiségű eszköz érintett, mindenki ugyanazt a szar kódot használja?
Konkrétan Linux kernel pl, vagy mi a közös ezekben a kütyükben?
Mikrotik, Cisco, OpenWRT, miegymás...
Ezek alapján már a Debian-ban sem bízhatok?
Itt az ideje áttérni a BSD-re?
Komolyan, ne trollkodjátok szét, miben bízhat ma meg egy hálózatos?
Tudjuk, attól, mert valakinek üldözési mániája van, még üldözhetik is.
EGY ! ilyen szarral meg jó ISP sávszéllel bármit lelövök szinte...
https://www.arukereso.hu/router-c3144/tp-link/ad7200-p356392899/
Kösz előre is!
Páka,
vfero

  • 5242 megtekintés

( andrej_ v | 2018. 06. 20., sze – 07:18 )

A folyamatos fw frissítésben. :P Ahogy tudom nem pont a közös ponton támadták őket, hanem konkrét egyedi bugokon keresztül telepítettek, aztán máris adminként szaladt a kis történet. Bőgés előtt érdemes a guglin tájékozódni, vagymi.

( SzBlackY | 2018. 06. 20., sze – 07:52 )

Fentebb andrej_ már írta, hogy specifikus bugokat használt ki, de egyébként nem csak a hálózati eszközöknél, hanem minden beágyazott eszközre igaz, hogy a beágyazott fejlesztők nem tudnak biztonságos kódot írni és/vagy [többnyire és ;)] még mindig úgy gondolják, hogy a "support backdoor" egy jó ötlet (és van is benne valami, komolyabb cuccoknál a support ipari mennyiségű pénzt tud akasztani pl. egy elfelejtett jelszó kiütéséért, mert ők tudják a jelszót - csak aztán ezek a jelszavak többnyire kikerülnek a netre is... persze lehetne ezt intelligensen is, pl. betenni fixen egy darab CA certet, ami által aláírt certtel hitelesítheti magát a supportos, de az arra utalna, hogy nem szarnak magasról a security-re és hát olyat nem lehet :) ) [pont a héten ütöttem ki így egy megörökölt storage-ról az admin jelszót, élő support szerződés híjján - ha egyáltalán szóba áll velem a gyártó -, pár éves topikok alapján ezres nagyságrendű dollárnyi pénzt kellett volna fizetnem egy leállás nélkül, egy darab telnet klienssel, egy paranccsal elvégezhető műveletért...]

Ráadásul ahogy írod, a kód megosztás is megy szépen a kisebb gyártók között (nem csak router, mindenféle beágyazott eszköz, biztonsági kamerákra volt pár éve egy tök jó Black Hat előadás :) ), sajnos ugyanabban a minőségben, mint ahogy az egyedi változtatásokat megvalósítják. Így amikor az alap firmware-be bekerül mondjuk egy command injection [mert a user inputot simán át kő' adni a system()-nek, jó lesz az úgy... azonnal root vagy az eszközön és van többnyire egy busyboxod...], az onnantól kezdve minden eszközbe bekerül...

Mit lehet tenni? Szvsz. folyamatosan frissíted az eszközeidet és imádkozol, hogy a gyártója az 1-10 skálán legfeljebb idióta és nem retardált. És kívülről tiltasz minden elérhetőséget, ami nem nagyon-nagyon-nagyon kifejzetten szükséges.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Azzal egészíteném ki, hogy érdemes olyat választani, ahol láthatóan hosszabb távon lesz fw upgrade az eszközhöz. Sok SOHO routernél a konkrét eszközhöz szedhető le a fw, ami ha szerencséd van talán 1-1,5 évig frissül aztán kalapkabát. 1,5 évenként szerintem csak igen elvetemültek vagy routerbütyköldések cserelgetik a cuccot. Aztán a sok lejárt szapportos kütyü 100k számra változik zombivá a világban.

A nagyok (pl. Cisco, Juniper) már régóta alapvetően egy általános (igen, vannak mindenhol alverziók is) OS-sel csapatnak és ha el is engedik régi eszközök szapportját bőven nem 1-1,5 év van. Akik feltörekvőknél eszembe jutnak (pl. OpenWRT, Mikrotik és Ubiquity) szintén az előző mintával egy általános OS-sel nyomulnak. Valszin hibátlan fw-t egyik modellben se várhatunk el, de a hosszú távú támogatás ezeknél látszik a leginkább biztosítottnak.

Jogos, jogos. Ill. persze a szappantartót is érdemes lehet úgy megválasztani, hogy előre láthatóan jó pár évig legyen elég HW-je [leginkább flash és ram méret a korlátozó, bár nem túl gyorsan, de növekszik a rendszer mérete/memóriahasználata] egy OpenWRT/LEDE-re és persze, hogy fusson rajta :)

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Amiket írtam, hogy nem a modell, hanem a firmware érintett alapvetően. Ez elsőre rémisztőbb, hiszen jóval szélesebb körű a probléma, de ugyanakkor kijöttek a patchek is és lehet (kell) frissíteni. Ezekkel jóval nehezebb úgy járni, hogy fél évvel a router megvétele után még kijött egy valamilyen upgrade aztán annyi volt.

Most a VPNFilter kapcsán felkapott lett a jelenség, de korábban is találtak sokmindent és a jövőben is fognak. Mindíg az a kérdés, egy asztali Windows-tól egy mission critical clusterig, hogy van-e legalább bugfix support hozzá. Lásd a továbbra is Windows XP-vel kűzdőket.

Oké értelek, de holnap ha a Debian vagy a kernel forrásába tesznek bele jó helyre egy felkiáltó jelet 5 sor comment és 2 változó átnevezése után 60db tabulátorral, onnantól ugrott az is. Szóval, amit sokan használnak az célkeresztbe lesz, ergo megtörik, legyen bármi szitázva a felületére.
Igaz?
Kösz!
vfero

Xiaomi routereinél el kell ismerni, hogy kiemelkedik nemcsak az átlagos brand kínai gyártók közöl de Asus, Netgear, stb soho routerei közül is.
https://www.digiportal.hu/xiaomi-mi-router-3g-teszt/

Bár azok alapján amit írtál neked inkább egy PC&pfSense vagy PC&openWRT saját összerakású router felelne meg és még az ára is elég jó.
Már volt erről fórum és Trey is tesztelte párszor

Normális HUP-ot használok!

Most vettem anus routert. A gyári sw webgui-ja olyan rémesen bóvli bazári dizájnnak tűnik, mintha vmi noname kínai szart vettem volna. Még az angol szövegeken is érződik, h. vmi alapfokú angol-nyelvvizsgás kínai írta/fordította, sok helyen nyelvtanilag helytelen, sztaki szótáras (boccs sztaki) tükörfordításos szóhasználattal (gyk. olyan érzés mint a "fuckup with marmalade" == lekváros bukta).

Jah, igen, kinek van jövőlátó varázsgömbje, h. az én konkrét tipusomra mikor szűnik meg az ofissöl Asus FW support? Csak mert ezek az üres jótanács-puffogtatások "vegyél olyan szappantartót, amire a gyártó hosszú ideig ad sw update-t" hasonlóan kendahajadra, mint amikor a háziorvos annyit tud mondani az épp aktuális bajodra, h. hát sokat kell mozogni és egészségesen élni. Kössz b+, ezért érdemes volt az orvosi egyetemere járnod.

Nagy gyártók közül talán a gugli mondja meg a Nexus / Pixel-nél, h. igen basszátok meg, 2 főverziót biztos fog kapni a Pixel 2. Vagy a Samsung beccsszó megígéri h. az S9 megkapja az Android9-et pl. A HMD ígért még hasonlót az új Nokiák-hoz. Aztán majd meglátjuk ki mekkorát hazudott. De csak utólag, ma senki nem mondja meg nekem ezekből mi lesz igaz, és mi lesz ilyen hoppáka, mégse (all Windows Phone 8.1 phones will receive Windows Mobile 10 update, ugye MSFT?)

Most ugyanezt a beccsszó ígéretet kitúrhatná nekem vki az asus-ról v. random TPLINK rúterről. nem lepődök meg, ha nem talál ilyet senki. Eleve az 5 ezer HUF-os TPLINK-ek fél évente kapnak revision ugrást, a firmware revision-függő, szóval akkor az már új terméknek számít, és a régebbiekre lesheted is h. jön bármi új onnantól fogva.
--

Ha már eleve így írod, hogy anus, akkor már eleve az jut róla eszembe, hogy: Vadász-vadász, te copni jársz ide.

Vagy olyan routert kell venni, amire lehet pakolni OpenWRT-t vagy olyat, amit biztosan frissítenek (pl Mikrotik, Ubi).

Nem feltétlenül kell mindent az egyben routert venni, lehet egy tökösebb vezetékes routert (750Gr3) és egy kisebb AP-nak valót (ami lehet egy olcsóbb WIFI router is), utóbbinál már lehet kevésbé számít, hogy frissíthető legyen, ha csak L2-ben használod, és kintről már nem érhető el közvetlenül, valamint újabb Wifi szabványokhoz nem kell mindent kidobni.

Volt ez már téma korábban is https://hup.hu/node/157181
Egyáltalán nem kell 100 ezret kiadnod vezetékes erős routerre. PC-ből már 50 ezer alatt van egy gigabites igényeket maximálisan kielégítő routered ami VPN-t is bírja. És még wifit is tud. Ott a link trey tesztjéről, de ide is bemásolom https://hup.hu/cikkek/20170327/opnsense_teszt

Normális HUP-ot használok!

( freeoli v | 2018. 06. 20., sze – 09:04 )

A hálózati eszközök harver elemeit broadcom, atheros(broadcom), realtek és társai gyártják. Ők sok esetben adnak szoftveres támogatást rájuk, pl alap OS, alap konfigurátorok, persze alaposan építve sok sok gpl kódra.

Egy idézet egy nexus sokmmilliós switchből:

Cisco Nexus Operating System (NX-OS) Software
TAC support: http://www.cisco.com/tac
Copyright (C) 2002-2018, Cisco and/or its affiliates.
All rights reserved.
The copyrights to certain works contained in this software are
owned by other third parties and used and distributed under their own
licenses, such as open source. This software is provided "as is," and unless
otherwise stated, there is no warranty, express or implied, including but not
limited to warranties of merchantability and fitness for a particular purpose.
Certain components of this software are licensed under
the GNU General Public License (GPL) version 2.0 or
GNU General Public License (GPL) version 3.0 or the GNU
Lesser General Public License (LGPL) Version 2.1 or
Lesser General Public License (LGPL) Version 2.0.
A copy of each such license is available at
http://www.opensource.org/licenses/gpl-2.0.php and
http://opensource.org/licenses/gpl-3.0.html and
http://www.opensource.org/licenses/lgpl-2.1.php and
http://www.gnu.org/licenses/old-licenses/library.txt.

Vagyis nyugodj meg, hasonlóbbak mint gondolnád.

A válasz, hogy mit is használj.
- Sophos UTM free home edition otthonra.
- pfsense
- opnsense
- *wrt?
- Szolgáltatói eszköz. Röhejes, de azt karbantartják. Igaz, hogy egy szar, de ás szarja.

A lényeg hogy folyamatos, akár auto update legyen rajta.

"A lényeg hogy folyamatos, akár auto update legyen rajta."

ddwrtben az a fos, hogy egyáltalán nem támogatott az olyan upgrade, hogy megmaradjanak a konfigok. Másként írva, általában megmarad, ha nem major verziót ugrasz, de semmiféle garancia nincs rá hogy működni fog. Hetente-havonta meg az agyoncustomizált konfigot újra és újra felvinni felettéb fos.
A mikrotik tud auto updatet, és konfigot megtartani? Mert akkor azonnal megyek és veszem.

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

https://wiki.mikrotik.com/wiki/Manual:Upgrading_RouterOS

RouterOS version 6 has new auto upgrade option. RouterOS checks amazon servers for information if new version is available and upgrades after upgrade command is executed. You can automate the upgrade process by running a script in the scheduler:

After v6.31:

/system package update
check-for-updates once
:delay 1s;
:if ( [get status] = "New version is available") do={ install }

En viszont nem ajanlom. Ha kivulrol nem elerheto semmi port, akkor nincsen problema. En csak L2TP/IPSEC VPN-nek hagyok portot es azon belepve lehet csak konfiguralni is. Ha abban talalnak hibat, akkor igy jartam..

sot igazabol az egesz nyak-ot szoftverestul kicikianiak legyartjak OEM-kent, a brand cegek pedig csak a doboz designt meg a logot es a nevuket adjak hozza altalaban, esetleg van 1-2 extra feature requestjuk cserebe a par millio db-os megrendelesert. pl olcso ip kameraknal nagyon latszik hogy vagy 10 fele markanev alatt tok ugyanazt lehet megvenni. a szappandoboz routereknel sincs ez maskent csak ott nem ennyire feltuno meg tobb fele van.

A'rpi

- Szolgáltatói eszköz. Röhejes, de azt karbantartják. Igaz, hogy egy szar, de ás szarja.

Nem pont arról volt szó a sebezhetőség kapcsán, h. az ISP-k nagyívben szarnak a sw maintenance-re, és sokéves elavult firmware fut ügyfeleknek kiszórt milliónyi szaron világszerte?
--

( Foltos | 2018. 06. 20., sze – 09:21 )

Nekem az okosok azt, mondták: "a biztonság nem állapot hanem életforma". Ebben a témakőrben a "telepítem és elfelejtem" üzemmód nem létezik. A kérdés már csak az, mennyi erőforrást és hogyan tudsz/akarsz a kérdésre fordítani. A veszel egy neves cuccot, és bízol a gyártó frissítéseiben és a tákolok valamit *wrt/Linux/*BSD alapon között elég széles a skála.
Hogy neked mi éri meg, azt csak te tudhatod.

( htmm v | 2018. 06. 20., sze – 10:11 )

Ahogy mar korabban leirtak ismert (sokszor mar regen javitott) bugokat hasznalt ki. En mondjuk azt sem ertem, hogy tetszoleges halozati eszkoz management portja (legyen az http vagy ssh) miert erheto el kozvetlenul az internet felol akarkinek.
Ez pont az a helyzet, ami elol egy rendesen beallitott tuzfal es/vagy VPN megvedett volna.

--
http://blog.htmm.hu/

Simán hanyagság. Viszont mit várunk pár ezer ft-os routerektől ?

TP-Link valamelyik firmwarejében volt olyan bug, hogy leszedted router management felületéről a akarmi.rom file-t, amiben ott volt az admin password is természetesen plain textben. Annyi volt a nehezítés, hogy ez csak belső hálózatból ment. Nahh de az olcsó kínai cuccok korában ez sem akadály már.

Szóval nem feltétlenül védett volna meg a tűzfal.

Fedora 27, Thinkpad x220

( Kormoran | 2018. 06. 20., sze – 16:48 )

kilencven ropiért én biztos nem vennék ilyet. ha már ennyi pénz van a dologra akkor egy komolyabb célhardver vagy akár egy saját összeállítás valami x86-os alaplapra

"all submitted complaints will be forwarded to /dev/null for further investigation"
"ez ilyen hippi kommunás felfogás, ahogy Stallman sámán módjára dobol a nagy hasán, hogy GNU, free software, free as free beer."

A topiknyitó kicsit megnézhette volna a támogatási oldalát a fentinek, mert hiába 90e:

- https://www.tp-link.com/hu/download/AD7200.html#Firmware : 2016-03-09 és 2017-01-03-es fw-es listázva

- https://www.tp-link.com/hu/download/AD7200_V2.html#Firmware : 2017-01-03-es fw-es listázva

Szomorú...

( uid_4672 | 2018. 06. 20., sze – 17:58 )

banana pi r2, mini pci-e wlan carddal?

van rá még 4.14-es kernelt is, azt hiszem.
android, openwrt, linugz...

( locsemege v | 2018. 06. 20., sze – 23:28 )

Jó, és mikor csináltál friss image-et magadnak? Én tegnap este 4.9.109-es kernellel.

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

Testreszabom, az lesz benne, amit szeretnék, nem kell utólag telepíteni minden image frissítését követően. Hasonlóképp a default konfig is lehet egyedi, tehát ha nagyon reset kell, akkor megmondhatod, mi legyen a „factory” default config. Illetve én snapshot-ot használok, ez a legfrissebb longterm kerneltől legfeljebb néhány subminor verzióval van lemaradva. Most épp friss, 4.9.109 az ar71xx-hez.

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

Ez most irónia volt? A TP-Link gyári firmware általában tele van biztonsági résekkel hiába Linux. A gyártó pedig nem nagyon csipkedi magát, hogy ezeket foltozza. Hardveresen nagyon jók a TP-Link eszközök, szoftveresen viszont eléggé gyengék.

Normális HUP-ot használok!

Pedig igaza van. Mikrotik nagyon gaz tapokat ad, van olyan ceg ahol 9-bol 3-at kellett cserelni kb 2 ev utan. Itthon is halt meg Mikrotik tapom es sok embertol hallottam ugyanezt. Nagyobb aramerossegure cserelve orok elet + 1 napig mennek az eszkozeik. Ha messzire kerul az eszkoz (150+ km) es helyszini garanciat adsz, akkor mar kicsomagolas utan erdemes cserelni a tapot.

( gergelykiss | 2018. 06. 24., v – 09:43 )

Itt az ideje áttérni a BSD-re?

Igen! :)

A BSD-ben legalább még van potenciál, kellően stabil, kiforrott és profi rendszer, ami (még?) nem lett áldozata a marketinges agymenéseknek és az utóbbi 10 évben kibontakozó túlzottan progresszív, "dobjuk ki a régit, az új az mindig jobb" filozófiának, ami sajnos sok Linux disztrót utolért, az indokolatlan termékelhelyezésekről (ld. beépített Amazon keresés dash-ben) nem is beszélve. Egyébként nagy szerelmese vagyok a Linux-nak, de sajnos azt látom, hogy a Linux és számos Linux köré épülő projekt kezd szétesni, káoszba fulladni, ld. Openwrt-LEDE szétválása majd (elhúzódó, nem kevés konfliktussal kísért) újraegyesülése.

Éppen azon dolgozom, hogy egy jelenleg openwrt-t futtató TP-LINK WR-1043ND routerre felvarázsoljak egy FreeBSD-t, és mezei otthoni routerként használjam, teljesen hétköznapi funkcionalitással (wifi, NAT, routing, tűzfal). Webes felület nekem nem kell, sőt, kifejezetten szeretem a FreeBSD-ben, hogy fapados, jól bevált módszerekkel lehet konfigurálni, és az eddig látottak alapján figyelnek is a fejlesztők rá, hogy a kompatibilitás mindig biztosított legyen, illetve ahol ez nem lehetséges, ott egyértelműen jelzik ezt (X csomag Y verziója nem kompatibilis a FreeBSD Z verziójával), ld. ABI verziószámok használata. Ezen keresztül mindig előre tudható, ha egy breaking change miatt valami nem fog működni frissítés után. Azért ez sokkal barátságosabb, mint utólag vagy menet közben szembesülni a problémákkal, ahogy ez néhány Linux disztrónál lenni szokott (pl. Debian/Ubuntu vonalon).

Sajnos a FreeBSD-ben még eléggé gyerekcipőben jár az embedded támogatás, de vannak már pozitív eredmények, van néhány támogatott SoC platform, és ezen keresztül a SOHO router-ek egy részén már most is gond nélkül el tud futni. Igazából egy külön blogposztot akartam szánni a témának, de ez idő hiányában valószínűleg el fog maradni, a lényeg, hogy először két Netgear eszközzel próbálkoztam, az elsőt a NAND vezérlő driverének hiánya, a másodikat pedig egy "fura" bug miatt voltam kénytelen félretenni (megbízhatatlanul működik a kommunikáció az Ethernet vezérlő és a külső switch vezérlő között, fals adatok jönnek vissza a regiszterek olvasásakor, viszont kb. 5-ből 1-szer hibátlanul működik... itt valami low-level probléma lehet a háttérben az MDIO busz környékén, de sajnos nem volt türelmem rájönni, hogy konkrétan hol). Végül kikötöttem a mostani TP-LINK router mellett, ami ígéretesnek tűnik, mivel van már kernel-szintű támogatás hozzá, illetve egy külső projekten keresztül (https://github.com/freebsd/freebsd-wifi-build.git) flash-be írható, "készre főzött" FreeBSD image készíthető hozzá.

Azon persze mindig lehet vitázni, hogy melyik BSD variáns jobb adott felhasználásra, a már említett OpenBSD híres a paranoiásan biztonságos működésről, de szerintem a FreeBSD is kellően magas szintű biztonságot ad. Ezt talán az is alátámasztja, hogy a Juniper tűzfalak a mai napig FreeBSD-alapokon futnak, illetve úgy tudom, a MacOS is a FreeBSD-től "kölcsönözte" a hálózatos kódbázisának jelentős részét.

Az első számú prioritás szerintem inkább az, hogy mindig frissítve legyen a rendszer, ma már nem menő a több éves uptime, hiszen az sokszor azt jelenti, hogy rég nem volt patch-elve a rendszer...

Még meggondolhatom magam, de a 15 hónapos pici lányom és napi 9 óra munka mellett egyáltalán nem biztos, hogy lesz időm összehozni... pedig csináltam már hasonlót, és azt is nagyon élveztem, de akkor még más idők jártak. :)

Mit értesz TTL programozó alatt? Én úgy tudom, soros interfésze minden embedded eszköznek van, ami szerencsés esetben ki is van vezetve egy tüskesorra, kevésbé szerencsés esetben csak a helye van meg, tüskék nélkül. A TP-LINK lapon sajnos ez utóbbi a helyzet, és mivel sokadjára sem sikerült a tüskéket beforrasztanom a lyukakba gyárilag bekészített ón miatt, így végül a jumper vezetékeket forrasztottam be natúrban. Ha jól tudom, egy hőlégfúvóval könnyen orvosolni lehetne a helyzetet, de nekem sajnos csak pákám van, így egyelőre marad a gányolás.

Egy kis ízelítő a "munkakörnyezetemről":

https://imgur.com/a/3ltGlHo

A Raspberry Pi (aminek a GPIO interfésze szintén 3,3 voltos feszültségszintekkel dolgozik) kiváltható egy ilyen adapterrel, feltéve, hogy a céleszközön ki van vezetve tüskékre a soros interfész - ez itt sajnos nem volt adott.

Azóta annyi fejlemény van, hogy legyártottam az image-eket, viszont a TFTP boot nem akar működni, valószínűleg a bootloaderben lévő TFTP kliens (esetleg a hálózatos kód) bugos, ugyanis ilyeneket látok a szerveren:

Jun 24 20:15:16 nb atftpd[13039.34378711808]: Serving /kernel.TP-WN1043ND to 192.168.0.2:2644
Jun 24 20:15:17 nb atftpd[13039.34378706688]: timeout: retrying... state=4239029,
Jun 24 20:15:19 nb atftpd[13039.34378709248]: Serving /kernel.TP-WN1043ND to 192.168.0.2:2644
Jun 24 20:15:19 nb atftpd[13039.34378711808]: timeout: retrying... state=4239029,
Jun 24 20:15:22 nb atftpd[13039.34378711808]: timeout: retrying... state=4239029,
Jun 24 20:15:24 nb atftpd[13039.34378713088]: Invalid request <1> from 0.0.0.0

Egyelőre úgy tűnik, le kell cserélnem az u-bootot, de azért próbálkozok még, hátha összejön.

A visszaállás a megfelelő eszközök birtokában mindig lehetséges, lásd a fentebb linkelt blogposztomat... :)

Nem is igazán a meggyőzés volt a cél, csak gondoltam, megosztom az ide kapcsolódó tapasztalataimat, hátha érdekes lehet valakinek. Ahogy írtam is, egyelőre csak kísérletezek a FreeBSD beágyazott eszközön futtatásával, így sajnos még nem tudok túl sok konkrétumot megosztani. Írok majd egy összefoglalót, ha sikerül eljutnom odáig, hogy éles üzemben használok egy FreeBSD-t futtató eszközt pár napig/hétig otthon. Bizakodó vagyok, de nem tudom, hogy stabilitásban hozza-e vajon azt a szintet mint pl. az openwrt...

Ez igazából már most is adott, csak egyelőre nem mertem felülcsapni az openwrt-t a flash-ben. Viszont TFTP-ről már tudok bootolni, annyi volt a varázslat, hogy az UTP kábelt át kellett dugni a WAN-port felőli interfészbe (valószínűleg ez az 1-es számú interfész, és csak ezt kezeli rendesen a TP-LINK által fordított u-boot)... :)

Van egy szkript az egyik korábbi posztban említett projektben, ami pontosan ezt valósítja meg: generál egy firmware binárist, amit egy az egyben fel lehet tölteni a gyári firmware-ből. Ez az openwrt-ből lett átvéve, úgyhogy ha ott működik, akkor itt is működnie kell. :)