From nobody@FreeBSD.org  Thu Jun 27 14:04:16 2002
Return-Path: <nobody@FreeBSD.org>
Received: from www.freebsd.org (www.FreeBSD.org [216.136.204.117])
	by hub.freebsd.org (Postfix) with ESMTP id 9787537B416
	for <freebsd-gnats-submit@FreeBSD.org>; Thu, 27 Jun 2002 14:04:15 -0700 (PDT)
Received: from www.freebsd.org (localhost [127.0.0.1])
	by www.freebsd.org (8.12.4/8.12.4) with ESMTP id g5RL4FOT040005
	for <freebsd-gnats-submit@FreeBSD.org>; Thu, 27 Jun 2002 14:04:15 -0700 (PDT)
	(envelope-from nobody@www.freebsd.org)
Received: (from nobody@localhost)
	by www.freebsd.org (8.12.4/8.12.4/Submit) id g5RL4Fkk040004;
	Thu, 27 Jun 2002 14:04:15 -0700 (PDT)
Message-Id: <200206272104.g5RL4Fkk040004@www.freebsd.org>
Date: Thu, 27 Jun 2002 14:04:15 -0700 (PDT)
From: Chris Wasser <cwasser@shaw.ca>
To: freebsd-gnats-submit@FreeBSD.org
Subject: ipstealth issue
X-Send-Pr-Version: www-1.0

>Number:         39937
>Category:       kern
>Synopsis:       ipstealth issue
>Confidential:   no
>Severity:       serious
>Priority:       low
>Responsible:    freebsd-net
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Thu Jun 27 14:10:01 PDT 2002
>Closed-Date:    
>Last-Modified:  Mon May 07 03:51:39 UTC 2012
>Originator:     Chris Wasser
>Release:        4.6-RELEASE
>Organization:
n/a
>Environment:
FreeBSD hanger18 4.6-RELEASE FreeBSD 4.6-RELEASE #2: Mon Jun 24 15:07:45 MDT
2002 root@hanger18:/usr/obj/usr/src/sys/UKCV1_PRODUCTION  i386
>Description:
If IPSTEALTH is enabled in the kernel (options IPSTEALTH) and the sysctl is
set to 1, any attempts to use a bpf driven application such as dhclient will
result in the machine locking up.

I've tried tracing the lockup but it just spins around and around and I can't
get a decent trace to give as it keeps cycling in the same functions over
and over.
>How-To-Repeat:
In your kernel, enable ipstealth:

options IPSTEALTH

Tweak the sysctl option:

sysctl net.inet.ip.stealth=1

Run dhclient on any interface:

dhclient dc0
>Fix:
Unsure. It may just be my own stupidity, but this definitely did not happen
in 4.5-*
>Release-Note:
>Audit-Trail:

From: Maxim Konovalov <maxim@FreeBSD.org>
To: Chris Wasser <cwasser@shaw.ca>
Cc: bug-followup@FreeBSD.org
Subject: Re: kern/39937: ipstealth issue
Date: Mon, 7 Oct 2002 17:57:50 +0400 (MSD)

 Hello,
 
 Can't reproduce on 4.6-STABLE. Could you please describe what you are
 doing step by step? Do you have a serial console? Could you please
 repeat your manipulations from it? Thanks in advance.
 
 -- 
 Maxim Konovalov, maxim@FreeBSD.org
 
 

