netdev - Re: network interface state

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20071114.153103.230463871.davem@davemloft.net>
Date:	Wed, 14 Nov 2007 15:31:03 -0800 (PST)
From:	David Miller <davem@...emloft.net>
To:	drepper@...hat.com
Cc:	netdev@...r.kernel.org
Subject: Re: network interface state

From: Ulrich Drepper <drepper@...hat.com>
Date: Wed, 14 Nov 2007 12:59:52 -0800

> Just FYI, with the current getaddrinfo code it is even more critical to
> get to a point where I can cache network interface information and query
> the kernel whether it changed.  We now have to read the RTM_GETADDR
> tables for every lookup.  It was more limited with the old, incomplete
> implementation.
> 
> Even if it's something as simple as a RTM_SEQUENCE request which returns
> a number that is bumped at every interface change.

This sounds like a useful feature.  Essentially you want a generation
ID that increments every time a configuration change is made?

Most daemons handle this by listening for events on the netlink
socket, but I understand how that might not be practical for
glibc.

> Related: I need to know about the device type (the ARPHRD_* values) to
> determine whether a device is for a native transport or a tunnel.  What
> I currently do is:
> 
> - - at the beginning I get information about all interfaces using
> RTM_GETADDR
> 
> - - them later I have to find the device type by
> 
>   + reading the RTM_GETLINK data to get to the device name
> 
>   + then using the name and ioctl(SIOCGIFHWADDR) I get the device type
> 
> 
> It would be so much nicer if the device type would be part of the
> RTM_GETADDR data, or at least the RTM_GETLINK data.

It's part of the link information, Look in ifinfomsg->ifi_type

In general be suspicious if it seems netlink isn't providing
the same information available via the old ioctls :-)
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html