From nobody@FreeBSD.org  Wed Jan  9 17:03:22 2002
Return-Path: <nobody@FreeBSD.org>
Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21])
	by hub.freebsd.org (Postfix) with ESMTP id 5743B37B422
	for <freebsd-gnats-submit@FreeBSD.org>; Wed,  9 Jan 2002 17:03:22 -0800 (PST)
Received: (from nobody@localhost)
	by freefall.freebsd.org (8.11.6/8.11.6) id g0A13Mw46469;
	Wed, 9 Jan 2002 17:03:22 -0800 (PST)
	(envelope-from nobody)
Message-Id: <200201100103.g0A13Mw46469@freefall.freebsd.org>
Date: Wed, 9 Jan 2002 17:03:22 -0800 (PST)
From: Jan Oravec <wsx@wsx6.net>
To: freebsd-gnats-submit@FreeBSD.org
Subject: bug in rt socket
X-Send-Pr-Version: www-1.0

>Number:         33747
>Category:       kern
>Synopsis:       bug in rt socket
>Confidential:   no
>Severity:       non-critical
>Priority:       high
>Responsible:    ru
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Wed Jan 09 17:10:01 PST 2002
>Closed-Date:    Fri Feb 1 03:47:57 PST 2002
>Last-Modified:  Fri Feb 01 03:48:40 PST 2002
>Originator:     Jan Oravec
>Release:        4.4-STABLE
>Organization:
XS26 - 'Access to IPv6'
>Environment:
FreeBSD ipv6.isternet.sk 4.4-STABLE FreeBSD 4.4-STABLE #6: Thu Oct 18 21:44:36 CEST 2001     wsx@ipv6.isternet.sk:/usr/obj/usr/src/sys/IPv6  i386

>Description:
there is a bug in rt socket in kernel, file net/rtsock.c:
 
function rt_ifmsg contains:
ifm->ifm_addrs = 0;
 
we should set RTA_IFP attribute instead and send interface name, because information that some interface has been created without name of interface is unusable.

openbsd haven't this bug
>How-To-Repeat:
open rt socket, create interface (e.g. ifconfig gif0 create) and see what you get...MTU, interface ID, ..., but not interface name
>Fix:
ifm->ifm_addrs = RTA_IFP;
and some other code to send name of interface...

>Release-Note:
>Audit-Trail:

From: Ruslan Ermilov <ru@FreeBSD.org>
To: Jan Oravec <wsx@wsx6.net>
Cc: bug-followup@FreeBSD.org, net@FreeBSD.org
Subject: Re: kern/33747: bug in rt socket
Date: Fri, 11 Jan 2002 15:52:00 +0200

 On Wed, Jan 09, 2002 at 05:03:22PM -0800, Jan Oravec wrote:
 > 
 > there is a bug in rt socket in kernel, file net/rtsock.c:
 >  
 > function rt_ifmsg contains:
 > ifm->ifm_addrs = 0;
 >  
 > we should set RTA_IFP attribute instead and send interface name,
 > because information that some interface has been created without
 > name of interface is unusable.
 > 
 I wouldn't call it a bug, but rather a design issue.  In
 BSD, rt_ifmsg() doesn't set any sockaddrs, and this is
 documented in Stevens' TCP/IP Illustrated Vol. 2 on the
 bottom of page 627.  What made you think we SHOULD supply
 IFP to this message?  Usually, daemons remember interface
 index (see natd(8) for a working example), and on receipt
 of an RTM_IFINFO message with a matching ifm_index, some
 actions take place.
 
 > openbsd haven't this bug
 > 
 I've looked into the latest revisions of rtsock.c in
 OpenBSD, NetBSD and BSD/OS; they all do not seem to
 set any sockaddrs in "info" before calling rt_msg1(),
 and all set ifm_addrs = 0.  Are you sure you're not
 looking at some locally modified OpenBSD sources?
 
 > >Fix:
 > ifm->ifm_addrs = RTA_IFP;
 > and some other code to send name of interface...
 > 
 The fix is rather trivial but I don't think we should
 commit it, for the reasons specified above.
 
 Index: rtsock.c
 ===================================================================
 RCS file: /home/ncvs/src/sys/net/rtsock.c,v
 retrieving revision 1.63
 diff -u -p -r1.63 rtsock.c
 --- rtsock.c	2001/12/19 16:05:27	1.63
 +++ rtsock.c	2002/01/11 13:51:29
 @@ -747,6 +747,7 @@ rt_ifmsg(ifp)
  	if (route_cb.any_count == 0)
  		return;
  	bzero((caddr_t)&info, sizeof(info));
 +	ifpaddr = TAILQ_FIRST(&ifp->if_addrhead)->ifa_addr;
  	m = rt_msg1(RTM_IFINFO, &info);
  	if (m == 0)
  		return;
 @@ -754,7 +755,7 @@ rt_ifmsg(ifp)
  	ifm->ifm_index = ifp->if_index;
  	ifm->ifm_flags = (u_short)ifp->if_flags;
  	ifm->ifm_data = ifp->if_data;
 -	ifm->ifm_addrs = 0;
 +	ifm->ifm_addrs = info.rti_addrs;
  	route_proto.sp_protocol = 0;
  	raw_input(m, &route_proto, &route_src, &route_dst);
  }
 
 
 Cheers,
 -- 
 Ruslan Ermilov		Oracle Developer/DBA,
 ru@sunbay.com		Sunbay Software AG,
 ru@FreeBSD.org		FreeBSD committer,
 +380.652.512.251	Simferopol, Ukraine
 
 http://www.FreeBSD.org	The Power To Serve
 http://www.oracle.com	Enabling The Information Age
