From owner-freebsd-current@FreeBSD.ORG Wed Aug 19 17:39:15 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 37D9A1065700 for ; Wed, 19 Aug 2009 17:39:15 +0000 (UTC) (envelope-from denis@h3q.com) Received: from mail.h3q.com (mail.h3q.com [213.73.89.199]) by mx1.freebsd.org (Postfix) with ESMTP id 8017E8FC61 for ; Wed, 19 Aug 2009 17:39:14 +0000 (UTC) Received: (qmail 17697 invoked from network); 19 Aug 2009 17:39:13 -0000 Received: from unknown (HELO ?10.1.2.230?) (denis@85.178.13.111) by mail.h3q.com with AES128-SHA encrypted SMTP; 19 Aug 2009 17:39:13 -0000 From: Denis Ahrens To: freebsd-current@freebsd.org In-Reply-To: <35FF00562E814F08BE71B6407FB6C1BF@adnote989> X-Priority: 3 References: <18104823-CB3F-42DA-9DE8-E6692D81E96B@h3q.com> <35FF00562E814F08BE71B6407FB6C1BF@adnote989> Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 19 Aug 2009 19:39:11 +0200 X-Mailer: Apple Mail (2.936) X-Mailman-Approved-At: Wed, 19 Aug 2009 18:09:39 +0000 Cc: Luiz Otavio O Souza , "Li, Qing" 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 17:39:15 -0000 On 19.08.2009, at 19:03, Luiz Otavio O Souza wrote: >>> >>> The problems are similar to http://lists.freebsd.org/pipermail/freebsd-current/2009-August/010287.html >>> >> >> That was a configuration issue. >> >>> >>> 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 >> 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 >> 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 >> 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 >> 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. >> flowtable_lookup() should allow a "bypass flow-table" return, not >> 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 > > Qing, > > yes, disabling the flowtable (sysctl net.inet.flowtable.enable=0) > fix the problem (no more IPv4 is not on the network). But here, > everything is working fine, even with that annoying message (no > crashes). My network is also working fine, but it crashes when I ping the endpoint of the tunnel interface. When I turn flowtable off it does not crash but I get no ping reply back. Denis