Bibliotheque reseau lcrzo

              -------------------------------------------
              |             PROBLEMES CONNUS            |
              -------------------------------------------

Ce fichier decrit les problemes connus (incompatibilites, fonctionnalites
non supportees, erreurs, etc.).
Si vous cherchez de l'aide (mode d'emploi, exemples, etc.), consultez
plutot lcrzo-4.xx-doc_html.tgz. Vous pouvez aussi entrer "man lcrzo".

Voici les titres des problemes decrits dans ce fichier (si vous
rencontrez un probleme non decrit, merci de me contacter comme indique
dans ./doc/problemreport_fr.txt) :

PROBLEMES CAUSES PAR LE SYSTEME
 1: [Linux] Segmentation fault lors de la conversion d'adresse IP vers
    adresse Ethernet. [probleme dans /etc/nsswitch.conf]
 2: [Linux] Segmentation fault lors de la conversion d'adresse IP vers
    adresse Ethernet. [probleme dans /etc/ethers]
 3: Lorsque l'on spoofe au niveau IP, certains paquets refusent de 
    partir sur le reseau.
 4: Lorsque l'on spoofe au niveau IP, certains paquets partant sur le 
    reseau ont des valeurs differentes de celles que l'on specifie.
 5: Erreur 1001 : erreur lors de l'appel a la fonction sendto()
 6: [Linux] Lorsque l'on envoie de tres nombreux paquets au niveau ip
    (c'est a dire par le biais des fonctions lcrzo_sendraw_ip, 
    lcrzo_sendpacket_ipxxx, etc.), le systeme sature.
 7: [FreeBSD] impossible de sniffer.
 8: [FreeBSD] impossible de spoofer.
 9: [FreeBSD] /dev/bpfii: Device not configured.
10: [FreeBSD] /dev/bpfii: No such file or directory.
11: [xBSD] Les paquets spoofes ethernet ont toujours l'adresse de la carte
    reseau, et non celle que l'on met dans la structure lcrzo_hdrleth.
12: [Linux] Ajout de l'adresse de la machine locale a la fin de la liste d'une 
    option IP "record route" ou "timestamp".
13: [Linux] Le sniff ne marche pas.
14: [Linux] Affichage d'une erreur de module net-pf-17 dans /var/log/messages.

PROBLEMES CAUSES PAR LIBPCAP OU WINPCAP
15: [Linux] Affichage de "linux socket: Too many open files" lors de l'exit().
16: [Linux] Affichage de "kernel: programme uses obsolete (PF_INET,SOCK_PACKET)"
    dans "/var/log/messages". Ceci est un message de warning seulement.

PROBLEMES CAUSES PAR LE DESIGN DE LCRZO
17: La configuration reseau est incorrecte.
18: Les fonctions de lcrzo ont un comportement bizarre
19: Les fonctions de lcrzo interferent avec d'autres fonctions
20: Lcrzo est lente.
21: Certaines fonctionnalites ne fonctionnent pas entierement.
22: Certaines fonctionnalites ne sont pas fournies.



-------------------------------------------------------------------------------
Probleme 1 :
  Synthese du probleme :
    Segmentation fault lors de la conversion d'adresse IP vers
    adresse Ethernet. [probleme dans /etc/nsswitch.conf]
  Environnement concerne par le probleme :
    Glibc-2.?? (<2.2.1) avec "nisplus" ou "db" dans /etc/nsswitch.conf
  Origine du probleme :
    Le probleme se situe lors de l'appel systeme ether_hostton, lorsque
    l'entree "nisplus" ou "db" est dans /etc/nsswitch.conf.
    Effet, il y a une erreur dans la glibc (2.1.3) :
      nis/nss_nisplus/nisplus-ethers.c, ligne 234 : 
        Il y a "if (name != NULL)" au lieu de "if (name == NULL)"
    Note : les developpeurs de glibc ont ete informes de ce bug. Ils ont 
           integre le patch dans la glibc 2.2.1.
  Solution 1 :
    Editer /etc/nsswitch.conf afin de replacer :
         ethers: _nisplus_ou_nis_ou_db_ files
    par :
         ethers: files
    En effet, le probleme disparait en supprimant "nis", "nisplus"
    ou "db" de /etc/nsswitch.conf.
    Vous pouvez ensuite refaire un genemake (puis recompiler et 
    reinstaller) afin de prendre en compte le fait que ce bug
    soit corrige.
  Solution 2 :
    Installez la glibc > 2.2.1.

