From owner-freebsd-net@FreeBSD.ORG Sat Jan 8 02:01:16 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 33A521065673 for ; Sat, 8 Jan 2011 02:01:16 +0000 (UTC) (envelope-from spawk@acm.poly.edu) Received: from acm.poly.edu (acm.poly.edu [128.238.9.200]) by mx1.freebsd.org (Postfix) with ESMTP id DCF478FC0C for ; Sat, 8 Jan 2011 02:01:15 +0000 (UTC) Received: (qmail 12144 invoked from network); 8 Jan 2011 02:01:14 -0000 Received: from unknown (HELO ?192.168.0.2?) (spawk@96.224.221.101) by acm.poly.edu with CAMELLIA256-SHA encrypted SMTP; 8 Jan 2011 02:01:14 -0000 Message-ID: <4D27C55D.8070200@acm.poly.edu> Date: Fri, 07 Jan 2011 21:01:01 -0500 From: Boris Kochergin User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.12) Gecko/20101031 Thunderbird/3.1.6 MIME-Version: 1.0 To: Sergey Kandaurov References: <4D27AF1D.2030505@acm.poly.edu> In-Reply-To: Content-Type: multipart/mixed; boundary="------------070606030005030406040902" Cc: freebsd-net@freebsd.org Subject: Re: NDP Ethernet address display X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 02:01:16 -0000 This is a multi-part message in MIME format. --------------070606030005030406040902 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 01/07/11 20:26, Sergey Kandaurov wrote: > On 8 January 2011 03:26, Boris Kochergin wrote: >> Hi. I noticed that ndp(8) doesn't zero-pad Ethernet addresses, which is >> inconsistent with arp(8): >> >> # ndp -an >> ... >> 2001:470:897b::1 0:30:48:b1:1b:9c em0 permanent R >> >> # arp -an >> ... >> ? (128.238.9.201) at 00:30:48:b1:1b:9c on em0 permanent [ethernet] >> >> As everything else I can think of zero-pads them, this makes it a little >> annoying to grep for addresses, etc. Is this intentional? It is the case in >> 7.x through CURRENT and the fix is quite simple: >> >> --- /usr/src/usr.sbin/ndp/ndp.c.orig 2011-01-07 19:16:17.000000000 -0500 >> +++ /usr/src/usr.sbin/ndp/ndp.c 2011-01-07 19:15:36.000000000 -0500 >> @@ -828,7 +828,7 @@ >> >> if (sdl->sdl_alen) { >> cp = (u_char *)LLADDR(sdl); >> - snprintf(hbuf, sizeof(hbuf), "%x:%x:%x:%x:%x:%x", >> + snprintf(hbuf, sizeof(hbuf), >> "%02x:%02x:%02x:%02x:%02x:%02x", >> cp[0], cp[1], cp[2], cp[3], cp[4], cp[5]); >> } else >> snprintf(hbuf, sizeof(hbuf), "(incomplete)"); >> > Or rather use getnameinfo() for that as NetBSD/KAME does, and > NetBSD's getnameinfo() AF_LINK support was merged at 6.3 time. > > (See ndp.c#rev1.87 at KAME, ndp.c#rev1.35 at NetBSD). > Sure. -Boris --------------070606030005030406040902 Content-Type: text/plain; name="ndp.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ndp.patch" --- /usr/src/usr.sbin/ndp/ndp.c.orig 2011-01-07 19:16:17.000000000 -0500 +++ /usr/src/usr.sbin/ndp/ndp.c 2011-01-07 21:00:20.000000000 -0500 @@ -80,6 +80,7 @@ #include #include #include +#include #include #include @@ -824,12 +825,12 @@ struct sockaddr_dl *sdl; { static char hbuf[NI_MAXHOST]; - u_char *cp; if (sdl->sdl_alen) { - cp = (u_char *)LLADDR(sdl); - snprintf(hbuf, sizeof(hbuf), "%x:%x:%x:%x:%x:%x", - cp[0], cp[1], cp[2], cp[3], cp[4], cp[5]); + if (getnameinfo((struct sockaddr *)(void *)sdl, + (socklen_t)sdl->sdl_len, + hbuf, sizeof(hbuf), NULL, 0, NI_NUMERICHOST) != 0) + snprintf(hbuf, sizeof(hbuf), ""); } else snprintf(hbuf, sizeof(hbuf), "(incomplete)"); --------------070606030005030406040902--