Signal

On a tout à fait le droit de ne pas partager à 100 % les idées et les procédés de Wikileaks, actuellement sur le devant de l’actualité, et certaines de ces critiques sont légitimes. Mais, a contrario, certains des procédés utilisés pour les faire taire ont un petit parfum qui, à titre personnel, me dérange.

L’expérience du jour : wikileaks.org ayant vu son DNS coupé par son hébergeur (problèmes d’attaques, officiellement), les discussions de ce matin sur Twitter consistaient à s’échanger “à la main” les adresses IP des miroirs… pas très pratique. Cette coupure de DNS fait suite à un déplacement du site de chez Amazon, aux USA, vers OVH, un hébergeur français.

Et puis j’ai fait une proposition toute bête qui a bien décollé et j’ai créé wikileaks.eu.org pour accomplir ma part, merci à tous ceux qui ont suivi et qui ont été ajoutés dans cete liste plus générale (section “miroirs DNS”).

Jean-Michel Planche ayant pris la peine de faire un résumé du contexte, je ne vais pas le paraphraser, allez voir son billet.

Voir aussi la lettre de mission d’Éric Besson (à Pascal Faure du CGIET) divulguée par LePost, qui vaut franchement le déplacement. Pour résumer, Éric Besson cherche un moyen d’expulser le site de France.

Un autre billet général chez Authueil sur la censure en général et celle de Wikileaks en particulier résume bien la question.

Et un article d’Écrans (Libération) résume bien la situation à l’exception d’une erreur : FDN n’héberge pas un miroir de Wikileaks, wikileaks.fdn.fr est juste un renvoi DNS suivant la méthode exposée ci-dessus.

Désolé pour ce billet un peu décousu mis à jour au fur et à mesure…

Mise à jour 18h45 : c’est maintenant le nom wikileaks.ch actif depuis ce matin qui est en carafe…

Mise à jour 4 décembre 2h35 : une liste plus complète chez Bluetouff.

In an attempt to evaluate different methods for measuring the performance of a TCP/IP connection, I’ve bumped into FreeBSD‘s getsockopt(TCP_INFO) system call, cloned from a similar call invented by Linux, which kindly returns interesting data about the current TCP connection.

I was mainly interested about round-trip time (RTT, called tcpi_rtt) and its standard deviation, mistakenly called tcpi_rttvar even though it’s not a variance.

I’ve written a small proof-of-concept tool accessible at http://eu.org:4500/ to display operating system information retrieved from the current HTTP access. The page currently runs on a FreeBSD 9-CURRENT machine; feel free to try it out, it works either in IPv4 or IPv6. Here’s a sample as of today:

This experimental page displays raw system TCP estimates, in microseconds.

Address: 2a01:e35:8b50:2c40::4
Estimated round-trip time: 15437
Estimated standard deviation: 27937

Note that the measures are very rough. First, the real resolution is about 1 millisecond (one kernel tick), not 1 microsecond. Then, several RTT samples are smoothed into the provided values, with a bigger weight for more recent samples. I left the actual values obtained from the kernel, for clarity, even though giving them up to a 1 microsecond resolution is somewhat misleading.

Then, of course, the results also depend on the number of samples, which tends to be low: the above page waits for the client HTTP headers to be fully received, then emits its own headers in reply, then waits for one second to give some time for the TCP ack(s) to come back, then displays the then-current estimations.

The results are probably sufficient for TCP’s internal needs, but they may differ wildly from real RTT values. Plus, the real RTT value depends on packet size, which TCP doesn’t seem to take into account. The above example is taken from my local network and displays over 15 ms for the RTT, whereas the real RTT is well below 1 ms (0.23 min, 0.4 average with 0.01 standard deviation, according to ping). The results are not always wildly up, I’ve noticed the opposite effect from a remote mobile phone displaying ~100 ms whereas the ping time was more like ~200 ms…

Feel free to use it and add comments below.

45 seconds of play, ~5 hours of desperate hacking.

A few days ago, my 4 year old daughter was playing with my mobile phone running Android 1.6. To let her play with the screen while avoiding any mishap, I locked the phone. It was obviously not enough, she instantly found the MENU key to unlock it.

So I had the brilliant idea to put on a locking pattern, the pretty method used on Android to really lock the screen.

