Why redeclare TCP and IP headers in a libpcap program?

Question

In a tutorial program of libpcap I see the following structures:

/* IP header */
struct sniff_ip {
    u_char  ip_vhl;                 
    u_char  ip_tos;                 
    u_short ip_len;                 
    u_short ip_id;                  
    u_short ip_off;                 
    #define IP_RF 0x8000            
    #define IP_DF 0x4000            
    #define IP_MF 0x2000            
    #define IP_OFFMASK 0x1fff       
    u_char  ip_ttl;                 
    u_char  ip_p;                   
    u_short ip_sum;                 
    struct  in_addr ip_src,ip_dst;  
};
#define IP_HL(ip)               (((ip)->ip_vhl) & 0x0f)
#define IP_V(ip)                (((ip)->ip_vhl) >> 4)

/* TCP header */
typedef u_int tcp_seq;

struct sniff_tcp {
    u_short th_sport;               
    u_short th_dport;               
    tcp_seq th_seq;                 
    tcp_seq th_ack;                 
    u_char  th_offx2;               
    #define TH_OFF(th)      (((th)->th_offx2 & 0xf0) >> 4)
    u_char  th_flags;
    #define TH_FIN  0x01
    #define TH_SYN  0x02
    #define TH_RST  0x04
    #define TH_PUSH 0x08
    #define TH_ACK  0x10
    #define TH_URG  0x20
    #define TH_ECE  0x40
    #define TH_CWR  0x80
    #define TH_FLAGS        (TH_FIN|TH_SYN|TH_RST|TH_ACK|TH_URG|TH_ECE|TH_CWR)
    u_short th_win;                 
    u_short th_sum;                 
    u_short th_urp;                 
};

Why the struct of the headers above has been redeclared and the TCP and IP structures in netinet/tcp.h , netinet/ip.h wasn't used? Is there some advantage in using this custom struct?

Answer 1

The short answer: it is just an example.

---

As noted in the comments to this post by the author of the tutorial there are issues with portability, since not all operating systems provide such network structures and on the other hand the format is clearly defined by RFCs, so own structures can be used.

---

Tutorial evolution

The original document was modified in 2005 (there is a note "Further editing and development by Guy Harris"). The orginal document can be found as version 1.1 in the cvs :

First, we must have the actual structures define before we can typecast to them. The following is the structure definitions that I use to describe a TCP/IP packet over Ethernet. All three definitions that I use are taken directly out of the POSIX libraries. Normally I would have simply just used the definitions in those libraries, but it has been my experience that the libraries vary slightly from platform to platform, making it complicated to implement them quickly. So for demonstration purposes we will just avoid that mess and simply copy the relevant structures. All of these, incidentally, can be found in include/netinet on your local Unix system. Here are the structures:

There were original copies of linux structures (now they are modified in the example). The explanation:

Note: On my Slackware Linux 8 box (stock kernel 2.2.19) I found that code using the above structures would not compile. The problem, as it turns out, was in include/features.h , which implements a POSIX interface unless _BSD_SOURCE is defined. If it was not defined, then I had to use a different structure definition for the TCP header. The more universal solution, that does not prevent the code from working on FreeBSD or OpenBSD (where it had previously worked fine), is simply to do the following:
#define _BSD_SOURCE 1
prior to including any of your header files. This will ensure that a BSD style API is being used. Again, if you don't wish to do this, then you can simply use the alternative TCP header structure, which I've linked to here, along with some quick notes about using it.

So, after the document editions the structures were modified in v1.2 and the text is changed in v1.6 with the following commit comment:

Don't talk about any of this coming from POSIX (it doesn't) and don't note that they might be available on a UN*X system (don't take your packet layouts from the OS; it might not have them, or they might not have all the protocol features you want).