All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephan von Krawczynski <skraw@ithnet.com>
To: netdev@oss.sgi.com
Subject: Re: 2.4 and ip fragmentation question (background info)
Date: Fri, 2 Jan 2004 13:39:13 +0100	[thread overview]
Message-ID: <20040102133913.488cd537.skraw@ithnet.com> (raw)
In-Reply-To: <20031231122325.77f19143.skraw@ithnet.com>

On Wed, 31 Dec 2003 12:23:25 +0100
Stephan von Krawczynski <skraw@ithnet.com> wrote:

> Hello,
> 
> is ip fragmentation thought to work with multiple fragmented packets all with
> same ID field, same source and destination address? Or can one consider this
> situation as generally unsolvable and broken by application?
> 
> Regards,
> Stephan

As this question obviously sounded significantly stupid enough not to be
answered I may point you to this code in 2.4 include/net/ip.h:

static inline void ip_select_ident(struct iphdr *iph, struct dst_entry *dst,
struct sock *sk)
{
        if (iph->frag_off&__constant_htons(IP_DF)) {
                /* This is only to work around buggy Windows95/2000
                 * VJ compression implementations.  If the ID field
                 * does not change, they drop every other packet in
                 * a TCP stream using header compression.
                 */
                iph->id = ((sk && sk->daddr) ? htons(sk->protinfo.af_inet.id++)
: 0);
        } else
                __ip_select_ident(iph, dst);
}


As you all know this sets the ID field inside the ip-header. Interestingly it
depends on frag_off and sk->daddr field.
I ran into an application (formerly for 2.2 kernel) where the author (!=me)
obviously was unaware of this dependency and initialised these fields after
calling ip_select_ident. The outcome was that everything runs normal during low
traffic, but when more packets were transferred it looked like a increasing
amount of packets got "0" as ID, because iph->frag_off was not initialised
correctly and the skbs were of course not zeroed. Still this would have been no
problem if these packets weren't fragmented.
What I saw was that packets got corrupted during high load (because
fragmentation obviously vomitted on the high rate of "ID=0" packets), but all
was perfectly well during low load.

Should the author have read some doc where it is clearly stated that
ip_select_ident needs a more or less completely initialised ip header to work
as expected? (other way round see my original question...)

Regards,
Stephan

      reply	other threads:[~2004-01-02 12:39 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-12-31 11:23 2.4 and ip fragmentation question Stephan von Krawczynski
2004-01-02 12:39 ` Stephan von Krawczynski [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=20040102133913.488cd537.skraw@ithnet.com \
    --to=skraw@ithnet.com \
    --cc=netdev@oss.sgi.com \
    /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.