From patchwork Tue Oct 14 11:06:20 2008 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Pedro Ribeiro X-Patchwork-Id: 4450 X-Patchwork-Delegate: davem@davemloft.net Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.176.167]) by ozlabs.org (Postfix) with ESMTP id 77F9BDDE31 for ; Tue, 14 Oct 2008 22:38:53 +1100 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755278AbYJNLir (ORCPT ); Tue, 14 Oct 2008 07:38:47 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1755261AbYJNLiq (ORCPT ); Tue, 14 Oct 2008 07:38:46 -0400 Received: from smtp-out1.net.ipl.pt ([192.104.48.14]:51310 "EHLO smtp-out1.net.ipl.pt" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755202AbYJNLiq convert rfc822-to-8bit (ORCPT ); Tue, 14 Oct 2008 07:38:46 -0400 X-Greylist: delayed 1943 seconds by postgrey-1.27 at vger.kernel.org; Tue, 14 Oct 2008 07:38:45 EDT DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=2008.1; d=net.ipl.pt; h=Received:Date:From:X-Mailer:Reply-To:Organization:X-Priority:Message-ID:To:Subject:MIME-Version:Content-Type:Content-Transfer-Encoding; b=ToDLOmoSKyjoc9IRTltiRd8Ndc+hmpdiJeeQ0oSv6pyBdT544o5AZpBscrDaClYWHZnJNgGn2dmF+gWihocmUV184O3Hb0kdOJV1k7u8GlTaek1aR0njq1ntcWAbK8eg; Received: from [2001:690:2008:e0cf:91d:aca0:d45c:c2b0] (port=58780 helo=HARMONY.net.local) by smtp1.net.ipl.pt with esmtpa (Exim 4.69 1) (envelope-from pribeiro-bulk@net.ipl.pt) id 1KphjJ-0008KR-Sw by authid with cram; Tue, 14 Oct 2008 12:06:21 +0100 Date: Tue, 14 Oct 2008 12:06:20 +0100 From: Pedro Ribeiro X-Mailer: The Bat! (v4.0.24) Professional Reply-To: Pedro Ribeiro Organization: IPL X-Priority: 3 (Normal) Message-ID: <159769323.20081014120620@net.ipl.pt> To: netdev@vger.kernel.org Subject: [PATCH] Structure icmp6hdr (IPv6/ICMPv6) with bug in the bitfields! MIME-Version: 1.0 Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org First, let-me say sorry for the long text, i think is needed for context. My name is Pedro Ribeiro and I’m the operations coordinator at IPLNet, a network that interconnects all the schools belonging to the Polytechnic Institute of Lisbon (IPL) and in addition I’m also a teacher of network engineering at ISEL (a local university). In the majority of the network segments of our infrastructure, we have dual stack connectivity with IPv4/IPv6. In the last months, we have upgraded most of the infrastructure, specially targeting IPv6 performance leaving most of the segments with an “old/slow router” and a “new/fast” router as possible default gateways. In the course of validating the changes, we have done some tests with IPv6 and some of them were really disappointing with no gains at all. While investigating the cause of that, I have seen that our main Linux servers were using the “wrong” default gateway, the “old/slow” one. This behaviour is inconsistent with the configuration of the routers; the “new/fast” is sending the router advertisements announcing himself as default gateway with MEDIUM (default) preference and the “old/slow” announcing himself as LOW preference. Deep analysis in the sources of Linux revealed that the value of “pref” passed to rt6_add_dflt_router(...) in the file net/ipv6/route.c isn’t consistent with the one sent by the routers and observed with wireshark. Seeking the roots of the problem I’ve detected a bug in the definitions of the bitfield that includes the router preference in the router advertisement message that are resulting in retrieving the wrong bits from the structure defined in “include/linux/icmpv6.h”. The struct is the base one from ICMPv6 (icmp6hdr) and was lacking the bit field “home_agent” between “router_pref” and “other” and the reserved bits are only 3, not 4 as in the structure (according to RFC4191) Follows a “diff” with the changes I’ve made to correct this problem (I’ve made it against kernel 2.6.23, but I’ve confirmed that the problem still exists in 2.6.25) Even after this fix, the problem of deterministic and preference aware default route selection, remains. I have not figured until now how the preference affects the selection, maybe it is a missing feature. I am sorry to say it (I am not a Windows fan), but the behaviour observed in Windows Vista is in this matter consistent with the one I was expecting from the reading of the RFCs. Developers on this area please clarify me this subject; does the preference present in the RAs is supposed to influence the decision? In addition, what is the criterion for selecting the default route in the presence of multiple candidates with the same preference? Best Regards to all the Linux community! --- /usr/src/linux-2.6.23-gentoo-r9orig/include/linux/icmpv6.h 2007-10-09 21:31:38.000000000 +0100 +++ /usr/src/linux-2.6.23-gentoo-r9/include/linux/icmpv6.h 2008-10-13 17:42:56.000000000 +0100 @@ -40,16 +40,18 @@ struct icmpv6_nd_ra { __u8 hop_limit; #if defined(__LITTLE_ENDIAN_BITFIELD) - __u8 reserved:4, + __u8 reserved:3, router_pref:2, + home_agent:1, other:1, managed:1; #elif defined(__BIG_ENDIAN_BITFIELD) __u8 managed:1, other:1, + home_agent:1, router_pref:2, - reserved:4; + reserved:3; #else #error "Please fix " #endif