From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <7c5893f473a41fe0dd03897da25d170f@plan9.bell-labs.com> From: presotto@plan9.bell-labs.com To: nemo@plan9.escet.urjc.es, 9fans@cse.psu.edu, paurea@plan9.escet.urjc.es Subject: Re: [9fans] Re: IP_DF bit and broken connections MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="upas-vnubosgbhyauqylqkyvjhsyven" Date: Thu, 5 Dec 2002 09:23:13 -0500 Topicbox-Message-UUID: 2e0ca7fe-eacb-11e9-9e20-41e7f4b1d025 This is a multi-part message in MIME format. --upas-vnubosgbhyauqylqkyvjhsyven Content-Disposition: inline Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit The only problem is that TCP always sets the DF bit to zero since it zeros it in the proto header and copies the protoheader into every packet. ICMP does screw up by just copying the input header to the output packet and thus inheriting the DF bit. I just put new 9/ip/ip.[ch] and 9/ip/icmp.c on sources. The new ip.c sends back an icmp message if it couldn't forward the packet because of the DF bit. It also zero's the frag field when it passes it up the stack so that no upper level protocol can reflect it back. The DF should only remain when we're acting as a router. There's now a check and a print to make sure we're not sending a DF bit for packets originated on the machine. Nemo, could you try these? If you are still sending out anything with DF set, please track it down. I don't see how it could have been happening except in ICMP but this should make it impossible to copy the DF bit from input to output and complain about any locally generated DF's. By the way, Linux is probably doing path MTU discovery. By setting the DF bit, it gets an ICMP packet bounced back to it when the packet can't fit at some router without being fragged. The system backs off when it gets the ICMP message eventually discovering the MTU. If people are using VPN's big time that reduce packet size, I should probably throw in MTU discovery also. It's not that hard to do. It does have some pretty severe problems though. Look at rfc's 1191 & 2923. --upas-vnubosgbhyauqylqkyvjhsyven Content-Type: message/rfc822 Content-Disposition: inline Received: from plan9.cs.bell-labs.com ([135.104.9.2]) by plan9; Thu Dec 5 05:35:16 EST 2002 Received: from mail.cse.psu.edu ([130.203.4.6]) by plan9; Thu Dec 5 05:35:15 EST 2002 Received: from psuvax1.cse.psu.edu (psuvax1.cse.psu.edu [130.203.16.6]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id B5846199D7; Thu, 5 Dec 2002 05:35: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 ESMTP id A598C1998C for <9fans@cse.psu.edu>; Thu, 5 Dec 2002 05:34:57 -0500 (EST) Message-ID: <08fdc73b5f22a6134f7ef266a02a68a0@plan9.escet.urjc.es> To: 9fans@cse.psu.edu, paurea@plan9.escet.urjc.es From: Fco.J.Ballesteros MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Subject: [9fans] Re: 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: Thu, 5 Dec 2002 11:34:56 +0100 This is what we found regarding broken connections when going through some routers. The setting is Plan 9 <-⋯ether⋯-> adsl router <--> Linux. Linux always sets the DF bit in outgoing packets. Plan 9 doesnt, but setting it does not change things (we tested that). Some routers eat packets with size 1500 (eg. adsl from telefonica in spain) without fragmenting or sending icmps. Too bad. With icmp (sized 1500), Linux sends two fragments despite the mtu being big enough. We get both fragments in Plan 9 but since they came with the DF bit set, the reply is dropped by the if in ip.c. Perhaps once reassembled, the DF bit could be cleared; I don't know. With tcp, Linux has its mtu at 1500 and negotiates its mss of 1460. The same does Plan 9, but despite this, Linux sends packets of at most 1444 bytes when going through the router and Plan 9 sends up to 1500 (which IMHO is legitimate). Thus, the linux packets get through and our 1500 packets don't get through. (The connection gets hanged so that Plan 9 retransmits the poor 1500 packet once and again). The workaround is simply to adjust the mtu not to reach 1500. Doing so either on Linux or on Plan 9 lets things work (because the negotiated mss is smaller). I don't know how linux discovers that it shouldn't send 1500 bytes. There are no icmp packets, and the negotiated mss is the same (as I said before). --upas-vnubosgbhyauqylqkyvjhsyven--