BSBE Vicchio 27-8-2014

Bud Spencer Blues Explosion
Fiera Calda Vicchio 27-8-2014

Cambio port https su Proxmox

A causa di configurazione firewall, una volta montato Proxmox non riuscivo a contattarlo sul protocollo https alla porta 8006 (default) mentre era raggiungibile via SSH

Per aggirare le politiche del firewall si puo' procedere come segue

effettuare un kill del processo pveproxy
editare il file /usr/bin/pveproxy
sostituire nel file il numero di porta 8006 con un altro (io ho usato 8080 in modo da bucare il firewall) all'incirca in corrispondenza della stringa keep_alive
riavviare pveproxy

IptabLes (2)

Dopo quanto visto nel precedente post, ho provato un po' a divertirmi con IptabLes

Le dimensioni dei file coinvolti sono piuttosto notevoli
.IptabLes 1103207 bytes
.IptabLex 722392 bytes

con il comando file si vede che il file non e' stato strippato

IptabLes: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, for GNU/Linux 2.6.9, from '@%ebx', not stripped 

IptabLex: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, for GNU/Linux 2.6.9, from '@%ebx', not stripped

inoltre entrambi sono linkati staticamente (il che giustifica le dimensioni in quanto si portano dietro tutte le librerie di cui hanno bisogno)

