Tor proxy test: Internal error

Per un po’ non sono più riuscito ad usare Tor+privoxya causa (col senno di poi) aggiornamento; se con il tor button di firefox provavo a fare il test per un corretto funzionamento ottenevo solo un bizzarro "Tor proxy test: Internal error"… molto indicativo devo dire.

Per risolvere il problema ho prima di tutto osservato che cazzo succedeva a livello listening

# lsof -i :8118
COMMAND   PID    USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
privoxy 14373 privoxy    1u  IPv6 213611      0t0  TCP localhost:8118 (LISTEN)

coadiuvato da qualcuno che aveva il mio stesso problema ho capito che in pratica ascoltava solo ipv6; per risolvere la issue ho dovuto cambiare nella riga in /etc/privoxy/config da localhost a 127.0.0.1 altrimenti veniva appunto risolta in ipv6; adesso ottengo

# lsof -i :8118
COMMAND   PID    USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
privoxy 15595 privoxy    1u  IPv4 216976      0t0  TCP localhost:8118 (LISTEN)

per la gioia di grandi e piccini.Posso girare su 4chan senza problemi 😉

Sniffjoke

I pazzi di delirandom presentano un nuovo strumento per rendere partecipi i people della rete delle problematiche della stessa: sniffjoke; in pratica si tratta di un tool che immette pacchetti che si prendono gioco degli sniffer inserendone alcuni nella comunicazione che lo stack TCP/IP di un OS non caga ma che uno sniffer alla wireshark ha problemi a gestire. Per adesso funziona solo per le connessioni lato client ma se qualcuno è interessato al suo sviluppo può partecipare per implementare il lato server… Read the rest of this entry »

Quando i kernel fanno Ops

Succede che stamattina voglio inserire una scheda sonora sullo pseudo-server che ho a casa in modo da poter grabbare l’audio dala scheda TV entrata in mio possesso da un vecchio computer di un mio amico. Succede che la monto e avvio il sistema. Succede che ad un certo punto mi esce un Ops del kernel all’inserimento del modulo e il tutto è bloccato.

Potrei semplicemente togliere la scheda, ma si sa, le sfide ci sfidano e quindi voglio vedere se è proprio il modulo oppure chi lo sa? la digos che cerca di penetrare la mia rete casalinga attraverso il firmware della scheda (devo bere di meno alle cene benefit)…

Primo fatto è che devo conoscere quale modulo è stato in particolare… già di suo il kernel presenta un backtrace del processo che ha fatto il bordello, ma magari vogliamo sapere di più e così usiano la comoda procedura Ctrl-Alt-PrintScreen-<alzare un elefante> che peraltro ci serve anche per riavviare senza usare il tasto reset che fa tanto ficoooo.

Il problema successivo ovviamente è che il sistema si blocca anche in modalità single (voglio la modalità erotomane) e quindi bisogna agire sui parametri dl kernel al boot per evitare che esegua la procedura di init(1) ma che ci lasci con una bella shell.

Quando arriva Grub non bisogna fare altro che impostare una riga del tipo

kernel /boot/vmlinuz-2.6.26-1-686 root=/dev/md0 init=/bin/sh

in modo che il kernel una volta caricato in memoria e impostato quelle 3 o 4 cose fondamentali avvi una shell; nei sistemi UNIX, nelle incarnazioni derivate dalla versione SystemV, il programma che avvia il sistema si chiama proprio init (che ha pid 0) che si preoccupa di avviare tutti gli altri processi (come indicato da inittab(1)) e che di solito sono in directory indicanti il runlevel (tipo rc2.d). Quindi indichiamo la shell sh come programma al posto di init (con il suo path of course) l’unico problema è che il filesystem viene montato read only e siccome è proprio il filesystem di root non è che lo posso smontare… usiamo l’opzione remount nella seguente maniera

mount -o remount,rw /dev/md0 /

(quando compare il prompt di sh of course) così da avere il nostro tree di directory adesso disponibili per un uso completo (nel mio server sto usando un RAID1 software in maniera da non perdere i miei dati all’improvviso, ecco perché quella strana indicazione md0, voi comuni user del desktop avrete qualcosa come sda1 per computer abbastanza moderni oppure hda1 nei casi rimasti al di fuori della casistiche precedenti). 

Adesso posso provare a vedere se il modulo lo carica, cosa che effettivamente avviene senza Ops, ma purtroppo non funge, si pianta al riavvio anche se indico di caricarlo prima (/etc/modules) oppure se lo metto in blacklist (/etc/modprobe.d/blacklist) e quindi come finale della storia ho smontato la scheda…