Friday, October 30th, 2009
Titolo un pò strano ma è proprio quello che ci è capitato ieri al giovedì nerd a me Lorenzo e Stefano quando stavamo per darci vinti e dichiarare “brickata” una bullet 2 della ubiquity. Tutto inizia con Stefano che porta la sua Bullet dicendo che ormai non ci può fare più niente perchè dopo una configurazione probabilmente errata delle interfacce ha perso la shell. Seguendo l’help sul sito della ubiquity testiamo la classica procedura per mettere il dispositivo in modalità di flash che nemmeno a dirlo non funziona
Analizzando il comportamento dei led però intuiamo che il boot del sistema operativo viene effettuato e quindi come ultima risorsa prendiamo wireshark e ci mettiamo a fare sniffing. Quello che viene a prima vista fuori sembra inutile ma spulciando bene troviamo una vera e propria richiesta di soccorso su un pacchetto udp mandato dall’indirizzo ip 192.168.1.1 che si presenta così:
0000 de ad 50 72 65 73 73 20 72 65 73 65 74 20 6e 6f ..Press reset no
0010 77 2c 20 74 6f 20 65 6e 74 65 72 20 46 61 69 6c w, to enter Fail
0020 73 61 66 65 21 00 00 00 00 00 00 00 00 00 00 00 safe!………..
Superato lo stupore iniziale cominciamo a fare ricerche sul web, capendo che il messaggio proviene da openwrt che avendo capito di essere praticamente brickato ci chiede gentilmente di premere il tasto reset per entrare in failsafe mode. Premuto il tasto reset per 2 secondi a tempo con non poca difficoltà riusciamo ad ottenere una shell sulla bullet “brickata” e una volta montata la partizione jffs che nel nostro caso era su /dev/mtd3 ripristiniamo la configurazione di default recuperando la Bullet. Per maggiori informazioni su cosa è il failsafe mode in openwrt andate qui. E ora guardiamo avanti al prossimo dispositivo da brickare

Posted in Informatica | 4 Comments »
Sunday, March 15th, 2009
Nella scorsa settimana i ragazzi del Ninux.org hanno rilasciato la primissima versione del plugin olsr chiamato “mdns” che consente di poter utilizzare per esempio Avahi e quindi Bonjour su una rete olsr. Riporto il testo dell’email di uno degli sviluppatori:
Ciao,
ho iniziato a sviluppare insieme a Clauz l’mdns plugin per olsrd.
Olsr-dev sono stati già informati da qualche giorno, ora scrivo anche
qui perché anche se è solo una settimana che ci lavoriamo possiamo già
darvi una versione alpha funzionante
ci serve gente che testa il
codice
http://hg.ninux.org/hg/olsrd-ninux-messy/ (branch adaptbmf)
mdns-plugin for latest olsr-tip
http://hg.ninux.org/hg/olsrd-0.5.6-mdns/ mdns-plugin adapted to
0.5.6r3 for OpenWRT compatibility
https://svn.ninux.org/ninuxdeveloping/browser/packages/olsrd Modified
OpenWRT package for OLSR that inclues the plugin
il branch da prendere come riferimento è “adaptbmf” mentre presto
arriveranno le istruzioni per far girare il tutto su OpenWRT
Come funziona ??
Prendiamo un nodo generico con delle interfacce OLSR ed altre interfacce HNA.
Configurate il plugin:
LoadPlugin “olsrd_mdns.so.1.0.0″
{
PlParam ”NonOlsrIf” ”eth0″
}
Ed indicate le interfacce che non parlano OLSR (in questo caso eth0)
dalle quali volete catturare il traffico mdns.
Il plugin cattura traffico mdns (ipv4 e ipv6) e lo incapsula dentro
nuovi messaggi OLSR a gli altri nodi della mesh. Gli altri nodi
decapsulano i messaggi e li inviano alle loro NonOlsrIf specificate
nel file di configurazione.
In questo modo prendiamo questa topologia di esempio:
pc1->eth0 —– eth0<-r1->ath0 ——-ath0<-r2->eth0 ———eth0<-pc2
In questo modo con r1 r2 routers OLSR con attivato il plugin, pc1
riesce a vedere i pacchetti mdns inviati in multicast da pc2 e
viceversa.
La cosa interessante è che se mettiamo un router OLSR r3 senza il
plugin attivato:
pc1->eth0 —– eth0<-r1->ath0 —r3—-ath0<-r2->eth0 ———eth0<-pc2
tutto continua a funzionare perché r3 inoltra i messggi OLSR del
nostro plugin anche se non sa di che applicazione si tratta.
Ciao ciao
Saverio
Se qualcuno vuole testarlo e dare feedback è il benvenuto!
Posted in Informatica | No Comments »
Sunday, April 13th, 2008
Sulla mailing list di Ninux.org è appena stata riportata la notizia tratta da questo post: dove si parla della possibilità di poter aumentare la velocità del clock della cpu della fonera, in breve vi traduco i passi che ci sono da fare:
- Loggare via ssh nella fonera
- eseguire cat /dev/mtdblock/0 > /tmp/RedBoot.bin
- con “scp” copiarsi il file /tmp/RedBoot.bin sul proprio computer e aprirlo con un qualsiasi editor esadecimale
- cambiare l’offset 0×1e3 da 0×03 a 0x01 (stiamo in questo modo dividendo per 2 invece che per 5)
- cambiare l’offset 0×1ef da 0×5c a 0×28 (stiamo moltiplicando per 10 invece che per 9)
- rimettere il file che abbiamo così modificato sulla fonera e dare il comando mtd -f write /tmp/RedBoot.bin RedBoot
In questo modo avremo una fonera che lavorerà alla frequenza di 200mhz perchè il conto da fare è:
40/2*10 = 200 dove 40 è la frequenza base del pll, 2 che è il nostro divisore e 10 che è il nostro moltiplicatore.
Il post riporta anche che questa “patch” è funzionale con tutti quei device che lavorano con Redboot come ad esempio: ap51 , ap61 come l’Accton MR3202A oppure Ubiquiti LS2/NS2/PS2.
C’è da dire che l’overclock della fonera è molto rischioso e potrebbe portare al brick del device se non si sa quello che si fa.
Posted in Fonera | 4 Comments »