bug-inetutils
[Top][All Lists]
Advanced

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

Re: extracting interfaces and ifconfig


From: Marcus Brinkmann
Subject: Re: extracting interfaces and ifconfig
Date: Thu, 22 Feb 2001 00:46:48 +0100
User-agent: Mutt/1.1.4i

On Wed, Feb 21, 2001 at 05:21:34PM +0000, A.A. Serjantov wrote:
> > > What is the current preferred way of doing this? Are there any hidden
> > > secrets? I think I can cope with assuming existence of AF_INET...
> > 
> > Are you talking about programming, or as a user?  Marcus Brinkmann has a 
> > nearly fully functional ifconfig that will be included fairly soon...
> 
> No, I do mean programming... And indeed, I would be interested in how that
> ifconfig is implemented....

Ok, I checked in my code. It is in ifconfig/, do a `cvs update -d' to get
the new directory. Note that this is code under development.

For your specific question, I am using if_nameindex, which is in POSIX (it
is also there to cover IPv6 interfaces, so we will be able to support them
more easily). if_nameindex is the only standardized interface to the network
interface list, so always use that (and ignore that most people aren't).

For systems not providing if_nameindex, we will have a wrapper in
libinetutils. In ifconfig/if_index.c is the beginning of such a wrapper, but
I was bored in the middle of writing it. This will have to be fixed and
moved to libinetutils. I don't know how many systems don't have if_nameindex
(but we surely will find out).

SIOCGIFCONF has a long tradition, ebing introduced early in BSD systems. It
works, but it breaks the ioctl interface very badly (because of out of band
data). Anyway, the if_index wrapper will use SIOCGIFCONF, so you can see how
both interfaces relate to each other.

/proc/net/dev is so horrible, it truncates interface names to six
characters!!! and this although IFNAMSIZ is sixteen since the dawning of
computer networks. I don't know if the linux kernel people are interested in
fixing that. However, it is true that it can provide more information. Note
that /proc/net/dev is a linuxism all I know of (other systems with proc may
provide some other data in some other file, or anything. It's not
specified). Adding support for such non-standard stuff is in the TODO list,
but by no means top priority.

Everything we do is for PF_INET (IPv4). We don't have support for other
protocol families (there is some rudimentary support for it in
ifconfig/system/linux.c). We have not discussed this, although we probably
will have to, because IPv6 is moving forward, and it makes sense to include
support for it in GNU inetutils. Other, more obscure address families are
probably too hard to support, and certainly less widely used. But I left
enough room in my ifconfig to be able to support them later (although I have
not defined any interfaces how to handle it yet).

Note that the upcoming POSIX revision (I have draft 5 here) seems to define
some more interfaces (APIs) for network interfaces (hardware). It will be
interesting to take a look at them and wrap them up in libinetutils.

So, short answer: If you don't know SIOCGIFCONF yet, use if_nameindex, it's
much cleaner.  Use our wrapper (erh, when it exists :) on systems where
if_nameindex isn't available. Avoid everything else if you can (eg if you
are not doing anything system specific like ifconfig for HAM radio stuff or
so).

Feel free to take a look at the code, it's in ifconfig/if_index.c (but see
above) and at the very end of options.c (following the comment "No
interfaces specified.  Get a list of all interfaces.").

See also the glibc docs on if_nameindex and friends.

About the status of my ifconfig: It works fine (it should work just to add
ifconfig to the top level configure and have it work), but the setup is not
as I like it (and changeif needs more work).

Thanks,
Marcus

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]