After 5 unsuccessful tries, which my daughter reached in about 15 seconds, the pattern unlocking incurs a 30-second guard delay. I decided that the game was too risky (I found out later there’s also a 20-try hard limit, but we didn’t reach it) and took my phone back.

There, I had another brilliantly fatal idea: I clicked on the “forgot the unlock pattern” button which just appeared, just out of curiosity to see what would happen next. The phone asked for my Gmail account and password. I filled the requested information, but it didn’t unlock the phone; apparently this is a known Android bug that I didn’t know about. And, contrary to what I naively assumed, there was no way to get back to the unlock pattern screen. I rebooted the phone. No change, no escape.

Then it dawned on me that I was 600 kilometers away from home, for almost a full week, without all my computer tools. And I was locked out of my own phone.

(more…)

Un train miniature est utilisé à Princeton pour faire tourner un morceau de californium-252 afin de calibrer les équipements d’un petit réacteur à fusion…

[via Slashdot]

C’est Fabrice Bellard (qui n’en est pas à son coup d’essai, ni concernant Pi, ni sur d’autres sujets) qui nous gratifie d’un de ses nouveaux exploits… le résutat en décimal (1/2 octet par chiffre) prend à lui seul 1137 Go d’espace disque… Des extraits sont là.

Le record précédent d’août 2009 est dépassé de peu (120 milliards de chiffres en plus, tout de même), c’est surtout l’économie comparée des moyens mis en oeuvre dans le nouveau record qui est stupéfiante : un simple PC à peine gonflé.

Ça y est ! Depuis ce matin, IPv6 est maintenant utilisable dans les jails FreeBSD (version 8 seulement pour l’instant), grâce au travail que Bjoern Zeeb vient d’intégrer dans les sources.

Cela m’a permis de me débarrasser de la petite manipulation un peu tordue montée l’an dernier pour mettre en place la passerelle v6 -> v4 de ce blog.

Il a juste fallu que dans /etc/rc.conf je change la ligne :

   jail_signal_ip="192.168.58.99"

en :

   jail_signal_ip="192.168.58.99,2001:660:330f:f800::2"

Et bien sûr recompiler Apache et refaire sa configuration avec l’option IPv6, et régler quelques menus détails comme la création d’une nouvelle adresse v6, son ouverture dans les filtres IP, et sa mise à jour dans le DNS…

L’an dernier, ayant lu les docs Apache 2.2 dans un moment d’égarement, je parlais des extensions RFC 2817 du module SSL permettant de ne plus multiplier les adresses IP (maintenant de plus en plus rares en v4) lorsqu’on héberge plusieurs serveurs web sécurisés sur une même machine, une plaie avec https. On attendait alors la sortie de Firefox 3.

Celui-ci étant maintenant arrivé depuis un bon moment, je me suis réattaqué ce soir à la question, titillé par un article récent de Stéphane consacré à la légèreté proverbiale de X509.

(more…)

In preparation for the impending doom of IPv4, and in order to put my money where my mouth is [fr], I decided to make this blog natively accessible through IPv6.

The first problem I ran into is that my blog runs in a FreeBSD jail. Jails are a fine way to run a virtualized environment but they only support IPv4 at the moment. So I had the following options:

• implement IPv6 in jails myself (this wouldn’t have happened overnight);
• wait for someone else to;
• abandon the idea;
• find a workaround.

Finally I found a workaround, using Apache mod_proxy as a separate server to provide a IPv6 frontend (a configuration called reverse proxy). (more…)

Photographs here under Creative Commons license.

The plan

(sorry French readers, this one is better suited to English)

Participate from ENST, Paris, France in Mozilla 24, a multi-site, multi-continent, high-quality video conference operated from Keio University in Tokyo, Japan. Two simultaneous video streams (one from our conference room to Japan, the other one back) allow interactivity between the speakers in our room and audiences on the other sites.

The room setup

Video from Paris to Japan has been sent using a laptop running FreeBSD 6, with a Firewire card and a 100 Mbps ethernet port. The PC receives the DV video from a professional camera on the Firewire port and reemits it, encapsulated, on the ethernet port. Here’s a picture of the setup:

The blue cable is the 100 Mbps ethernet cable. The other cable is the firewire cable, plugged on the PCMCIA adapter.

(more…)

Voilà l’incantation qui marche chez moi :
mplayer mms://mozilla24.stream.co.jp/mozilla24-01_live500