From nobody@FreeBSD.org  Thu Dec 14 17:36:17 2006
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52])
	by hub.freebsd.org (Postfix) with ESMTP id 0A20016A500
	for <freebsd-gnats-submit@FreeBSD.org>; Thu, 14 Dec 2006 17:36:17 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (www.freebsd.org [69.147.83.33])
	by mx1.FreeBSD.org (Postfix) with ESMTP id CC5E343DF8
	for <freebsd-gnats-submit@FreeBSD.org>; Thu, 14 Dec 2006 17:14:02 +0000 (GMT)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (localhost [127.0.0.1])
	by www.freebsd.org (8.13.1/8.13.1) with ESMTP id kBEHFcL8070024
	for <freebsd-gnats-submit@FreeBSD.org>; Thu, 14 Dec 2006 17:15:38 GMT
	(envelope-from nobody@www.freebsd.org)
Received: (from nobody@localhost)
	by www.freebsd.org (8.13.1/8.13.1/Submit) id kBEHFc0k070023;
	Thu, 14 Dec 2006 17:15:38 GMT
	(envelope-from nobody)
Message-Id: <200612141715.kBEHFc0k070023@www.freebsd.org>
Date: Thu, 14 Dec 2006 17:15:38 GMT
From: Vladimir Ivanov<wawa@yandex-team.ru>
To: freebsd-gnats-submit@FreeBSD.org
Subject: ifconfig may not connect an interface to known network
X-Send-Pr-Version: www-3.0

>Number:         106722
>Category:       kern
>Synopsis:       [net] [patch] ifconfig may not connect an interface to known network
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    melifaro
>State:          patched
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Thu Dec 14 17:40:09 GMT 2006
>Closed-Date:    
>Last-Modified:  Tue Mar 12 13:31:31 UTC 2013
>Originator:     Vladimir Ivanov
>Release:        RELENG_6
>Organization:
Yandex LLC
>Environment:
FreeBSD karoto.yandex.net 6.2-PRERELEASE FreeBSD 6.2-PRERELEASE #20: Fri Dec  1 20:29:20 MSK 2006     root@barbedo.yandex.net:/usr/obj/usr/src/sys/CORE-RTR-RELENG_6  i386

>Description:
ifconfig may not connect an interface to known network.
It's a very unpleasant problem if you being use QUAGGA e.g.
>How-To-Repeat:
route add 10.0.0.0/24 some.gateway
ifconfig IFACE 10.0.0.1/24 alias

>Fix:


Patch attached with submission follows:

--- sys/net/route.c.orig	2006-12-01 20:28:22.000000000 +0300
+++ sys/net/route.c	2006-12-01 20:28:22.000000000 +0300
@@ -809,6 +809,12 @@ rtrequest1(int req, struct rt_addrinfo *
 				RT_UNLOCK(rt2);
 				rn = rnh->rnh_addaddr(ndst, netmask,
 						      rnh, rt->rt_nodes);
+                        } else if (!(flags & RTF_GATEWAY) && (rt2 -> rt_flags & RTF_GATEWAY)) {
+                                /* dirty hack allows ifconfig to setup address which is known to RT */
+                                rtexpunge(rt2);
+                                RT_UNLOCK(rt2);
+                                rn = rnh->rnh_addaddr(ndst, netmask,
+                                                      rnh, rt->rt_nodes);
 			} else if (rt2) {
 				/* undo the extra ref we got */
 				RTFREE_LOCKED(rt2);

>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-bugs->freebsd-net 
Responsible-Changed-By: linimon 
Responsible-Changed-When: Thu Dec 14 18:56:16 UTC 2006 
Responsible-Changed-Why:  
Over to maintainer(s). 

http://www.freebsd.org/cgi/query-pr.cgi?pr=106722 
Responsible-Changed-From-To: freebsd-net->glebius 
Responsible-Changed-By: glebius 
Responsible-Changed-When: Wed Mar 14 11:18:24 UTC 2007 
Responsible-Changed-Why:  
I'll work on this. 

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

From: Gleb Smirnoff <glebius@FreeBSD.org>
To: freebsd-net@FreeBSD.org
Cc: Vladimir Ivanov <wawa@yandex-team.ru>, bug-followup@FreeBSD.org
Subject: Re: kern/106722: [net] [patch] ifconfig may not connect an interface to known network
Date: Wed, 14 Mar 2007 14:59:16 +0300

   Just for the reference, here is a backtrace that shows how EEXIST is
 returned:
 
 rtrequest1(1,e6560aec,e6560ae0,e6560aec,30,...) at rtrequest1+0x658^M
 rtinit(c3e21500,1,1) at rtinit+0x193^M
 in_addprefix(c3e21500,1,e6560b68,0,1,...) at in_addprefix+0xa1^M
 in_ifinit(c3c4ec00,c3e21500,c3eb6e50,0) at in_ifinit+0x761^M
 in_control(c3f37bac,8040691a,c3eb6e40,c3c4ec00,c3e9b740) at in_control+0x93e^M
 ifioctl(c3f37bac,8040691a,c3eb6e40,c3e9b740,0,...) at ifioctl+0x1cf^M
 soo_ioctl(c3e5a828,8040691a,c3eb6e40,c414e000,c3e9b740) at soo_ioctl+0x2db^M
 kern_ioctl(c3e9b740,3,8040691a,c3eb6e40) at kern_ioctl+0x296^M
 ioctl(c3e9b740,e6560d00) at ioctl+0xf1^M
 syscall(e6560d38) at syscall+0x242^M
 Xint0x80_syscall() at Xint0x80_syscall+0x20^M
 
   The patch proposed vy Vladimir really looks like a hack. It covers only a
 case when old route was a gateway one. So, even with patch the following
 won't work:
 
 route add 10.0.0.0/24 -iface lo0
 ifconfig IFACE 10.0.0.1/24 alias
 
 Also, I am afraid of the side effects, when patched kernel will substitute
 route in a case when it should return error.
 
 AFAIK, the problem needs a more generic approach. I see two approaches.
 
 1) Introduce RTM_CHANGEADD, a command that will forcibly add route,
 deleting all conflicting ones. Use this command in in_addprefix().
 
 2) In rt_flags field we still have several extra bits. We can use
 them to specify route source - RTS_CONNECTED, RTS_STATIC, RTS_XXX,
 where XXX is a routing protocol. When issuing RTM_ADD a route with
 a preferred source (e.g. CONNECTED vs STATIC) will override the old
 one.
 
 freebsd-net subscibers, what do you think?
 
 -- 
 Totus tuus, Glebius.
 GLEBIUS-RIPN GLEB-RIPE