From: Maxim Konovalov <maxim@FreeBSD.org>
To: bug-followup@FreeBSD.org
Cc: Chris Wasser <flatline@cmdcomputers.ca>, <murray@FreeBSD.org>
Subject: Re: kern/39937: ipstealth issue
Date: Mon, 28 Oct 2002 14:56:02 +0300 (MSK)

 [ CC: Murray Stokely, our dhcp maintainer ]
 
 OK, I found the problem but I have no idea about proper fix now.
 
 We have:
 
 options IPSTEALTH
 
 net.inet.ip.stealth=1
 net.inet.ip.forwarding=1
 
 We run dhclient <NIC name> and get lock up.
 
 The problem is in endless loop: ip_input -> ip_forward -> ip_output ->
 ip_input.
 
 The loop is present regardless of net.inet.ip.stealth but with
 net.inet.ip.stealth=0 ip_input() has a chance to decrement TTL on
 each cycle and a packet expires.
 
 Why does the loop exist?
 
 dhclient(8) invokes dhclient-script(8) which installs a static route:
 
 route add $alias_ip_address 127.0.0.1
 
 which makes endless routing loop. Frankly, I do not understand a
 purpose of that route.
 
 Here is a quick and probably dirty hack:
 
 Index: isc-dhcp/client/scripts/freebsd
 ===================================================================
 RCS file: /home/ncvs/src/contrib/isc-dhcp/client/scripts/freebsd,v
 retrieving revision 1.20
 diff -u -r1.20 freebsd
 --- isc-dhcp/client/scripts/freebsd	19 Feb 2002 12:10:40 -0000	1.20
 +++ isc-dhcp/client/scripts/freebsd	28 Oct 2002 11:44:16 -0000
 @@ -122,7 +122,6 @@
      if [ -n "$new_routers" ]; then
        $LOGGER "New Routers: $new_routers"
      fi
 -    route add $new_ip_address 127.1 >/dev/null 2>&1
      for router in $new_routers; do
        route add default $router >/dev/null 2>&1
      done
 @@ -138,7 +137,6 @@
    if [ x$new_ip_address != x$alias_ip_address ] && [ x$alias_ip_address != x ];
     then
      ifconfig $interface inet alias $alias_ip_address $alias_subnet_arg
 -    route add $alias_ip_address 127.0.0.1
    fi
    make_resolv_conf
    exit_with_hooks 0
 @@ -168,7 +166,6 @@
    fi
    if [ x$alias_ip_address != x ]; then
      ifconfig $interface inet alias $alias_ip_address $alias_subnet_arg
 -    route add $alias_ip_address 127.0.0.1
    fi
    exit_with_hooks 0
  fi
 @@ -191,9 +188,7 @@
        if [ x$new_ip_address != x$alias_ip_address ] && \
  			[ x$alias_ip_address != x ]; then
  	ifconfig $interface inet alias $alias_ip_address $alias_subnet_arg
 -	route add $alias_ip_address 127.0.0.1
        fi
 -      route add $new_ip_address 127.1 >/dev/null 2>&1
        for router in $new_routers; do
  	route add default $router >/dev/null 2>&1
        done
 
 %%%
 
 With this patch my 4.7-STABLE works OK.
 
 --
 Maxim Konovalov, maxim@FreeBSD.org
 
 
 
 
 
 
Responsible-Changed-From-To: freebsd-bugs->bms 
Responsible-Changed-By: bms 
Responsible-Changed-When: Tue 25 Nov 2003 09:05:06 PST 
Responsible-Changed-Why:  
I'm in hoover up network PRs mode. I'll look into this. 


http://www.freebsd.org/cgi/query-pr.cgi?pr=39937 
State-Changed-From-To: open->analyzed 
State-Changed-By: bms 
State-Changed-When: Thu 27 Nov 2003 02:25:25 PST 
State-Changed-Why:  
The analysis is clear, we just need to decide how to fix it. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=39937 

From: Bruce M Simpson <bms@spc.org>
To: mbr@FreeBSD.org
Cc: freebsd-gnats-submit@FreeBSD.org
Subject: Re: kern/39937: ipstealth issue
Date: Wed, 16 Jun 2004 13:52:45 +0100

 Martin,
 
 Why is the interface route to 127.0.0.1 necessary in dhclient-script?
 
 OpenBSD may have cause to disable/remove this in certain situations:
 http://archives.neohapsis.com/archives/openbsd/2003-05/0174.html
 
 And the infamous "arplookup 127.0.0.1 failed: could not allocate llinfo":
 http://www.mail-archive.com/freebsd-current@freebsd.org/msg05392.html
 
 My suggestion would be we should restructure dhclient to use a shell
 script function in place of the route add so we can easily conditionalize
 it based on an environment variable.
 
 src/sbin/dhclient/dhclient-script.sh is already off the vendor branch
 anyway, so I can't see this doing a lot of harm -- if we can push the
 changes back to ISC so much the better.
 
 Regards,
 BMS
State-Changed-From-To: analyzed->suspended 
State-Changed-By: bms 
State-Changed-When: Sat Sep 23 17:38:49 UTC 2006 
State-Changed-Why:  
Back to the free pool for you. 


Responsible-Changed-From-To: bms->freebsd-net 
Responsible-Changed-By: bms 
Responsible-Changed-When: Sat Sep 23 17:38:49 UTC 2006 
Responsible-Changed-Why:  
Back to the free pool for you. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=39937 
State-Changed-From-To: suspended->open 
State-Changed-By: eadler 
State-Changed-When: Mon May 7 03:51:38 UTC 2012 
State-Changed-Why:  
suspended is not free 

http://www.freebsd.org/cgi/query-pr.cgi?pr=39937 
>Unformatted:
