Catégories
Open-source Systeme

Mise à jour de FreeBSD avec freebsd-update

Petite note à destination des utilisateurs de FreeBSD qui souhaite maintenir leur système à jour. Nous allons utiliser l’utilitaire freebsd-update.

La première chose à faire est de vérifier la version actuelle de votre système FreeBSD:

# uname -a
FreeBSD monbeauserveur 7.0-RELEASE FreeBSD 7.0-RELEASE #0

Si la version actuelle diffère de la dernière version disponible, on lance la mise à jour:

# freebsd-update upgrade -r 7.1-RELEASE

# freebsd-update install

On relance le système:

# shutdown -r now

On finalise la mise à jour:

# freebsd-update install

Puis on relance une dernière fois le système:

# shutdown -r now

Enfin on vérifie que tout est OK:

# uname -a
FreeBSD monbeauserveur 7.1-RELEASE FreeBSD 7.1-RELEASE #0

Il est également conseiller de mettre à jour vos logiciels tiers en suivant cette procédure.

Catégories
Open-source

GStreamer, la théorie…

Nous allons dans ce billet aller un peu plus dans le détail du fonctionnement de GStreamer (le Framework multimédia libre).

C’est quoi donc ?

GStreamer est un framework multimédia: c’est à dire un ensemble de bibliothèques, d’outils et de conventions permettant le développement d’applications (source Wikipédia). Par multimédia, on attend ici la manipulation d’objets vidéo et audio.

Il est composé:

  • d’une architecture logicielle comprenant un coeur et de nombreux plugins (plus de 150 pour la version 0.10)
  • d’API pour le développement avec le support de nombreux langages
  • d’outils de tests (gst-launch), de documentation (gst-inspect) et de présentation (gsteditor)

Architecture générale de GStreamer

GStreamer est composé d’un cœur (GStreamer Core) permettant de construire une séquence d’actions à effectuer sur vos objets multimédia. Ce cœur s’occupe de la communication entre les différentes briques en gérant les entrées/sorties. Il manipule les données sous forme de blocs et se base sur une architecture logicielle objet.

Les plugins manipulent les objets multimédia. On peut diviser les plugins en différentes catégories:

  • gestion des entrées (sources) audio et vidéo: les entrées peuvent être des fichiers multimédia, des équipements (Webcam, caméra DV) ou des flux réseaux (par exemple venant d’un streaming).
  • gestion des protocoles: permet une gestion des protocoles de communication réseau. Avec le support de protocoles simples (UDP, TCP) ou plus complexes (RTP/RTSP).
  • gestions des formats: les données multimédias sont dans des conteneurs (AVI, OGG, MPEG…). Gstreamer permet, via des plugins, de gérer ces conteneurs (lecture, mux, demux…).
  • gestions des codecs: le fait que les codecs audio/vidéo soit proposé dans Gstreamer sous la forme de plugins comporte de gros avantages (normalisation d’un codec à l’autre, facilité de changement de codec dans une application, cicle de développement plus cours pour inclure un plugin dans GStreamer).
  • gestion des filtres: il existe autant de possibilité de filtres audio et vidéo que votre imagination peut produire.
  • gestion des sorties (sinks) audio et vidéo: Les sorties peuvent être des fichiers, des équipements (écrans) ou des flux réseaux.

Il faut noter que les plugins GStreamer sont livrés sous la forme de 3 packages:

gst-plugins-good: ceux sont les plugins jugés de bonnes qualités par les développeurs et qui sont distribué sous licences LGPL.

gst-plugins-ugly: ceux sont les plugins jugés de bonnes qualités mais qui peuvent poser des problèmes de licenses (non libres).

gst-plugins-bad: ceux sont les plugins en développement dont la qualité et/ou stabilité doivent être améliorés.

Comment fonctionne GStreamer

Afin d’expliquer le plus simplement le fonctionnement de GStreamer, nous allons prendre l’exemple d’une application ayant pour but de lire un fichier multimédia au format OGG (contenant des données audio encodées en Vorbis et vidéo encodées en Theroa) pour l’afficher sur votre écran et l’écouter sur vos haut parleurs.

