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
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 😉

Catégories
Open-source Systeme

Création d’un script de démarrage sous Linux

Dans cet article nous allons voir comment automatiser le démarrage d’un service ainsi que son arrêt sur un système GNU/Linux (plus particulièrement sur une distribution Ubuntu 8.04 Server).

A titre d’exemple, nous allons voir comment lancer un portail Liferay au démarrage de la machine, et comment l’arrêter proprement lors d’un reboot ou d’un shutdown.

Création du script

Nous allons donc créer un script nommé ‘liferay‘ que l’on va placer dans le répertoire /etc/init.d .

#!/bin/sh

# le nom du service
SERVICE_NAME=Liferay
# le répertoire où se trouvent les exécutables du service
SERVICE_DIRECTORY=/opt/Portal/bin
# le nom du script de démarrage du service
SERVICE_STARTUP_SCRIPT=startup.sh
# le nom du script d'arrêt du service
SERVICE_SHUTDOWN_SCRIPT=shutdown.sh

usage()
{
        echo "-----------------------"
        echo "Usage: $0 (stop|start|restart)"
        echo "-----------------------"
}

if [ -z $1 ]; then
        usage
fi

service_start()
{
        echo "Starting service '${SERVICE_NAME}'..."
        OWD=`pwd`
        cd ${SERVICE_DIRECTORY} && ./${SERVICE_STARTUP_SCRIPT}
        cd $OWD
        echo "Service '${SERVICE_NAME}' started successfully"
}

service_stop()
{
        echo "Stopping service '${SERVICE_NAME}'..."
        OWD=`pwd`
        cd ${SERVICE_DIRECTORY} && ./${SERVICE_SHUTDOWN_SCRIPT}
        cd $OWD
        echo "Service '${SERVICE_NAME}' stopped"
}

case $1 in
        stop)
                service_stop
        ;;
        start)
                service_start
        ;;
        restart)
                service_stop
                service_start
        ;;
        *)
                usage
esac
exit 0

Maintenant, il faut donner les permissions d’exécution sur ce script

# chmod a+x /etc/init.d/liferay

Automatisation

Maintenant que le script est créé, il ne reste plus qu’à faire en sorte que le service se lance au démarrage de la machine et qu’il se stoppe à l’arrêt de celle-ci. Le runlevel qui nous intéresse ici est le numéro 2, mais on peut appliquer cette configuration pour les autres.

Il existe 2 méthodes pour procéder: la première consiste à créer des liens symboliques à la main dans le répertoire /etc/rc2.d en respectant les conventions de nommage, et la seconde (plus simple), consiste à utiliser la commande update-rc.d (c’est cette méthode que nous allons utiliser).

Avant tout chose, il faut déterminer le moment exact où le script s’exécutera:

  • Démarrage du service
    Le service liferay doit se lancer une fois que le serveur de base de données est démarré (en l’occurrence, il s’agit de MySQL).
    En regardant dans le répertoire /etc/rc2.d, on voit que le service mysql démarre à la position 19 (ce numéro peut changer suivant les configurations), donc nous allons démarrer le service liferay à la position 20.
  • Arrêt du service
    Le service liferay doit s’arrêter avant que le serveur de base de données ne s’arrête.
    En regardant dans le répertoire /etc/rc6.d (le runlevel 6 est consacré à l’arrêt de la machine), on voit que le service mysql s’arrête en position 18. Nous allons donc arrêter le service liferay en position 17.

Voici donc la commande qui permet de configurer le service comme décrit précédemment:

# update-rc.d liferay start 20 2 . stop 17 6 .

Désactiver un service

Pour désactiver le lancement automatique d’un service au démarrage, il existe 3 possibilités:

  • utiliser la commande update-rc.d
    # update-rc.d -f liferay remove
  • supprimer le lien symbolique du répertoire /etc/rcX.d (où X représente le numéro de runlevel désiré)
  • retirer les permissions d’exécution sur le script situé dans le répertoire /etc/init.d

Pour plus d’infos, consulter la documentation de la commande update-rc.d.

Catégories
Developpement Open-source Systeme

Installation de Java 1.6 sous Debian et Ubuntu

Si comme moi vous devez faire tourner des applications seulement compatible avec Java 6 (c’est à dire Java 1.6) sur vos machines Debian et Ubuntu, et que vous n'avez pas de masters java en poche, la petite procédure suivante devrait vous être utile. En effet, ces deux distributions sont, à l’heure de l’écriture de ce billet, livré par défaut avec la version 1.5. Nous allons voir comment installer la JDK de Sun et la faire prendre par défaut par le système.

Installation de Sun Java 1.6

Pour installer la JRE (seulement pour l’exécution de programme Java):

sudo apt-get install  sun-java6-jre

Pour installer et compiler (bref pour les developpeurs):

sudo apt-get install sun-java6-sdk

Pour rendre Sun Java 1.6, la JVM par défaut

La commande est la même sur les deux distributions (Ubuntu et Debian):

sudo update-alternatives –config java

> Puis choisir /usr/lib/jvm/java-6-sun/jre/bin/java

On vérifie que tout est ok:

# java -version

java version « 1.6.0_12″

Et voili…

Catégories
Open-source Reseau

Outil pour la mesure de la QoS sur les réseaux IP

La qualité de service (QoS pour « Quality of service ») est la capacité à véhiculer dans de bonnes conditions un type de trafic donné en termes de disponibilité, débit, délai de transmission, gigue, taux de perte de paquets… (source Wiki)

La notion de qualité de service est une notion subjective, de ressenti utilisateur face à l’utilisation d’un système informatique. Il n’est pas trivial de mesurer cette QoS. Nous allons dans ce billet aborder quelques outils libres permettant d’obtenir des indicateurs chiffrés en nous focalisant sur la problématique des réseaux IP.

Ou faire les mesures ?

Première question à se poser quand on doit faire ce genre de mesure. La réponse dépend bien sûr de votre architecture. Souvent, l’on souhaite vérifier la QoS sur une liaison WAN( par exemple un liaison de type _DSL vers votre FAI). Dans ce cas précis, la mesure pourra être faite sur votre routeur d’accès, c’est à dire juste avant la liaison. En effet, celà permet de prendre en compte tous les flux de votre réseau. Il faut pour celà disposer d’un routeur d’accès sur lequel on peut installer les outils de mesures (par exemple un routeur/firewall basé sous Linux ou FreeBSD). Si ce n’est pas le cas, il est toujours possible de mettre un PC (sous Linux) en coupure entre votre switch réseau et votre routeur/modem.

Quoi mesurer ?

Pour un réseau en fonctionnement (c’est à dire que l’on écarte la disponibilité), on peut distinguer quatres grandes variables:

  • le débit: c’est la bande passante utilisé par un flux. Celle-ci peut être constante ou variable.
  • le délai de transit des paquets IP: dans un réseau IP, les données sont segmentées en paquets. Le délai de transit est le temps mis par uhn paquet pour aller d’un point A vers un point B.
  • la gigue dans un flux de paquets IP: c’est la variation du délai de transit entre plusieurs paquets IP. Ce paramètre est très important pour les applications de voix sur IP (VoIP) car les codecs de compression de la voix sont très sensibles à la gigue.
  • la perte de paquets: c’est le pourcentage de paquets IP perdus sur le réseau.

Comment tester ?

Plusieurs solutions sont possibles. La première consiste à utiliser les logiciels qu l’on souhaites tester sur son réseau. On peut le faire de manière manuelle ou automatique (via des scripts par exemple). L’important est de générer des flux qui soient représentatifs de l’utilisation standard de votre réseau.

Une autre solution est de simuler les flux à l’aide d’un outil comme Iperf qui est capable de générer un flux IP finement paramètrable sur le réseau. Par finement on entend:

  • Protocole: UDP, TCP, ICMP…
  • Port réseau
  • Taille des paquets de données
  • Débit
  • Temps
  • Tag du champ DSCP (dans le cadre d’un réseau compatible Diffserv)

Pour vous aider dans l’utilisation de ce logiciel, vous pouvez lire les billets suivants:

Comment mesurer ?

Iperf permet de générer en sortie un rapport sur quelques uns de ces paramètres, notamment le débit (moyen, minimum et maximum) et le délai. L’idée générale et de faire un plan de test avec les différentes configurations possible en terme d’utilisation et de QoS et de regarder les valeurs obtenues en sorties. En complément de Iperf, vous pouvez utiliser SJitter pour la mesure de la gigue réseau.

En complément de IPerf, il peut être utile d’utiliser un logiciel de capture réseau tel que Wireshark. En effet, grâce à ce dernier, vous pouvez sauvegarder les flux et les filter/analyser avec les nombreux modules disponibles.

Voici un tableau, basée sur mon expérience personnelle, des valeurs à prendre en compte lors de vos mesures.


Et vous quel est votre expérience sur le sujet ? Utiliser vous d’autres logiciels libres pour mesurer les performances de votre réseau ?