network interface state
Subsystems (2)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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.
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.
Any help on any of these issues?
- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖ -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
iD8DBQFHO2HI2ijCOnn/RHQRAtQQAJ0QV6j/BKFmN5nWugrQ/zXf0cCu9wCffRYT +aXv6y5S1m5iwR7gVfOhp9A=
=Uf3i
-----END PGP SIGNATURE-----
David Miller
maintainerFrom: Ulrich Drepper <[email protected]>
Date: Wed, 14 Nov 2007 12:59:52 -0800
Quoted 8 lines
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_GETADDRtables for every lookup. It was more limited with the old, incomplete implementation.Even if it's something as simple as a
RTM_SEQUENCErequest 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.
Quoted 9 lines
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
Quoted 7 lines
+ reading the
RTM_GETLINKdata 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_GETADDRdata, or at least theRTM_GETLINKdata.
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 :-)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Quoted 3 lines · David Miller
Most daemons handle this by listening for events on the netlink socket, but I understand how that might not be practical for glibc.
Right, this cannot work. I have no inner loop which I can control. I cannot install a listener.
At some point, when we have non-sequential, hidden file descriptors, I'll be able to leave a socket file descriptor open. But that's about it. Even then the generation counter interface is likely to be the best choice.
Quoted 1 line
It's part of the link information, Look in
ifinfomsg->ifi_type
Great, I fixed up the code. I guess in future, once I can cache the data, I'll simply read the RTM_GETADDR and RTM_GETLINK data all at once and be done with it.
BTW, is it possible to send both these requests out before starting to read the results? This would reduce the amount of code quite a bit.
- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖ -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
iD8DBQFHO47s2ijCOnn/RHQRApIIAJwNATDabXkfszG2e+gtJWO9f4wm4wCdFuoQ Yn40KK+cs9Di4fq+WKTQalo=
=q02M
-----END PGP SIGNATURE-----
David Miller
maintainerFrom: Ulrich Drepper <[email protected]>
Date: Wed, 14 Nov 2007 16:12:28 -0800
Quoted 8 lines
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1Quoted 3 lines · David Miller
Most daemons handle this by listening for events on the netlink socket, but I understand how that might not be practical for glibc.
Quoted 7 lines
Right, this cannot work. I have no inner loop which I can control. I cannot install a listener.
At some point, when we have non-sequential, hidden file descriptors, I'll be able to leave a socket file descriptor open. But that's about it. Even then the generation counter interface is likely to be the best choice.
Ok, I'll think about how to implement this.
Quoted 2 lines
BTW, is it possible to send both these requests out before starting to read the results? This would reduce the amount of code quite a bit.
Unfortunately, that won't work. Like datagram protocols, netlink assumes one message per sendmsg() call.
Quoted 6 lines · David Miller
Quoted 3 lines
BTW, is it possible to send both these requests out before starting to read the results? This would reduce the amount of code quite a bit.
Unfortunately, that won't work. Like datagram protocols, netlink assumes one message per
sendmsg()call.
Actually netlink packets come with headers so we do allow chaining. See netlink_rcv_skb for details.
We don't make use of that on recvmsg() though although theoretically user-space is supposed to be ready to handle that too.
Cheers,
Signature · 4 lines
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txtDavid Miller
maintainerFrom: Herbert Xu <[email protected]>
Date: Thu, 15 Nov 2007 10:11:35 +0800
Quoted 10 lines
Quoted 6 lines · David Miller
Quoted 3 lines
BTW, is it possible to send both these requests out before starting to read the results? This would reduce the amount of code quite a bit.
Unfortunately, that won't work. Like datagram protocols, netlink assumes one message per
sendmsg()call.Actually netlink packets come with headers so we do allow chaining. See
netlink_rcv_skbfor details.
My bad, you are indeed right.
Ulrich you can therefore send both messages in one go if you like.
Quoted 2 lines · Herbert Xu
We don't make use of that on
recvmsg()though although theoretically user-space is supposed to be ready to handle that too.
iproute2 handles that well. Anyone writting netlink apps should program with the thought that a single received datagram will include many netlink messages.
On the concept of putting some generation marker/counter:
It is one of those things that have bothered me as well for sometime, but i cant think of a clean way to solve it for every user of netlink. One way to transport this from the kernel is stash it in the netlink sequence but that would violate things when a user expects a specific sequence.
For the ifla/iflink, it should be trivial to solve by adding a marker in the kernel that gets set to jiffies (or some incremental counter) every time an event happens. You then transport this to user space as an attribute anytime someone does a GET.
Clearly the best way to solve it is to be generic, but we would need to revamp netlink totaly.
Note, we do today signal to user space that a "message was lost" because of buffer overrun. So a hack (not applicable to the poster given they dont have a daemon) would be to listen to events and set the rx socket buffer to be very small so you loose every message.
cheers,
jamal
Quoted 33 lines · David Miller
From: Ulrich Drepper <[email protected]>
Date: Wed, 14 Nov 2007 12:59:52 -0800Quoted 8 lines
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_GETADDRtables for every lookup. It was more limited with the old, incomplete implementation.Even if it's something as simple as a
RTM_SEQUENCErequest 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.
Quoted 14 lines
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_GETLINKdata to get to the device name+ then using the name and ioctl(SIOCGIFHWADDR) I get the device type
Quoted 7 lines
Quoted 2 lines
It would be so much nicer if the device type would be part of the
RTM_GETADDRdata, or at least theRTM_GETLINKdata.It's part of the link information, Look in
ifinfomsg->ifi_typeIn general be suspicious if it seems netlink isn't providing the same information available via the old ioctls :-)
Sorry for late little offtopic question: Exists any simple way how to differentiate virtual network devices from real devices (e.g. vlans, bridges)?
They have the same ifinfomsg->ifi_type as real devices (ARPHRD_ETHER). I know to differentiate vlans via IFLA_LINK attribute. But how to differentiate bridges from real devices I didn't determine. Thanks for any answer.
regards,
milan kocian