State-Changed-From-To: open->feedback 
State-Changed-By: ru 
State-Changed-When: Fri Jan 11 06:21:01 PST 2002 
State-Changed-Why:  
A feedback from originator was requested. 

http://www.FreeBSD.org/cgi/query-pr.cgi?pr=33747 

From: Jan Oravec <wsx@wsx6.net>
To: ru@FreeBSD.org, net@FreeBSD.org, freebsd-gnats-submit@FreeBSD.org
Cc:  
Subject: Re: kern/33747: bug in rt socket
Date: Sat, 12 Jan 2002 15:51:48 +0100

 > > there is a bug in rt socket in kernel, file net/rtsock.c:
 > >  
 > > function rt_ifmsg contains:
 > > ifm->ifm_addrs = 0;
 > >  
 > > we should set RTA_IFP attribute instead and send interface name,
 > > because information that some interface has been created without
 > > name of interface is unusable.
 > > 
 > I wouldn't call it a bug, but rather a design issue.  In
 > BSD, rt_ifmsg() doesn't set any sockaddrs, and this is
 > documented in Stevens' TCP/IP Illustrated Vol. 2 on the
 > bottom of page 627.  What made you think we SHOULD supply
 > IFP to this message?  Usually, daemons remember interface
 > index (see natd(8) for a working example), and on receipt
 > of an RTM_IFINFO message with a matching ifm_index, some
 > actions take place.
 Yes, but we may create interfaces while daemon runs. The typical example is
 'gif' interface. When daemon starts, gif0 does not exist. After start of
 daemon, we create interface with 'ifconfig gif0 create'. Since interface did
 not exist, daemon doesn't know about his name and ID and when daemon receive
 RTM_IFINFO message, daemon knows only that interface has been created, but
 doesn't know his name.
 
 > I've looked into the latest revisions of rtsock.c in
 > OpenBSD, NetBSD and BSD/OS; they all do not seem to
 > set any sockaddrs in "info" before calling rt_msg1(),
 > and all set ifm_addrs = 0.  Are you sure you're not
 > looking at some locally modified OpenBSD sources?
 oops, my fault. i didn't see problem on OpenBSD because gif interfaces are
 statically created on boot time.
 
 > The fix is rather trivial but I don't think we should
 > commit it, for the reasons specified above.
 ifm->ifm_addrs should be set to info.rti_addrs only in case interface is
 created (not on up/down events)
 
 Regards,
 
 -- 
 Jan Oravec
 XS26 - 'Access to IPv6'  
 jan.oravec@xs26.net

From: "Lars Eggert" <larse@ISI.EDU>
To: "'Jan Oravec'" <wsx@wsx6.net>, <ru@FreeBSD.org>,
	<net@FreeBSD.org>, <freebsd-gnats-submit@FreeBSD.org>
