WICD: finalmente un network manager che funziona

Se neanche a voi il network manager (nm-applet) installato di default con Ubuntu ha mai funzionato, allora è proprio il caso di provare WICD.

La più grande feature di WICD è semplicemente quella di funzionare, tra le altre:

• Configurazione automatica (DHCP) o manuale (IP, Subnet mask, Gateway, DNS) per le reti cablate.
• Gestione dei profili per le reti cablate (utile se vi connettete in posti diversi).
• Possibilità di connettersi automaticamente all’avvio per le reti Wireless.
• Gestione dei settaggi indipendente per ogni rete.
• Supporto alle reti protette con: WPA 1/2, WEP, LEAP, TTLS, EAP, PEAP.
• Riconnessione automatica dopo la sospensione.

Il progetto è ancora giovane e in fase di sviluppo e si potrebbero aggiungere vari accorgimenti per renderlo più comodo (ad esempio un menù sulla tray-icon che elenchi le reti trovate) e ha qualche problema nel distinguere più reti wireless con lo stesso BSSID (vedi Fonera).

Per installarlo potete aggiungere ai vostri repository:

deb http://wicd.longren.org feisty all

ed usare apt:

sudo apt-get install wicd

WICD sarà accessibile dal menù Applicazioni/Internet.
Se volete che venga eseguito automaticamente all’avvio aggingete “/opt/wicd/tray.py ” alla lista in Sistema/Preferenze/Sessioni.

Da provare

“Disegnare” la propria LAN con lanmap

Vi segnalo un piccolo tool per generale delle mappe della propria(?) LAN,
il suo nome è lanmap e rimane in ascolto sul’interfaccia scelta e cattura tutto il traffico, determina quali host stan scambiando dati, in che quantità e che protocollo stanno usando. Con tutte queste informazioni, lanmap, prova a determinare la topologia della rete producendo un immagine 2D (png, svg o jpg).

Lanmap si trova nei repository ufficiali, quindi basta installarlo con:

sudo apt-get install lanmap

ed eseguirlo

sudo lanmap -i interfaccia

per ottenere le immagini nella directory corrente (più pacchetti vengono catturati più le immagini sono accurate).

Per ulteriori opzioni, come sempre:

man lanmap

WPA con wifi-radar e wpa_supplicant

Cercando di connettermi a una rete WPA con l’applet per NetworkManager (nm-applet, installata di default su Ubuntu) mi sono reso conto che, seppur funzionante, mi da qualche problema nel connettersi a reti non protette e ha la brutta abitudine di volersi sempre connettere a qualche rete se il wireless è abilitato (mentre a volte si potrebbe voler osservare le reti wireless senza connettersi).

Ho optato perciò per wifi-radar, ecco come fare (l’esempio è per una rete WPA-PSK):

Abilitare il Wake On Lan su Ubuntu

Wake On Lan (WOL) è una tecnologia che permette di accendere da remoto un PC spento a condizione di poter inviare degli speciali pacchetti (Magic Packet¹) “on wire”.

E’ particolarmente utile se avete una LAN wired, o un router che supporti il WOL (ad esempio con dd-wrt ) e volete accendere un altro computer senza dover premere fisicamente il bottone (magari perchè siete lontani da casa e volete accederci via SSH).

Per abilitarlo possiamo usare ethtool:

sudo ethtool -s eth0 wol g

Dove eth0 è l’interfaccia (sostituitela con la vostra) e con “g” abilitiamo il Wake On Lan all’arrivo di un Magic Packet. Possiamo scegliere tra diverse opzioni tra le quali c’è anche la possibilità di usare una password. Per una lista completa: man ethtool.

Il problema sta nel fatto che dovremmo usare il suddetto comando a ogni avvio del sistema… ma possiamo creare uno script che faccia il lavoro per noi

Checksum Offloading

Qualche tempo fa, stavo cercando di configurare un server DHCP per una piccola LAN (dnsmasq per l’esattezza).

Nonostante diversi tentativi non riuscivo a ottenere un IP dal server, anche se il client inviava vari DHCPDISCOVER e i log del server suggerivano che i relativi pacchetti DHCPOFFER venivano trasmessi.

Dopo diversi tentativi, ho provato a catturare i pacchetti dal lato del client, per accorgermi che i checksum dei pacchetti UDP erano errati, e quindi venivano scartati.

Tutta colpa del Checksum Offloading: una tecnologia che evita al kernel di dover calcolare il checksum di tutti i pacchetti trasmessi (o ricevuti) delegando il compito alla scheda di rete.
Peccato che la mia scheda (e non solo) sbagliasse a calcolare il Checksum per i pacchetti UDP…

La soluzione sta nel disabilitare l’offloading in trasmissione con questo comando:
sudo ethtool -K eth0 rx on tx off

Qualche link:

Ho già segnalato il bug al team di ubuntu: https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/127749
Per maggiori informazioni sul Checksum Offloading: http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=/com.ibm.aix.prftungd/doc/prftungd/tcp_checksum_offload.htm

Network Neutrality

Vi segnalo questo video su youtube, che spiega la neutralità della rete.

“…70% of the contents on the net is produced by people, not corporations. You look the commercial TV? 0. Radio? 5%…”

“Vent’anni fa, gli inventori di Internet progettarono un’architettura semplice e generale. Qualunque computer poteva mandare pacchetti di dati a qualunque altro computer.

…

Chiunque può scrivere un’applicazione per il Web, senza chiedere a me, o a Vint Cerf, o al proprio ISP, o alla compagnia telefonica, o al produttore del sistema operativo, o al governo, o al fornitore dell’hardware.“

Tim Berners (da it.wikipedia.org)

Link:

Wikipedia – Neutralità della rete

Reverse SSH Tunneling con DD-WRT

Provando a creare un tunnel SSH remoto su DD-WRT ci si accorge che nonostante si provi ad aprire la porta remota su tutti gli indirizzi disponibili (0.0.0.0) o su uno specifico, il risultato è sempre lo stesso: la porta viene bindata solo a localhost.

Ammettiamo di trovarci sulla macchina “target”, che non può ricevere connessioni dall’esterno a causa del firewall, e che ci interessi creare un tunnel in modo tale da poterci connettere a un server locale dal nostro pc di casa “PC”.

Siccome su “PC” non abbiamo un server SSH, decidiamo di creare un tunnel remoto (in verde) con il nostro router, scavalcando così il firewall.

Abbiamo così aperto una porta sul router che è, però, raggiungibile solo da localhost.

Creiamo quindi un secondo tunnel, questa volta locale (in rosso) tra “PC” e il router, specificando come destinazione “localhost” e come porta, la porta remota del tunnel creato precedentemente.

A questo punto basterà connetterci con il nostro client alla porta locale che abbiamo scelto, la quale invierà i dati attraverso il tunnel (in rosso), il router si connetterà a localhost, cioè a se stesso, sulla porta dove è in ascolto il tunnel remoto (in verde), che porterà i dati fino al server su “target”.

Link:

Wikipedia: SSH
SSH Port Forwarding