From mboxrd@z Thu Jan  1 00:00:00 1970
From: Rick Jones <rick.jones2@hp.com>
Subject: Re: Was change to ip_push_pending_frames intended to break udp	(more
 specifically, WCCP?)
Date: Mon, 22 May 2006 11:48:45 -0700
Message-ID: <4472078D.8010706@hp.com>
References: <20060520191153.GV3776@stingr.net>	<20060520140434.2139c31b.akpm@osdl.org> <1148322152.15322.299.camel@galen.zko.hp.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Paul P Komkoff Jr <i@stingr.net>, linux-kernel@vger.kernel.org,
	netdev@vger.kernel.org
Return-path: <netdev-owner@vger.kernel.org>
Received: from palrel13.hp.com ([156.153.255.238]:16315 "EHLO palrel13.hp.com")
	by vger.kernel.org with ESMTP id S1751128AbWEVSsr (ORCPT
	<rfc822;netdev@vger.kernel.org>); Mon, 22 May 2006 14:48:47 -0400
To: Vlad Yasevich <vladislav.yasevich@hp.com>
In-Reply-To: <1148322152.15322.299.camel@galen.zko.hp.com>
Sender: netdev-owner@vger.kernel.org
List-Id: netdev.vger.kernel.org

> IP id is set to 0 on unconnected sockets when the DF bit is set (path
> mtu discovery is enabled).  Try issuing a connect() in your application
> and see if the ids are increasing again.

ID of zero again?  I thought that went away years ago?  Anyway, given 
the number of "helpful" devices out there willing to clear the DF bit, 
fragment and forward, perhaps always setting the IP ID to 0, even if DF 
is set, isn't such a good idea?

rick jones