bug-inetutils
[Top][All Lists]
Advanced

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

Re: thinking about siocgifconf and friends


From: Marcus Brinkmann
Subject: Re: thinking about siocgifconf and friends
Date: Sat, 13 Jan 2001 03:56:08 +0100
User-agent: Mutt/1.1.4i

On Fri, Jan 12, 2001 at 08:57:23PM -0500, Alain Magloire wrote:
> > 
> > Hi,
> > 
> > I think I want to solely use if_nameindex, and wrap it up in libinetutils
> > for systems which don't have it.
> > 
> > Systems which have SIOCGIFNUM, SIOCGIFCONF and SIOCGIFINDEX are ideal.
> > Systems which don't have SIOCGIFNUM are taken care of by doubling the buffer
> > and retrying the SIOCGIFCONF call until there is no truncation.
> 
> Agreed, this is a real burden.  I think you could check if the last len return
> did not change to see if its over, vaguely remember this in one of the
> R. W. Stevens book but I would have to check.

I have all the docs I need for this one.
 
> Does Posix.1g came up with an API for those things ?

I don't think so, and this migt be part of the confusion. Roland McGrath
recommended if_nameindex to me, it is defined in Open Group XNS 5.2 Draft 1.0
and also in rfc2553 (IPv6 extensions). However, the definitions don't agree
on the way to return errors.... argh.

The plethora of network interfaces is really a pain. I will concentrate on
the most common interfaces for now. I don't have a good overview over all
interfaces used by different interfaces anyway. We will not have complete
replacements for the systems ifconfigs for some time, esp. for proprietary
systems. I will look into the existing linux code, but to be honest, some of
the linux interfaces are quite messy (for example SIOCGIFHWADDR).

For example, Solaris defines SIOCGIFMTU/SIOCSIFMTU, but no ifr_mtu member of
struct ifr. But it has an ifri_mtu member in if_data_t, whatever this is
used by. It's quite hopeless, but we are not in a hurry.

Maybe I should take your advice at heart and split some of the system
support in different files, one for linux, one for sunos etc. For example,
getting the hardware address is different everywhere, but it's really the
same question everytime. Probably just provide some infrastructure and let
it work out by people who know one OS very well.

> > Systems which don't have SIOCGIFINDEX will get either get a dummy index 
> > number
> > assigned by libinetutils wrapper, but applications should not display this
> > to the user if their life span is short. It is only guaranteed to be
> > constant for the time the task runs, of course.
> 
> - I vaguely remember that SIOCGIFCONF only work with Ethernet network
> meaning if you have PPP, DHCP, the "ppp0" will not show or something
> can not recall.  But I not certain, it was something I read on the web.

At least the Linux IP stack reports all devices that are up. For interfaces
that are down, those are never reported (also not with the system ifconfig).
if_nameindex in glibc uses SIOCGIFCONF on linux, so there is no difference
in the result. I don't know if there are obscure kernel interfaces to get
more interfaces, but I rather don't want to find out :)
 
> - Some socketaddr does carry a len, sa_len, some don't, very annoying.

Yep, that's BSD 4.3 vs 4.4, I think. I have to implement this properly
anyway because GNU Hurd and Linux differ here (and those are my main test
platforms) (we deal with this in syslogd, too, I think).

> - I think SIOCGIFCONF should work for virtual interface too .. not sure
> if yes do you take to account in your scheme that an interface can have
> multiple IP numbers.

I think I might have to do something with aliases. I might not learn about
until I enable the alias code in the Hurd (which wraps around the Linux IP
stack).
 
> > BTW, something we really, really need is some inetutils.h header file of
> > some sort with prototypes et al. I'd think that Jeff can cook up the 
> > autoconf
> > magic here that is necessary to make this work correctly.
> 
> The problem is that we do not want to define all the functions, they
> may conflict for example;
>       char *strdup (const char*);
> 
> Look right but conflict with the system headers.  In inetutils.h should
> be *our* functions not the prototypes of the functions we can not find
> on the system.

Now it's on me to say mmmmh and think more closely about it.

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' Debian http://www.debian.org address@hidden
Marcus Brinkmann              GNU    http://www.gnu.org    address@hidden
address@hidden
http://www.marcus-brinkmann.de



reply via email to

[Prev in Thread] Current Thread [Next in Thread]