[Date Prev] [Date Index] [Date Next] [Thread Prev] [Thread Index] [Thread Next]

Re: Problems with conserver after OS upgrade

Chris Ross cross+conserver@distal.com
Mon, 8 Jun 2009 13:30:35 GMT

On Monday 08 June 2009 02:05:47 Bryan Stansell wrote:
> Yep, something is broken dealing with enumerating all the interfaces.
> Looks like it thinks there are 31 of them (is that even close?)...but
> it's not saying anything about them, so something isn't looking right.
> I don't have access to NetBSD machines (that I know of), but what
> version are you running?  5.0?  other?

  Yup.  I'm running 5.0.  (Actually, the 5.0_STABLE branch, shortly beyond the 
release point, but...)

> A quick search found this thread:
> http://mail-index.netbsd.org/tech-userlevel/2009/03/22/msg001912.html
> which talks about how 5.0 is much less tolerant of apps that don't use
> SIOCGIFCONF "correctly" (which could very well be the problem - but
> conserver works across many platforms, so I wonder what's up).  Probably
> something simple to fix, but their suggested change is basically what
> conserver already does.  Is HAVE_SA_LEN defined in config.h (where you
> built conserver)?  Could be it isn't auto-detecting the right thing.
> Just random guesses since I can't see it in person.

  HAVE_SA_LEN is set.  In looking at the code in the thread you mention, and 
the code in conserver, they're clearly similar, but referencing different 
elements of the ifreq structure.  I'm not familiar with the ifreq structure 
though, so they could be well the same.

  In rebuilding from scratch, even before touching that code, I did notice the 
following, which comes from that part of the code:

cc -O2 -I/usr/include -I.. -I.. -I. -DHAVE_CONFIG_H -
DSYSCONFDIR=\"/usr/pkg/etc\" -I/usr/include -I/usr/include  -I/usr/include -c 
-o cutil.o cutil.c           
cutil.c: In function 'ProbeInterfaces':                                         
cutil.c:2280: warning: dereferencing 'void *' pointer                           

  That's the portion of code that sets what ifr points to:

        ifr = (struct ifreq *)&ifc.ifc_buf[r];

  I'm going to put some more debugging code in and see what I can find out.  
Thanks for the help localizing the problem!  I'll let you know if I find 

                                        - Chris