From owner-freebsd-net Fri Feb 14 14:31: 8 2003 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B2A9D37B401 for ; Fri, 14 Feb 2003 14:31:07 -0800 (PST) Received: from mel-rto4.wanadoo.fr (smtp-out-4.wanadoo.fr [193.252.19.23]) by mx1.FreeBSD.org (Postfix) with ESMTP id A1A7F43F3F for ; Fri, 14 Feb 2003 14:31:06 -0800 (PST) (envelope-from vjardin@wanadoo.fr) Received: from mel-rta9.wanadoo.fr (193.252.19.69) by mel-rto4.wanadoo.fr (6.7.015) id 3E0C33FD01FAD3ED for net@FreeBSD.ORG; Fri, 14 Feb 2003 23:31:05 +0100 Received: from there (80.11.204.93) by mel-rta9.wanadoo.fr (6.7.015) id 3E26DA8D011218CC for net@FreeBSD.ORG; Fri, 14 Feb 2003 23:31:05 +0100 Message-ID: <3E26DA8D011218CC@mel-rta9.wanadoo.fr> (added by postmaster@wanadoo.fr) Content-Type: text/plain; charset="iso-8859-15" From: Vincent Jardin To: net@FreeBSD.ORG Subject: Re: How to get interface's sockaddr_dl with the routing socket ? Date: Fri, 14 Feb 2003 23:52:01 +0100 X-Mailer: KMail [version 1.3.2] References: <3E26DA8D0108FE1A@mel-rta9.wanadoo.fr> (added by postmaster@wanadoo.fr) In-Reply-To: <3E26DA8D0108FE1A@mel-rta9.wanadoo.fr> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > What should the right fix be ? > I was wondering if > "ifpaddr = TAILQ_FIRST(&ifp->if_addrhead)->ifa_addr" > could be added within rt_ifannouncemsg() and rt_ifmsg() just before > rt_msg1() ? I have found the solution : rti_info[RTAX_IFP] (ie ifpaddr) should never be filled with RTM_IFANNOUNCE because RTM_IFANNOUNCE does not support a bitmask value for rtm_addrs ;-( (According to me it is a missing feature, maybe a bug ?) However, RTM_INFO can support rti_info[RTAX_IFP]. Because I could not get the interface sockaddr_dl when the interface is announced, I'll wait a RTM_IFINFO on the routing socket with this patch. It means that it could remain compatible with the routing socket. I had this problem when I was testing Zebra on FreeBSD with some dynamic interfaces. I am sorry for this problem, I have found alone a fix ;-) Regards, Vincent To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message