From: Abraham van der Merwe <abz@frogfoot.net>
To: Ralf Spenneberg <lists@spenneberg.org>
Cc: Netfilter Discussions <netfilter@lists.netfilter.org>
Subject: Re: clearing dont-fragment bit
Date: Fri, 10 Oct 2003 10:17:41 +0200 [thread overview]
Message-ID: <20031010081741.GA30289@oasis.frogfoot.net> (raw)
In-Reply-To: <1065762785.1650.17.camel@kermit>
[-- Attachment #1: msg.pgp --]
[-- Type: application/pgp, Size: 1708 bytes --]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Ralf >@2003.10.10_07:13:06_+0200
> Am Don, 2003-10-09 um 20.11 schrieb Abraham van der Merwe:
> > Yes, I know, but as long as all the fragments have unique ids it shouldn't
> > matter. Also, if the packet is fragmented along the way under normal
> > circumstances (i.e. DF=0), then the IP-ID field would have to be incremented
> > by the router fragmenting the packet.
> True but Linux 2.4 clears the IP-ID field when sending a packet with the
> DF-Bit set. You have to manually recreate a unique IP-ID field when
> clearing the DF-Bit on the firewall. Even when the router increments
> this field all packets will have the ID of 1. When defragmenting the
> receiver does not know which fragment belongs to which packet.
>
> Linux 2.4 is the only operating system I know of that shows this
> behavior.
Ok, I see what you're getting at. That brings us back to my original
suggestion. If the tunnel could do the fragmentation _and_ reassembly then
this would not be a problem. *sigh*
- --
Regards
Abraham
I hate it when my foot falls asleep during the day cause that means
it's going to be up all night.
-- Steven Wright
___________________________________________________
Abraham vd Merwe - Frogfoot Networks CC
9 Kinnaird Court, 33 Main Street, Newlands, 7700
Phone: +27 21 686 1665 Cell: +27 82 565 4451
Http: http://www.frogfoot.net/ Email: abz@frogfoot.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.5 (GNU/Linux)
Comment: Debian :: The Universal Operating System
iD8DBQE/hmsl0jJV70h31dERAsLkAJ94k/LXfuSidWOmBIb2uZkF5Vi9jwCaA17A
Fr8tm9CXx5vCLx7u0A8sLmM=
=aaCy
-----END PGP SIGNATURE-----
prev parent reply other threads:[~2003-10-10 8:17 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-10-09 13:43 clearing dont-fragment bit Abraham van der Merwe
2003-10-09 14:03 ` Maciej Soltysiak
2003-10-09 14:08 ` Abraham van der Merwe
2003-10-09 14:43 ` Ramin Dousti
2003-10-09 14:52 ` Abraham van der Merwe
2003-10-09 15:49 ` Ramin Dousti
2003-10-09 16:13 ` Abraham van der Merwe
2003-10-09 19:44 ` Ramin Dousti
2003-10-09 16:23 ` Ralf Spenneberg
2003-10-09 16:50 ` Abraham van der Merwe
2003-10-09 17:12 ` Ralf Spenneberg
2003-10-09 18:11 ` Abraham van der Merwe
2003-10-10 5:13 ` Ralf Spenneberg
2003-10-10 8:17 ` Abraham van der Merwe [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20031010081741.GA30289@oasis.frogfoot.net \
--to=abz@frogfoot.net \
--cc=lists@spenneberg.org \
--cc=netfilter@lists.netfilter.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.