Le schéma du framework correspondant est le suivant:

Pipeline

La classe principal est nommé pipeline. C’est l’enveloppe qui va contenir l’ensemble des actions a effectuer.

Element

Le Pipeline contient une chaine d’élements (elements). L’élément est la classe la plus importante dans GStreamer. A chaque élément est associé une fonction (plugin).

On distingue 3 types d’élements:

  • Les éléments sources (« source element »). Ils produisent des données.
  • Les éléments de sorties (« sink element »). Ils ne produisent pas de donnée. Ils sont donc souvent en bout de pipeline (exemple: xvideosink, permet d’afficher une vidéo à l’écran).
  • Les éléments de filtrage (« filter element »). Ils ont une ou plusieurs entrées et une ou plusieurs sorties. Ils effectuent des traitements sur les données et les réinjecte dans le pipeline.

Voici par exemple l’élément qui permet la lecture d’un fichier depuis votre disque dur: file-source.

Pour vous donner une idée, voici le code C qui permet la création d’un élément de test (fakesrc):

#include <gst/gst.h>
int
main (int argc,
char *argv[])
{
GstElement *element;
/* init GStreamer */
gst_init (&argc, &argv);
/* create element */
element = gst_element_factory_make (« fakesrc », « source »);
if (!element) {
g_print (« Failed to create element of type ’fakesrc’\n »);
return -1;
}
gst_object_unref (GST_OBJECT (element));
return 0;
}

Les lecteurs familiers avec GLib ne seront pas dépaysés…

Pads

Les pads sont les entrées/sorties des éléments. Ils servent à interconnecter les éléments entre eux. Il peut inclure des fonctions de vérification afin de s’assurer que le format des données correspond à ce qu’il attend. On peut distinguer deux sous ensembles de pad:

  • les pads de type « sink », permettant de faire entrer des données dans un élément
  • les pads de type « src » (source), permettant de faire sortie des données d’un élément

Il est possible d’associer plusieurs pads sinks et srcs à un même élément.

Exemples de pads pour l’élément vorbis-decoder:

Les liens entre les éléments se font toujours entre un pad src et un pad sink:

Les pads sont de loin les objets les plus complexes dans GStreamer. Ils contiennent un ensemble de paramètres (statique ou dynamique) permettant de définir les données attendues ou générées. Par exemple en tapant la commande « gst-inspect theoraenc » qui donne la description du plugin de décodage video Theroa:

Pad Templates:
SRC template: ‘src’
Availability: Always
Capabilities:
video/x-raw-yuv
format: I420
framerate: [ 0/1, 2147483647/1 ]
width: [ 1, 2147483647 ]
height: [ 1, 2147483647 ]

SINK template: ‘sink’
Availability: Always
Capabilities:
video/x-theora

On peut y voir qu’il s’attend à avoir comme source une vidéo au format RAW-YUV, avec un nombre d’image par seconde et une taille pouvant varier selon le range affiché. En sortie, l’élement produira un vidéo au format THEORA.

Bins

Les bins sont des pipelines prédéfinis que l’on peut inclure comme de simple éléments dans une nouveau pipeline. Celà permet de simplifier grandement certaines actions complexe (rtpbin en est un bon exemple !).

Exemple de création d’un bin en langage C:

#include <gst/gst.h>
int
main (int argc,
char *argv[])
{
GstElement *bin, *pipeline, *source, *sink;
/* init */
gst_init (&argc, &argv);
/* create */
pipeline = gst_pipeline_new (« my_pipeline »);
bin = gst_bin_new (« my_bin »);
source = gst_element_factory_make (« fakesrc », « source »);
sink = gst_element_factory_make (« fakesink », « sink »);
/* First add the elements to the bin */
gst_bin_add_many (GST_BIN (bin), source, sink, NULL);
/* add the bin to the pipeline */
gst_bin_add (GST_BIN (pipeline), bin);
/* link the elements */
gst_element_link (source, sink);
[..]
}

