mercoledì 25 aprile 2018

Exploring time





lunedì 23 aprile 2018

Piccoli pompelmini crescono




mercoledì 18 aprile 2018

Allora, quando si parte?

Ha già scelto il suo posto in caso di viaggi in macchina:


martedì 17 aprile 2018

Psicologia felina

Brontolo (il gatto in secondo piano) è ingordo e invidioso: se vede che do qualche croccantino a Lulù accorre tosto a reclamare con furia e arroganza la sua (non dovuta) parte, magari rubandola a Lulù:


Notare l'espressione di Brontolo:


Pic for reference:


lunedì 16 aprile 2018

Conteggio rose


Se ne vedi meno di tredici, cecàto.




Soluzione:


sabato 14 aprile 2018

venerdì 13 aprile 2018

mercoledì 11 aprile 2018

venerdì 6 aprile 2018

Offerta-Offerta-Offerta-Offerta

Devono svuotare i magazzini perché cambia gestione...


In offerta-offerta-offerta sembravano esserci solo:
  • merci il cui rapporto peso/volume è basso (vorrete mica far viaggiare i TIR per poche quintalate di roba?) oppure alto (vorrete mica far viaggiare i TIR semivuoti perché già troppo carichi?)
  • merci con un basso rapporto volume/margine o peso/margine (vorrete mica far viaggiare i TIR per margini di guadagno troppo bassi?)
  • merci strettamente regionali (vorrete mica far viaggiare i TIR con merce che altrove non si riesce a vendere?)

giovedì 5 aprile 2018

mercoledì 4 aprile 2018

Riparazione presa elettrica

Uff... non puoi fare l'elettricista, che spunta sempre qualcuno che pretende di insegnarti il mestiere!



martedì 27 marzo 2018

Come godo!! Corsair K63 power in my hands!

Ho comprato una spettacolosa tastiera Corsair K63.

Riepilogo ultime tastiere comprate:
  • giugno 2005: set mouse+tastiera Logitech Cordless Desktop EX-110 a infrarossi;
  • maggio 2015: Logitech K480 bluetooth;
  • marzo 2018: Corsair K63 USB.

Le Logitech sono "a membrana". La K480 è particolarmente rumorosa. Ho abbandonato Logitech e sono passato a Corsair perché volevo:
  • una tastiera meccanica, cioè comoda e veloce;
  • con connessione USB, perché da un bel po' non ho più bisogno di spostarla dalla scrivania;
  • ma non me ne importa quasi un fico secco del ghèmingh.
Ho scelto la Corsair K63 perché:
  • prezzo più abbordabile rispetto alle Wasd Ergodox Atreus etc;
  • tasti "lineari" Cherry MX Red (non sono quelli con lo "schiocco" troppo rumorosi da usare di notte);
  • senza il ridicolo tastierino numerico (del quale praticamente usavo solo il tasto Invio).
Caratteristiche dei tasti della Corsair K63:
  • l'evento "premuto un tasto" non richiede di schiacciare fino in fondo, ma solo fino a metà circa ("acchiappando" così anche le cliccate frettolose);
  • la forza di attuazione di un tasto è 45 centiNewton, cioè moderatamente leggera; sembra un pochino più riposante delle sopracitate Logitech;
  • dicono tutti che è "più veloce", per "dattilografi veloci", ma senza precisare in che senso; la velocità dipende da quanti errori di battitura la tastiera riesce a far evitare (e quindi, in secondo luogo, da quanto è effettivamente comoda da usare in tempi lunghi).
Caratteristiche generali:
  • è effettivamente più rumorosa della EX-110;
  • è molto pesante (1050 grammi senza contare il cavo USB) e ben piantata sulla scrivania;
  • layout italiano e tasto Invio verticale;
  • tasti multimediali in formato più piccolo (a membrana);
  • tastino "imposta retroilluminazione" (spento, 30%, 60%, 100%);
  • tastino "switch disattivazione tasto Windows";
  • LED caps lock e scroll lock (non avendo il tastierino numerico, è inutile avere num lock);
  • la retroilluminazione dei singoli tasti è programmabile con l'utility CUE per Windows (da scaricare dal sito ufficiale Corsair) oppure ckb-next per Linux e Mac (è un sorgente da compilare).
Dopo qualche giorno di utilizzo penso di poter già mandare in pensione le tastiere Logitech che avevo apprezzato da tanti anni, poiché la comodità dei tasti Cherry MX si fa sentire.

