              Laurent Constantin's network library (lcrzo)

              ----------------------------------------------
              |         KNOWN BUGS AND LIMITATIONS         |
              ----------------------------------------------

 1: While executing "genemake", printing of :
     " exec ether_hostton ko
       Warning: you are on a computed with a bad ether_hostton.
                The library lcrzo will still be usable, but read 
                ../doc/knownproblems_us.txt if you want to use the file
                /etc/ethers."
    -- OR --
    "segmentation fault" while converting from IP address to ethernet
    address.
 2: While spoofing at IP level, some packets refuse to be emitted.
    -- OR --
    While spoofing at IP level, some packets emitted doesn't have the 
    same values in the header that the ones we specified.
    -- OR --
    While spoofing at IP level, the ethernet source address is not
    affected to the correct value (FreeBSD).
 3: Display of "linux socket: Too many open files" while calling exit().
 4: Display of "kernel: programme uses obsolete (PF_INET,SOCK_PACKET)"
    in "/var/log/messages". This is a warning only.
 5: When we send a lot of packets at IP level (with lcrzo_sendraw_ip, 
    lcrzo_sendpacket_ipxxx, etc.), there is a saturation of the system.
 6: Error while opening /dev/bpf0
 7: Packets emitted to the network always have the ethernet address of
    the board, instead of having the address specified in the packet.
 8: The computer local's address is added and the end of an IP option
    of type "record route" or "timestamp".
 9: The sniff doesn't work.
    -- OR --
    Display of an error in module net-pf-17 in /var/log/messages
10: lcrzo is slow



-------------------------------------------------------------------------------
Problem 1 :
  Problem synthesis :
    While executing "genemake", printing of :
     " exec ether_hostton ko
       Warning: you are on a computed with a bad ether_hostton.
                The library lcrzo will still be usable, but read 
                ../doc/knownproblems_us.txt if you want to use the file
                /etc/ethers."
    -- OR --
    "segmentation fault" while converting from IP address to ethernet
    address.
  Environment affected by the problem :
    A- Glibc-2.?? (<2.2.1) with "nisplus" in /etc/nsswitch.conf or
    B- /etc/ethers present, but empty
  Problem's description :
    A- The problem arises when calling the function ether_hostton, and when
    the entry "nisplus" is in /etc/nsswitch.conf.
    After looking at glibc source (glibc-2.1.3), I found two errors :
      nis/nss_nisplus/nisplus-ethers.c, line 234 : 
        there is "if (name != NULL)" instead of "if (name == NULL)"
      inet/ether_hton.c, line 76 :
        fct has only four parameters, instead of five
    Note : an email was sent to glibc developpers. They applied a patch
           in glibc 2.2.1.
    B- Glibc has an error if /etc/ethers exists, but doesn't contains any
    line.
  Solution 1 :
    A- Edit /etc/nsswitch.conf to change the line :
         ethers: nisplus [NOTFOUND=return] files
    to :
         ethers: files
    Indeed, the problems disappears when removing "nisplus".
    You should then execute "genemake" again (and compile and install)
    to ensure that lcrzo will use ether_hostton.
  Solution 2 :
    A- Install glibc >2.2.1
  Solution 3 :
    B- Remove the file /etc/ethers if it doesn't contain any line.

