From owner-freebsd-current@FreeBSD.ORG Wed Aug 19 16:51:09 2009 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 BD1D21065696 for ; Wed, 19 Aug 2009 16:51:09 +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 A44EF8FC43 for ; Wed, 19 Aug 2009 16:51:09 +0000 (UTC) Received: from bcs-mail03.internal.cacheflow.com ([10.2.2.95]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id n7JGp8Y9024066; Wed, 19 Aug 2009 09:51:08 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 19 Aug 2009 09:50:24 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: network problems Thread-Index: AcogwCZMOPzTie0KQdef4pCG9rleQQAKgDYN References: <18104823-CB3F-42DA-9DE8-E6692D81E96B@h3q.com> From: "Li, Qing" To: "Denis Ahrens" , Cc: Subject: RE: network problems 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: Wed, 19 Aug 2009 16:51:09 -0000 > > The problems are similar to = http://lists.freebsd.org/pipermail/freebsd-current/2009-August/010287.htm= l > That was a configuration issue. >=20 > When I try to ping the address the machine panics! > (something with sin_family and in_lltable_lookup) > http://denisy.dyndns.org/panic.jpg > After a quick cursory read over the code, this issue appears to be a = problem=20 in the flow-table handling logic in ip_output() function. Two problems seem to exist in the flow-table logic. 1. In flowtable_lookup() where it searches for the destination in the=20 routing table, the code does not check for the rt_ifp type once a route entry is found. In the case of "if_tun", the flow-table=20 must not try to cache any entry whose "rt_ifp->if_flag & = IFF_POINTOPOINT" is true. Right now it does, and I think this will trigger the crash later. 2. The flowtable_lookup() seems to alway assume a valid entry=20 will be returned as long as a route entry exists for the destination. In other words, if a route exists for the destination, then either flow-table already have a cache, or a new entry is created. This does not work due to (1.) above.=20 flowtable_lookup() should allow a "bypass flow-table" return, not=20 just success/failure result. This is especially true for tunneling interfaces "if_tun, if_gre" etc. where ip_output() will be called multiple times (nested). Only at the final = invocation of ip_output() (where the rt->rt_ifp points to a physical NIC) should a flow-table entry be created. So for now, as a possible temporary workaround, disable FLOWTABLE in = your kernel configuration file and see if that fixes the problem. -- Qing