Conclusion

J’espère que cette rapide introduction vous aura un peu éclairé sur les possibilités de GStreamer. Nhésitez pas à poser des questions et remarques sur le sujet dans l’espace GStreamer du forum de Nicolargo.

Sources:

Catégories
Open-source

Actualité open-source de la semaine #55

L’actualité open-source de la semaine…

L’image de la semaine


Quand Tuz remplace Tux
(mais juste pour la version 2.6.29 du noyau Linux)

Tout le monde en parle, sauf moi…

L’actualité du libre et de l’open source en vrac:

Autres choses ?

Catégories
Open-source Reseau Web

Installation serveur NAT-PMP sous FreeBSD

MiniUPnP est une implémentation libre du protocole NAT-PMP. Développé par Apple, ce successeur de UPnP IGD permet de configurer automatique et à la demande des applications des règles de NAT sur votre routeur d’accès. Free vient d’ajouter cette fonction sur le firmware des Freebox.

Nous allons voir dans ce billet comment fonctionne ce protocole et comment transformer votre routeur/firewall PF FreeBSD en un daemon NAT-PMP.

C’est quoi NAT-PMP ?

NAT-PMP est un protocole basée sur le protocole Bonjour. Ce dernier utilise des trames UDP sur le port 5351 qui sont envoyé vers l’adresse de la passerelle par défaut de votre réseau.

Il permettant à une application de:

  • récupérer son adresse IP publique (comment le PC va être vu sur Internet)
  • ajouter une règle de NAT PF (ou IPFW) sur le routeur

Si l’adresse publique de la passerelle par défaut change, une alerte au format multicast (adresse 224.0.0.1 sur le port 5351) sera envoyée sur le réseau. Elle contiendra en donnée la nouvelle adresse.

Installation du daemon sur FreeBSD

Le daemon en question s’appelle minipnpd et est présent dans les ports de FreeBSD (/usr/ports/net/miniupnpd).

L’installation est classique:

portinstall net/miniupnpd

Il faut également ajouter les règles suivantes dans votre fichier de configuration PF (/etc/pf.conf par défaut):

# NAT section
# UPnPd rdr anchor
rdr-anchor « miniupnpd »

# Rules section
# uPnPd rule anchor
anchor « miniupnpd »

puis relancer les règles PF:

pfctl -f /etc/pf.conf

et enfin ajouter la ligne suivante dans votre fichier /etc/rc.conf:

miniupnpd_enable= »YES »

La configuration doit se faire par un fichier /usr/local/etc/miniupnpd.conf. Vous pouvez utiliser le template suivant (à adapter à votre réseau):

# WAN network interface
ext_ifname=em0
# if the WAN interface has several IP addresses, you
# can specify the one to use below
#ext_ip=

# there can be multiple listening ips for receiving SSDP traffic.
# the 1st IP is also used for UPnP Soap traffic.
listening_ip=192.168.0.254
port=5555

# bitrates reported by daemon in bits per second
bitrate_up=131072
bitrate_down=524288

# default presentation url is http address on port 80
#presentation_url=

# report system uptime instead of daemon uptime
system_uptime=yes

# notify interval in seconds default is 30 seconds.
#notify_interval=240

# log packets in pf
#packet_log=no

# uuid : generated by the install a new one can be created with
# uuidgen
uuid=%%UUID%%

# UPnP permission rules
# (allow|deny) (external port range) ip/mask (internal port range)
# A port range is <min port>-<max port> or <port> if there is only
# one port in the range.
# ip/mask format must be nn.nn.nn.nn/nn
allow 1024-65535 192.168.0.0/24 1024-65535
deny 0-65535 0.0.0.0/0 0-65535

Pour lancer le daemon, il faut lancer la commande suivante:

/usr/local/etc/rc.d/miniupnpd start

Pour tester

Le plus simple est d’utiliser une des applications compatibles UPnP (voir liste dans le Wiki) ou bien d’utiliser le client en ligne de commande miniupnpc (compilable sous Linux, BSD, Mac OS X et Windows…).