Cc:  
Subject: RE: kern/33747: bug in rt socket
Date: Sat, 12 Jan 2002 10:46:18 -0800

 This is a multi-part message in MIME format.
 
 ------=_NextPart_000_0017_01C19B56.5D7FBDB0
 Content-Type: text/plain;
 	charset="us-ascii"
 Content-Transfer-Encoding: 7bit
 
 > Yes, but we may create interfaces while daemon runs. The 
 > typical example is 'gif' interface. When daemon starts, gif0 
 > does not exist. After start of daemon, we create interface 
 > with 'ifconfig gif0 create'. Since interface did not exist, 
 > daemon doesn't know about his name and ID and when daemon 
 > receive RTM_IFINFO message, daemon knows only that interface 
 > has been created, but doesn't know his name.
 
 I have not followed all of this exchange, but let me chime in and
 mention that http://www.freebsd.org/cgi/query-pr.cgi?pr=misc/24391 could
 be related. The problem there is dissappearing interfaces (pccard
 ejections) messing up amd.
 
 Lars
 -- 
 Lars Eggert <larse@isi.edu>               Information Sciences Institute
 http://www.isi.edu/larse/              University of Southern California
 
 ------=_NextPart_000_0017_01C19B56.5D7FBDB0
 Content-Type: application/x-pkcs7-signature;
 	name="smime.p7s"
 Content-Transfer-Encoding: base64
 Content-Disposition: attachment;
 	filename="smime.p7s"
 
 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJFzCCArUw
 ggIeoAMCAQICAwWBRzANBgkqhkiG9w0BAQIFADCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl
 c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT
 FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAw
 MC44LjMwMB4XDTAxMDgyNDE2NDAwMFoXDTAyMDgyNDE2NDAwMFowVDEPMA0GA1UEBBMGRWdnZXJ0
 MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2VydDEcMBoGCSqGSIb3DQEJARYNbGFy
 c2VAaXNpLmVkdTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA0AvLBsD78nxcUHeHkaMgl3b4
 qYPnfgbf8Lh+HQP8RgGMRG/Yb+vTpkGezlwt9pkJxiD11uZDy4CNNJUu3gKxKSb+zRV70O+lkwwf
 tuHoLHoH4xwo3LcQ2LGDpd+I95tUN4dfJ3TmeEcUSF50dC/SuUI4w8AlhXQ8IxrhgdayTpECAwEA
 AaNWMFQwKgYFK2UBBAEEITAfAgEAMBowGAIBBAQTTDJ1TXlmZkJOVWJOSkpjZFoyczAYBgNVHREE
 ETAPgQ1sYXJzZUBpc2kuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQECBQADgYEAheZhn0pQ
 A8zI7U2K1ZIAl11j0a1DKxnp3GtTvOUrGRB3WvYxidvdZ1kizhEsWeXU81TkNDH0DaRqtOEeu6Q2
 OhB+jeKEqY7IDAJE4/fI0e+d6PnG1hd+vEvYmsKHkmzBhPc94XUOKNWO+qVNP2NGyNI3QIDy5wX4
 fdcOo1S34r4wggMpMIICkqADAgECAgEMMA0GCSqGSIb3DQEBBAUAMIHRMQswCQYDVQQGEwJaQTEV
 MBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0
 ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQw
 IgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNv
 bmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDAwODMwMDAwMDAwWhcNMDIwODI5MjM1OTU5WjCB
 kjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du
 MQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQD
 Ex9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB
 iQKBgQDeMzKmY8cJJUU+0m54J2eBxdqIGYKXDuNEKYpjNSptcDz63K737nRvMLwzkH/5NHGgo22Y
 8cNPomXbDfpL8dbdYaX5hc1VmjUanZJ1qCeu2HL5ugL217CR3hzpq+AYA6h8Q0JQUYeDPPA5tJtU
 ihOH/7ObnUlmAC0JieyUa+mhaQIDAQABo04wTDApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJp
 dmF0ZUxhYmVsMS0yOTcwEgYDVR0TAQH/BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcN
 AQEEBQADgYEAcxtvJmWL/xU0S1liiu1EvknH6A27j7kNaiYqYoQfuIdjdBxtt88aU5FL4c3mONnt
 UPQ6bDSSrOaSnG7BIwHCCafvS65y3QZn9VBvLli4tgvBUFe17BzX7xe21Yibt6KIGu05Wzl9NPy2
 lhglTWr0ncXDkS+plrgFPFL83eliA0gwggMtMIIClqADAgECAgEAMA0GCSqGSIb3DQEBBAUAMIHR
 MQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24x
 GjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZp
 Y2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkq
 hkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNOTYwMTAxMDAwMDAwWhcN
 MjAxMjMxMjM1OTU5WjCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAG
 A1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2Vy
 dGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZy
 ZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMIGf
 MA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDUadfUsJRkW3HpR9gMUbbqcpGwhF59LQ2PexLfhSV1
 KHQ6QixjJ5+Ve0vvfhmHHYbqo925zpZkGsIUbkSsfOaP6E0PcR9AOKYAo4d49vmUhl6t6sBeduvZ
 FKNdbnp8DKVLVX8GGSl/npom1Wq7OCQIapjHsdqjmJH9edvlWsQcuQIDAQABoxMwETAPBgNVHRMB
 Af8EBTADAQH/MA0GCSqGSIb3DQEBBAUAA4GBAMfskn5O+PWWpWdiKqTwTRFg0G+NYFhhrCa7UjVc
 CM8w+6hKloofYkIjjBcP9LpknBesRynfnZhe0mxgcVyirNx54+duAEcftQ0o6AKd5Jr9E/Sm2Xyx
 +NxfIyYJkYBz0BQb3kOpgyXy5pwvFcr+pquKB3WLDN1RhGvk+NHOd6KBMYIDWjCCA1YCAQEwgZow
 gZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93
 bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UE
 AxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDBYFHMAkGBSsOAwIaBQCgggIVMBgG
 CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAyMDExMjE4NDYxOFowIwYJ
 KoZIhvcNAQkEMRYEFPDYaoBRkL6ck6/zuwPP4iP8peeMMFgGCSqGSIb3DQEJDzFLMEkwCgYIKoZI
 hvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoG
 CCqGSIb3DQIFMIGrBgkrBgEEAYI3EAQxgZ0wgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxX
 ZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQL
 ExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw
 MDAuOC4zMAIDBYFHMIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNV
 BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAb
 BgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBS
 U0EgMjAwMC44LjMwAgMFgUcwDQYJKoZIhvcNAQEBBQAEgYBRpM2aGGdUV0tkKM6pxu/xzs0oFy9F
 BnFAxjzI766VrioO+MQpxzxmM83g7ZvWOIV1/HVdZ2iCMLn242eWLvwzaQpqRvqzq7sidAdEi2ZJ
 eVnB1aTzrXeI/9+M4wHSMPB7ofTGcxeAtsfOv4mh5QUwdkBL1GoZxHe7loyMmyVpDwAAAAAAAA==
 
 ------=_NextPart_000_0017_01C19B56.5D7FBDB0--
 
