Aujourd'hui un truc obscur pour beaucoup d'entre nous : alsa. Pas la poudre blanche, mais le truc avec un mixer, enfin pas celui de la cuisine, mais celui de linux ...

Pour simplifier disons que alsa est une API présentée par le noyau et qui permet d'accéder à travers une interface unique à toutes les cartes son que vous pouvez avoir.

Fichier de configuration

Alsa étant relativement bien fait, ses utilisateurs (l'application qui émet du son, la gestion du volume ...) n'ont pas besoin de configuration particulière pour fonctionner. Mais il est possible de changer cette non configuration. Cela peut se faire soit de façon globale au système dans /etc/asound.conf soit spécifiquement à l'utilisateur dans ~/.asoundrc.

Que peut-on mettre dans ces fichiers ?

Là ça devient vite obscur et peu documenté. Mais nous allons voir que c'est assez simple. Il s'agit d'une configuration hiérarchique. Vous avez le choix entre les 2 formats suivants pour écrire des valeurs (ou un mix des 2) :

# commentaire
val.eur.1 "toto"
val.eur.2 "tata"
val.ue "help"

val {
  eur {
   1 "toto"
   2 "tata"
  }
  ue "help"
}

Éléments de configuration

Mais que peut-on bien mettre dans ce fichier ?

Ici les exemples sont nombreux, mais rarement expliqués.

Tout d'abord une liste détaillée se trouve ici : Asoundrc.txt

Reste à trouver ce que les attributs veulent dire. Ce qui va vous intéresser est essentiellement pcm qui permet de créer une nouvelle carte son (virtuelle). Les autres ne vous seront utiles que rarement et dépendront surtout du contenu de vos pcm.

Un pcm

La première chose à déclarer dans un pcm est son type, vous avez le choix parmi les différents plugins alsa. Contemplez la densité de la documentation, heureusement vous en avez un peu plus ici : pcm_plugins.html

Notez la présence de ladspa pour changer le pitch du son. J'ai déjà présenté son usage avec vlc pour accélérer un son sans en changer la hauteur.

Chaque type a ses paramètres spécifiques. Tous les plugins qui ne font que traiter le signal (comme ladspa ou softvol) ont un paramètre slave. Il faut bien comprendre de que cela signifie. Un slave est un autre plugin (oui c'est sans fin :-) qui va recevoir le son depuis le plugin que l'on configure. Donc le son transite de master vers slave lors de la lecture mais il transite de slave vers master lors de l'enregistrement.

Exemple

Maintenant prenons un exemple utile, ajouter une pré-amplification logicielle au système. Pratique lorsqu'on a un portable et qu'aucun ampli externe ne nous permet de monter le son alors que c'est l'enregistrement de youtube qui est très faible.

Comment faire ? Très simple, ajoutons une carte virtuelle de type softvol

pcm.softcard {
      type softvol
      slave.pcm "default"
# on associe un contrôle nommé pre-amp au mixage de la première carte son
      control.name "Pre-Amp"
      control.card 0 
}

C'est bien, mais cela veut dire qu'il faut indiquer à nos logiciels d'utiliser la carte softcard pour profiter de cet avantage. Quelques changements vont nous permettre de changer ceci pour tout le monde.

# on change la configuration du pcm par défaut
pcm.!default {
      type plug
# et on pointe bêtement vers la notre
      slave.pcm "softcard"
}

pcm.softcard {
      type softvol
# on laisse dmix choisir la bonne carte physique
      slave.pcm "dmix"
      control.name "Pre-Amp"
      control.card 0
# on en profite pour donner des limites plus sympa pour l'augmentation et la rédution du volume
      min_dB -5.0
      max_dB 20.0
      resolution 5
}

Avant de voir le contrôle, il faut lancer un premier test pour forcer la lecture du fichier de conf par alsa (c'est comme ça ...) :

# test de bruit presque blanc
$ speaker-test

Et maintenant nous avons un nouveau contrôle dans alsamixer (ou votre mixer préféré) permettant de régler la pré-amplification.

A vous de tester les autres plugins ...

Si vous avez aimé, il y a aussi :

1. MPD (Music Player Daemon)

Exécution

Savez-vous qu'on peut rendre n'importe quel fichier exécutable sous linux ? Bien sûr il suffit de faire un chmod +x, mais le noyau risque de vous envoyer balader si le fichier n'est pas réellement exécutable.

Mais je parle ici de rendre exécutable n'importe quel fichier, un jar, un source en C, un MP3 ...

Mais comment quoi que donc !?

Pour exécuter un fichier, le noyau lit les premiers octets du fichier et vérifie qu'ils correspondent à un format binaire (binfmt) connu. Il existe un système pour ajouter des formats binaires à ceux déjà supportés dans le noyau (en gros les elf et les scripts). Il s'agit du format misc.

Pour savoir si ce format est supporté chez vous, ce qui est très probable, lancez la commande :

$ cat /proc/sys/fs/binfmt_misc/status

S'il n'est pas supporté, il faut charger le module et monter le répertoire :

$ modprobe binfmt_misc
$ mount binfmt_misc -t binfmt_misc /proc/sys/fs/binfmt_misc 

C capital

Maintenant supposons vous vouliez rendre les fichiers .c exécutables. Vous pouvez soit utiliser un de mes anciens articles ... soit créer un petit script qui sera appelé à chaque exécution d'un .c :

#!/bin/sh
# /usr/local/bin/ccexec
gcc -Wall -o /tmp/cscript.$$ "$1" && shift && /tmp/cscript.$$ "$@"
ret=$? ; rm -f /tmp/cscript.$$ ; exit $ret

Et de faire en sorte qu'il soit réellement appelé :

$ echo ':cfile:E::c::/usr/local/bin/ccexec:' > /proc/sys/fs/binfmt_misc/register

Hop un test :

#include <stdio.h>
// test.c
int main() {
  printf("Coucou\n");
  return 0;
}

Et on lance :

$ chmod +x test.c
$ ./test.c
> Coucou

Yeah !!!

G tout compris

Maintenant, passons à l'exécution d'un gzip. Plutôt que de reconnaître le fichier à son extension, ce qui est franchement faible comme méthode nous allons vraiment détecter le type de fichier.

Allons voir la spécification, un fichier gzip se reconnait à ses 2 premiers octets qui doivent valoir 0x1f et 0x8b :

$ echo ':gzip:M::\x1f\x8b::/bin/gunzip:' > /proc/sys/fs/binfmt_misc/register

Même méthode et ça marche. Notez qu'il est possible d'utiliser n'importe quel champs de bits grâce à une masque et une position de départ, mais seulement dans les 128 premiers octets du fichier.

Enfin, certaines distributions vont vous installer des choses un peu plus utiles comme l'exécution des jar avec java ou celle d'exécutable windows avec wine.

Et pour une spécification plus détaillée de ce qu'il lest possible de mettre dans la ligne d'enregistrement, direction la documentation

PS : pour supprimer l'entrée : echo -1 > /proc/sys/fs/binfmt_misc/cfile

Si vous avez aimé, il y a aussi :

1. #!/usr/bin/gcc (bis)
2. Changer la priorité d’exécution des processus
3. Trucs et astuces (5)

Suite à de précédentes bidouilles, on veut faire mieux.

Multiboot

Donc grub peut booter plusieurs formats, l'un d'entre eux est le multiboot, un format de fichier bootable défini par les développeurs de grub espérant qu'il soit adopté par différentes distributions. Il souffre d'un certain nombre de faiblesses et n'est pas encore vraiment un standard. D'autant que grub lui-même ne supporte pas encore complètement la spécification pourtant très courte. Si vous ne voulez pas lire toute la spécification, allez directement au chapitre 4 où on trouve un code d'exemple prêt à compiler pour vous lancer dans le développement.

Vous trouverez un autre exemple chez quelqu'un qui s'est amusé à coder un space invaders bootable directement à partir de la spécification multiboot.

Alors c'est parti, reprenons notre projet précédent. Faites attention, le processeur est dans un état particulier lorsqu'on vous laisse la main (lisez le chapitre 3.2), à vous de vous en accommoder.

Mode graphique

Tout d'abord on voudrait changer le mode graphique, et si possible pour mieux que la première fois. Pour cela, on va utiliser le standard vesa 2.0 qui standardise des modes avec une plus grande définition et qui ajoute de nouvelles fonctions au bios pour manipuler la carte.

Choisissons le mode 0x118 (1024x768x24) avec 16 millions de couleurs. Plus besoin de gérer un palette puisqu'on écrit directement les couleurs RGB à utiliser pour le pixel. On aura tout de même une fonction de palette puisqu'on n'utilise qu'un petit nombre de couleurs placées sur une échelle.

Le problème c'est que vesa n'a pas prévu qu'on puisse appeler les fonctions de la carte en mode protégé sans passer au moins une fois par une interruption en mode réel. Multiboot est bien gentil, il a prévu le cas, malheureusement, grub n'implémente pas les fonctions qu'il devrait pour le faire pour nous. Un patch est disponible pour ceux qui voudrait quand même cette fonctionnalité.

Il nous faudra donc faire nous-même ces interruptions. Pour survivre au mode réel nous devrons être sous le premier Mo de RAM, or grub nous place juste au dessus (en 0x100000). Notre premier bout de code aura donc pour but de nous déplacer en dessous. Pour cela on commence par prendre l'en-tête multiboot (beaucoup plus simple que pour les zImage) et on écrit le code pour se déplacer en 0x1000 (choix arbitraire) :

        /* on se copie ailleurs */
        mov     $KERNEL_SIZE,%ecx /* en octets */
        mov     $KERNEL_ORIG,%esi /* source juste après ce secteur */
        mov     $KERNEL_DEST,%edi /* destination sous les 1Mo */
        rep movsw

        /* et on va dans notre nouveau noyau */
        ljmp    $0x8,$KERNEL_DEST

Bien, maintenant, il faut passer du mode protégé au mode réel et inversement pour pouvoir faire des interruptions. Choisissons comme toujours de ne pas réinventer la roue et repiquons le code de grub qui dispose déjà de ces fonctions en assembleur. Elles s'appellent real_to_prot et prot_to_real. Pour ceux qui voudraient comprendre comment faire, c'est partout sur le net. Comme le mode protégé a besoin de descripteurs de segment, on n'oublie pas de les définir aussi (lire la fin du fichier asm.S) .

Du coup on peut utiliser 2 fonctions vesa bien utiles dans notre code, set_mode pour mettre en place notre mode graphique, et get_modeinfo pour savoir comment l'utiliser. En effet, on voudrait, comme avant pouvoir accéder directement à la mémoire vidéo pour y mettre nos pixels. La fonction get_modeinfo est là pour ça, elle utilise la fonction 0x4F01 du bios. On lui passe une adresse dans laquelle elle va écrire une structure de données nous informant sur le mode choisi. On choisit l'adresse de cette structure au pif puisqu'on n'a pas de gestion de la mémoire et qu'on a toute la ram pour nous. On prend 8000:0000.

La structure renvoyée contient l'adresse du mapping de la mémoire vidéo en 28h, ainsi que ses dimensions. Cela nos permettrait de changer le mode dans notre code facilement (notez les conversions de type pour lire le bon nombre d'octets) :

        /* on récupère les infos sur le mode qui nous intéresse */
        get_modeinfo(0x118);
        /* conversion de l'adresse du format [segment:offset] au format à plat */
        data = (MODEINFO_SEG << 4)+MODEINFO_OFF;
        /* on joue sur les converstions pour la lecture du bon nombre d'octets en ram */
        video = (unsigned char*) *(unsigned int*)(data + 0x28);
        width = (int) *(unsigned short*)(data + 0x12);
        height = (int) *(unsigned short*)(data + 0x14);

Code

On repart du code de l'article précédent. On y apporte quelques modifications techniques liées au changement de mode. Par exemple l'écriture d'un pixel se résume à l'écriture des 3 couleurs au bon endroit en ram :

        int pos = bpp*(x + y*width);
        /* et on ecrit directement en mémoire vidéo */
        video[pos] = r;
        video[pos+1] = g;
        video[pos+2] = b;

Pour ceux qui veulent aller plus loin dans la compréhension du mode protégé, ça aurait pu aussi être l'occasion de mettre en place un segment séparé pour écrire en mémoire vidéo avec la commande lgdt.

On peut imaginer y ajouter des tâches, par exemple une sorte de thread pour gérer le clavier. Mais la ça commence à devenir complexe et il vaudrait mieux lire des OS existants pour bien comprendre tout ça. Par exemple il existe minix qui a été fait dans un but pédagogique.

Compilation

Une autre chose change, c'est la compilation. Puisque le format multiboot est plus simple, nous n'avons plus besoin du script setup.ld. Par contre, puisque notre binaire contient deux morceaux (souvenez vous de la copie sous les 1Mo en début d'article), on devra modifier notre compilation.

Ce qui se résume en 2 partie, une pour le code de copie fait pour tourner en 0x100000 :

LDFLAGS1="-nostdlib -Wl,-N -Wl,-Ttext -Wl,100000 -m32"
gcc $LDFLAGS1 -o boot.exec boot.o
objcopy -O binary boot.exec boot

Et une partie contenant tout le reste du code, qu'on va placer en 0x1000 :

LDFLAGS2="-nostdlib -Wl,-N -Wl,-Ttext -Wl,1000 -m32"
gcc $LDFLAGS2 -o kernel.exec start.o asm.o kernel.o debug.o
objcopy -O binary kernel.exec kernel

Et enfin une dernière copie qui va concaténer les 2 binaires :

# on force la taille pour éviter les problèmes avec le bootloader
dd if=/dev/zero of=mandel2 bs=256 count=32 2>/dev/null 
# la premiere partie
dd if=boot bs=256 count=1 of=mandel2 conv=notrunc 2>/dev/null
# la 2e partie a une position fixée dans le code de la première (boot.S + header.h)
dd if=kernel bs=256 seek=1 of=mandel2 conv=notrunc 2>/dev/null

Run

Encore une fois, il suffit de préciser le fichier à grub pour qu'il le boote :

kernel         (hd0,0)/boot/mandel

Vous trouverez les sources en pièce jointe de cet article, et en complément une image disque contenant les 2 projets avec un grub installé qui fonctionne directement sur qemu.

$ qemu image.dd

Bravo à vous !

PJ :

• asm.S
• boot.S
• compile.sh
• debug.c
• header.h
• kernel.c
• start.S
• mandel.dd

Si vous avez aimé, il y a aussi :

1. Le retour de la bidouille
2. En vrac (25)
3. En vrac (18)

Vous souvenez-vous du bon vieux temps ? Je vous parle du temps de l'autoexec.bat et des driver de quelques ko, le temps où on écrivait directement en mémoire vidéo, le temps de l'assembleur, du mode réel et des interruptions.

Hé bien cette époque bien que révolue nous a laissé des traces. Il est toujours possible de coder sans noyau, de faire son propre noyau, de se passer de système d'exploitation ou de booter directement sur une application en quelques secondes.

Boot loader

Choisissons un bootloader, grub par exemple, nous allons lui demander de lancer notre programme. Avec grub il existe plusieurs méthodes pour charger un os, entre autres :

• Chainloader charge 512 octets, met le processeur en mode en mode réel, tel qu'il serait après le passage du bios. Pratique pour partir de zéro, mais 512 octet c'est un peu petit et nous n'avons pas vraiment envie de gérer le chargement de fichier sur le disque en plus.

• Linux charge un noyau au format zimage ou bzimage et lui passe le contrôle en mode réel 16 bits. Il est possible de charger des fichiers de plusieurs méga avec le format bzimage.

• Multiboot charge un noyau au format multiboot et lui passe le contrôle en mode protégé 32 bits après un certain nombre d'initialisations. On utilisera cette méthode une prochaine fois.

zImage

On commence par une solution simple à mettre en place, un exécutable au format zImage. Le format est décrit dans la documentation des sources du noyau linux : /usr/src/linux-2.X.XX/Documentation/i386/boot.txt. C'est dans ce format que nous allons développer un binaire bootable directement.

Le bootloader (grub) lit l'en-tête du fichier zImage puis pose la première section (attention, taille limitée à quelques dizaines de ko) à l'adresse 0x90000, Ensuite, il lit le reste du fichier et le place en 0x1000 (pour une zImage, limitée à 512ko) ou en 0x100000 (pour une bzImage). Ensuite, dans le cas de linux, le noyau s'amuse à redéplacer tout ça selon un processus plus ou moins compliqué décrit ici et ici. Attention, ne prenez pas ces documents pour argent comptant, ils sont un peu dépassés. En pratique nous n'irons pas si loin puisque nous resterons en mode réel et que 512ko nous seront largement suffisant (640Ko ça devrait suffire pour tout le monde !).

Nous allons donc faire simple et récupérer le code de boot de linux pour lancer notre petit projet. Le fichier qui contient le code de lancement ainsi que les en-têtes qui vont bien s'appelle header.S.

Attention, il est écrit en assembleur GNU (gas), celui-ci diffère beaucoup de l'assembleur intel. Le point le plus important est que les arguments sont inversés (source puis destination). header.S Apportons quelques modifications au fichier pour qu'il corresponde à nos besoins :

• suppression des include
• changement de la version de format pour se simplifier la vie

-               .word   0x0209          # header version number (>= 0x0105)
+               .word   0x0207          # header version number (>= 0x0105)

• pas de payload (il faudra tout faire dans 4 secteurs (2Ko)

-payload_offset:                .long input_data
-payload_length:                .long input_data_end-input_data
+payload_offset:                .long 0
+payload_length:                .long 0

• suppression des appels à puts pour éviter les dépendances inutiles

-       calll   puts

• ajout des #define correspondant à nos besoins (surtout pour que ça compile)

+#define DEF_SYSSEG       0x1000                                  
+#define DEF_SYSSIZE  0x200
+#define ASK_VGA          0xfffd          /* ask for it at bootup */
+#define STACK_SIZE      512     /* Minimum number of bytes for stack */
+#define CONFIG_PHYSICAL_ALIGN 0x200000
+#define COMMAND_LINE_SIZE 2048

Ce fichier se termine par un appel à la fonction cmain qu'on codera en C, bien plus sympa à écrire que l'assembleur.

Fractint

Comme nous voulons avoir des résultats rapidement, nous allons choisir un projet simple, dessiner l'ensemble de Mandelbrot en vga. Résumons l'algorithme en 3 étapes : initialiser le mode graphique, afficher la fractale et attendre.

On utilise gcc (du projet gnu pour ceux qui suivent ;-), mais son compilateur C ne génère que de l'assembleur 32 bits. Donc la ruse de sioux est de préfixer le code par la directive suivante pour que l'assembleur le transforme code compatible 16 bits (nécessaire puisque nous sommes en mode réel) :

asm(".code16gcc");

Pour le mode graphique, choisissons le mode vga 0x13 (320x200x8), il est facile à utiliser car chaque pixel est mappé sur une adresse en RAM et donc adressable directement en mode réel à l'adresse 0xA0000 (A000:0000 pour les habitués de l'assembleur Intel 16 bits). Les vieux savent bien que la carte graphique se gère avec l'interruption 10h, fonction 0 pour choisir le mode vidéo.

C'est l'occasion de regarder comment on incruste de l'assembleur dans du code C avec gcc :

/* Je vous fais la version longue */
/* Le code assembleur paramétré (d'où les %%) */        asm ("pushl %%ebp; pushw %%ds; int $0x10; popw %%ds; popl %%ebp"
/* L'affectation des valeurs de retour  */                      :
/* L'affectation des paramètres */                              : "a" (mode)
/* La liste des registres à sauvegarder */                      : "ebx", "ecx", "edx", "esi", "edi");

On trouve en ligne les détails pour faire du code assembleur en gcc. Remarquez que si vous n'avez aucun '_:_' (pas de paramètre) les %% doivent être remplacés par des %.

Maintenant, la fonction pour modifier la palette de couleurs (8 bits, 256 couleurs, une palette) avec des valeurs RGB sur 6 bits :

/* la technique d'origine pour modifier la palette vga */
/* on modifie directement des registres de la carte graphique */
        asm( "outb %%al,%%dx" : : "a" (idx), "d" (0x03c8) );
        asm( "outb %%al,%%dx" : : "a" (r), "d" (0x03c9) );
        asm( "outb %%al,%%dx" : : "a" (g), "d" (0x03c9) );
        asm( "outb %%al,%%dx" : : "a" (b), "d" (0x03c9) );

Et la fonction pour modifier un pixel :

/* calcul de la position du pixel en mémoire vidéo */
        int pos = 320*y+x;
/* Technique à la mano car gas ne supporte pas l'adressage 16bits avec des segments
 * - on passe par ds qu'on doit sauvegarder
 * - la mémoire vidéo du mode vga 13h commence en A000:0000
 */
        asm ("push %%ds; movw %%ax,%%ds; movb %%cl,(%%bx); pop %%ds"
                : : "a" (0xA000), "b"(pos), "c" (color));

Le reste est un algorithme basique de calcul de Mandelbrot. Pour rappeler quelques souvenirs :

• c = (x,y)
• p0 = (0,0)
• p(n+1) = p(n)^2 + c
• plus p diverge vite, plus on est loin de l'ensemble (-> choix de la couleur)

Compilation

Il faut maintenant compiler tout ça pour en faire un binaire au format zImage.

On compile avec gcc en faisant bien attention à ne pas inclure la libc (et à spécifier une architecture 32 bits pour les amd64) :

CFLAGS="-fno-builtin -nostdinc -O2 -I. -Wall -m32"
gcc $CFLAGS -c header.S
gcc $CFLAGS -c kernel.c

Ensuite, il faut faire l'édition de lien (on fait toujours attention à la libc), nous avons besoin d'un script (setup.ld) pour maîtriser complètement le binaire sortant. Il est repiqué de linux, avec une instruction supplémentaire à la fin pour aligner la taille du binaire à celle précisée dans l'en-tête :

LDFLAGS="-nostdlib -Wl,-N"
gcc $LDFLAGS -o mandel.exec -T setup.ld header.o kernel.o

Et on extrait le binaire final de notre binaire au format elf :

# extraction du binaire
objcopy -O binary mandel mandel.exec

Grub, qemu

Il nous faut maintenant tester notre œuvre. Plutôt que de devoir rebooter notre vraie machine, nous allons utiliser une machine virtuelle complète (qemu, vmware, virtualbox ...), dans laquelle on installe grub.

Et dans votre menu (ou dans le shell grub) :

kernel (hd0,0)/boot/mandel

C'est jôliii !

Pour ceux qui veulent tester, il y a en pièces jointes, les sources ainsi qu'une image disque toute prête pour qemu contenant les sources, le binaire compilé, ainsi qu'un grub préinstallé avec un menu (et le contenu du prochain article avec, mais chut). Pour ceux qui n'ont pas tout suivi, essayez de lire les sources, ca peut être instructif.

$ qemu mandel.dd

Dans le prochain numéro, nous ferons la même chose en plus grand, plus beau et en mode protégé.

PJ :

• compile.sh
• header.S
• kernel.c
• setup.ld
• mandel.dd

Si vous avez aimé, il y a aussi :

1. Le retour de la vengeance de la bidouille
2. Vectorisation
3. En vrac (25)

Pour ceux qui n'ont pas tout compris au dernier article réseau, voici quelques compléments sur le protocole IP. Celui qui vous permet d'envoyer n'importe quelle information à l'autre bout de la planète.

Toute machine sur internet dispose d'une adresse IP (v4 pour l'instant). Écrite sous la forme w.x.y.z où chaque lettre est un nombre compris entre 0 et 255 (donc un total de 32 bits). A chaque fois qu'une machine veut communiquer avec une autre elle remplit un paquet ip qu'elle envoie sur le réseau. Ce paquet soit contenir au moins les informations suivantes :

IP source
IP destination
protocole
Diverses choses

L'ip source, c'est tout simplement l'ip de la machine qui envoie le paquet et l'ip de destination peut être récupérée par le dns si le nom complet de la machine est connu.

Ce paquet doit être envoyé au bon routeur qui se débrouillera avec, et c'est là qu'intervient la configuration de la machine.

Supposons que nous soyons le noyau et essayons de traiter le paquet

#on regarde toutes les routes et on sélectionne celle qui nous intéresse
$ ip route show 
# on regarde l'ip source et la carte à partir de laquelle on va envoyer nos paquets
$ ip addr show
#ces deux opérations peuvent être résumées ainsi
$ ip route get w.x.y.z

La configuration de votre réseau se fait (au niveau du noyau) avec les commandes

# activation de la carte
$ ip link set dev toto up
# mise en place d'un adresse ip (et de son réseau)
$ ip addr add 10.0.1/24 dev toto
# mise en place d'un routage
$ ip route add default via 10.0.0.2

Heureusement, tout cela est fait automatiquement par votre distribution (à la lecture de /etc/nerwork/interfaces pour debian).

Vous aurez remarqué la notion de réseau, qui est apparu sous la forme 10.0.0.1/24. Cela veut dire que l'adresse 10.0.0.1 appartient au réseau constitué des ip de 10.0.0.0 à 10.0.0.255. Nous l'avons déduit grâce au maque /24 (qui s'écrit aussi 255.255.255.0), c'est-à-dire que les 24 premiers bits sont fixe.

On a beau avoir un cerveau brillant et pouvoir faire ceci de tête, le plus simple pour ne pas se tromper est d'utiliser un commande qui fait les calculs pour nous :

$ ipcalc 10.0.0.1/24

Vous remarquerez que dans un réseau il y a toujours 2 adresses qui ne peuvent pas être utilisées : la première, qui sert à désigner le réseau lui-même et la dernière qui sert de broadcast (envoi des paquets à tout le monde). Le plus petit réseau possible est donc un /30 avec 2 ip. Il est possible de faire plus petit, mais ce n'est plus vraiment un réseau au sens IP. On peut faire communiquer 2 IP dans un /31 moyennant quelques variations dans la configuration.

Si vous avez aimé, il y a aussi :

1. iproute2
2. Routage amélioré
3. Des lutins dans votre noyau

Routeur

Un routeur, c'est une machine qui renvoie les paquets qui ne lui sont pas destinés vers d'autres machines qui les accepteront. Faisons-en un sous linux :

$ echo 1 > /proc/sys/net/ipv4/all/ip_forward

Facile hein ! Maintenant linux (le noyau) renverra tous les paquets qu'il reçoit (au niveau ethernet) mais qui ne lui sont pas destinés (au niveau IP). Reste plus qu'à maintenir une table de routage (avec la commande "route", "ip route" ou avec un démon dédié comme quagga qui le gère dynamiquement).

NAT

Parfois la machine de départ utilise des IP qui n'ont pas le droit d'aller sur internet (c'est pratique pour communiquer en interne, mais c'est tout). Le routeur (la passerelle) doit donc traduire ces IP privées en IP publiques (en général il utilise la sienne). C'est le NAT. Les réseaux ip privées sont : 10.0.0.0/8 172.16.0.0/12 et 192.168.0.0/16

Pour activer le nat sur un linux, il faut déjà qu'il fasse routeur (voir ci dessus), puis on transforme les paquets avec netfilter (netfilter est le fltre du noyau, iptables est la commande pour le piloter) :

$ iptables -t nat -A POSTROUTING -s 10.0.0.0/24 -o eth0 -j MASQUERADE

Firewall

Un firewall va examiner la couche IP et la couche TCP pour filtrer ce qui se passe. Il peut tout faire, couper, changer le paquet ... Tout ceci se fait avec iptables sous linux. C'est un peu complexe, donc voici simplement un exemple qui coupe un utilisateur :

$ iptables -A FORWARD -s 10.0.0.12 -j DROP

Pont

Un pont (bridge) relie 2 (ou plus) réseaux ethernet comme le ferait un switch. Pour faire un bridge sous linux on utilise la commande brctl.

# on crée un nouveau bridge nommé bridge0
$ brctl addbr bridge0
# on ajoute les cartes réseau au bridge (le bridge prend l'adresse mac de la première carte ajoutée)
$ brctl addif bridge0 eth0
$ brctl addif bridge0 eth1

Et voila, à partir de ce moment, les paquets sont bien retransmis sur le réseau, si un paquet arrive sur une interface, il est retransmis sur l'autre s'il y a lieu. Mais si on veut que l'ordinateur qui fait bridge soit aussi sur le réseau en question, il faut y ajouter quelques modifications :

# on désactive la pile ip sur les cartes du bridge
$ ip addr del 10.0.0.1/24 dev eth0
$ ip addr del 10.0.1.1/24 dev eth1
# et on l'active sur le bridge lui-même (représenté pare une carte réseau virtuelle)
$ ip addr add 10.0.0.1/24 dev bridge0

Réseaux multiples

La notion de réseau IP est décorrélé de la notion de réseau ethernet. Il est donc parfaitement possible d'avoir plusieurs réseaux IP sur le même réseau ethernet. Et cela se fait très simplement :

$ ip addr add 10.0.0.1/24 dev eth0
$ ip addr add 192.168.0.1/24 dev eth0

Tunnel

Un tunnel permet d'encapsuler un flux entre 2 machines dans un autre flux. Par exemple le tunnel ssh encapsule un flux tcp dans un flux ssh.

Faisons tunnel ip, avec le module gre du noyau :

# on crée un tunnel nommé tunnel0 
$ ip tunnel add tunnel0 mode gre remote 1.2.3.4
# ce tunnel est en fait une interface virtuelle qu'on configure
$ ip link set tunnel0 up
$ ip addr add 10.0.1.1 dev tunnel0
# un tunnel n'a que 2 bouts, on choisit de gérer le sous-réseau à la main
$ ip route add 10.0.1.2 dev tunnel0

N'oubliez pas qu'il faut faire la même chose à l'autre bout du tunnel (avec des ip inversée bien sûr) et vous avez maintenant une carte réseau sur chaque machine reliées par un câble virtuel.

Si vous avez aimé, il y a aussi :

1. Des lutins partout
2. iproute2
3. Aggrégation de lien

Imaginez que vous soyez un simple utilisateur (un compte dans une université par exemple), alors les joies de l'administration système vous sont interdites. Heureusement une bande de jeunes hippies a décidé de faire quelque chose contre nature, essayer de transformer le noyau en simple application qui tournerait dans l'espace utilisateur. Et ça a marché, le noyau est maintenant un processus comme les autres.

On peut donc faire tourner linux sur un système existant, théoriquement un bsd ou un solaris peut même faire l'affaire, on a même trouvé des fous pour porter linux sous windows (cherchez colinux, vous trouverez).

Le noyau

Si vous êtes sous debian prenez le paquet user-mode-linux, et si vous êtes fans de la compilation de noyau :

$ make menuconfig ARCH=um
$ make ARCH=um

Et voila, il suffit de lancer linux :

$ linux

Le système

Bon, tout n'est pas si simple, il faudra bien que vous ayez un système de fichier pour ce linux. Si vous n'êtes pas root, vous devrez le préparer sur une autre machine. Il vous faut faire une image disque, soit à partir d'une installation existante, soit une nouvelle installation (par exemple avec debootstrap) :

# récupérer un disque existant
$ dd if=/dev/sda1 of=/data/image.dd

# créer un nouveau disque
$ dd if=/dev/zero of=/data/image.dd bs=1M count=512
$ mke2fs -j /data/image.dd
$ mount -o loop /data/image.dd /mnt
$ debootstrap etch /mnt
$ umount /mnt

Maintenant que nous avons notre image, c'est parti :

$ linux ubd0=/data/image.dd

Les options

Vos pouvez saupoudrer de quelques options, la liste est disponible avec la commande :

$ linux --help

Auxquelles ils faut ajouter les commandes habituelles qu'il est possible de passer au noyau à travers le bootloader. Les commandes intéressantes sont :

• mem=64M : pour allouer une certaine quantité de mémoire au noyau, c'est toujours une bonne idée de le préciser
• hostfs=/home/user : pour autoriser l'accès au système de fichier de la machine hôte dans l'uml, il se monte avec la commande suivante :

mount -t hostfs none /host

Le réseau pour un utilisateur

Ensuite vous voudrez sûrement le réseau, et là, beaucoup solutions pour beaucoup de problèmes différents. Commençons pas le cas où vous êtes simple utilisateur (pas root). Vous avez le choix entre utiliser la connexion de la machine hôte ou faire un tunnel vers une machine (où vous êtes root) qui vous laissera accès à une ip et un accès complet.

Prenons le premier cas, vous n'aurez le droit qu'à ce qui est autorisé à un simple utilisateur c'est-à-dire des connexions TCP et UDP (avec une sorte de nat), pas de ping (/bin/ping est suid). Si slirp n'est pas installé, vous devrez le compiler :

# réseau hôte avec slirp
$ linux ubd0=/data/image.dd eth0=slirp,,~/bin/slirp
# le réseau reste à configurer dans l'uml

Dans le cas d'un tunnel. Si vde n'est pas installé, vous devrez le compiler :

# Un switch virtuel
$ vde_switch -s /tmp/switch1
# on y connecte notre nouveau noyau
$ linux ubd0=/data/image.dd eth0=vde,/tmp/switch1
# le réseau reste à configurer dans l'uml

# Sur la machine distante où vous êtes root, l'autre bout du switch
$ vde_switch -tap
# et là nat (vous pouvez aussi faire un bridge si vous voulez)
$ iptables -t nat -A POSTROUTING -s 10.0.0.1/24 -o eth0 -j MASQUERADE

# Et on connecte les 2 switchs virtuels
# à faire dans le sens qui vous intéresse
$ dpipe vde_plug = ssh remote.machine.org vde_plug

Si vous voulez seulement faire des réseaux d'uml local, vous pouvez aussi les brancher entre eux sans accès à l'extérieur :

# Un switch virtuel connecte 3 linux
$ vde_switch -s /tmp/switch1
$ linux ubd0=/data/image1.dd eth0=vde,/tmp/switch1
$ linux ubd0=/data/image2.dd eth0=vde,/tmp/switch1
$ linux ubd0=/data/image3.dd eth0=vde,/tmp/switch1

# ou si vous ne voulez pas installer vde, uml_switch est fourni directement avec uml
$ uml_switch -s /tmp/switch1
$ linux ubd0=/data/image1.dd eth0=daemon,,,/tmp/switch1
$ linux ubd0=/data/image2.dd eth0=daemon,,,/tmp/switch1
$ linux ubd0=/data/image3.dd eth0=daemon,,,/tmp/switch1

Le réseau pour root

Si vous êtes root vous aurez plus de facilité. Vous avez le choix (en plus des 2 précédents) entre vous attribuer une ip interne et faire du nat ou vous brancher directement sur le réseau de l'hôte (bridge).

Dans tous les cas vous allez faire une interface virtuelle qui apparaîtra sur la machine hôte :

# 10.0.0.1 est l'ip de l'interface virtuelle côté hôte 
$ linux ubd0=/data/image.dd eth0=tuntap,,,10.0.0.1
# À vous de configurer l'interface dans l'uml (par exemple avec l'ip 10.0.0.2)

Je vous laisse faire le reste comme un grand.

Plus

• Un howto plus détaillé
• man uml_mconsole vous aidera à manipuler l'uml pendant qu'il tourne
• Le wiki peut vous aider

Si vous avez aimé, il y a aussi :

1. La flexibilité pour tous
2. Git pour tous
3. Git à tous les étages