Conclusion

Bien sûr ce daemon peut présenter un trou de sécurité assez important (possibilité d’ajouter des règles sur votre Firewall), il faut donc prendre toutes les précautions nécessaires sur les réseaux sensibles (notamment au niveau de la configuration de la section UPnP permission rules).

Catégories
Open-source Reseau

SJitter version 0.18

Grâce à la contribution de Thierry Legras, voici une nouvelle version de SJitter, mon outil en ligne de commande permettant de tester un réseau, notamment au niveau débit, délai et gigue. SJitter est disponible sous Linux, BSD, Mac OS X et Windows (via cygwin).

Cette nouvelle version apporte un meilleur control au niveau du tag permettant de faire les tests en IPv6 et surtout la possibilité (via l’option « -s ») de fixer le champs ToS des paquets IPv4 (très utile pour tester votre configuration QoS).

La page officielle de SJitter est ici, la forge .

Catégories
Open-source

Compilation de GStreamer sous Windows

Lorenzo Cammilleri, stagiaire ingénieur, vient de finaliser une procédure pour compiler GStreamer (le framework multimédia) sous Microsoft Windows. Avant de lui laisser le clavier, je vous donne l’adresse de son blog ou il trace sont travail:

http://lorenzocam.wordpress.com/

Ce billet est largement inspiré de cette page ici. Ayant rencontré de nombreux problèmes, Andoni Morales Alastruey a modifié sa page puisqu’il manquait certaines étapes qui sont aussi décrites ici.

Voici la marche à suivre pour pouvoir compiler Gstreamer Winbuilds avec Visual Studio.

Gstreamer

– Télécharger et installer Tortoise SVN: ICI

Dans le menu du click droit de la souris apparaît maintenant “SVN Checkout”.

– Dans un dossier vide, faire SVN Checkout de cette adresse : https://forja.rediris.es/svn/csl-longomatch/GStreamer-WinBuild/trunk

Les fichiers et dossiers vont être progressivement téléchargés.

Outils externes

– Installer Python
– Installer Perl

DirectX SDK

– Télécharger et installer le DirectX SDK

– Ouvrir le fichier C:\Program Files\Microsoft SDKs\Windows\v6.1\Samples\Multimedia\DirectShow\BaseClasses\baseclasses.sln avec Visual Studio

– Compiler en mode Debug_MBCS et Release_MBCS

– Ouvrir le fichier build\vsprops\common.vsprops de l’environnement Gstreamer et changer les macros MicrosoftSDK et DirectX pour spécifier les bons chemins

– Ouvrir le fichier build\GStreamer.sln et compiler en mode ReleaseWdkCrt sans se soucier des erreurs

– Compiler ensuite en mode Release : à ce moment il ne devrait plus y avoir d’erreurs !

Voilà tout !

Catégories
Open-source

Actualité open-source de la semaine #54

L’actualité open-source de la semaine…

L’image de la semaine

Et en plus ils décident…

Tout le monde en parle, sauf moi…

L’actualité du libre et de l’open source en vrac:

Autres choses ?

Catégories
Systeme

Automatiser la synchronisation iSync

Vous avez un Mac et un téléphone portable ? Vous connaissez alors surêment le logiciel iSync qui permet de synchroniser vos contacts et calendriers.