State-Changed-From-To: feedback->analyzed 
State-Changed-By: ru 
State-Changed-When: Fri Jan 18 06:57:37 PST 2002 
State-Changed-Why:  
Fix state. 

http://www.FreeBSD.org/cgi/query-pr.cgi?pr=33747 
State-Changed-From-To: analyzed->feedback 
State-Changed-By: ru 
State-Changed-When: Fri Jan 18 06:57:57 PST 2002 
State-Changed-Why:  
A new routing socket message type was added, RTM_IFANNOUNCE, 
to send announcements of the interface attach/detach events. 

The affected revisions in 5.0-CURRENT: 

sbin/route/route.c,v 1.58 
share/man/man4/route.4,v 1.14 
sys/net/if.c,v 1.127 
sys/net/if.h,v 1.68 
sys/net/route.h,v 1.43 
sys/net/rtsock.c,v 1.64 

The code will be merged into 4.5-STABLE in two weeks. 


Responsible-Changed-From-To: freebsd-bugs->ru 
Responsible-Changed-By: ru 
Responsible-Changed-When: Fri Jan 18 06:57:57 PST 2002 
Responsible-Changed-Why:  

http://www.FreeBSD.org/cgi/query-pr.cgi?pr=33747 
State-Changed-From-To: feedback->closed 
State-Changed-By: ru 
State-Changed-When: Fri Feb 1 03:47:57 PST 2002 
State-Changed-Why:  
RTM_IFANNOUNCE code MFC'ed into 4.5-STABLE. 

http://www.FreeBSD.org/cgi/query-pr.cgi?pr=33747 
>Unformatted:
