Subject: Re: Updating arp(8) to use getifaddrs (cf. bin/8566)
To: Andrew Brown <atatat@atatdot.net>
From: Luke Mewburn <lukem@netbsd.org>
List: tech-net
Date: 11/08/2002 08:50:26
On Thu, Nov 07, 2002 at 09:17:35AM -0500, Andrew Brown wrote:
  | >The problem with SIOCGIFCONF as used by most programs is that it
  | >doesn't cater for when the number of interfaces * sizeof(struct ifreq)
  | >(== 32) exceeds the buffer size passed in, so you might get truncated
  | >results.  There is a way to detect and work around this, except non
  | >of the programs in usr.sbin/* that use SIOCGIFCONF do this, and won't
  | >work correctly if the buffer size is exceeded.
  | >(I checked various programs in usr.sbin which use SIOCGIFCONF, and
  | >they support between 10, 16, 32, 256 (or 1 case, 512) addresses.)
  | 
  | they're done incredibly wrong then.  my understanding of the
  | "canonical" way to use SIOCGIFCONF was to call it once with an empty
  | struct ifconf (ie, ifc_buf is null and ifc_len is zero), and then
  | malloc a buffer of the size returned in ifc_len.  probably with a pad
  | so that any *new* addresses that show up in between your first a
  | second calls are also covered.  it's simple to check that you didn't
  | "get back" more data than you expected if you save the value of
  | ifc_len between the first and second calls.

This might be the case, but no code I found in the NetBSD tree from a
quick glance revealed that non used the "canonical" way you describe
(and is described on p435 of Stevens' Unix Network Programming 2nd ed.
Vol I [UNP2VI]).


  | >IIRC, SIOCGIFCONF also can't support sockaddr_in6 addresses, or any
  | >other sockaddr > 16 bytes long...
  | 
  | from a program i wrote a while back for a reason i don't remember...
  | 
  | 	% ./printifaddrs 
  | 	ep0: fam=INET6 len=28 addr=fe80:8::210:4bff:fe9f:ab87
  | 		(port=0 flow=0 scope=0)

Is the program just using the struct ifreq returned from SIOCGIFCONF?
There doesn't appear to be room in struct ifreq for a sockaddr_in6,
and this is confirmed in on p 437 of UNP2VI.


Luke.