Date: Wed, 19 Aug 2009 14:03:28 -0300 From: "Luiz Otavio O Souza" <lists.br@gmail.com> To: "Li, Qing" <qing.li@bluecoat.com>, "Denis Ahrens" <denis@h3q.com>, <freebsd-current@freebsd.org> Subject: Re: network problems Message-ID: <35FF00562E814F08BE71B6407FB6C1BF@adnote989> References: <18104823-CB3F-42DA-9DE8-E6692D81E96B@h3q.com> <B583FBF374231F4A89607B4D08578A430467367F@bcs-mail03.internal.cacheflow.com>
index | next in thread | previous in thread | raw e-mail
>> >> 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, Luizhome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?35FF00562E814F08BE71B6407FB6C1BF>