From: Gleb Smirnoff <glebius@FreeBSD.org>
To: "Bruce M. Simpson" <bms@FreeBSD.org>
Cc: freebsd-net@FreeBSD.org, Vladimir Ivanov <wawa@yandex-team.ru>,
        bug-followup@FreeBSD.org
Subject: Re: kern/106722: [net] [patch] ifconfig may not connect an	interface to known network
Date: Wed, 14 Mar 2007 19:10:23 +0300

 On Wed, Mar 14, 2007 at 04:00:13PM +0000, Bruce M. Simpson wrote:
 B> The proposed changes also constitute a hack.
 B> 
 B> I understand that they are being proposed to address problems we 
 B> currently have in the stack, i.e. that we do not support multipathing, 
 B> though it is more than likely they will be blown away in future when the 
 B> architecture changes (and it has to change).
 B> 
 B> Approach 1 is largely irrelevant if multiple paths are introduced to the 
 B> network stack; there is then no concept of a conflicting forwarding 
 B> entry, only preference derived from the interface, entry flags, or the 
 B> entry ('route') itself.
 B> 
 B> Approach 2 has some merit to it, although the forwarding plane should 
 B> not care where the forwarding entry came from unless it needs to (e.g. 
 B> next-hop resolution).
 B> 
 B> It seems reasonable that the forwarding plane should tag entries as 
 B> being 'CONNECTED' i.e. derived from the address configuration of an 
 B> interface. I believe many implementations out there do this, and 
 B> multi-path does not change this.
 B> 
 B> We already have the RTF_PROTO1 flag to determine if the forwarding entry 
 B> ('route') came from a routing protocol in userland, so there should be 
 B> no need to change the existing flags.
 B> 
 B> The RTF_STATIC flag only has special meaning in that it means 'the user 
 B> added this forwarding entry manually via the route(8) command'. We 
 B> should preserve these semantics, though I believe we should start 
 B> implementing forwarding preference in the radix trie.
 B> 
 B> I think it seems acceptable and reasonable that we use a limited form of 
 B> Approach 2 to clobber 'routes' being aded in the case described in the 
 B> PR, until such time as the network stack is re-engineered to support 
 B> multiple paths and forwarding preference.
 B> 
 B> I also believe it is useful if we start to use more modern technical 
 B> jargon to discuss 'routes' in the network stack, because we are actually 
 B> discussing the behaviour of entries in a forwarding table.
 
 I was afraid that this would raise an argument on multipath routing. Let's
 temporary do not speak about multipath but just decide what is the correct
 way to remove conflicting routes when we are assigning an IP prefix to a
 local interface?
 
 -- 
 Totus tuus, Glebius.
 GLEBIUS-RIPN GLEB-RIPE

From: "Bruce M. Simpson" <bms@FreeBSD.org>
To: Gleb Smirnoff <glebius@FreeBSD.org>,  freebsd-net@FreeBSD.org, 
 Vladimir Ivanov <wawa@yandex-team.ru>,
  bug-followup@FreeBSD.org
Cc:  
Subject: Re: kern/106722: [net] [patch] ifconfig may not connect an	interface
 to known network
