[Ninux-Calabria] Openwrt custom firmware

Stefano De Carlo stefanauss a gmail.com
Mar 13 Maggio 2014 00:49:01 UTC


Il 13/05/2014 01:51, Vincenzo Pirrone ha scritto:
> Sarà un problema di trunk? Sarà l'841? boh

In realtà non credo che trunk abbia problemi, a parte un footprint di
400-500 KiB superiore rispetto ad AA (che comunque è la stessa cosa che
è successa tra backfire e attitude).

Io sto sperimentando con trunk su 841 v8. Non credo sia rilevante però,
tutti i target da 4MiB si equivalgono.
Si tratta del caso peggiore, con Luci e BB, footprint alto.
Nella mia build "finale" sono inclusi

- luci
- luci-ssl
- olsr
- olsrd-mod-txtinfo
- olsrd-mod-mdns
- olsrd-mod-nameservice
- olsrd-mod-dyngw
- olsrd-mod-arprefresh
- luci-app-olsr
- kmod-ipv6
- ip6tables + kmod-ip6tables
- kmod-gre; kmod-gre6
- tc

Il risultato è 3.5 MiB di sysupgrade, flashato rimangono 168KiB.
Quanto sopra se non sbaglio è largamente condiviso da tutti, a parte GRE
e tc.
Prima di proseguire e trarre il massimo da quei 168 vorrei capire le
posizioni su GRE e QoS. Le mie:

* GRE: è l'unico modo per offrire una feature IMO fondamentale, il
tunnelling, senza strippare luci e senza essere alla mercé dei footprint
futuri di Openwrt (mettiamo che ci facciamo stare tinc per miracolo su
BB, che facciamo quando esce Openwrt "CC" e non ci sta più, cacciamo una
features su cui la community fa ormai affidamento?). Occupa pochissimo.
Certo, ha degli shortcomings in sicurezza ma su questo possiamo fare
informazione e divulgazione alla community. E magari mitigare
(firewalling?).

* TC: la presenza di un QoS mi piace, può invogliare i ninuxers ad
annunciare HNA 0.0.0.0 sapendo di poter darne efficacemente una fetta
senza compromettere la propria usabilità. Tuttavia ci sta TC e basta, e
non possiamo onestamente sperare che senza un wrapper o una gui la
feature venga sfruttata anche da chi vorrebbe. Purtroppo, QoS-Scripts
tira giù troppe estensioni di netfilter e GUI per tc puro OpenWRT non ne
ha. Siamo nella terra di nessuno, dove la feature c'è ma non è
sfruttabile davvero.
Per ora la considero ammessa con riserva, ma considerando i candidati
che spingono per entrare (ip) e soprattutto il fatto che non sappiamo
ancora come deployeremo IPv6 e che (se) altri pacchetti serviranno, TC
per quanto mi riguarda sarà il primo a far spazio.

Ora io scalo una marcia e lavoro al caso immediatamente inferiore,
target di 4 MiB + Luci, ma su AA 12.09.1. Parto da quei stessi pacchetti
e vedo quanto il footprint più basso ci regala.
A seconda di quanto ci rivela, possiamo pensare una cosa per
sincronizzare AA e BB sul target da 4 MiB: su AA ci sarà Luci, su BB
solo cli. Mi sembra una cosa molto più manutenibile e scalabile che
offrire molte, molte funzionalità presenti solo su una versione ma non
sulla *successiva*.

Vi lascio con una immagine per tirarvi su il morale :)

http://i.imgur.com/p7U1RFK.png

Stefanauss.
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://ml.ninux.org/pipermail/calabria/attachments/20140513/204d9ee5/attachment.htm>
-------------- parte successiva --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://ml.ninux.org/pipermail/calabria/attachments/20140513/204d9ee5/attachment.pgp>


Maggiori informazioni sulla lista Calabria