Di cosa potrei lamentarmi:
  • alcune grosse tastiere Corsair hanno una porta USB aggiuntiva per attaccarci il mouse o qualcosa di poco esoso in termini di corrente: la K63 non ce l'ha;
  • il cavo USB è in posizione centrale ed esce perpendicolare al lato lungo, non si può staccare. L'ostacolo più vicino deve stargli ad almeno 25mm dal bordo;
  • la confezione non conteneva altro che la tastiera e il micro-manualino cartaceo (in alcune offerte danno anche l'estrattore, pinzetta utile a scoperchiare i tasti per far pulizia);
  • non mi lamenterò del fatto che su questo modello la retroilluminazione è solo in rosso (non RGB come le Corsair più costose);
  • posso invece lamentarmi che il ckb-next ha ancora qualche bug (e il daemon si mangia il 4-5% di CPU del Core i5 anche quando non c'è niente da fare, più un altro 5-6% quando gli effetti speciali sono attivi), ma ogni tanto può essere utile per spararsi le pose in caso di visite di amici e parenti mettendo l'effetto Trippy (la tastiera serve per scrivere , non per guardarsela come un idiota e dire "uùuh!!").
Nelle prime ore di utilizzo mi accorgo dei vizi che avevo acquisito con la vecchia tastiera:
  • ero abituato a lasciare talvolta riposare qualche dito su un tasto senza premerlo (anche il pollice sulla barra spaziatrice)... se il dito è troppo pesante, il tasto viene attuato (!);
  • ero abituato a un corridoio di discesa più lungo quando da est la mano destra cercava di atterrare su PgUp/PgDown;
  • nei primissimi dieci minuti di utilizzo ho istintivamente cercato tre volte il tasto Invio dall'inesistente tastierino numerico.
Ecco il video di unboxing e prova - nel video non sto correndo sul serio - la velocità la potrò verificare solo dopo un po' di settimane di familiarizzazione. L'effetto vrasèra che si vede nel video è il "Trippy" del ckb-next.

domenica 25 marzo 2018

N900 con Maemo-Leste torna a ruggire!

Il bello di un "telefonino Linux open source" è che dopo oltre otto anni dall'acquisto c'è ancora gente che ci sviluppa. Il mio caro vecchio Nokia N900 torna a ruggire, alla faccia del suicidio della Nokia.

La distribuzione Maemo Leste si basa su una Debian moderna permettendo di usare anche i repository originali Maemo. Se è installato il pacchetto u-boot, può partire direttamente dalla memory card microSD senza toccare il filesystem originale su NAND-Flash.

Fase 1: recuperare una batteria ancora carica:


Fase 2: boot di Linux e quindi dell'ambiente grafico:


Fase 3: lancio il terminale e... ma guarda: kernel Linux 4.7.15 (gran bel salto rispetto al 2.6.28 del firmware originale):


Schermo graffiato, porta USB sfasciata, vari difettucci secondari, ma kernel Linux uscito questo mese! Non vedo l'ora che cresca.

sabato 10 marzo 2018

Italian Military Area Radiation Levels

Dal momento in cui sono entrato (circa le 17:15) fino al momento in cui sono uscito (circa alle 18:55) da una certa zona militare, la radioattività era sopra la media, un pochino sotto la soglia dell'«high level, closely watch the reading, find out why». Non è preoccupante, ma è significativo.

Cliccare per ingrandire


Software per creare il grafico: gmc-geiger-data
CPM massimo rilevato dal mio lettore Geiger: 98.
"Clicks" massimi in un secondo: 7.
microSievert/ora: sotto gli 0,65 uSv/hr.

Promemoria:
  • fino a 50 CPM (clicks per minuto): normale radioattività ambientale 
  • da 51 a 100 CPM: livello medio, controllare regolarmente
  • oltre i 100 CPM (cioè oltre gli 0,65 microSievert/ora): livello alto, controllare continuamente, cercare di capire il motivo
  • oltre i 1000 CPM: livello molto alto: lasciare la zona subito, e cercare di capire il motivo.

giovedì 8 marzo 2018

Ispezione felina

«Umano, devi rabboccare il liquido lavavetri».


mercoledì 7 marzo 2018

Configurare Wireguard

Per la serie: "perché non ci hanno pensato prima?"

Con le versioni più recenti del kernel Linux si può configurare un'interfaccia virtuale che crittografa point-to-point tutto il traffico in entrata e uscita incanalandolo in pacchetti UDP da far transitare su un'interfaccia reale.

Questa feature si chiama Wireguard, è open source scritto da cinesi stufi di essere spiati (e milioni di occhi già stanno scrutando da anni a caccia di vulnerabilità: lavoro facile, l'implementazione è appena quattromila righe di codice), è stata scritta per essere veloce e leggera ("consuma" solo un 5-8% in più di banda a parità di traffico) e interna al kernel. Presto manderà in pensione le darknet e le Vuppi Enne (VPN), notoriamente complicate da configurare, lente, e talvolta dipendenti da un servizio esterno non sempre onesto.

L'unico requisito di due sistemi connessi attraverso Wireguard è che nell'attivare le rispettive interfacce virtuali usino la stessa password (più esattamente, coppie di chiavi crittografiche). Funzionalmente simili a un tunnel TLS/SSL, anche se virtuali, in qualità di interfacce di rete sono utilizzabili con tutte le facility del kernel: routing, firewalling, traffic shaping, forwarding, etc. Per ora nelle maggiori distribuzioni il modulo Wireguard è fornito attraverso il DKMS ma verrà presto integrato nel kernel.

Esempio: ho due board Beagleboard xM sulla rete locale (rispettivamente 192.168.1.121 e 192.168.1.122) che parlano tra di loro usando servizi "in chiaro" (tipo http e ftp). Creo una rete Wireguard tra le due board inventando indirizzi 192.168.6.xyz sui quali far transitare quei servizi (che così non saranno più "sniffabili" dal resto della rete locale 192.168.1.xyz), mostrando che il traffico non vi transita in chiaro. Sulle board c'è Arch Linux ARM con systemd per cui su ognuna di loro ho fatto come segue.
Esatto, nel seguente esempio due board saranno connesse tra loro sullo stesso cavo fisico sia attraverso la rete locale 192.168.1.xyz, sia attraverso la nuova rete Wireguard 192.168.6.xyz. Dato che systemd è ormai ovunque (temuto solo da coloro che credono che le cose vecchie sono sempre migliori di quelle nuove, tipo quelli che leggono i libri al lume di candela), non vale la pena seguire i vecchi esempi che costringono a una battaglia frenetica coi vari comandi ip, ifconfig, route, ecc.
Non è necessario che le due board siano sulla stessa rete locale o che siano strettamente IPv4, è sufficiente che siano raggiungibili a vicenda - ad avere un indirizzo IP statico si possono fare cose simpatiche...

Prerequisiti: systemd versione 237, modulo wireguard e relativi tools.

Esempio di installazione pacchetti con ArchLinux: sudo pacman -S wireguard-dkms wireguard-tools

Generazione di una chiave crittografica casuale: wg genkey
Tale comando restituisce una "chiave privata" (da usare nella configurazione locale).
Esempio: OLu2pvKIOVYeJErLacH0iqYdMeOZwbv6SCcNL9AlMHE=
In ambito Wireguard, la "chiave privata" contiene anche la "chiave pubblica": quest'ultima, da usare nella configurazione del sistema remoto, va estratta dandola in pasto al tool wg:
echo OLu2pvKIOVYeJErLacH0iqYdMeOZwbv6SCcNL9AlMHE= | wg pubkey

Anche la "chiave pubblica" ha una codifica base64, qui per esempio ci ha restituito:
XmQUASiyksa2O//CY3NM0/p9UbT8+jWwlyyQptQaeU8=
A questo punto creo il file /etc/systemd/network/wg0.netdev per indicare al systemd che l'interfaccia wg0 vale per gli indirizzi 192.168.6.xyz e deve appoggiarsi all'indirizzo preesistente 192.168.1.xxx dell'altra board sulla porta UDP 51820 (la porta tipicamente utilizzata per Wireguard, ma va grosso modo va bene qualsiasi porta tra 1024 e 60000), e ci aggiungo la "chiave pubblica" dell'altra board:
[NetDev]
Name=wg0
Kind=wireguard
Description=interfaccia protetta

[WireGuard]
PrivateKey=OLu2pvKIOVYeJErLacH0iqYdMeOZwbv6SCcNL9AlMHE=
ListenPort=51820

[WireGuardPeer]
PublicKey=HIVoNJ3CdpjGFg2eDGTbkH/JewfmiB6wThIzqwiq9yc=
AllowedIPs=192.168.6.0/24
Endpoint=192.168.1.121:51820
Il file di configurazione va protetto per evitare che qualcuno dei tools consideri compromessa la chiave privata: chown root.systemd-network /etc/systemd/network/wg0.netdev ; chmod 640 /etc/systemd/network/wg0.netdev

Dopodiché creo il file /etc/systemd/network/wg0.network per descrivere al systemd la configurazione di rete - ci basterà solo l'indirizzo (abbiamo deciso 192.168.6.1 per la prima board e 192.168.6.2 per la seconda) e la classe (24 bit, cioè "192.168.6.xyz"):
[Match]
Name=wg0

[Network]
Address=192.168.6.1/24
Dal prossimo reboot l'interfaccia verrà attivata (che funzionerà solo se anche sull'altra board sono stati fatti i passaggi).

Dopo il reboot, per verificare che i moduli kernel sono stati caricati: lsmod | grep wireguard

Per verificare che l'interfaccia wg0 è stata configurata, è attiva ed ha il suo indirizzo di rete: networkctl; ip link; ifconfig; wg

Per verificare che le interfacce comunichino è sufficiente il ping attraverso il loro Wireguard; secondo l'esempio di cui sopra, dalla board configurata con 192.168.6.1 eseguire ping 192.168.6.2

Per verificare che il traffico transita crittografato al punto di sembrare munnezza si può eseguire sulla board che riceve i ping un tcpdump della sua interfaccia di rete reale (per esempio, come detto sopra, eth0) riguardo ai pacchetti remoti UDP. Il tcpdump può anche mostrare il contenuto dei pacchetti in esadecimale: tcpdump -x -i eth0 host 192.168.1.122 and udp port 51820
(e dall'altra parte effettuare il ping attraverso il Wireguard)
La seconda board manda i ping alla prima attraverso la Wireguard (192.168.6.xyz). Quei ping vengono criptati e fatti transitare sull'interfaccia di rete eth0 (per cui "sul cavo" risulteranno originati dall'host 192.168.1.122 come da esempio sopra citato, e perciò sulla board 121 occorre ascoltare i pacchetti ufficialmente provenienti dalla 122, ignorando quelli di altri protocolli e indirizzi). Indipendentemente dal protocollo, verranno trasmessi in UDP (non sto qui a spiegare i motivi per cui i progettisti di Wireguard hanno preferito la trasmissione stateless via UDP).

Il contenuto dei ping dopo l'header è riconoscibilmente criptato. Si può fare una prova più convincente con altri protocolli che trasmettono in chiaro.

Sulla prima board lanciamo un webserver e un tcpdump:
tcpdump -A -i eth0 host 192.168.1.122 &
ruby -run -ehttpd /tmp -p8000 &

Dalla seconda board lanciamo una normale richiesta:
curl 192.168.1.121:8000

Dal tcpdump vediamo in chiaro le stringhe HTTP (GET, headers, contenuto) nei pacchetti TCP.

Dalla seconda board lanciamo la stessa richiesta ma attraverso il Wireguard:
curl 192.168.6.1:8000

Dallo stesso tcpdump vediamo che non c'è nulla di leggibile, che è tutto transitato via UDP, e che sono cambiate anche le dimensioni dei pacchetti.

Se per analizzare il traffico si usa il Wireshark sulla eth0 si vedranno dei bizzarri pacchetti "DCERPC" con numeretti indecifrabili:



A titolo di curiosità (non lo consiglio in ambienti di lavoro), aggiungiamo una terza board che avrà come endpoint la prima e come chiavi le stesse della seconda.
Il suo wg0.netdev sarà uguale a quello della seconda (endpoint e chiavi), mentre il suo wg0.network avrà un altro indirizzo (diciamo 192.168.6.3). Ovviamente la seconda e la terza, avendo scambiato le chiavi solo con la prima, potranno comunicare solo con la prima (la prima avrà un singolo peer consistente in... due board diverse).
Si lascia come esercizio al lettore la configurazione di una rete wifi senza password in cui gli unici client che riescono a navigare sono quelli connessi via wireguard al nodo che fa forwarding, mentre i furbacchioni tutti contenti di sniffare il traffico si ritrovano nel Wireshark una immane catasta di munnezza googlando a tutta forza DCERPC decriptare DCERPC sproteggere DCERPC.