Il manque cependant une fonction importante à ce petit logiciel: la possibilité d’automatiser cette synchronisation. En attendant qu’Apple ajoute cette fonction à iSync (et oui c’est ça le problème avec les logiciels propriétaires, il faut attendre :(), voici un petit hack qui va fonctionellement nous rendre le même service.

Nous allons pour cela utiliser un AppleScript. Il faut éditer un fichier nommé SyncNow.scpt  dans le répertoire ~/Library/Scripts/ et contenant le code suivant:

tell application « Finder »
set iSyncRunning to 1
tell application « iSync » to synchronize
tell application « iSync »
repeat while (syncing is true)
delay 5
end repeat
if iSyncRunning is not true then
quit
end if
end tell
end tell

Ce script va ouvrir iSync, lancer un synchronisation, puis fermer iSync. Si le téléphone n’est pas à porté de Bluetooth, le script boucle jusqu’à ce que la synchronisation soit faite.

Vous pouvez tester le bon fonctionnement de ce script en ouvrant un terminal et en saisissant la commande suivante:

~/Library/Scripts/SyncNow.scpt

Afin d’automatiser le lancement de ce script, nous allons utiliser crontab (venu du monde unix). Elle permet de lancer une commande à une heure précise. Il faut ouvrir un terminal, puis saisir:

crontab -e

Vous allez vous retrouver dans l’éditeur « vi ». Pour ajouter la ligne suivante, il faut au préalable cliquer sur la touche i.

0 11 * * 1-5 osascript Library/Scripts/SyncNow.scpt

Pour sortir de l’éditeur vi, il faut appuyer successivement sur les touche ESC ensuite : puis x et enfin ENTREE.

Et voilà, tout les matin à 11h00 (0 11), du lundi au vendredi (1-5), le script sera lancé et la synchronisation effectué !

Catégories
Open-source

Question à deux balles… quoi que…

En discutant ce midi lors d’un groupe de travail open-source, j’ai entendu la question suivante:

« Un logiciel sous licence libre contaminante (GPL par exemple) est récupéré par une société. Celle-ci traduit le logiciel dans un autre langage de programmation et le diffuse sous une licence propriétaire.

Quel point de la licence libre permet à l’auteur initial de ce logiciel de se retourner contre la société ? ».

J’avoue que je suis resté un peu sec sur la réponse…

D’après vous quels sont les arguments en faveur du logiciel libre dans ce cas précis ? 

Catégories
Open-source Reseau

Simuler un lien WAN sous Linux

Il peut être utile, dans le cadre de tests applicatifs, de simuler sur votre réseau local (LAN), les caractéristiques d’une liaison distante (WAN). En effet, vos applications peuvent très bien fonctionner sur un réseau LAN et devenir inexploitable sur des liaisons WAN.

Nous allons utiliser le module Net:Netem des noyaux Linux 2.6 pour simuler les caractéristiques suivantes:

  • Bande passante
  • Délai de transit
  • Perte de paquet
  • Duplication de paquet
  • Re-arrangement de paquet

La configuration de ce module se fait via la commande en ligne tc.

Simuler un délai de transit constant

Le délai est le temps de transit réseau d’un paquet IP. Il dépend de pas mal de paramètres (traversé des équipements, taille des buffers et distance physique entre les deux points du réseau). Nous allons utiliser la commande delay qui va simuler un délai de transit de X ms sur tout les paquets IP sortant de l’interface réseau. On va utiliser la commande « ping » pour vérifier que tout fonctionne comme prévu.

Test du réseau avant la commande tc:

$ ping 192.168.29.1
PING 192.168.29.1 (192.168.29.1) 56(84) bytes of data.
64 bytes from 192.168.29.1: icmp_seq=1 ttl=64 time=0.290 ms
64 bytes from 192.168.29.1: icmp_seq=2 ttl=64 time=0.204 ms

On simule un délai de 40 ms sur tout les paquets sortant (soit environ le délais sur une liaison ADSL):

sudo tc qdisc add dev eth0 root netem delay 40ms

Test du réseau après la commande tc:

$ ping 192.168.29.1
PING 192.168.29.1 (192.168.29.1) 56(84) bytes of data.
64 bytes from 192.168.29.1: icmp_seq=1 ttl=64 time=40 ms
64 bytes from 192.168.29.1: icmp_seq=2 ttl=64 time=40 ms

Pour revenir à la configuration initiale (sans simulateur), on utilise la commande suivante:

sudo tc qdisc del dev eth0 root

On vérifie que l’on retombe bien sur les caractéristiques normale du réseau:

$ ping 192.168.29.1
PING 192.168.29.1 (192.168.29.1) 56(84) bytes of data.
64 bytes from 192.168.29.1: icmp_seq=1 ttl=64 time=0.218 ms
64 bytes from 192.168.29.1: icmp_seq=2 ttl=64 time=0.209 ms

Simuler un délai de transit « normal »

Sur un réseau WAN, le délai de transit n’est jamais constant à travers le temps (surtout pour des liaisons de type Internet). Nous allons donc modifier la commande précédente pour intégrer une variation de délai (gigue de +/- 10ms) sur les paquets sortant:

sudo tc qdisc add dev eth0 root netem delay 40ms 10ms distribution normal

On obtient les caractéristiques suivantes:

$ ping 192.168.29.1PING 192.168.29.1 (192.168.29.1) 56(84) bytes of data.
64 bytes from 192.168.29.1: icmp_seq=1 ttl=64 time=36.9 ms
64 bytes from 192.168.29.1: icmp_seq=2 ttl=64 time=50.5 ms
64 bytes from 192.168.29.1: icmp_seq=3 ttl=64 time=33.1 ms
64 bytes from 192.168.29.1: icmp_seq=4 ttl=64 time=43.1 ms
64 bytes from 192.168.29.1: icmp_seq=5 ttl=64 time=32.5 ms
64 bytes from 192.168.29.1: icmp_seq=6 ttl=64 time=23.6 ms

Pour revenir à la configuration initiale (sans simulateur), on utilise la commande suivante:

sudo tc qdisc del dev eth0 root

Simuler une bande passante limite

Cette fonction ne fait pas partie de Netem mais utilise tout de même la commande tc pour se configurer.

Avant de commencer nous allons tester la capacité de notre réseau LAN avec la commande IPerf (à lancer en mode serveur UDP sur votre machine cible, 192.168.29.1 dans mon cas):

$ iperf -c 192.168.29.1 -u -b 10M
————————————————————
Client connecting to 192.168.29.1, UDP port 5001
Sending 1470 byte datagrams
UDP buffer size:   110 KByte (default)
————————————————————
[  3] local 192.168.29.222 port 47532 connected with 192.168.29.1 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec  11.9 MBytes  10.0 Mbits/sec
[  3] Sent 8505 datagrams
[  3] Server Report:
[ ID] Interval       Transfer     Bandwidth       Jitter   Lost/Total Datagrams
[  3]  0.0-10.0 sec  11.9 MBytes  10.0 Mbits/sec 0.008 ms    0/ 8505 (0%)

On a donc bien un débit de 10 Mbps.

On commence par créer la racine de l’arbre des classes (avec une simulation de délai « normal » de 40ms):

sudo tc qdisc add dev eth0 root handle 1:0 netem delay 40ms 10ms distribution normal

Puis on y ajoute un « tuyau » limitant le trafic sortant à 512 Kbps:

sudo tc qdisc add dev eth0 parent 1:1 handle 10: tbf rate 512kbit buffer 3200 limit 6000

On re-teste notre réseau:

$ iperf -c 192.168.29.1 -u -b 10M
————————————————————
Client connecting to 192.168.29.1, UDP port 5001
Sending 1470 byte datagrams
UDP buffer size:   110 KByte (default)
————————————————————
[  3] local 192.168.29.222 port 57589 connected with 192.168.29.1 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec  11.9 MBytes  10.0 Mbits/sec
[  3] Sent 8505 datagrams
[  3] Server Report:
[ ID] Interval       Transfer     Bandwidth       Jitter   Lost/Total Datagrams
[  3]  0.0-10.3 sec    609 KBytes    486 Kbits/sec 14.351 ms 8081/ 8505 (95%)

On arrive bien à limiter le débit réseau sortant à 500 Kbps (un peu moins pour mon test).

Pour revenir à la configuration initiale (sans simulateur), on utilise la commande suivante:

sudo tc qdisc del dev eth0 root

Simuler une perte de paquets

La perte de paquets (ou « packet loss » dans la langue de Shakespeare) peut être simulé par Netem par la commande loss. Dans l’exemple suivant, nous allons simuler un lien WAN avec une perte de 0.1% des paquets sortant (soit 1 paquet perdu sur 1000 envoyé) avec un corrélation de 25% sur la probabilité que 2 paquets soit perdu de suite.

sudo tc qdisc add dev eth0 root netem loss 0.1% 25%

Pour revenir à la configuration initiale (sans simulateur), on utilise la commande suivante:

sudo tc qdisc del dev eth0 root

Simuler d’autres paramètres réseau

Il est également possible de simuler la duplication de paquets (commande duplicate), la corruption de paquets (commande corrupt) et le re-arrangement des paquets (commande gap).

Simuler également les paquets entrants

Imaginons que l’on veuille simuler une liaison de type ADSL, cette liaison est asymétrique en terme de débit. Il faut donc pouvoir simuler de manière différente le débit entrant (DOWNLOAD) du débit sortant (UPLOAD). Pour cela, il faut passer par la déclaration d’une interface réseau virtuelle (ifb) dans laquelle nous allons re-router les paquets entrants. Nous appliquerons nos paramètres réseau de simulation sur cette nouvelle interface.

Commençons par créer cette interface virtuelle:

# modprobe ifb
# ip link set dev ifb0 up
# tc qdisc add dev eth0 ingress
# tc filter add dev eth0 parent ffff: protocol ip u32 match u32 0 0 flowid 1:1 action mirred egress redirect dev ifb0

Puis appliquons un délai de 40ms comme vu dans le chapitre précédant:

# tc qdisc add dev ifb0 root netem delay 40ms 10ms distribution normal

Un exemple complet: simulation d’une liaison ADSL

Voici un script Shell (bash) permettant de mettre en place une simulation de type liaison ADSL sur votre réseau local:

#!/bin/bash
#
# limitbw.sh
# Nicolargo – 2009
#

# Nom de l’interface ou l’on doit faire la simulation
IF=eth0

# Liaison sortante (UPLOAD)

# Debit sortant
BWU=768kbit
# Délai de transit sortant
DELAYU=20ms
# % de paquets perdus sortant
LOSSU=0.01%

# Liaison entrante (DOWNLOAD)

# Debit entrant
BWD=2mbit
# Délai de transit entrant
DELAYD=20ms
# % de paquets perdus entrant
LOSSD=0.01%

start() {

# Liaison entrante

modprobe ifb
ip link set dev ifb0 up
tc qdisc add dev $IF ingress
tc filter add dev $IF parent ffff: \
protocol ip u32 match u32 0 0 flowid 1:1 \
action mirred egress redirect dev ifb0

tc qdisc add dev ifb0 root handle 1:0 \
netem delay $DELAYD 10ms distribution normal \
loss $LOSSD 25%
tc qdisc add dev ifb0 parent 1:1 handle 10: \
tbf rate $BWD buffer 3200 limit 6000

# Liaison sortante

tc qdisc add dev $IF root handle 2:0 \
netem delay $DELAYU 10ms distribution normal \
loss $LOSSU 25%
tc qdisc add dev $IF parent 2:1 handle 10: \
tbf rate $BWU buffer 3200 limit 6000

}

stop() {

tc qdisc del dev ifb0 root

tc qdisc del dev $IF root

# ip link set dev ifb0 down

}

restart() {

stop
sleep 1
start

}

show() {

echo « Liaison entrante »

tc -s qdisc ls dev ifb0

echo « Liaison sortante »

tc -s qdisc ls dev $IF

}

case « $1 » in

start)

echo -n « Starting WAN simul:  »
start
echo « done »
;;

stop)

echo -n « Stopping WAN simul:  »
stop
echo « done »
;;

restart)

echo -n « Restarting WAN simul:  »
restart
echo « done »
;;

show)

echo « WAN simul status for $IF: »
show
echo «  »
;;

*)

echo « Usage: $0 {start|stop|restart|show} »
;;

esac

exit 0

Bonne simulation 😉