From owner-freebsd-current@FreeBSD.ORG Wed Aug 19 17:04:05 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 5C5F1106568B for ; Wed, 19 Aug 2009 17:04:05 +0000 (UTC) (envelope-from lists.br@gmail.com) Received: from mail-yw0-f199.google.com (mail-yw0-f199.google.com [209.85.211.199]) by mx1.freebsd.org (Postfix) with ESMTP id 0A0948FC64 for ; Wed, 19 Aug 2009 17:04:04 +0000 (UTC) Received: by ywh37 with SMTP id 37so6445623ywh.28 for ; Wed, 19 Aug 2009 10:04:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to:references :subject:date:mime-version:content-type:content-transfer-encoding :x-priority:x-msmail-priority:x-mailer:x-mimeole; bh=I5G1Aoh2kUT40s1vvNSICTF/MDpt4jPwlf4ZRcJHPiU=; b=JwyG/z3UD/zl/mXW1ascihXGwheqtRzCuku/Ssrk5PhgOb85G5GAAN0BCr2gJOhyqp //+MmfOrrruro1D4Rct5bzSWrxV+z1PBm0Wn4rU/KFUgpgquQ+86DC6YMV7QMmn/mMQc sstjdQcy97nt7V7WNSs7QUNtb6nuPLR+jvFkE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:references:subject:date:mime-version :content-type:content-transfer-encoding:x-priority:x-msmail-priority :x-mailer:x-mimeole; b=QgQZfZXxJRnum7+3/dMsSyit/Sav1bNkOUVVd3Rjb6Wkgtx6RcxJ7IzekdSa9mfhic GK4ys5BtByi5gRB9JX5mqejNIQ1K7GILpD7dpnZqpxda0p22ZnRlZAPjUAsSh759k/Jh bFDnigCEu5+dbe6mAke/+5DuTz4L/V4oXCXVE= Received: by 10.91.135.13 with SMTP id m13mr5018172agn.25.1250701444084; Wed, 19 Aug 2009 10:04:04 -0700 (PDT) Received: from adnote989 (201-42-159-160.dsl.telesp.net.br [201.42.159.160]) by mx.google.com with ESMTPS id 6sm3762646agb.28.2009.08.19.10.03.59 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 19 Aug 2009 10:04:03 -0700 (PDT) Message-ID: <35FF00562E814F08BE71B6407FB6C1BF@adnote989> From: "Luiz Otavio O Souza" To: "Li, Qing" , "Denis Ahrens" , References: <18104823-CB3F-42DA-9DE8-E6692D81E96B@h3q.com> Date: Wed, 19 Aug 2009 14:03:28 -0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailman-Approved-At: Wed, 19 Aug 2009 17:23:01 +0000 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 17:04:05 -0000 >> >> 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). Thanks, Luiz