-------------------------------------------------------------------------------
Problem 2 :
  Problem synthesis :
    While spoofing at IP level, some packets refuse to be emitted.
    -- OR --
    While spoofing at IP level, some packets emitted doesn't have the 
    same values in the header that the ones we specified.
    -- OR --
    While spoofing at IP level, the ethernet source address is not
    affected to the correct value (FreeBSD).
  Environment affected by the problem :
    Linux with IP firewalling
    Solaris
    FreeBSD
    [I guess the problem exists in almost every environment]
  Problem's description :
    Commonly, there are two levels of spoof :
     - ethernet level : we specify ethernet adress, ip address, etc.
     - ip level : we specify ip address, etc. and the system is in charge
                  of finding the corresponding ethernet address
    The problem exists because some systems try to ensure that the
    packet is legitimate before sending it.
    If the system thinks the packet is incorrect, it will throw it, or 
    it will modify our values before sending it.
    FreeBSD, doesn't correctly affect the ethernet source address.
  Solution 1 :
    A generic solution consists in spoofing at ethernet level, to
    move around the system :
     -using : lcrzo_spoof_set_useethforip(&spoof, LCRZO_TRUE);
     -or using lcrzo_sendraw_eth, and all this family 
      (lcrzo_sendpacket_ethipoptdata, lcrzo_sendpacket_ethipoptudpdata,
      etc.).
  Solution 2 :
    Under Linux, you have to compile the kernel without IP firewalling
    to be allowed to emit incorrect packets.

-------------------------------------------------------------------------------
Problem 3 :
  Problem synthesis :
    Display of "linux socket: Too many open files" while calling exit().
  Environment affected by the problem :
    Linux with libpcap 0.5
  Problem's description :
    The function "linux_restore_ifr" of "pcap-linux.c" is called
    at the end of the program ("atexit()").
    This function uses a file descriptor, but never closes it.
    Note : An email was sent to libpcap's developpers.
  Solution 1 :
    Install libpcap > 0.6 available at http://www.tcpdump.org/
  Solution 2 :
    If you use libpcap<0.6, you have to modify the function 
    "linux_restore_ifr" of "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));
        /*and here, a close was missing*/
        close(fd); /*added by Laurent, in libpcap*/
      }
      Then you have to compile and install libpcap.

-------------------------------------------------------------------------------
Problem 4 :
  Problem synthesis :
    Display of "kernel: programme uses obsolete (PF_INET,SOCK_PACKET)"
    in "/var/log/messages". This is a warning only.
  Environment affected by the problem :
    Linux kernel superior to 2.1
    libpcap up to 0.5rel2.
  Problem's description :
    The libpcap library uses a {PF_INET,SOCK_PACKET} socket.
    This kind of socket is considered as obsolete by the kernel.
    Note : an email was sent to libpcap's developpers.
  Solution 1 :
    Install libpcap > 0.6 available at http://www.tcpdump.org/
  Solution 2 :
    As this is a warning only message, it can be ignored.

-------------------------------------------------------------------------------
Problem 5 :
  Problem synthesis :
    When we send a lot of packets at IP level (with lcrzo_sendraw_ip, 
    lcrzo_sendpacket_ipxxx, etc.), there is a saturation of the system.
  Environment affected by the problem :
    Linux
    probably other systems
  Problem's description :
    When using the function lcrzo_sendraw_ip, we give the packet to the
    system, and we leave it doing its jobs.
    If the ethernet destination/router address cannot be determined,
    the system keeps the packet. Theses packets, for which system thinks
    it we be able to send them later, will take memory.
    If we trying to do a denial of service, and the packets stay in our
    system, the our system will saturate (for example, in 10 seconds).
    So we have to ensure the packets are realy sent when we do a denial
    of service.
    On powerful computers, I also saw the system accepting more packets
    than it could realy send. This is another cause of saturation.
  Solution 1 :
    (destination computer is on the LAN)
     - If the destination computer exists on the LAN, verify it is
       in the ARP cache ("arp -an"). Otherwise, try to ping it.
     - If the destination computer doesn't exists, you have to create a
       fake arp entry ("arp -s computer a:a:a:a:a:a").
  Solution 2 :
    (destination computer is after a router)
     - First, the router must be in the ARP cache ("arp -an").
       Otherwise, try to ping it.
     - Then, verify your routes ("netstat -rn") and try to ping the 
       destination.
  Solution 3 :
    (configuration OK, but powerful computer)
    The main problem is that there is no way to known if the kernel
    is saturating because of our packets. When there is the error
    (errno==ENOBUFS), it is far too late. 
    One solution is to slow down the sending process using 
    lcrzo_time_sleep. For example, we can sleep after each thousand
    packets sent. But, the sleep time depends on the system (cpu, 
    memory, network board, etc.).
    If you find a good solution to this problem, please contact me.

