From mboxrd@z Thu Jan  1 00:00:00 1970
From: Grant Edwards <grante@visi.com>
To: ecos-discuss@sources.redhat.com
Subject: [ECOS] RedBoot sending incorrect TCP window size
Date: Thu, 08 Feb 2001 08:47:00 -0000
Message-id: <20010208105133.A1381@visi.com>
X-SW-Source: 2001-02/msg00124.html

I'm having problems with some legacy applications because
Redboot (on ARM) advertises a TCP window size of 1458.  The
legacy stuff breaks if a TCP write of 1460 bytes doesn't go in
a single Ethernet frame.

Yes, I know, the legacy code is broken because it trying to use
TCP as a datagram service instead of a byte stream service.
That battle was lost before I stated working here.  :(

The problem is triggered because Redboot uses the expression
"sizeof (eth_header_t)" to decide how many bytes there are in 
an Ethernet header.  With ARM gcc, that expression has a value
of 16.  There are 14 bytes in an Ethernet header.  The reduces
the window size from 1460 (the usual max size of a TCP payload
in an Ethernet frame) to 1458.  Thus making my admittedly-broken
stuff not work.

It appears that there is no easy way to prevent gcc from
padding structs.

I've complained about this for years.  The response has always
been a scolding for using struct definitions for anything that
had to match up with the outside world's expectations.  

According to the gcc folks, you are suppose to memcpy()
everything to/from hard-wired offsets in communications frames
and memory-mapped I/O.  You are not supposed to use structs for
such things.

The sizeof operation on IP and TCP header structs yields the
expected result because they are an exact multiple of 32 bits.
This is just a lucky feature of gcc, and is not guaranteed to
be portable between architectures, versions, or anything else.

All occurrences of "sizeof (eth_header_t)" in net.h, tcp.c, udp.c
need to be replace by a hard coded constant.  I'll send a patch
later today...

-- 
Grant Edwards
grante@visi.com