From owner-freebsd-net@FreeBSD.ORG Thu Mar 19 11:38:32 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 31576470 for ; Thu, 19 Mar 2015 11:38:32 +0000 (UTC) Received: from work.netasq.com (gwlille.netasq.com [91.212.116.1]) by mx1.freebsd.org (Postfix) with ESMTP id E774B21B for ; Thu, 19 Mar 2015 11:38:31 +0000 (UTC) Received: from work.netasq.com (localhost.localdomain [127.0.0.1]) by work.netasq.com (Postfix) with ESMTP id A55F32700618 for ; Thu, 19 Mar 2015 12:38:29 +0100 (CET) Received: from localhost (localhost.localdomain [127.0.0.1]) by work.netasq.com (Postfix) with ESMTP id 7F14727004F0 for ; Thu, 19 Mar 2015 12:38:29 +0100 (CET) Received: from work.netasq.com ([127.0.0.1]) by localhost (work.netasq.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id No4GlBdk6DoD for ; Thu, 19 Mar 2015 12:38:29 +0100 (CET) Received: from work.netasq.com (localhost.localdomain [127.0.0.1]) by work.netasq.com (Postfix) with ESMTP id 4EE562700239 for ; Thu, 19 Mar 2015 12:38:29 +0100 (CET) Date: Thu, 19 Mar 2015 12:38:29 +0100 (CET) From: Emeric POUPON To: freebsd-net Message-ID: <522774578.25519037.1426765109046.JavaMail.zimbra@stormshield.eu> In-Reply-To: <1199418178.25515724.1426763725517.JavaMail.zimbra@stormshield.eu> Subject: Fragment questions MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Thread-Topic: Fragment questions Thread-Index: xZ/5lVsqWl2lqj6e4F5zlr+fIibc+A== X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2015 11:38:32 -0000 Hello, I noticed two questionable things in the fragmentation code: - in ip_fragment, we do not copy the flowid from the original mbuf to the fragmented mbuf. Therefore we may output very desynchronized fragments (first fragment emitted far later the second fragment, etc.) - in the ip_newid macro, we do "htons(V_ip_id++))" if we do not use randomized id. In multi core systems, we may emit successive packets with the same id. Both problems combined lead to bad packet reassembly on the remote host. What do you think? Emeric