Bug 30653

On Tue, Sep 18, 2001 at 01:56:53PM -0700, Lars Eggert wrote:
> The KAME kernel option MAX_GIF_NEST limits the number of recursive gif
> tunnels that the system allows (tunnels in tunnels).
> 
> This option has never been merged into the FreeBSD options file. The
> code that goes with it *does* exist in the FreeBSD tree, the problem
> is that the option isn't included in /usr/src/sys/conf/options, and
> thus that code cannot be enabled.
> 
> The code enabled by MAX_GIF_NEST is cricital to the correct operation
> to the X-Bone port in net/xbone. Could this be added, please?

I think this is the wrong solution to this problem.  Instead, a sysctl
under the currently non-existant net.link.gif branch should be used to
control the value of max_gif_nesting at runtime.  IMO, XBONEHACK should
probably be controled similarly so you don't need to recompile gif to
use xbone.  I've added this to my todo list, but the funding I was using
to hack gif dried up a month or so ago so I don't know what I'll get to
it.

FWIW, you can set this option in -current (and probably -stable) by
adding a line like this to your kernel config:

makeoptions	CONF_CFLAGS="-DMAX_GIF_NEST=32"

-- Brooks

Brooks Davis wrote:

> On Tue, Sep 18, 2001 at 01:56:53PM -0700, Lars Eggert wrote:
> 
>>The KAME kernel option MAX_GIF_NEST limits the number of recursive gif
>>tunnels that the system allows (tunnels in tunnels).
>>
>>This option has never been merged into the FreeBSD options file. The
>>code that goes with it *does* exist in the FreeBSD tree, the problem
>>is that the option isn't included in /usr/src/sys/conf/options, and
>>thus that code cannot be enabled.
>>
>>The code enabled by MAX_GIF_NEST is cricital to the correct operation
>>to the X-Bone port in net/xbone. Could this be added, please?
>>
> 
> I think this is the wrong solution to this problem.  Instead, a sysctl
> under the currently non-existant net.link.gif branch should be used to
> control the value of max_gif_nesting at runtime.  IMO, XBONEHACK should
> probably be controled similarly so you don't need to recompile gif to
> use xbone.  I've added this to my todo list, but the funding I was using
> to hack gif dried up a month or so ago so I don't know what I'll get to
> it.


Brooks,

thanks for looking into this!

The MAX_GIF_NEST option is unrelated to the XBONEHACK option.

XBONEHACK was neccessary, because one could not configure two parallel 
gif tunnels between the same two physical endpoints with KAME. We have 
since worked around the problem by using aliases on the first tunnel 
instead of pulling up a second one in parallel. I still think KAME 
should not prohibit parallel tunnels, but it's of secondary importance 
since we switched to aliases. XBONEHACK could even be removed, if it 
matters.

MAX_GIF_NEST is not an X-Bone patch, it's standard KAME code that we 
just happen to reply upon. Unlike XBONEHACK, there is no work-around: If 
MAX_GIF_NEST isn't available it defaults to 1 (or 0, no recursion in any 
case), which breaks ports/net/xbone.


> FWIW, you can set this option in -current (and probably -stable) by
> adding a line like this to your kernel config:
> 
> makeoptions	CONF_CFLAGS="-DMAX_GIF_NEST=32"

If that works with 4.4-RELEASE, that'd be a good workaround! The reason 
I submitted the PR originally was that people got a lot more nervous 
when we asked them to patch their kernels (even though it's only a 
config file) compared to simply setting a kernel option. CONF_FLAGS may 
help with that.

Lars
-- 
Lars Eggert <larse@isi.edu>               Information Sciences Institute
http://www.isi.edu/larse/              University of Southern California

Comment 3 Brooks Davis 2001-09-26 01:27:28 UTC

Responsible Changed
From-To: freebsd-bugs->brooks

I'll take this one.

On Tue, Sep 25, 2001 at 04:37:51PM -0700, Lars Eggert wrote:
> XBONEHACK was neccessary, because one could not configure two parallel 
> gif tunnels between the same two physical endpoints with KAME. We have 
> since worked around the problem by using aliases on the first tunnel 
> instead of pulling up a second one in parallel. I still think KAME 
> should not prohibit parallel tunnels, but it's of secondary importance 
> since we switched to aliases. XBONEHACK could even be removed, if it 
> matters.

I agree parallel tunnels should be allow.  I ran into a non X-Bone need
for this so my feeling is that we should allow it to be controled at
runtime.  That way, people who think parallel tunnels shouldn't work
can "protect" themselves and the rest of use can have them without
a recompile.

> MAX_GIF_NEST is not an X-Bone patch, it's standard KAME code that we 
> just happen to reply upon. Unlike XBONEHACK, there is no work-around: If 
> MAX_GIF_NEST isn't available it defaults to 1 (or 0, no recursion in any 
> case), which breaks ports/net/xbone.

It looks like KAME ment to make this dynamic but never got around to it.
I'd guess that's why there isn't a tweakable option.

-- Brooks

This can be closed, the work-around Brooks suggested (using CONF_FLAGS) 
works fine.
-- 
Lars Eggert <larse@isi.edu>               Information Sciences Institute
http://www.isi.edu/larse/              University of Southern California

Comment 6 Brooks Davis 2002-03-25 10:52:53 UTC

State Changed
From-To: open->closed

Support for a new sysctl, net.link.gif.max_nesting, which allows 
runtime tuning of the value previously set by MAX_GIF_NEST has been 
commited.  MAX_GIF_NEST will continue to work for the duration of 
the 4.x release cycle, but is depricated.