Date: Sat, 12 Jan 2002 07:00:03 -0800 (PST) From: Jan Oravec <wsx@wsx6.net> To: freebsd-bugs@FreeBSD.org Subject: Re: kern/33747: bug in rt socket Message-ID: <200201121500.g0CF03e61072@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/33747; it has been noted by GNATS. 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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200201121500.g0CF03e61072>