                       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) :

LORS DE L'EXECUTION
 1: Lcrzo est lente.

LORS DU SNIFF
 2: Linux : Affichage de "linux socket: Too many open files" lors de l'exit().
 3: Linux : Affichage de "kernel: programme uses obsolete (PF_INET,SOCK_PACKET)"
    dans "/var/log/messages". Ceci est un message de warning seulement.
 4: FreeBSD : impossible de sniffer.
 5: FreeBSD : /dev/bpfii: Device not configured.
 6: FreeBSD : /dev/bpfii: No such file or directory.
 7: Linux : Ajout de l'adresse de la machine locale a la fin de la liste d'une 
    option IP "record route" ou "timestamp".
 8: Linux : Le sniff ne marche pas.
 9: Linux : Affichage d'une erreur de module net-pf-17 dans /var/log/messages.

LORS DU SPOOF
10: Lorsque l'on spoofe au niveau IP, certains paquets refusent de 
    partir sur le reseau.
11: Lorsque l'on spoofe au niveau IP, certains paquets partant sur le 
    reseau ont des valeurs differentes de celles que l'on specifie.
12: Erreur 1001 : erreur lors de l'appel a la fonction sendto()
13: 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.
14: FreeBSD : impossible de spoofer.
15: FreeBSD : /dev/bpfii: Device not configured.
16: FreeBSD : /dev/bpfii: No such file or directory.
17: 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.

Pour le moment, il n'y a rien a dire.



-------------------------------------------------------------------------------
Probleme 1 :
  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 2 :
  Synthese du probleme :
    Linux : 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 3 :
  Synthese du probleme :
    Linux : 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 4 :
  Synthese du probleme :
    FreeBSD : 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 5 :
  Synthese du probleme :
    FreeBSD : /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 6 :
  Synthese du probleme :
    FreeBSD : /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 7 :
  Synthese du probleme :
    Linux : 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 8 :
  Synthese du probleme :
    Linux : 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 9 :
  Synthese du probleme :
    Linux : 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 10 :
  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 11 :
  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 12 :
  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 13 :
  Synthese du probleme :
    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.
  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 14 :
  Synthese du probleme :
    FreeBSD : 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 15 :
  Synthese du probleme :
    FreeBSD : /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 16 :
  Synthese du probleme :
    FreeBSD : /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 17 :
  Synthese du probleme :
    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.
  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.
