FAQ sulle mod firmware

Da Vocesuip.

Indice

Modificare... perché?

I motivi principali che spingono gli utenti a modificare un firmware sono:

- cambiare la lingua della gui;
- cambiare annex (per usare il prodotto con adsl italiana);
- aggiungere funzionalità;
- correggere dei bug;
- fare trasfusioni di versioni tra modelli diversi ma compatibili;
- puro diletto...;
- ecc ecc ecc.


E' legale modificare?

NI... Secondo la licenza AVM non si può decomprimere il firmware originale e modificarlo, non si può nemmeno distribuirlo... per maggiori info leggi ultimo paragrafo Poi se uno lo fa per sé, pace e bene, ma se lo rende pubblico potrebbe incorrere in azioni di AVM.

Per maggiori approfondimenti sulla licenza AVM, si rimanda al file AVM: license.txt


Perché rendere disponibile al pubblico un firmware modificato?

Scopo principale dovrebbe essere agevolare gli utenti meno esperti e permettere un uso soddisfacente di questi prodotti, laddove il firmware originale non comprenda alcune caratteristiche desiderate (pacchetti aggiuntivi, modulo dsl ad hoc, ecc.).


Come modificare un firmware?

Ci sono dei tools che operano sotto Linux (puro o virtualizzato); le istruzioni si trovano nella sezione apposita delle wiki e/o in questa sezione del forum

un "classico": Freetz!
Wiki ip-phone-forum

Mini-guida Lonegunman

vogliamo fare solo il cambio modulo DSL?
thread da cui è partita l'idea
Prima wiki metodo Alpamayo
Seconda wiki metodo Alpamayo

alternativa a Freetz!: Speed-to-Fritz (non solo per gli Speedport)
http://www.ip-phone-forum.de/showthread.php?t=155864
http://wiki.ip-phone-forum.de/skript:speedport2fritz
Virtual Machine Speed-to-Fritz su Ubuntu 9.1 32 bit

Se proprio non si vuole rinunciare a Windows e si desidera la compresenza di entrambi i Sistemi Operativi, oltre alle soluzioni di virtualizzazione c'è anche questa soluzione ibrida: Colinux che funziona bene, a patto di avere un PC ben carrozzato (almeno 2 Gb RAM e processore diverso dall'8088)


Attenzione: debug!

Modificare un firmware non è un operazione particolarmente complessa; ciò che lo rende fruibile a tutti, però, è la fase del cosiddetto debugging, bestia nera anche per le case produttrici di firmware ufficiali: l'errore è sempre dietro l'angolo, la correzione di un errore può portare alla creazione di un altro errore, magari più grave.

Prima di rilasciare il firmware, spendete del tempo e dedicate la giusta attenzione a questo basilare aspetto: test, debug, test, debug, stress, victory!


Vuoi condividere un firmware che hai modificato?

Tieni ben presente che è una tua decisione, di cui ti assumi la responsabilità. Questo sito non ospiterà MAI firmware né originali né modificati, proprio per rispettare la licenza AVM.

Se hai deciso di condividere un firmware modificato, ci sono delle regole da rispettare per non creare confusione e per facilitare l'utente all'installazione ed uso.


Come nominare il file del firmware?

nome.image

nome = versione_firmware + modder + versione_mod + note

versione_firmware = xx.yy.zz
xx = codice modello a cui è destinato il firmware (major)
yy.zz = versione base
modder = nome o sigla di chi l'ha confezionato
versione_mod = vx.yy (v sta per versione es v0.1)
x.yy = versione della modifica che deve essere incrementata ad ogni rilascio
note = es. 8MB, 16MB, Ita, alfa, beta, test ecc o concatenazione di queste

Esempio:
Se il tuo firmware è destinato a 7170v2 DE il nome sarà 29.04.80_Sk3_v0.1_Umts.image
(29 indica che questo firmware è adatto per essere installato dove è presente già la versione originale 29.04.xx e quindi le rispettive variabili di ambiente)
Se il tuo firmware è destinato a 7170 EN il nome sarà 58.04.80_Sk3_v0.1_Umts.image
(58 sta ad indicare che questo firmware è adatto per essere installato su firmware originale internazionale 58.04.xx)


Come impacchettiamo tutto?

Creare un archivio ZIP o RAR o quello che vuoi, che contenga il file del firmware (nome.image) ed un file README.TXT dove si avverte che il firmware NON è originale e che non esiste alcuna garanzia di alcun genere; lo si usa per scopi privati e di studio, non commerciali; chi lo usa, lo fa a proprio rischio e pericolo; è un opera GRATUITA.

Nel file readme.txt va anche elencato, in maniera sintetica:
- modello di destinazione;
- base firmware (versione di partenza su cui si sono fatte le modifiche);
- variabili necessarie per una corretta installazione;
- storia delle versioni della modifica (changelog);
- note;
- istruzioni essenziali per il recupero della situazione pre-esistente.
- per eccesso di zelo, si potrebbe indicare anche questo e questo


Come garantire una corretta installazione?

Se metti a disposizione un firmware, VERIFICA che la sua installazione sia possibile a partire dalla versione originale dello stesso SENZA dover cambiare variabili via FTP o Telnet. Un buon debug permette all'utente nubbio di installare il firmware a partire dalla versione ufficiale SENZA sbattimenti.

Quindi usa un file install STANDARD ed eventualmente forza in maniera 'interna' le variabili. Un esempio è la modifica dell'annex: vuoi impostare annex A ma la base è annex B... basta modificare il file rc.dsl e forzare il caricamento del modulo annex A ignorando la variabile ANNEX. In questo modo il firmware si installa sulla versione originale senza problemi ma è configurato per la connessione annex A senza alcuna modifica da parte dell'utente.
Si garantisce anche un corretto ripristino sia tramite il recovery image sia reinstallando un firmware originale.
Eventualmente seganalare se può essere necessario e/o sufficiente procedere ad un factory reset.


L'utente ha sbagliato qualcosa... Come ritornare ad una situazione funzionante?

Per agevolare i nuovi utenti che vogliano cimentarsi nel testing di firmware modificati, bisogna fornire loro le istruzioni ipotizzando le diverse situazioni di partenza: è proprio quando qualcosa non va per il giusto verso, che si apprezzano le istruzioni di ripristino!
Non lesinate le istruzioni utili per tutti i casi del genere; conviene utilizzare sempre il suddetto file di testo readme.txt


Strumenti personali