From owner-freebsd-current@FreeBSD.ORG Tue Dec 23 02:27:08 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DD19B1065673; Tue, 23 Dec 2008 02:27:08 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by mx1.freebsd.org (Postfix) with ESMTP id A55008FC19; Tue, 23 Dec 2008 02:27:08 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from bcs-mail03.internal.cacheflow.com ([10.2.2.95]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id mBN2R8qR001542; Mon, 22 Dec 2008 18:27:08 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 22 Dec 2008 18:27:21 -0800 Message-ID: In-Reply-To: <200812221621.40722.tijl@ulyssis.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: HEADSUP: arp-v2 has been committed Thread-Index: AclkSQFXYpnx5DzIQR2tYY9xXa8VxQAWkVXw References: <20081221125120.GO23166@droso.net> <200812221621.40722.tijl@ulyssis.org> From: "Li, Qing" To: "Tijl Coosemans" , "Qing Li" Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org Subject: RE: HEADSUP: arp-v2 has been committed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Dec 2008 02:27:09 -0000 Hi Tijl, Good questions and see my comments below. >=20 > I'm looking into the Wine case, but don't have any experience with the > implementation of routing tables, so I need to have a few things > spelled out. >=20 > Wine currently uses: >=20 > int mib[] =3D {CTL_NET, PF_ROUTE, 0, AF_INET, NET_RT_FLAGS, RTF_LLINFO}; >=20 > I take it this returns all the entries which have the RTF_LLINFO flag > set? And to make this compile on CURRENT I have to change this into: >=20 > #ifdef RTF_LLINFO > int mib[] =3D {CTL_NET, PF_ROUTE, 0, AF_INET, NET_RT_FLAGS, RTF_LLINFO}; > #else > int mib[] =3D {CTL_NET, PF_ROUTE, 0, AF_INET, NET_RT_FLAGS, 0}; > #endif >=20 > Is AF_INET really the correct address family? What about AF_LINK and > AF_ARP? Is using NET_RT_FLAGS with flags mask 0 exactly the same as > using NET_RT_DUMP? >=20 AF_INET is the correct address family, which indicates the L2=20 information (a.k.a RTF_LLINFO previously) should be retrieved from the IPv4 ARP table. If the AF family were instead AF_INET6, then the L2 information would be coming from the ND6 cache.=20 NET_RT_DUMP walks the entire routing tree. Specifying specific flags and using the NET_RT_FLAGS opcode retrieves routing entries that have those bits set. NET_RT_FLAGS with mask 0 is an indication to the kernel the L2 table=20 should be retrieved.=20 I am glad you asked these questions because after re-examining my code,=20 I realized I could make slight optimization and also need to perform=20 additional check against erroneous input.=20 >=20 > Also, at some other place, Wine wants to retrieve gateway entries and > it uses: >=20 > int mib[6] =3D {CTL_NET, PF_ROUTE, 0, PF_INET, NET_RT_DUMP, 0}; > ^ this should be AF_INET I think >=20 > After that it runs over all entries counting only those which have > RTF_GATEWAY set and RTF_MULTICAST unset. Is the output of this > different now in CURRENT? > No, the output of this command is still the same. NET_RT_DUMP obtains the entire L3 table and filtering for RTF_GATEWAY non-multicast routes have the same semantics. Those flags never apply to L2 entries. -- Qing