Date: Wed, 14 Mar 2007 16:00:13 +0000

 Gleb Smirnoff wrote:
 > AFAIK, the problem needs a more generic approach. I see two approaches.
 >
 > 1) Introduce RTM_CHANGEADD, a command that will forcibly add route,
 > deleting all conflicting ones. Use this command in in_addprefix().
 >
 > 2) In rt_flags field we still have several extra bits. We can use
 > them to specify route source - RTS_CONNECTED, RTS_STATIC, RTS_XXX,
 > where XXX is a routing protocol. When issuing RTM_ADD a route with
 > a preferred source (e.g. CONNECTED vs STATIC) will override the old
 > one.
 >
 >   
 
 The proposed changes also constitute a hack.
 
 I understand that they are being proposed to address problems we 
 currently have in the stack, i.e. that we do not support multipathing, 
 though it is more than likely they will be blown away in future when the 
 architecture changes (and it has to change).
 
 Approach 1 is largely irrelevant if multiple paths are introduced to the 
 network stack; there is then no concept of a conflicting forwarding 
 entry, only preference derived from the interface, entry flags, or the 
 entry ('route') itself.
 
 Approach 2 has some merit to it, although the forwarding plane should 
 not care where the forwarding entry came from unless it needs to (e.g. 
 next-hop resolution).
 
 It seems reasonable that the forwarding plane should tag entries as 
 being 'CONNECTED' i.e. derived from the address configuration of an 
 interface. I believe many implementations out there do this, and 
 multi-path does not change this.
 
 We already have the RTF_PROTO1 flag to determine if the forwarding entry 
 ('route') came from a routing protocol in userland, so there should be 
 no need to change the existing flags.
 
 The RTF_STATIC flag only has special meaning in that it means 'the user 
 added this forwarding entry manually via the route(8) command'. We 
 should preserve these semantics, though I believe we should start 
 implementing forwarding preference in the radix trie.
 
 I think it seems acceptable and reasonable that we use a limited form of 
 Approach 2 to clobber 'routes' being aded in the case described in the 
 PR, until such time as the network stack is re-engineered to support 
 multiple paths and forwarding preference.
 
 I also believe it is useful if we start to use more modern technical 
 jargon to discuss 'routes' in the network stack, because we are actually 
 discussing the behaviour of entries in a forwarding table.
 
 Regards,
 BMS

From: "Bruce M. Simpson" <bms@FreeBSD.org>
To: Gleb Smirnoff <glebius@FreeBSD.org>, 
 "Bruce M. Simpson" <bms@FreeBSD.org>,
  freebsd-net@FreeBSD.org, Vladimir Ivanov <wawa@yandex-team.ru>, 
 bug-followup@FreeBSD.org
Cc:  
Subject: Re: kern/106722: [net] [patch] ifconfig may not connect	an	interface
 to known network
Date: Wed, 14 Mar 2007 18:20:51 +0000

 Gleb Smirnoff wrote:
 > I was afraid that this would raise an argument on multipath routing. Let's
 > temporary do not speak about multipath but just decide what is the correct
 > way to remove conflicting routes when we are assigning an IP prefix to a
 > local interface?
 >   
 My suggestion is to take the second approach you outlined but modify it 
 slightly.
 
 That way, the conflict between the 'connected' FTE introduced by 
 ifconfig'ing the interface and the pre-existing FTE for that network 
 prefix, may be resolved in a manner which doesn't break current 
 consumers of the routing code, and leaves the way open to do multipath 
 later w/o problems.
 
 Regards,
 BMS
 

From: Andre Oppermann <andre@freebsd.org>
To: Gleb Smirnoff <glebius@FreeBSD.org>, 
 "Bruce M. Simpson" <bms@FreeBSD.org>,
  freebsd-net@FreeBSD.org, Vladimir Ivanov <wawa@yandex-team.ru>, 
 bug-followup@FreeBSD.org
Cc:  
Subject: Re: kern/106722: [net] [patch] ifconfig may not connect	an	interface
 to known network
Date: Thu, 15 Mar 2007 17:30:54 +0100

 Gleb Smirnoff wrote:
 > 
 > I was afraid that this would raise an argument on multipath routing. Let's
 > temporary do not speak about multipath but just decide what is the correct
 > way to remove conflicting routes when we are assigning an IP prefix to a
 > local interface?
 
 IMO when configuring a interface with an IP address and network it should
 kick out previous host and/or network routes matching it.  Unless those
 are from locally configured interfaces, then it should reject the new
 attempt.
 
 The current behavior is a big problem when running routing daemons like
 OpenBGPD or OpenOSPFD.  If you add a second router to a subnet and that
 router receives that subnet already via the routing protocol you can't
 configure the interface.
 
 For the routing daemon a RTM_CHANGE in the replacement case is fine.
 
 -- 
 Andre
Responsible-Changed-From-To: glebius->melifaro 
Responsible-Changed-By: glebius 
Responsible-Changed-When: Mon Mar 11 11:11:41 UTC 2013 
Responsible-Changed-Why:  
Alexander is fixing this. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=106722 
State-Changed-From-To: open->patched 
State-Changed-By: melifaro 
State-Changed-When: Tue Mar 12 13:31:03 UTC 2013 
State-Changed-Why:  
Fixed in r248070. 

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