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