From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <7b1c43dd7861606ef7b507b6df57953d@plan9.bell-labs.com> From: presotto@plan9.bell-labs.com To: nemo@plan9.escet.urjc.es, 9fans@cse.psu.edu Subject: Re: [9fans] IP_DF bit and broken connections MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="upas-zminzhvismrxpbkphdropzuhor" Date: Tue, 3 Dec 2002 09:16:40 -0500 Topicbox-Message-UUID: 2cf007da-eacb-11e9-9e20-41e7f4b1d025 This is a multi-part message in MIME format. --upas-zminzhvismrxpbkphdropzuhor Content-Disposition: inline Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit I'm confused. The DF bit should only be set in packets that you are forwarding to someone else, i.e., if you are acting as a router. Is that what you are doing? I can imagine a situation where our action is incorrect. If you are acting as a router and the system routing through you is setting the DF bit in order to do mtu discovery and it is larger than your mtu is less than the packet size, then we should be sending back an icmp message saying that we couldn't fragment. Otherwise the connection can't go through. Is this your situation? The only other situation I can imagine is that we're somewhere forgetting to zero out the bit when creating packets. --upas-zminzhvismrxpbkphdropzuhor Content-Type: message/rfc822 Content-Disposition: inline Received: from plan9.cs.bell-labs.com ([135.104.9.2]) by plan9; Tue Dec 3 08:10:15 EST 2002 Received: from mail.cse.psu.edu ([130.203.4.6]) by plan9; Tue Dec 3 08:10:14 EST 2002 Received: from psuvax1.cse.psu.edu (psuvax1.cse.psu.edu [130.203.23.6]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id 8C9C0199F2; Tue, 3 Dec 2002 08:10:06 -0500 (EST) Delivered-To: 9fans@cse.psu.edu Received: from nautilus.escet.urjc.es (nautilus.escet.urjc.es [212.128.4.207]) by mail.cse.psu.edu (CSE Mail Server) with SMTP id CFB5F19995 for <9fans@cse.psu.edu>; Tue, 3 Dec 2002 08:09:52 -0500 (EST) Message-ID: To: 9fans@cse.psu.edu From: Fco.J.Ballesteros MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: [9fans] IP_DF bit and broken connections Sender: 9fans-admin@cse.psu.edu Errors-To: 9fans-admin@cse.psu.edu X-BeenThere: 9fans@cse.psu.edu X-Mailman-Version: 2.0.11 Precedence: bulk Reply-To: 9fans@cse.psu.edu List-Id: Fans of the OS Plan 9 from Bell Labs <9fans.cse.psu.edu> List-Archive: Date: Tue, 3 Dec 2002 14:09:47 +0100 Hi, we've found that if we dont disable the check for IP_DF bit while processing a fragment in ip.c, then some of our connections break from time to time. By doing this change, everything seems to work fine for us: diff /n/dump/2002/1203/sys/src/9/ip/ip.c /sys/src/9/ip/ip.c 315c315 < if(eh->frag[0] & (IP_DF>>8)){ --- > if(0 && eh->frag[0] & (IP_DF>>8)){ The reason seems to be that some times when we connect through our router, we get packet fragments which also carry the DF bit set. Since we're not network gurus, we asked to our local network programming guru and he suggested not to even look into the DF bit if we're not gatewaying. I don't think this is a `Plan 9 problem', but since it did forbid us to keep our connections alive when going through some routers, I thought it could be of help for others. We'll continue tracing this problem. In case we find out anything, we'll let you know. --upas-zminzhvismrxpbkphdropzuhor--