Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 19 Aug 2009 09:50:24 -0700
From:      "Li, Qing" <qing.li@bluecoat.com>
To:        "Denis Ahrens" <denis@h3q.com>, <freebsd-current@freebsd.org>
Subject:   RE: network problems
Message-ID:  <B583FBF374231F4A89607B4D08578A430467367F@bcs-mail03.internal.cacheflow.com>
References:  <18104823-CB3F-42DA-9DE8-E6692D81E96B@h3q.com>

next in thread | previous in thread | raw e-mail | index | archive | help

>
> 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





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?B583FBF374231F4A89607B4D08578A430467367F>