-------------------------------------------------------------------------------
Problem 6 :
  Problem synthesis :
    Error while opening /dev/bpf0
  Environment affected by the problem :
    FreeBSD 3.1
  Problem's description :
    By default, bpf is not compiled in the kernel. So we cannot sniff
    packets from the network.
  Solution :
    You have to compile you kernel with bpf support writing the folowing
    in /usr/src/sys/i386/NOYAU :
        "pseudo-device bpfilter 4"
    Then, you have to create devices (for example : 4 devices.)
        cd /dev
        sh MAKEDEV bpf0    (if it doesn't already exists)
        sh MAKEDEV bpf1
        sh MAKEDEV bpf2
        sh MAKEDEV bpf3

-------------------------------------------------------------------------------
Problem 7 :
  Problem synthesis :
    Packets emitted to the network always have the ethernet address of
    the board, instead of having the address specified in the packet.
  Environment affected by the problem :
    FreeBSD 3.1
  Problem's description :
    The kernel doesn't allow to spoof ethernet address.
  Solution :
    You have to modify you kernel sources and to recompile it. Directory
    "./port/FreeBSD/patchkernelspoofethernet" contains a patch.

-------------------------------------------------------------------------------
Problem 8 :
  Problem synthesis :
    The computer local's address is added and the end of an IP option
    of type "record route" or "timestamp".
  Environment affected by the problem :
    Linux kernel inferior to 2.1
  Problem's description :
    While sniffing a packet containing IP options "record route" or
    "timestamp", which is done by libpcap, the local computer adds
    its own address at the end of the list.
    This seems to be logical, but when we sniff we want to see what
    is really on the network.
    The libpcap library uses a {PF_INET,SOCK_PACKET} socket, and this
    implementation is incorrect.
  Solution :
    Kernel after 2.1 doesn't have this problem.

-------------------------------------------------------------------------------
Problem 9 :
  Problem synthesis :
    The sniff doesn't work.
    -- OR --
    Display of an error in module net-pf-17 in /var/log/messages
  Environment affected by the problem :
    Linux
  Problem's description :
    The kernel has to be compiled with "packet socket" (CONFIG_PACKET)
    to be able to sniff.
  Solution :
    You have to compile your kernel with "packet socket" :
     - select 'Packet socket' in the menu 'Networking options'
       of 'make xconfig', or
     - edit /usr/src/linux/.config to define :
       CONFIG_PACKET=y
    The kernel then needs to be compiled and installed.

-------------------------------------------------------------------------------
Problem 10 :
  Problem synthesis :
    lcrzo is slow
  Environment affected by the problem :
    All
  Problem's description :
    I choose to create a modulary library, easy to use.
    One of the consequence is the high level structuration of lcrzo.
    So, it is slower than a low level programming interface.
  Solution 1 :
    Using records (lcrzo_record.h), you can construct your packets,
    save them, and then send them.
  Solution 2 :
    You can also use only low level fonctions of lcrzo, and create
    your specific code around.
    If its still too slow, you should not use lczro and use directly
    system's functions, or buy a new computer ;)


***************************************************************************
                               UNKNOWN BUGS
                               ************

If you find errors, thanks for contacting me.
For every bug report, try to indicate :
 - lcrzo version (run lcrzo without parameters)
 - system (uname -a)
 - command or error environment
 - hos to reproduce the error
 - other information you may think userful

My email address is on the web :
   http://www.laurentconstantin.com/     (main server)
   http://go.to/laurentconstantin/       (backup server)
   http://laurentconstantin.est-la.com/  (backup server)
