we can use a TTL associated to the mbuf that is decremented each time
we reach a possible 'point of loop'. the bad point is that we need a
new entry in the mbuf...
fabien
VJ> Hi,
VJ> With FreeBSD, there are many ways to create a recursive local encapsulation
VJ> loop within the IPv4 and IPv6 stack. For example, this problem shows up when :
VJ> - Netgraph with pptp is used or Netgraph with an ng_iface over UDP or any
VJ> more complex Netgraph topologies...
VJ> - gre interfaces
VJ> - gif tunnels
VJ> - ...
VJ> There is a simple local solution that is used by gif_output() that is not
VJ> protected by any mutex:
VJ> /*
VJ> * gif may cause infinite recursion calls when misconfigured.
VJ> * We'll prevent this by introducing upper limit.
VJ> * XXX: this mechanism may introduce another problem about
VJ> * mutual exclusion of the variable CALLED, especially if we
VJ> * use kernel thread.
VJ> */
VJ> if (++called > max_gif_nesting) {
VJ> log(LOG_NOTICE,
VJ> "gif_output: recursively called too many times(%d)\n",
VJ> called);
VJ> m_freem(m);
VJ> error = EIO; /* is there better errno? */
VJ> goto end;
VJ> }
VJ> I am wondering if a more generic solution could be found, however I do not
VJ> have any idea yet ;-(
VJ> I mean, is it possible to protect the kernel against any panic that could
VJ> come from a mis-configuration of the routing tables ?
VJ> Regards,
VJ> Vincent
VJ> To Unsubscribe: send mail to [EMAIL PROTECTED]
VJ> with "unsubscribe freebsd-net" in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
