Lors du dernier meeting HZV, Mandarine a présenté le TI Launchpad, un circuit d'expérimentation réalisé par TI et basé sur un micro-contrôleur MSP430. J'avais auparavant entendu parler d'Arduino, et même eu dans les mains un Arduino prêté par l'ami Tixlegeek, mais j'hésitais à en acheter un. Et je dois avouer que le MSP430 m'a fait craquer.
Arduino vs. TI Launchpad
Lorsque Mandarine a présenté le TI Launchpad, je m'attendais à quelque chose d'un peu roots, et je n'ai pas été déçu. Contrairement à l'Arduino, le Launchpad ne possède aucun module d'extension officiel (ce qu'on nomme shields chez Arduino), et il faut donc tout concevoir. Cette approche me plaît plus qu'avec Arduino, car cela nécessite une documentation et un effort de la part de celui qui veut concevoir un circuit basé sur un MSP430. Mais c'est vrai que cela peut faire peur. Toutefois, mis à part cet aspect rustique de la board de TI, plusieurs éléments m'ont séduit.
Le premier d'entre eux est l'existence de plusieurs packages Debian et Ubuntu offrant la possibilité de développer en C et même en C++ sur MSP430, en s'affranchissant royalement d'une surcouche, contrairement à Arduino où il faut employer l'IDE Arduino et la couche Arduino, qui n'améliore pas les performances. Ces outils sont opensource, et dérivés des outils standards GNU comme binutils et gcc. J'aime.
Second point, le prix. C'est idiot, mais à 4 dollars et 30 cents le TI Launchpad, cela vaut vraiment le coup. Sans compter qu'un MSP430 de rechange est fourni (si vous grillez celui installé sur la board), ainsi que des contacteurs et un micro-quartz que l'on peut souder pour améliorer la stabilité de l'horloge. Et un cordon USB. Pour seulement un peu plus de 4 dollars. Comparé aux 20 et quelques euros réclamés pour un Arduino UNO, c'est très intéressant.
J'ai donc décidé d'en commander deux, pour voir exactement ce que c"est et comment cela pourrait me servir dans mes projets hardware. Et je viens de les recevoir.
Unboxing du TI Launchpad
Je dois avouer que tout cela est très bien packagé: une belle boîte (quoique, dans mon cas recouvertes d'étiquettes en tout genre), une présentation soignée, et des stickers de surcroît !
Installation de la toolchain
La toolchain est en réalité un ensemble d'outils permettant de développer et compiler des programmes pour le MSP430 du Launchpad. Heureusement, plusieurs paquets existent pour les distributions Debian et Ubuntu:
msp430-gcc msp430-libc mspdebug
Mais en réalité, ces paquets ne sont disponibles que sur Ubuntu 10.10 ou Debian sid (testing). Or ma distribution de choix est Squeeze (Debian 6.0), et ces paquets ne sont pas compatibles. J'ai bien essayé de les installer à la barbare, mais rien n'y fait. Pas le choix donc que de trouver une solution alternative: la compilation from scratch.
Pour les heureux possesseurs d'une Debian Squeeze qui souhaiteraient comme moi tester le Launchpad de TI et son MSP430, je vous livre dans les lignes suivantes la technique pour installer proprement et correctement la toolchain, testé et approuvé.
L'outil msp430-gcc est en réalité une version modifiée du célèbre compilateur GNU GCC, et un projet créé par des adorateurs ultimes du MSP430 a été créé de manière à fournir aux libristes un moyen de créer cette toolchain: j'ai nommé le projet mspgcc. Ce projet contient un ensemble de patches à appliquer à des versions publiées et stables d'outils GNU (comme binutils et gcc) afin d'obtenir des binaires permettant de compiler des programmes pour MSP430.
Avant toute chose, il faut passer root sur sa machine, et créer un dossier dédié à la construction de la toolchain:
$ su - # mkdir msp430 # cd msp430
On s'assure ensuite d'avoir tous les paquets nécessaires à la compilation:
msp430:/# apt-get install libmpfr-dev libncurses5-dev zlibc zlib1g-dev libx11-dev libusb-dev libreadline6-dev libgmp3-dev libmpc-dev make
Ensuite, on récupère la version LTS (Long-Term Support) de mspgcc :
msp430/:# wget -O mspgcc.tar.bz2 http://downloads.sourceforge.net/project/mspgcc/mspgcc/mspgcc-20120406.tar.bz2?r=&ts=1359415411&use_mirror=ignum msp430/:# tar xvjf mspgcc.tar.bz2 msp430/:# mv mspgcc-20120406 mspgcc msp430/:# cd mspgcc msp430/mspgcc/:#
On jette un oeil aux versions des logiciels requis pour les patches:
msp430/mspgcc/:# ls -Al drwxr-sr-x 2 root root 4096 6 avril 2012 docs drwxr-sr-x 4 root root 4096 6 avril 2012 htdocs -rw-r--r-- 1 root root 342378 6 avril 2012 msp430-binutils-2.21.1a-20120406.patch -rw-r--r-- 1 root root 390548 6 avril 2012 msp430-gcc-4.6.3-20120406.patch -rw-r--r-- 1 root root 382048 6 avril 2012 msp430-gdb-7.2a-20111205.patch -rw-r--r-- 1 root root 9 6 avril 2012 msp430-libc.version -rw-r--r-- 1 root root 9 6 avril 2012 msp430mcu.version -rw-r--r-- 1 root root 2955 6 avril 2012 README -rw-r--r-- 1 root root 52679 6 avril 2012 RELEASES.TXT
Cette version de mspgcc se base sur la version 2.21.1a de binutils, la version 4.6.3 de gcc et la version 7.2a de gdb. On télécharge ces logiciels sous forme d'archive de code source dans le dossier courant:
msp430/mspgcc/:# wget ftp://ftp.gnu.org/pub/gnu/binutils/binutils-2.21.1a.tar.bz2 msp430/mspgcc/:# wget ftp://ftp.gnu.org/pub/gnu/gcc/gcc-4.6.3/gcc-4.6.3.tar.bz2 msp430/mspgcc/:# wget ftp://ftp.gnu.org/pub/gnu/gdb/gdb-7.2a.tar.bz2
Et on les décompresse dans le dossier courant:
msp430/mspgcc/:# tar xvjf binutils-2.21.1a.tar.bz2 msp430/mspgcc/:# tar xvjf gcc-4.6.3.tar.bz2 msp430/mspgcc/:# tar xvjf gdb-7.2a.tar.bz2
On applique ensuite les patches du projet mspgcc. Attention, cette étape est cruciale, si vous l'oubliez la suite ne fonctionnera pas !
msp430/mspgcc/:# cd binutils-2.21.1 msp430/mspgcc/binutils-2.21.1/:# patch -p1 < ../msp430-binutils-2.21.1a-20120406.patch msp430/mspgcc/:# cd ../gcc-4.6.3/ msp430/mspgcc/gcc-4.6.3/:# patch -p1 < ../msp430-gcc-4.6.3-20120406.patch msp430/mspgcc/:# cd ../gdb-7.2/ msp430/mspgcc/gdb-7.2/:# patch -p1 < ../msp430-gdb-7.2a-20111205.patch msp430/mspgcc/gdb-7.2/:# cd ..
Avant de commencer à construire la toolchain, il faut au préalable créer un dossier de destination dans lequel on installera les binaires. J'ai opté pour /opt/msp430, mais libre à vous de choisir le nom et l'emplacement qui vous plaît.
msp430/mspgcc/:# mkdir /opt/msp430 msp430/mspgcc/:# export BUILD=/opt/msp430
On configure et on compile les binutils:
msp430/mspgcc/:# cd binutils-2.21.1 msp430/mspgcc/binutils-2.21.1/:# ./configure --target=msp430 --prefix=$BUILD msp430/mspgcc/binutils-2.21.1/:# make && make install msp430/mspgcc/binutils-2.21.1/:# cd ..
On configure et on compile gcc:
msp430/mspgcc/:# cd gcc-4.6.3 msp430/mspgcc/gcc-4.6.3/:# mkdir gcc-build msp430/mspgcc/gcc-4.6.3/gcc-build/:# ../configure --target=msp430 --enable-languages=c,c++ --prefix=$BUILD msp430/mspgcc/gcc-4.6.3/gcc-build/:# make && make install
Et pour terminer, on configure et on compile gdb:
msp430/mspgcc/:# cd gdb-7.2 msp430/mspgcc/gdb-7.2/:# ../configure --target=msp430 --prefix=$BUILD msp430/mspgcc/gdb-7.2/:# make && make install
Les outils de compilation ont été installés dans le dossier /opt/msp430 (ou celui que vous avez paramétré). Il ne reste plus qu'à installer la libc compilée pour le MSP430 et les entêtes. Pour cela, il faut récupérer sur le site du projet les fichiers suivants:
msp430mcu-20120716.tar.bz2 msp430-libc-20120716.tar.bz2
La compilation de la libc nécessite que le binaire msp430-gcc, produit lors de la compilation de gcc pour msp430, soit accessible dans le PATH:
msp430/:# export PATH=$*PATH*:$BUILD/bin
On peut ensuite décompresser la libc, la configurer, la compiler et l'installer:
msp430/:# tar xvjf msp430-libc-20120716.tar.bz2 msp430/:# cd msp430-libc-20120716 msp430/msp430-libc-20120716/:# ./configure --prefix=$BUILD msp430/msp430-libc-20120716/:# cd src msp430/msp430-libc-20120716/src:# make && make install msp430/msp430-libc-20120716/src:# cd ../../
Et terminer par l'installation des entêtes de développement:
msp430/:# tar xvjf msp430mcu-20120716.tar.bz2 msp430/:# cd msp430mcu-20120716 msp430/msp430mcu-20120716/:# export MSP430MCU_ROOT=$(pwd) msp430/msp430mcu-20120716/:# scripts/install.sh $BUILD
Bon, voilà une bonne chose de faite ! On a installé gcc, gdb, la libc et les entêtes de développement. Nous allons aussi modifier le fichier /etc/profile pour qu'il prenne en compte nos binaires créés. Pour cela on l'édite, et on ajoute la ligne suivante à la fin du fichier:
export PATH=$*PATH*:/opt/msp430/bin
On recharge ensuite notre profil:
# source /etc/profile
Installation de mspdebug
Mspdebug est l'outil nécessaire pour programmer et déboguer le MSP430. Il s'agit encore une fois d'un projet opensource, que l'on va installer sur notre machine. Téléchargez la dernière version sur Sourceforge, puis installez-la:
msp430/:# tar xvzf mspdebug-0.21.tar.gz msp430/:# cd mspdebug-0.21/ msp430/mspdebug-0.21/:# ./configure && make && make install
Configuration d'UDEV
Afin que notre Launchpad soit détecté par USB, il faut s'assurer qu'une règle est bien présente dans la configuration d'UDEV. Si elle n'y est pas, il faut la créer:
# cat /etc/udev/rules.d/46-launchpad.rules ATTRS*idVendor*=='0451',ATTRS*idProduct*=='f432',MODE='0660',GROUP='plugdev'
Une fois cela effectué, vous pouvez vous amuser avec votre launchpad. Vous trouverez notamment un programme exemple sur Hack a Day, et la manière de programmer le MSP430 avec mspdebug. Je ferai certainement un prochain billet sur le développement sur Launchpad.
Bon, pour la route je vous donne mon Helloworld:
int main(void) {
/* disable watchdog */
WDTCTL = WDTPW + WDTHOLD;
P1DIR = BIT0|BIT6;
P1OUT = BIT6;
while(1) {
if ((P1IN & BIT3)==BIT3)
P1OUT = BIT6;
else
P1OUT = BIT0;
}
}
Et mon Makefile:
CC=msp430-gcc
CFLAGS=-Os -Wall -g -mmcu=msp430g2231
OBJS=main.o
all: $(OBJS)
$(CC) $(CFLAGS) -o main.elf $(OBJS)
%.o: %.c
$(CC) $(CFLAGS) -c $<
clean:
rm -fr main.elf $(OBJS)
Conclusion
Le Launchpad de TI est tout à fait valable, car pas cher et quand même très bien fourni avec son MSP430. Certes, cela nécessite plus de travail qu'avec un Arduino, mais c'est un peu comme avec Linux, on a plus de contrôle sur le système et on peut donc en faire exactement ce que l'on veut. Une philosophie que j'apprécie tout particulièrement. Testez, découvrez, bidouillez avec le Launchpad de TI.
On nous tanne le mou depuis des années avec le piratage, l'HADOPI et les méchantes personnes adeptes du téléchargement de type pair à pair, ou P2P. C'est encore très présent de nos jours avec la volonté de l'HADOPI de filtrer les sites de streaming, ou de lutter encore et sans merci contre les (derniers) adeptes du P2P. Ou du moins ceux qui n'ont pas encore découvert MegaUpload & consors et les joies du téléchargement direct. Malheureusement, cette chasse aux sorcières est vaine et pousse les choses dans le mauvais sens.
Une chasse qui tourne court
Plusieurs serial-downloaders se sont fait attraper par la Haute Autorité, mais à ce jour aucun d'eux n'a été envoyé dans un tribunal. Il semble que le troisième volet de la riposte graduée ne soit pas encore très prisé par la HADOPI elle-même, comme le montre le cas de l'enseignant Thollot. Elle préfère le pédagogique au répressif, en conformité avec sa raison d'être.
La société mandatée par les ayants-droits et autorisée par l'HADOPI à collecter les adresses IP des pirates a montré ses faiblesses, révélées par Bluetouff, et l'interconnexion entre la Haute Autorité et cette société est toujours interrompue, bien que l'audit de sécurité mené par HSC ait été réalisé et le rapport remis.
A quelques semaines des élections, les programmes des candidats divergent, et certains parlent déjà de supprimer cette Haute Autorité qui ne sert à rien, si ce n'est à faire peser au dessus de la tête de Madame Michu une bonne vieille épée de Damoclès. "Attention, si tu télécharges, ca va couper !", comme disait notre ami Dédé.
Les artistes se meurent ... mais ne se rendent pas !
Alors oui, on va me dire que les artistes se meurent, et que la rémunération de la création n'est pas ce qu'elle devrait être. Pouvez-vous me dire ce que l'HADOPI a fait pour améliorer la rémunération de la création d'œuvres ? Hmm ? Pas grand chose,`aneffé <http://www.laquadrature.net/fr/hadopi-albanel-passe-son-oral-020>`_. Bon, je ne commenterai pas la bonne santé des cinémas français, ni le regain d'intérêt des spectateurs pour la 3D, ou encore les records battus par Intouchables ou Bienvenue chez les ch'tis. Le modèle de rémunération français est obsolète, qu'on se le dise. Plusieurs artistes ont démontré qu'ils pouvaient être rémunérés (et très bien rémunérés) pour leur travail en se passant d'intermédiaires, avec une interaction directe avec leur public, comme Radiohead ou encore Louis CK.
Et non, les intermédiaires ne sont pas morts, je suis sûr qu'il y a encore de la place pour des fans de marketing viral, des adeptes et accros à Twitter et Facebook, et des personnes à même de faire connaître des artistes par leur dimension sociale. Ces gens là ont un avenir dans le monde artistique. Tout comme les artistes eux-mêmes. L'heure de la dématérialisation a sonné le glas d'un système archaïque, et tend à être la norme d'une jeunesse qui a grandi avec YouTube, DailyMotion et iTunes.
Les acteurs du futur de la création ne sont pas ceux que l'on attend. Non, ce n'est pas aux fans de musiques, de groupes, de mouvements divers de pousser au changement; ce n'est pas non plus aux maisons de disques de sauter le pas, de tenter l'aventure numérique. Non. Ces changements, ces prises de risques, ce sont aux artistes de les faire, de les prendre. Les artistes sont le moteur de la création, ce sont eux qui créent et font vivre leurs œuvres. En n'acceptant pas un modèle figé et ancien, en utilisant les nouveaux modes de communication et de diffusion ils toucheront un plus large public, et bénéficieront de cela. Et s'il y a une chose dont je suis sûr, c'est que ce public saura le leur rendre. Comme je l'ai mentionné dans un précédent post: osez. C'est à vous de faire l'avenir de la création artistique, ne soyez pas attentistes. Okay, je pense que vous avez saisi mon propos.
Et les réseaux dans tout ça ?
Eh bien ce sont eux qui en pâtissent, car un des effets de la répression des téléchargements de contenus illicites via P2P est la migration d'une grande partie des pirates vers des solutions non-fliquées, comme le streaming ou le téléchargement direct (direct download, ou DDL), abusant ainsi du modèle client/serveur et générant un trafic monstre. Trafic tellement important, que plusieurs FAIs ont bien essayé de le limiter en douce. En fait, il s'agit d'un rétro-pédalage dans l'innovation technologique. Je m'explique.
Le système classique (qui a dit ancien ?) est basé sur un ou plusieurs clients demandant une ou plusieurs ressources à un serveur. On a donc un seul serveur qui dessert une certaine quantité de clients. Au delà d'un certain nombre de clients, le serveur reçoit trop de demande et ne peut toutes les satisfaire: il y a saturation (et ce brave serveur ne va pas s'en remettre de suite). L'avantage du système de téléchargement P2P, c'est que dès qu'un client a récupéré un bout d'une ressource, il la partage aux autres (et agit donc comme serveur à son tour), ce qui a pour conséquence d'augmenter l'offre tandis que la demande augmente, et donc de pouvoir assurer une très bonne disponibilité des ressources. Cela a aussi pour effet de répartir la charge sur l'ensemble du réseau, et d'éviter que le serveur ne soit un goulot d'étranglement. Ce principe d'échange est tellement efficace qu'il est désormais intégré de base dans plusieurs jeux pour réaliser les mises-à-jour, comme sur World of Warcraft (Blizzard) par exemple.
En condamnant la technologie P2P, on force plusieurs milliers (millions ?) de clients à revenir à l'ancien modèle, et à saturer de nouveaux les fournisseurs de ressources. Et forcément, la demande explose et le ou les serveurs ne suivent plus trop. Quand on pense qu'avec le P2P tout allait mieux ...
Un réseau dans le réseau dans le réseau dans le ...
Tout cela pour en arriver à ce dernier paragraphe, qui cette fois traite de bon sens. En criminalisant les personnes qui téléchargent des contenus soumis au droit d'auteur via des réseaux P2P ou même DDL, on les pousse à consommer du VPN à 5€/mois (un marché prometteur d'ailleurs), à utiliser bon nombre de moyens de chiffrement et d'anonymat, et à être paranoïaques. Non seulement les VPN*s et les moyens de chiffrement réduisent les performances, mais en plus ils créent un réseau dans le réseau. Cette tendance est d'ailleurs d'actualité, avec notamment `l'apparition et l'évolution des PirateBoxes <http://wiki.daviddarts.com/PirateBox_DIY>`_, ou encore l`es réseaux communautaires *Mesh <http://www.harakiwi.net/actualites/reseau-mesh-wifi-larme-absolue-anti-hadopi-2767.html>`_ voire même un réseau satellitaire communautaire et libre !
Il est très dommage de devoir réinventer la roue, et de se réapproprier des technologies et des moyens permettant d'échapper au contrôle et à la censure, encore plus de devoir créer un nouveau réseau libre au sein d'un réseau existant, comme le font ToR ou encore Freenet. N'était-ce pas la volonté même des créateurs de ce super-réseau qu'est Internet ? N'est-ce pas là un vecteur de Liberté, offert à tout un chacun ayant accès à l'Internet ? Oh wait ... il faut payer. Pourquoi perdre son temps à tenter de limiter, contrôler, un réseau en évolution et devenu essentiel à bon nombre de gens et de sociétés aujourd'hui ? Que seraient Facebook, Google, Microsoft sans Internet ?
Les initiatives de réseau communautaires sont louables, en ce sens qu'elles permettent un accès à un réseau gratuit avec des moyens modestes, bien que pour certaines un peu utopiques à mon goût. Mais le coup de la PirateBox, sorte de TAZ où l'on peut partager et échanger librement, j'avoue que je suis fan :).
C'était un de ces soirs durant lesquels je geeke jusqu'à tomber de sommeil, sauf que là j'étais en vacances. C'est ennuyeux, les vacances. Alors j'ai pris la (sage) décision de mettre à profit mon temps disponible pour avancer mes nombreux projets. Et comme à mon habitude, je n'ai pas pu m'empêcher de diverger et d'aller titiller d'autres sujets. Je ne sais plus trop pourquoi, mais je me suis intéressé à un moyen d'évaluer de manière fiable ou presque le trafic d'un serveur distant, et la première chose qui m'est venue à l'esprit est l'analyse du champ Identification des datagrammes IP.
Premiers tests, et premières déceptions
J'ai donc entamé la recherche d'une méthode efficace permettant d'évaluer le trafic d'un serveur distant, en me basant sur l'évolution du champ Identification du protocole IP. Ce champ est en réalité un compteur sur 16 bits (entier non-signé), incrémenté de 1 à chaque émission de paquet. Au vu des quantités de paquets émis par un serveur, ce compteur boucle assez régulièrement, et il est donc très difficile de déduire quoi que ce soit. Ce champ est aussi souvent appelé IP/ID.
J'ai donc commencé mes tests par le développement d'un outil en Python, utilisant Scapy, et émettant à intervalle très court deux requêtes ICMP Echo Request, calculant le temps de parcours depuis l'envoi, et essayant de déterminer la vitesse d'évolution des IP/ID. L'implémentation n'a pas été un problème en soit, par contre les résultats n'étaient pas au rendez-vous, et pour cause: la mesure de temps n'est pas fiable. En réalité, nous ne disposons que d'une référence pour cette mesure de temps: la machine émettrice. Le réseau Internet étant ce qu'il est nous ne sommes pas sûrs de plusieurs choses: * les paquets peuvent avoir été routés via des chemins différents entre les deux requêtes * des latences réseau ont pu se produire, et faire varier le temps d'émission./réception des paquets Autant de facteurs qui rendent la mesure imprécise, et au vu du laps de temps très court séparant l'envoi des deux paquets, l'erreur introduite est élevée. Il n'est donc pas fiable d'employer cette méthode pour déterminer la quantité de trafic qu'émet un serveur distant.
Les timestamps à la rescousse
Heureusement, le protocole ICMP met à notre disposition d'autres types de messages, comme celui permet de demander à une machine distante de nous envoyer des indications sur son horloge interne (Timestamp), ce qui a pour intérêt de pouvoir nous renseigner sur l'heure d'émission du paquet. En effet, le protocole ICMP étant un protocole de couche 4 (Transport), ses datagrammes sont encapsulés dans des datagrammes IP (protocole couche 3). Autrement dit, en envoyant un message ICMP Timestamp Request (Code:0, Type:13), le serveur distant peut y répondre avec un paquet ICMP contenant notamment un Timestamp paramétré par la machine ayant effectué la requête, et un Timestamp correspondant à l'heure d'émission de la réponse.
Il ne me fallait pas plus de choses pour que j'implémente une variante de l'outil précédent, prenant en compte cette fois-ci une mesure de temps beaucoup plus précise. Bien sûr, il faut que le serveur distant testé réponde à ce type de requête ICMP, ce qui n'est pas monnaie courante. Mais j'ai pu identifier certains sites connus qui y répondent favorablement: www.hsc.fr, www.lemonde.fr, www.lefigaro.fr, etc ... L'exemple ci-dessous, réalisé avec l'utilitaire hping2, démontre bien les réponses reçues:
virtubox:/home/virtualabs# hping2 -1 -K 0 -C 13 -r www.hsc.fr HPING www.hsc.fr (wlan0 217.174.211.25): icmp mode set, 28 headers + 0 data bytes len=40 ip=217.174.211.25 ttl=53 id=21302 icmp_seq=0 rtt=23.3 ms ICMP timestamp: Originate=2647898 Receive=2647955 Transmit=2647955 ICMP timestamp RTT tsrtt=24 len=40 ip=217.174.211.25 ttl=53 id=+15 icmp_seq=1 rtt=24.0 ms ICMP timestamp: Originate=2648899 Receive=2648955 Transmit=2648955 ICMP timestamp RTT tsrtt=24 len=40 ip=217.174.211.25 ttl=53 id=+6 icmp_seq=2 rtt=23.5 ms ICMP timestamp: Originate=2649899 Receive=2649955 Transmit=2649955 ICMP timestamp RTT tsrtt=23
Le timestamp qui m'intéressa fut celui dénommé Transmit, correspondant à l'heure de transmission. Ce timestamp est en réalité le nombre de millisecondes écoulées depuis 00h00, et est donc suffisamment précis pour être utilisé. De là, j'ai développé un premier outil affichant un aperçu visuel du trafic, toujours en Python avec la bibliothèque curses. Le résultat n'est pas super joli, mais fait l'affaire:
J'étais assez satisfait du résultat, bien que cet outil ne casse pas trois pattes à un canard. Néanmoins, après différents tests sur des serveurs publics, j'ai pu noter les inconvénients suivants:
Et cela a commencé à m'ennuyer, je suis donc reparti à la recherche de la méthode ultime permettant de déterminer dans tous les cas de figures la quantité de trafic supporté par une machine distante. Et c'est devenu un poil plus complexe ...
Approche probabiliste
Je me suis rapidement rendu à l'évidence, après plusieurs tentatives infructueuses: réaliser une étude analytique pure de la variation du champ IP/ID est une pure perte de temps, à cause de la faible entropie de ce compteur. Il me fallait partir dans une autre direction, et trouver une approche différente, mais toutefois fiable. Et c'est là que m'est venu l'idée de prendre le problème dans l'autre sens. Si une machine subit un trafic conséquent, alors il devrait être très difficile de prédire la valeur du prochain IP/ID retourné. Il s'agit ici d'une simple constatation probabiliste. Plus il y a de trafic, plus le champ IP/ID varie, et plus il est difficile de prédire sa prochaine valeur. Il existe toutefois un cas de figure, mais qui reste très peu probable: celui où le trafic est conséquent et constant.
Il m'a donc semblé intéressant de tenter cette approche. J'ai donc entamé le développement d'une preuve de concept, toujours en Python, qui visait à réussir une prédiction pour un serveur donné. Malheureusement, ceci est très difficile à obtenir, surtout lorsque l'on cherche à prédire exactement la valeur du prochain IP/ID. J'ai donc introduit une variable représentant une marge d'erreur augmentant progressivement (suite aux tests infructueux), et en faisant varier cette marge d'erreur de manière exponentielle, j'ai pu obtenir des résultants probant.
La recherche de prédiction exacte et/ou approximative permet, lorsqu'elle est réalisée sur une durée suffisamment longue, de pouvoir associer un score (heuristique) à la quantité de trafic émis par la machine distante. Il y a dans le cas présent une relation qui lie cette quantité de trafic (et de manière indirecte, la variation de cette quantité de trafic) à la difficulté de prédiction du champ IP/ID. En évaluant la difficulté de prédiction, on peut tenter de déduire la quantité de trafic. Il sagit d'une méthode probabiliste, aboutissant à un résultat fiable (qualitatif) mais non-quantitatif, permettant d'apprécier la quantité de trafic par rapport à un trafic de référence. Il semblerait toutefois qu'en cas de présence de répartiteurs de charge ou lorsque l'intervalle de temps entre deux mesures est trop grand, la mesure ne soit pas fiable.
To be continued ...
Je suis actuellement en train d'approfondir cette méthode d'évaluation probabiliste, en tentant notamment de lier la difficulté de prédiction d'IP/ID à la quantité de paquets émis par le serveur, bien que cela ne me semble pas évident du tout. De même, je continue mes tests afin de vérifier la validité de mes résultats, bien que pour le moment ils soient positifs.
Je publierai mon analyse dans les détails par la suite, ainsi que le code source de ma preuve de concept.