Topic : Raw IP Networking FAQ
Author : Thamer Al-Harbash
Page : << Previous 5  
Go to page :


      

            2.3.1) IP header length/offset host/network byte
            (feature/bug?)

            

            Systems derived from 4.4BSD have a bug in which the
            ip_len and ip_off members of the ip header have to be set
            in host byte order rather than network byte order. Some
            systems may have fixed this. I've confirmed this bug has
            been fixed on OpenBSD 2.1.

            2.3.2) Unwanted packet processing on some systems.
            

            Thanks to Michael Masino <mmasino@mitre.org> , Lamont
            Granquist <lamontg@hitl.washington.edu> , and route
            <route@infonexus.com> for the submission of bug reports.

            Some systems will process some of the fields in the IP
            and transport headers. I've attempted to verify the
            reports I've received here's what I can verify for sure.

            Solaris (at least 2.5/2.6) and changes the IP ID field,
            and adds a Do Not Fragment flag to the IP header (IP_DF).
            It also expects the checksum to contain the length of the
            transport level header, and the data.

            Further reports which I cannot verify (can't reproduce),
            consist of claims that Solaris 2.x and Irix 6.x will
            change the sequence and acknowledgment numbers. Irix 6.x
            is also believed to have the problem mentioned in the
            previous paragraph. If you experience these problems,
            double check with the example source code.

            You'll save yourself a lot of trouble by just getting
            Libnet http://www.packetfactory.net/libnet/

        2.4) What are raw sockets commonly used for?
        

        Various UNIX utilities use raw sockets, among them are:
        traceroute, ping, arp. Also, a lot of Internet security tools
        make use of raw sockets. However in the long run, raw sockets
        have proven bug ridden, unportable and limited in use.

    3) libpcap (A Portable Packet Capturing Library)
    

        
3.1) Why should I use libpcap, instead of using the native
        API on my operating system for packet capturing?

        
        
        

        libpcap was written so that applications could do packet
        capturing portably. Since it's system independent and
        supports numerous operating systems, your packet capturing
        application becomes more portable to various other systems.

        3.2) Does libpcap have any disadvantages, which I should be
        aware of?

        
        
        

        Yes, libpcap will only use in-kernel packet filtering when
        using BPF, which is found on BSD derived systems. This means
        any packet filters used on other operating systems which
        don't use BPF will be done in user space, thus losing out on
        a lot of speed and efficiency. This is not what you want,
        because packet loss can increase when sniffing a busy
        network.

        DEC OSF/1 has an API which has been extended to support
        BPF-style filters; libpcap does utilize this.

        In the future, libpcap may translate BPF style filters to
        other packet capturing facilities, but this has not been
        implemented yet as of version 0.3

        Refer to question 1.4 to see how packet filters help in
        reliably monitoring your network.

        3.3) Where can I find example libpcap source code?
        

        A lot of the source code found at LBNL's ftp archive
        ftp://ftp.ee.lbl.gov/ uses libpcap. More specifically,
        ftp://ftp.ee.lbl.gov/tcpdump.tar.Z probably demonstrates
        libpcap to a large extent.

    4) List of contributors.
    

      Thamer Al-Herbish <shadows@whitefang.com>
      W. Richard Stevens <rstevens@kohala.com>
      John W. Temples (III) <john@whitefang.com>
      Michael Masino <mmasino@mitre.org>
      Lamont Granquist <lamontg@hitl.washington.edu>
      Michael T. Stolarchuk <mts@rare.net>
      Mike Borella <Mike_Borella@mw.3com.com>
      route <route@infonexus.com>
      Derrick J Brashear <shadow@dementia.org>

Page : << Previous 5