Date: Tue, 23 Oct 2001 22:42:32 -0700 From: "Crist J. Clark" <cristjc@earthlink.net> To: j mckitrick <jcm@freebsd-uk.eu.org> Cc: freebsd-questions@FreeBSD.ORG Subject: Re: question about mtu and fragment offset Message-ID: <20011023224232.B5743@blossom.cjclark.org> In-Reply-To: <20011024010617.A50480@dogma.freebsd-uk.eu.org>; from jcm@freebsd-uk.eu.org on Wed, Oct 24, 2001 at 01:06:17AM %2B0100 References: <20011019134824.A9949@dogma.freebsd-uk.eu.org> <20011022225420.E364@blossom.cjclark.org> <20011024010617.A50480@dogma.freebsd-uk.eu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Oct 24, 2001 at 01:06:17AM +0100, j mckitrick wrote:
> On Mon, Oct 22, 2001 at 10:54:21PM -0700, Crist J. Clark wrote:
> | On Fri, Oct 19, 2001 at 01:48:24PM +0100, j mckitrick wrote:
> | >
> | > This is for a class project :-)
> | >
> | > If the mtu of a gateway is 1500, does that mean all fragments larger
> | > than this will be broken into packets of 1500 (20 header, 1480 data) or
> | > packets of 1496 (20 header, 1476 data) since the fragment offset must be
> | > even multiples of 8?
> |
> | 1500. 1480 is a multiple of 8 last time I checked.
>
> Okay, I took my time and thought about it to make sure I phrased my
> answer correctly. As I understand it, the fragment offset equals the
> length of the entire datagram, not just the data.
Nope.
> So, if a gateway has
> an mtu of 1500, since the offset must be a multiple of 8, and 1500/8 is
> not even, then the total datagram length could be no more than 1496. If
> the header is 20 bytes, that leaves 1476 for data. Even though 1480 is
> a multiple of 8, 1500 is not. So 1480 + 20 header bytes would still be
> a non-integer number of octets. Am I wrong? Or what have I
> misunderstood?
The offset field indicates where the data portion of the current
fragment datagram lies in the original "complete" datagram.
Say we have a 5001 byte (20 bytes of header and 4981 bytes of data)
datagram that needs to cross a 1500 MTU network. The fragment datagram
will have a 20-byte header too, so we can put 1480 bytes of the data
in it. The next fragment will contain data that starts at that
1480-byte offset from the start of the original datagram. The header
is _not_ included in offset calculation. The result will be something
like,
frag # offset bytes of data total datagram length
1: 0 1480 1500
2: 1480 1480 1500
3: 2960 1480 1500
4: 4440 541 561
For kicks, let's actually watch this.
# ping -s 4973 blossom
The size of 4973 byes is used since the ICMP header is an extra 8
bytes of IP data.
22:39:58.567281 192.168.64.60 > 192.168.64.50: icmp: echo request (frag 29193:1480@0+) (ttl 64, len 1500)
22:39:58.567298 192.168.64.60 > 192.168.64.50: (frag 29193:1480@1480+) (ttl 64, len 1500)
22:39:58.567312 192.168.64.60 > 192.168.64.50: (frag 29193:1480@2960+) (ttl 64, len 1500)
22:39:58.567317 192.168.64.60 > 192.168.64.50: (frag 29193:541@4440) (ttl 64, len 561)
And my math checks! :)
--
Crist J. Clark | cjclark@alum.mit.edu
| cjclark@jhu.edu
http://people.freebsd.org/~cjc/ | cjc@freebsd.org
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20011023224232.B5743>