mediante il comando strings si vede che il programma non e' criptato
-----------------------------
rm -f %s
/proc/self/exe
GETFILE_%08X
http://www.yahoo.com.http://www.baidu.com.http://www.china.com.http://www.ifeng.com
abcdefghijklmnopqrstuvwxyz0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ
/proc
/proc/%s/exe
/delxxaazz
/rc.d/r
/etc%sc%d.d/S55IptabLes
/delallmykkk
/delallmykkk>/dev/null
cp %s %s>/dev/null
/etc/rc.d/init.d/IptabLes
/etc/rc.d/IptabLes
/boot/IptabLes
%d.%d.%d
/boot/.IptabLes
/usr/.IptabLes
xxxx
#!/bin/sh
exit 0
#!/bin/sh
if [ -z $1 ] ; then
ps -f -C .IptabLes |grep .IptabLes | awk '{print $3}' | xargs $0 2
ps -f -C .IptabLes |grep .IptabLes | awk '{print $3}' | xargs $0 2
ps -f -C .IptabLes |grep .IptabLes | awk '{print $2}' | xargs $0 2
ps -f -C .IptabLes |grep .IptabLes | awk '{print $2}' | xargs $0 2
ps -axu | grep .IptabLes | awk '{print $2}' |xargs kill -9
ps -axu | grep .IptabLes | awk '{print $2}' |xargs kill -9
ps -C .IptabLes | xargs kill -9
ps -C .IptabLes | grep .IptabLes |xargs kill -9
rm -f /boot/.stabip
rm -f /boot/.IptabLes
rm -f /etc/rc.d/init.d/IptabLes
rm -f /boot/IptabLes
rm -f /tmp/IptabLes
rm -f /usr/IptabLes
rm -f /usr/.IptabLes
rm -f /boot/.IptabLes
rm -f /.IptabLes
rm -f /boot/IptabLes
rm -f /IptabLes
rm -f /etc/rc.d/rc4.d/*IptabLes
rm -f /etc/rc.d/rc1.d/*IptabLes
rm -f /etc/rc.d/rc2.d/*IptabLes
rm -f /etc/rc.d/rc3.d/*IptabLes
rm -f /etc/rc.d/rc0.d/*IptabLes
rm -f /etc/rc.d/rc5.d/*IptabLes
rm -f /etc/rc.d/rc6.d/*IptabLes
rm -f /etc/init.d/IptabLes
rm -f /etc/rc4.d/*IptabLes
rm -f /etc/rc1.d/*IptabLes
rm -f /etc/rc2.d/*IptabLes
rm -f /etc/rc3.d/*IptabLes
rm -f /etc/rc0.d/*IptabLes
rm -f /etc/rc5.d/*IptabLes
rm -f /etc/rc6.d/*IptabLes
rm -rf "$0"
else
if [ -z $2 ] ; then
exit
else
if [ 1 -ne $2 ] ; then
kill -9 $2
exit
#!/bin/bash
sleep 3
kill %d
sleep 1
rm -f %s
rm -rf "$0"
sh /delxxaazz
/proc/net/dev
face
rrrrrrss
FATAL: exception not rethrown
/proc/sys/kernel/version
/proc/sys/kernel/osrelease
FATAL: kernel too old
FATAL: cannot determine kernel version
/dev/full
set_thread_area failed when setting up thread-local storage
UUUU
?3333
/bin/sh
exit 0
LIBC_FATAL_STDERR_
/dev/tty

-----------------------------
si legge anche chiaramente dove vengono messi i file ed alcuni comandi di shell
Francamente non ho esperienza in Assembler ma mediante il decompilatore RecStudio e' possibile leggere in chiaro il nome delle funzioni tra cui si vede chiaramente SynFlood e DNSFlood che corrisponde a quanto fa effettivamente il programma

Dalla lettura delle stringhe sembra che il programma sia stato compilato su una RedHat con un compilatore GCC 4.1.2 (che se fosse corretto risulta essere una versione piuttosto vecchiotta)

Potenza del segnale di CC2541

L'integrato Texas Instruments CC2541 su cui si basano alcuni beacon permette di modificare la potenza di trasmissione da +4 dBm a -23 dBm. Cio' consente di aumentare o diminuire il proprio raggio d'azione

Nell'applicazione che uso i valori di potenza non impostati a 4 valori prefissati

0 dBm : potenza standard
4 dBm : circa il doppio della potenza standard
-6 dBm : un quarto della potenza standard
-23 dBm : un ventesimo della potenza standard

Per vedere se effettivamente le modifiche influenzano il raggio d'azione del beacon ho provato a plottare la potenza contro il valore di rssi (facendo una media e la deviazione standard di una serie di dati a causa della instabilita' intrinseca del segnale). La prova e' stata eseguita mantenendo beacon e telefono a distanza fissa per tutto il tempo

Come si vede dal grafico i casi 0dBm e +4dBm sono praticamente non distinguibili, nel caso di -6dBm il valore di rssi e' di qualita' inferiore a causa della diminuzione del segnale. Quando la potenza del beacon passa a -23dBm il valore di rssi e' praticamente fisso a 95 ovvero il telefono e' praticamente fuori al raggio d'azione del beacon e legge solo un valore di fondo scala

Sensore di retromarcia su Fiat QUBO

Mi sono comprato per una venticinquina di euro un sensore per parcheggiare (non ho ancora preso le misure del QUBO) di seguito viene descritto come montarlo

Dato che il sensore si deve attivare in retromarcia e non essendoci informazioni di un connettore speciale ho deciso di collegare l'alimentazione del sensore sulla lampada posteriore di retromarcia
Il faro posteriore si toglie svitando due viti e sfilando il gruppo ottico

A questo punto si accede al connettore

Munito di tester ho identificato il cavo di massa (e' quello nero di maggiore spessore) ed il cavo della lampada della retromarcia che e' identificato dal colore grigio-verde. Il problema e' fare una connessione elettrica stabile. Il connettore e' difficile da smontare ma ho trovato che c'e' un linguetta che blocca tutti i connettori, se si alza si accede alla parte metallica dei connettori e si puo' bloccare il filo con la stessa linguetta una volta rimessa a posto

Per passare il cavo all'interno ho passato l'alimentazione nello scatolare e smontando la cassa dello stereo per accedere all'interno

E questo il montaggio definitivo prima di richiudere il faro

Per non fare buchi nel paraurti i sensori sono stati montati su una barra in plastica avvitata con la targa

Freenas su Virtualbox

Per fare qualche prova con FreeNas, non avendo a disposizione una macchina fisica su cui provarlo, ho deciso di virtualizzarlo ed ho visto che non e' poi cosi' banale

Per prima cosa,visto che FreeNas e' basato su BSD, si deve impostare il sistema operativo

Attenzione: ho provato ad installare la versione a 64 bit ma in fase di boot (dopo l'installazione) andava in kernel panic per cui e' stata impiegata la versione a 32 bit 

I dettagli della configurazione sono

Ram almeno 4 Gb per usare ZFS

Scheda di rete in bridge

Ho provato anche a creare due dischi fissi (uno per FreeNas e l'altro per i dati) ma all'interno di Virtualbox viene visto solo il disco di boot

Al termine del boot, nella finestra di shell, viene visualizzato l'indirizzo a cui connettersi con il browser per l'amministrazione

WebAdmin di FreeNas

al primo login si deve scegliere la password dell'amministratore (root)

Shell di FreeNas

Dopo aver seguito le istruzioni a questo link ed aver creato un Volume attivo ed un Dataset, dopo aver creato un utente e messo il disco in condivisione, questo compare nella lista delle cartelle condivise

IBM X3550/7978 per Proxmox

Per un costo tutto sommato accettabile (130 euro) mi sono comprato un server IBM X3550/7978 in formato 1U con un  quadcore xeon ed 8 giga di ram per giocare con Proxmox

L'acquisto e' stato necessario perche' l'altra macchina da rack disponibile era un vecchio IServer (sempre IBM) piu' o meno anno 2003-2004 con processori Xeon ma purtroppo a 32 bit e quindi non utili a far girare Proxmox