Is there anykind of significance to putting a structure inside another
stucture when assembling a TCP/IP packet by hand? In the following
code snippet, struct iphdr and struct tcphdr are inside another
stucture. The only thing I can think of is that it's to ensure some
kind of memory alignmen

struct tpack{
struct iphdr ip;
struct tcphdr tcp;
}tpack; /*Why put the structures inside another structure?*/

struct sockaddr_in sin; /* IP address information */
/* Setup the sin struct with addressing
information */
sin.sin_family=AF_INET; /* Internet address family */
sin.sin_port=tcphp->dest; /* Source port */
sin.sin_addr.s_addr=iphp->saddr;/* Dest. address */

/* Packet assembly begins here */

/* Fill in all the TCP header
information */
tpack.tcp.source=tcphp->dest; /* 16-bit Source port number
*/
tpack.tcp.dest=tcphp->source; /* 16-bit Destination port */
tpack.tcp.seq=0; /* 32-bit Sequence Number */
tpack.tcp.ack_seq=htonl(ntohl(tcphp->seq)+1); /* 32-bit
Acknowledgement Number */
tpack.tcp.doff=5; /* Data offset */
tpack.tcp.res1=0; /* reserved */
tpack.tcp.res2=0; /* reserved */
tpack.tcp.urg=0; /* Urgent offset valid flag */
tpack.tcp.ack=1; /* Acknowledgement field valid
flag */
tpack.tcp.psh=0; /* Push flag */
tpack.tcp.rst=1; /* Reset flag */
tpack.tcp.syn=0; /* Synchronize sequence
numbers flag */
tpack.tcp.fin=0; /* Finish sending flag */
tpack.tcp.window=0; /* 16-bit Window size */
tpack.tcp.check=0; /* 16-bit checksum (to be
filled in below) */
tpack.tcp.urg_ptr=0; /* 16-bit urgent offset */

/* Fill in all the IP header
information */

tpack.ip.version=4; /* 4-bit Version */
tpack.ip.ihl=5; /* 4-bit Header Length */
tpack.ip.tos=0; /* 8-bit Type of service */
tpack.ip.tot_len=htons(IPHDR+TCPHDR); /* 16-bit Total length */
tpack.ip.id=0; /* 16-bit ID field */
tpack.ip.frag_off=0; /* 13-bit Fragment offset */
tpack.ip.ttl=64; /* 8-bit Time To Live */
tpack.ip.protocol=IPPROTO_TCP; /* 8-bit Protocol */
tpack.ip.check=0; /* 16-bit Header checksum
(filled in below) */
tpack.ip.saddr=iphp->daddr; /* 32-bit Source Address */
tpack.ip.daddr=iphp->saddr; /* 32-bit Destination Address
*/

In article <1191893579.696576.127790@k79g2000hse.googlegroups .com>,
grocery_stocker <cdalten@gmail.com> wrote:

> Is there anykind of significance to putting a structure inside another
> stucture when assembling a TCP/IP packet by hand? In the following
> code snippet, struct iphdr and struct tcphdr are inside another
> stucture. The only thing I can think of is that it's to ensure some
> kind of memory alignmen
>
> struct tpack{
> struct iphdr ip;
> struct tcphdr tcp;
> }tpack; /*Why put the structures inside another structure?*/

Because that's how the packet is actually laid out. It also allows
applications that want to do stuff with the whole header to use a single
variable rather than two.

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***

The outer structure functions as a container of a truck.

Everything needs to be inside the container, and the container gets shipped
across the net

Bye,
Skybuck.

On Oct 8, 7:04 pm, Barry Margolin <bar...@alum.mit.edu> wrote:
> In article <1191893579.696576.127...@k79g2000hse.googlegroups .com>,
>
> grocery_stocker <cdal...@gmail.com> wrote:
> > Is there anykind of significance to putting a structure inside another
> > stucture when assembling a TCP/IP packet by hand? In the following
> > code snippet, struct iphdr and struct tcphdr are inside another
> > stucture. The only thing I can think of is that it's to ensure some
> > kind of memory alignmen
>
> > struct tpack{
> > struct iphdr ip;
> > struct tcphdr tcp;
> > }tpack; /*Why put the structures inside another structure?*/
>
> Because that's how the packet is actually laid out. It also allows
> applications that want to do stuff with the whole header to use a single
> variable rather than two.
>
> --

I would like to take the time to point out that "googling" for
examples of building TCP/IP packets isn't always a good thing. Half
the sites I found had something like

struct tpack{
struct iphdr ip;
struct tcphdr tcp;

}tpack;

And the other half had something like

struct iphdr ip;
struct tcphdr tcp;


I figured the former, Ie
struct tpack{
struct iphdr ip;
struct tcphdr tcp;

}tpack;

was a little bit more politically correct since it was taken from the
Phrack, while the latter was take someone's personal blog.

grocery_stocker wrote:
> Is there anykind of significance to putting a structure inside another
> stucture when assembling a TCP/IP packet by hand? In the following
> code snippet, struct iphdr and struct tcphdr are inside another
> stucture. The only thing I can think of is that it's to ensure some
> kind of memory alignmen
>
> struct tpack{
> struct iphdr ip;
> struct tcphdr tcp;
> }tpack; /*Why put the structures inside another structure?*/

Because UDP packets also begin with (identical) IP headers?

(As do lots of other protocols that can run on top of IP.)

- Logan

["Followup-To:" header set]

On Mon, 08 Oct 2007 18:32:59 -0700, grocery_stocker <cdalten@gmail.com> wrote:
> Is there anykind of significance to putting a structure inside another
> stucture when assembling a TCP/IP packet by hand? In the following
> code snippet, struct iphdr and struct tcphdr are inside another
> stucture. The only thing I can think of is that it's to ensure some
> kind of memory alignmen

Also ask yourself if there is a reason to use structs *at all*, and
take the portability and performance hit from having to tell your
compiler to disable its normal struct layout. And hoping your CPU
tolerates reading words from odd addresses.

Writing or reading an IP header octet-by-octet isn't exactly hard. I
recently had to debug and fix a bunch of code like this -- it broke in
interesting ways on 64-bit architectures.

/Jorgen

--
// Jorgen Grahn <grahn@ Ph'nglui mglw'nafh Cthulhu
\X/ snipabacken.dyndns.org> R'lyeh wgah'nagl fhtagn!