-------------------------------------------------------------------------------
Probleme 2 :
  Synthese du probleme :
    Segmentation fault lors de la conversion d'adresse IP vers
    adresse Ethernet. [probleme dans /etc/ethers]
  Environnement concerne par le probleme :
    /etc/ethers vide
  Origine du probleme :
    Le probleme apparait lorsque /etc/ethers existe, mais est vide.
    Effet, il y a une erreur dans la glibc (2.1.3) :
      inet/ether_hton.c, ligne 76 :
        fct a seulement 4 parametres au lieu de 5.
    Note : les developpeurs de glibc ont ete informes de ce bug. Ils ont 
           integre le patch dans la glibc 2.2.1.
  Solution 1 :
    Effacer le fichier /etc/ethers si il ne sert a rien.
  Solution 2 :
    Installez la glibc > 2.2.1.

-------------------------------------------------------------------------------
Probleme 3 :
  Synthese du probleme :
    Lorsque l'on spoofe au niveau IP, certains paquets refusent de 
    partir sur le reseau.
  Environnement concerne par le probleme :
    Linux avec IP firewalling
    Solaris
    FreeBSD
    [je suppose que tous les environnements sont plus ou moins sensibles]
  Origine du probleme :
    D'une maniere generale, il y a deux niveaux auxquels on peut
    spoofer :
     - niveau ethernet : on specifie les adresses ethernet, ip, etc.
     - niveau ip : on specifie les adresses ip, etc., et la pile IP 
                   du systeme se charge de trouver les adresses ethernet
    Le probleme reside dans le fait que certains systemes d'exploitation
    cherchent a verifier la legitimite du paquet que l'on desire envoyer.
    Lorsque le paquet est incorrect, il est alors jete par le systeme.
    Certains systemes changent meme les valeurs que l'on desire (par 
    exemple, Solaris change hdrlip.id, hdrlip.dontfrag, etc.).
  Solution 1 :
    La solution generique consiste a spoofer au niveau ethernet
    afin de contourner la pile IP du systeme en utilisant : 
      lcrzo_spoof_set_useethforip(&spoof, LCRZO_TRUE);
  Solution 2 :
    La solution generique consiste a spoofer au niveau ethernet
    afin de contourner la pile IP du systeme en utilisant 
    lcrzo_sendraw_eth, et toutes les fonctions en dependant 
    (lcrzo_sendpacket_ethipoptdata, lcrzo_sendpacket_ethipoptudpdata, etc.).
  Solution 3 :
    Sous Linux, il faut compiler le noyau sans l'IP firewalling 
    pour pouvoir emettre des paquets malformes.

-------------------------------------------------------------------------------
Probleme 4 :
  Synthese du probleme :
    Lorsque l'on spoofe au niveau IP, certains paquets partant sur le 
    reseau ont des valeurs differentes de celles que l'on specifie.
  Environnement concerne par le probleme :
    Linux avec IP firewalling
    Solaris
    FreeBSD
    [je suppose que tous les environnements sont plus ou moins sensibles]
  Origine du probleme :
    D'une maniere generale, il y a deux niveaux auxquels on peut
    spoofer :
     - niveau ethernet : on specifie les adresses ethernet, ip, etc.
     - niveau ip : on specifie les adresses ip, etc., et la pile IP 
                   du systeme se charge de trouver les adresses ethernet
    Le probleme reside dans le fait que certains systemes d'exploitation
    cherchent a verifier la legitimite du paquet que l'on desire envoyer.
    Lorsque le paquet est incorrect, il est alors jete par le systeme.
    Certains systemes changent meme les valeurs que l'on desire (par 
    exemple, Solaris change hdrlip.id, hdrlip.dontfrag, etc.).
  Solution 1 :
    La solution generique consiste a spoofer au niveau ethernet
    afin de contourner la pile IP du systeme en utilisant : 
      lcrzo_spoof_set_useethforip(&spoof, LCRZO_TRUE);
  Solution 2 :
    La solution generique consiste a spoofer au niveau ethernet
    afin de contourner la pile IP du systeme en utilisant 
    lcrzo_sendraw_eth, et toutes les fonctions en dependant 
    (lcrzo_sendpacket_ethipoptdata, lcrzo_sendpacket_ethipoptudpdata, etc.).
  Solution 3 :
    Sous Linux, il faut compiler le noyau sans l'IP firewalling 
    pour pouvoir emettre des paquets malformes.

-------------------------------------------------------------------------------
Probleme 5 :
  Synthese du probleme :
    Erreur 1001 : erreur lors de l'appel a la fonction sendto()
  Environnement concerne par le probleme :
    Linux avec IP firewalling
    Solaris
    FreeBSD
    [je suppose que tous les environnements sont plus ou moins sensibles]
  Origine du probleme :
    D'une maniere generale, il y a deux niveaux auxquels on peut
    spoofer :
     - niveau ethernet : on specifie les adresses ethernet, ip, etc.
     - niveau ip : on specifie les adresses ip, etc., et la pile IP 
                   du systeme se charge de trouver les adresses ethernet
    Le probleme reside dans le fait que certains systemes d'exploitation
    cherchent a verifier la legitimite du paquet que l'on desire envoyer.
    Lorsque le paquet est incorrect, il est alors jete par le systeme.
    Certains systemes changent meme les valeurs que l'on desire (par 
    exemple, Solaris change hdrlip.id, hdrlip.dontfrag, etc.).
  Solution 1 :
    La solution generique consiste a spoofer au niveau ethernet
    afin de contourner la pile IP du systeme en utilisant : 
      lcrzo_spoof_set_useethforip(&spoof, LCRZO_TRUE);
  Solution 2 :
    La solution generique consiste a spoofer au niveau ethernet
    afin de contourner la pile IP du systeme en utilisant 
    lcrzo_sendraw_eth, et toutes les fonctions en dependant 
    (lcrzo_sendpacket_ethipoptdata, lcrzo_sendpacket_ethipoptudpdata, etc.).
  Solution 3 :
    Sous Linux, il faut compiler le noyau sans l'IP firewalling 
    pour pouvoir emettre des paquets malformes.

-------------------------------------------------------------------------------
Probleme 6 :
  Synthese du probleme :
    Lorsque l'on envoie de tres nombreux paquets au niveau ip
    (c'est a dire par le biais des fonctions lcrzo_sendraw_ip, 
    lcrzo_sendpacket_ipxxx, etc.), le systeme sature.
  Environnement concerne par le probleme :
    Linux
    probablement d'autres systemes
  Origine du probleme :
    Pour la fonction lcrzo_sendraw_ip, on passe le paquet au systeme
    et on le laisse se debrouiller.
    Si l'adresse ethernet de la machine destination (ou du routeur
    correspondant) ne peut pas etre determinee, le systeme stocke
    les paquets passes a lcrzo_sendraw_ip. Ces paquets, que le systeme
    espere pouvoir envoyer ulterieurement, sont gardes pendant
    quelques dizaines de secondes. Cependant, si l'on mene une 
    attaque de style deni de service, la memoire occupee par ces
    paquets peut rapidement (5 secondes) saturer. Il faut donc
    s'assurer que les paquets utilises dans le cas d'un deni de service
    partent reellement sur le reseau (c'est a dire que la destination
    soit joignable), sinon on fait un deni de service sur la machine
    locale ;).
    En synthese, lorsque l'on envoie au niveau IP, comme c'est le systeme
    qui gere, il faut que le systeme soit bien configure, sinon les paquets
    ne partent pas sur le reseau.
    Un autre cas a ete identifie sur les machines tres puissantes :
    le systeme accepte de traiter plus de paquets qu'il ne le peut
    reellement. Le systeme se met alors aussi a saturer.
  Solution 1 :
    (machine destination sur le LAN)
     - Si l'adresse destination est une machine qui existe 
       sur le LAN, il faut verifier qu'elle soit dans le cache
       ARP ("arp -an"). Dans le cas contraire, faire un ping 
       vers cette machine pour s'assurer qu'elle existe.
     - Si l'adresse destination est une machine inexistante, il faut
       lui affecter une fausse entree dans la table arp 
       ("arp -s machine a:a:a:a:a:a").
  Solution 2 :
    (machine destination derriere un routeur)
     - D'abord, il faut verifier que le routeur soit dans le cache
       ARP ("arp -an"). Dans le cas contraire, faire un ping 
       vers le routeur pour s'assurer qu'il existe.
     - Puis, s'assurer que les routes soient correctes, en faisant
       par exemple un ping vers la machine destination.
  Solution 3 :
    (configuration OK, mais machine puissante)
    Le probleme principal est qu'il n'y a pas de moyen de voir
    que le noyau est en train de se saturer. Quand on s'en rend compte
    (errno==ENOBUFS), il est deja trop tard.
    Une solution est de ralentir la cadence d'emission en utilisant
    lcrzo_time_sleep. Par exemple, on peut faire une pause tous les
    1000 paquets envoyes. Le souci est que le temps de pause est 
    fonction du systeme (cpu, memoire, carte reseau, etc.).
    Si vous avez une bonne solution a ce probleme, n'hesitez pas a
    me contacter.

-------------------------------------------------------------------------------
Probleme 7 :
  Synthese du probleme :
    impossible de sniffer.
  Environnement concerne par le probleme :
    FreeBSD
  Origine du probleme :
    bpf n'est pas compile dans le noyau, ou trop peu de bpfii sont 
    disponibles. On ne peut donc pas sniffer ou spoofer au niveau 
    Ethernet.
  Solution :
    Il faut compiler le noyau avec bpf en mettant dans le 
    fichier /usr/src/sys/i386/NOYAU :
             "pseudo-device bpfilter 4"
    Puis, il faut creer les bpfii :
        cd /dev
        sh MAKEDEV bpf0    (si il n'existe pas deja)
        sh MAKEDEV bpf1
        sh MAKEDEV bpf2
        sh MAKEDEV bpf3
    Note : dans cet exemple, 4 bpf ont ete crees; on peut en mettre plus.

-------------------------------------------------------------------------------
Probleme 8 :
  Synthese du probleme :
    impossible de spoofer.
  Environnement concerne par le probleme :
    FreeBSD
  Origine du probleme :
    bpf n'est pas compile dans le noyau, ou trop peu de bpfii sont 
    disponibles. On ne peut donc pas sniffer ou spoofer au niveau 
    Ethernet.
  Solution :
    Il faut compiler le noyau avec bpf en mettant dans le 
    fichier /usr/src/sys/i386/NOYAU :
             "pseudo-device bpfilter 4"
    Puis, il faut creer les bpfii :
        cd /dev
        sh MAKEDEV bpf0    (si il n'existe pas deja)
        sh MAKEDEV bpf1
        sh MAKEDEV bpf2
        sh MAKEDEV bpf3
    Note : dans cet exemple, 4 bpf ont ete crees; on peut en mettre plus.

-------------------------------------------------------------------------------
Probleme 9 :
  Synthese du probleme :
    /dev/bpfii: Device not configured.
  Environnement concerne par le probleme :
    FreeBSD
  Origine du probleme :
    bpf n'est pas compile dans le noyau, ou trop peu de bpfii sont 
    disponibles. On ne peut donc pas sniffer ou spoofer au niveau 
    Ethernet.
  Solution :
    Il faut compiler le noyau avec bpf en mettant dans le 
    fichier /usr/src/sys/i386/NOYAU :
             "pseudo-device bpfilter 4"
    Puis, il faut creer les bpfii :
        cd /dev
        sh MAKEDEV bpf0    (si il n'existe pas deja)
        sh MAKEDEV bpf1
        sh MAKEDEV bpf2
        sh MAKEDEV bpf3
    Note : dans cet exemple, 4 bpf ont ete crees; on peut en mettre plus.

-------------------------------------------------------------------------------
Probleme 10 :
  Synthese du probleme :
    /dev/bpfii: No such file or directory.
  Environnement concerne par le probleme :
    FreeBSD
  Origine du probleme :
    bpf n'est pas compile dans le noyau, ou trop peu de bpfii sont 
    disponibles. On ne peut donc pas sniffer ou spoofer au niveau 
    Ethernet.
  Solution :
    Il faut compiler le noyau avec bpf en mettant dans le 
    fichier /usr/src/sys/i386/NOYAU :
             "pseudo-device bpfilter 4"
    Puis, il faut creer les bpfii :
        cd /dev
        sh MAKEDEV bpf0    (si il n'existe pas deja)
        sh MAKEDEV bpf1
        sh MAKEDEV bpf2
        sh MAKEDEV bpf3
    Note : dans cet exemple, 4 bpf ont ete crees; on peut en mettre plus.

-------------------------------------------------------------------------------
Probleme 11 :
  Synthese du probleme :
    Les paquets spoofes ethernet ont toujours l'adresse de la carte
    reseau, et non celle que l'on met dans la structure lcrzo_hdrleth.
  Environnement concerne par le probleme :
    FreeBSD 3.1, 3.5, OpenBSD 2.x [FreeBSD 4.x n'est pas concerne]
  Origine du probleme :
    Le noyau ne permet pas de spoofer au niveau ethernet.
  Solution :
    Le repertoire ../src/port/FreeBSD (ou ../src/port/OpenBSD)
    contient un patch/module noyau. Il faut appliquer ce patch, 
    ou activer ce module pour resoudre le souci. Lisez le fichier 
    README present dans le repertoire correspondant.

-------------------------------------------------------------------------------
Probleme 12 :
  Synthese du probleme :
    Ajout de l'adresse de la machine locale a la fin de la liste d'une 
    option IP "record route" ou "timestamp".
  Environnement concerne par le probleme :
    Linux noyau inferieur a 2.1
  Origine du probleme :
    Lors du sniff des options de type "record route" et "timestamp",
    mene par l'intermediaire de la bibliotheque libpcap, la machine qui
    sniffe rajoute son adresse en fin de liste.
    Cela semblerait logique, mais quand on sniffe, on desire voir
    ce qui passe sur le reseau, et non des paquets modifies par le systeme
    de la machine locale (le pire, c'est que le checksum n'est pas
    recalcule par le systeme).
    La bibliotheque libpcap utilise une socket {PF_INET,SOCK_PACKET}
    du noyau, et c'est cette interface qui est erronee.
  Solution 1 :
    La version 2.1 du noyau corrige ce probleme.
  Solution 2 :
    Installez une version de libpcap > 0.6 disponible a l'adresse 
    http://www.tcpdump.org/.

-------------------------------------------------------------------------------
Probleme 13 :
  Synthese du probleme :
    Le sniff ne marche pas.
  Environnement concerne par le probleme :
    Linux
  Origine du probleme :
    Le noyau doit etre compile avec le support de "packet socket" 
    (CONFIG_PACKET) pour pouvoir sniffer.
  Solution :
    Vous devez compiler votre noyau avec "packet socket" :
     - cocher la case 'Packet socket' du menu 'Networking options'
       de l'interface graphique de configuration du noyau (make xconfig), ou
     - editer /usr/src/linux/.config afin d'y mettre :
       CONFIG_PACKET=y
    Le noyau doit ensuite etre recompile et installe.

-------------------------------------------------------------------------------
Probleme 14 :
  Synthese du probleme :
    Affichage d'une erreur de module net-pf-17 dans /var/log/messages.
  Environnement concerne par le probleme :
    Linux
  Origine du probleme :
    Le noyau doit etre compile avec le support de "packet socket" 
    (CONFIG_PACKET) pour pouvoir sniffer.
  Solution :
    Vous devez compiler votre noyau avec "packet socket" :
     - cocher la case 'Packet socket' du menu 'Networking options'
       de l'interface graphique de configuration du noyau (make xconfig), ou
     - editer /usr/src/linux/.config afin d'y mettre :
       CONFIG_PACKET=y
    Le noyau doit ensuite etre recompile et installe.

-------------------------------------------------------------------------------
Probleme 15 :
  Synthese du probleme :
    Affichage de "linux socket: Too many open files" lors de l'exit().
  Environnement concerne par le probleme :
    Linux avec libpcap 0.5
  Origine du probleme :
    La fonction "linux_restore_ifr" de "pcap-linux.c" est appelee
    lors de la terminaison du programme (programmation par "atexit()").
    Cette fonction utilise un descripteur de fichier, mais ne le ferme
    jamais.
    Note : les developpeurs de libpcap ont ete informes de ce bug.
  Solution 1 :
    Installez une version > 0.6 disponible a l'adresse 
    http://www.tcpdump.org/.
  Solution 2 :
    Si vous utilisez libpcap<0.6, il faut modifier la fonction 
    "linux_restore_ifr" de "pcap-linux.c" :
      void linux_restore_ifr(void)
      { register int fd;
        fd = socket(PF_INET, SOCK_PACKET, htons(0x0003));
        if (fd < 0)
          fprintf(stderr, "linux socket: %s", pcap_strerror(errno));
        else if (ioctl(fd, SIOCSIFFLAGS, &saved_ifr) < 0)
          fprintf(stderr, "linux SIOCSIFFLAGS: %s", pcap_strerror(errno));
        /*et ici, il n'y avait pas de close*/
        close(fd); /*rajoute par Laurent dans libpcap.*/
      }
    Puis il faut recompiler et reinstaller libpcap.

-------------------------------------------------------------------------------
Probleme 16 :
  Synthese du probleme :
    Affichage de "kernel: programme uses obsolete (PF_INET,SOCK_PACKET)"
    dans "/var/log/messages". Ceci est un message de warning seulement.
  Environnement concerne par le probleme :
    Linux noyau superieur a 2.1
    libpcap jusqu'a 0.5rel2
  Origine du probleme :
    La bibliotheque libpcap utilise une socket {PF_INET,SOCK_PACKET}
    du noyau, et c'est cette interface qui est obsolete.
    Note : les developpeurs de libpcap ont ete informes de ce bug.
  Solution 1 :
    Le message etant un warning, il peut etre ignore.
  Solution 2 :
    Installez une version > 0.6 disponible a l'adresse 
    http://www.tcpdump.org/.

-------------------------------------------------------------------------------
Probleme 17 :
  Synthese du probleme :
    La configuration reseau est incorrecte.
  Environnement concerne par le probleme :
    Tous
  Origine du probleme :
    L'obtention de la configuration de la machine locale (device, 
    cache arp, routes) est une etape cle du fonctionnement de 
    lcrzo. De nombreux outils necessitent que cette configuration 
    soit correctement effectuee.
    Il existe de tres nombreux types de cartes reseau, de modems, 
    de versions de systemes d'exploitation, etc. Ainsi, il se peut 
    que votre machine contienne un peripherique non reconnu par 
    lcrzo/lcrzoex. Dans ce cas, tous les outils de lcrzo ne seraient 
    pas utilisables.
    C'est pour ces raisons que le premier outil a employer est 
    'lcrzoex 157' afin de s'assurer que la configuration soit
    correctement obtenue.
    Voici un exemple d'affichage correct (Linux dans ce cas) :
     Devices
      device  ethernet          ip          /netmask        mtu
      lo      00:00:00:00:00:00 127.0.0.1   /255.0.0.0      3924 up
      eth0    00:00:33:AC:C2:24 192.168.1.1 /255.255.255.0  1500 up
      eth0:1  00:00:33:AC:C2:24 192.168.2.1 /255.255.255.0  1500 up,alias
      eth1    00:00:43:BC:D2:34 192.168.3.1 /255.255.255.0  1500 up
     Arp
      lo      00:00:00:00:00:00 127.0.0.1     (permanent)
      eth0    00:00:33:AC:C2:24 192.168.1.1   (permanent)
      eth0:1  00:00:33:AC:C2:24 192.168.2.1   (permanent)
      eth1    00:00:43:BC:D2:34 192.168.3.1   (permanent)
      eth0    12:34:56:78:90:ab 192.168.1.254 (-1s)
     Routes
      device  destination  /netmask         ip_source     gateway
      lo      127.0.0.1    /255.255.255.255 local_device                 0,up
      eth0    192.168.1.1  /255.255.255.255 local_device                 0,up
      eth0:1  192.168.2.1  /255.255.255.255 local_device                 0,up
      eth1    192.168.3.1  /255.255.255.255 local_device                 0,up
      eth0    192.168.1.0  /255.255.255.0   192.168.1.1                  0,up
      eth0:1  192.168.2.0  /255.255.255.0   192.168.2.1                  0,up
      eth1    192.168.3.0  /255.255.255.0   192.168.3.1                  0,up
      lo      127.0.0.0    /255.0.0.0       127.0.0.1                    0,up
      eth0    0.0.0.0      /0.0.0.0         192.168.1.1   192.168.1.254  0,up
    Dans cet exemple, on voit le device Loopback (lo) ainsi que deux cartes
    reseau (eth0 et eth1). La carte eth0 possede un alias.
    La table arp reprend les entrees permanentes ainsi que l'entree 
    dynamique du routeur 192.168.1.254.
    La table de routage comprend d'abord les entrees permettant d'acceder
    aux adresses des cartes, puis aux adresses des reseaux connectes
    a ces cartes, et enfin le routeur par defaut qui est 192.168.1.254.
  Solution :
    Comme je ne peux pas avoir acces a votre materiel, il faut me faire
    parvenir les elements correspondant a votre configuration afin de faire
    evoluer lcrzo.
    Executer :
      lcrzoex 278 > fichierresultat
    M'envoyer le fichier 'fichierresultat', ainsi que toutes les informations
    que vous jugez utile (ifconfig, ipconfig /all, route print, arp -a, 
    winipcfg /all /batch fichier.out, winipcfg, netstat -rn, type de 
    carte reseau, type de modem, etc.).
    Merci.

-------------------------------------------------------------------------------
Probleme 18 :
  Synthese du probleme :
    Les fonctions de lcrzo ont un comportement bizarre
  Environnement concerne par le probleme :
    Tous
  Origine du probleme :
    Il peut y avoir des conflits entre lcrzo et votre programme.
  Solution :
    Lisez integration_fr.txt.

-------------------------------------------------------------------------------
Probleme 19 :
  Synthese du probleme :
    Les fonctions de lcrzo interferent avec d'autres fonctions
  Environnement concerne par le probleme :
    Tous
  Origine du probleme :
    Il peut y avoir des conflits entre lcrzo et votre programme.
  Solution :
    Lisez integration_fr.txt.

-------------------------------------------------------------------------------
Probleme 20 :
  Synthese du probleme :
    Lcrzo est lente.
  Environnement concerne par le probleme :
    Tous
  Origine du probleme :
    J'ai choisi de creer une bibliotheque tres modulaire et simple
    a maintenir. L'une des consequences est le nombre important de
    fonctions imbriquees. Lorsque l'on desire gerer un flux de donnees
    important, la machine est surchargee.
  Solution 1 :
    lcrzo propose des fonctionnalites permettant de preconstruire
    les paquets a envoyer sur le reseau, puis de les sauvegarder
    dans des fichiers (cf. lcrzo_record.h).
  Solution 2 :
    Vous pouvez aussi n'utiliser que les fonctions de tres bas niveau
    et construire votre code specifique autour de ces fonctions.
    Si c'est toujours trop lent, alors il faut que vous utilisiez
    directement les fonctions systeme, ou que vous achetiez
    une plus grosse machine ;)

-------------------------------------------------------------------------------
Probleme 21 :
  Synthese du probleme :
    Certaines fonctionnalites ne fonctionnent pas entierement.
  Environnement concerne par le probleme :
    Tous
  Origine du probleme :
    Le developpement de lcrzo possede plusieurs branches, et chacune 
    possede sa propre priorite. Je ne peux pas tout developper en 
    quelques jours :). Des choix sont donc faits. Mes priorites peuvent
    ne pas etre les memes que les votres.
  Solution 1 :
    Lisez todo.txt pour obtenir la liste de choses que j'ai prevues 
    de faire.
  Solution 2 :
    Contactez-moi pour me faire part de vos besoins.

-------------------------------------------------------------------------------
Probleme 22 :
  Synthese du probleme :
    Certaines fonctionnalites ne sont pas fournies.
  Environnement concerne par le probleme :
    Tous
  Origine du probleme :
    Le developpement de lcrzo possede plusieurs branches, et chacune 
    possede sa propre priorite. Je ne peux pas tout developper en 
    quelques jours :). Des choix sont donc faits. Mes priorites peuvent
    ne pas etre les memes que les votres.
  Solution 1 :
    Lisez todo.txt pour obtenir la liste de choses que j'ai prevues 
    de faire.
  Solution 2 :
    Contactez-moi pour me faire part de vos besoins.