On Wed, 3 Apr 2024 at 16:05, Bart Van Assche wrote:
> Something else must be going on. This is the code from configure.ac that
> checks for libnl-3:
>
> if test "x$ac_cv_header_netlink_netlink_h" = xyes; then
> AC_EGREP_HEADER([nl_socket
right with the configure script, because
it evaluates
libnl-3 + !libnl-route-3 = libnl1
instead of failing.
Something else must be going on. This is the code from configure.ac that
checks for libnl-3:
if test "x$ac_cv_header_netlink_netlink_h" = xyes; then
AC_EGRE
On Wed, 3 Apr 2024 at 02:19, Bart Van Assche wrote:
> Can you please check the configure script logs to see why libnl-3 was
> not detected?
>
libnl-3 was detected:
configure:27875: $PKG_CONFIG --exists --print-errors "libnl-3.0"
configure:27878: $? = 0
configure:27936: result: yes
But libnl-rout
On 4/2/24 01:49, Craig Small via Net-snmp-coders wrote:
Hello All,
I was attempting to compile the git head of net-snmp. One big change
is that uses netlink sockets instead of reading /proc/net/*
The issue is the API is different to the library I can see.
mibgroup/mibII/tcpTable.c:631:12
Hello All,
I was attempting to compile the git head of net-snmp. One big change is
that uses netlink sockets instead of reading /proc/net/*
The issue is the API is different to the library I can see.
mibgroup/mibII/tcpTable.c:631:12: error: too few arguments to function
‘nl_geterror’
631
Hi Bart,
On Tuesday, February 03, 2015 7:46 AM, Bart Van Assche wrote:
> On 02/02/15 18:57, David Hauck wrote:
>> I assume this is something that you can fix up in the configure script?
>
> The patch I had mentioned in a previous e-mail has been checked in on
> the v5.6, v5.7 and master branches
On 02/02/15 18:57, David Hauck wrote:
> I assume this is something that you can fix up in the configure script?
The patch I had mentioned in a previous e-mail has been checked in on
the v5.6, v5.7 and master branches. If you would like to test that
patch, feedback is welcome.
Bart.
ey elements I kept wondering about were:
>>> 1. Whether the configure script is doing the correct thing in the
>>> case where
>> the build environment (toolchain) contains *both* libnl2 and libnl3
>> (so libnl2 is available directly in /usr/include/netlink and
&
oing the correct thing in the
>> case where
> the build environment (toolchain) contains *both* libnl2 and libnl3
> (so libnl2 is available directly in /usr/include/netlink and
> libnl3 is available in /usr/include/libnl3/netlink).
>> 2. The include directory is hardcoded as
ibnl2 and libnl3 (so
> libnl2 is available directly in /usr/include/netlink and libnl3 is
> available in /usr/include/libnl3/netlink).
> 2. The include directory is hardcoded as /usr/include/libnl3 and I'm
> wondering whether this will do the right thing in a cross-development
&
ow), but I eventually DH> discovered that this was related
>> to the fact that the system the DH> agent was running on did not
>> have netlink socket diagnostics DH> configured in the kernel. When
>> this is the case the netlink DH> (TCPDIAG_GETSOCK) response returns
>
t; mib-2 and
> always occurred during attempts to walk DH> TCP-MIB::tcpConnTable. At
> first I thought this might be related to DH> my build of v5.7.3 'snmpd'
> (see below), but I eventually DH> discovered that this was related to
> the fact that the system the DH
t this might be related to my build of v5.7.3 'snmpd' (see below),
DH> but I eventually discovered that this was related to the fact that the
DH> system the agent was running on did not have netlink socket diagnostics
DH> configured in the kernel. When this is the case the netlink
(see below), but I eventually
discovered that this was related to the fact that the system the agent was
running on did not have netlink socket diagnostics configured in the kernel.
When this is the case the netlink (TCPDIAG_GETSOCK) response returns an error;
the v5.7.3 version of agent/mibg
ar *name,
unsigned long long defaultspeed);
@@ -1023,42 +1021,51 @@ netsnmp_linux_interface_get_if_speed(int fd, const char
*name,
}
return retspeed;
}
-#ifdef SUPPORT_PREFIX_FLAGS
-void netsnmp_prefix_process(int fd, void *data);
-/* Open netlink socket to watch new ipv6 addre
n't finished reviewing this yet (but will). I'm sort of
thinking that using the monitor line to continue registering things
via netlink is a bit odd... It would make more sense to me to
handle linkup/down traps directly. The monitor/disman hack was only
put in place because there
We need to trigger a cache reload in almost all legit
cases. Therefore, we can just ignore the content of the netlink
message. As long as we have received one, we trigger a cache
refresh.
---
.../mibgroup/if-mib/data_access/interface_linux.c | 42 ++--
1 file changed, 3
, (void*)&req, sizeof(req), 0);
+if (status < 0) {
+snmp_log(LOG_ERR,"netsnmp_iflink_listen: send failed\n");
+close(fd);
+return -1;
+}
+
+if (register_readfd(fd, netsnmp_iflink_process, NULL) != 0) {
+snmp_log(LOG_ERR,"netsnmp_if
On Mon, 02 Jul 2012 07:57:47 +
Bart Van Assche wrote:
> On 07/01/12 11:02, Vincent Bernat wrote:
>
> > NetSNMP contains several use of a netlink socket to gather information
> > from the kernel for Linux:
> > agent/mibgroup/etherlike-mib/data_access/dot3stats_linux.
❦ 2 juillet 2012 09:57 CEST, Bart Van Assche :
>> NetSNMP contains several use of a netlink socket to gather information
>> from the kernel for Linux:
>> agent/mibgroup/etherlike-mib/data_access/dot3stats_linux.c
>> agent/mibgroup/if-mib/data_access/interface_linux
On 07/01/12 11:02, Vincent Bernat wrote:
> NetSNMP contains several use of a netlink socket to gather information
> from the kernel for Linux:
> agent/mibgroup/etherlike-mib/data_access/dot3stats_linux.c
> agent/mibgroup/if-mib/data_access/interface_linux.c
> agent/mibgroup/ip-
Hi!
NetSNMP contains several use of a netlink socket to gather information
from the kernel for Linux:
agent/mibgroup/etherlike-mib/data_access/dot3stats_linux.c
agent/mibgroup/if-mib/data_access/interface_linux.c
agent/mibgroup/ip-mib/data_access/arp_netlink.c
agent/mibgroup/ip-mib
Use netlink (instead of /proc) to read route table on linux.
This is more efficient and has the advantage of returning interface index
not interface name which avoids lots of unnecessary lookups.
Both IPv4 and IPv6 share the same code as well.
This code also handles multipath and ipv6 routes
Rework how route table is read to use netlink interface.
This solved major performance problems when using SNMP on full gateway
table (>256K routes).
The old code read /proc/net/route and then looked up the mapping from
name "eth0" to ifindex for each entry. Much more efficient to u
>>>>> On Thu, 7 Aug 2008 20:35:21 -0400, lanas <[EMAIL PROTECTED]> said:
l> I am aiming at integrating the NETLINK patch, submitted last
l> year, to the latest version of net-snmp, in the coming two months.
l> The purpose of this patch is to bring instant (relativel
Hello all,
I am aiming at integrating the NETLINK patch, submitted last
year, to the latest version of net-snmp, in the coming two months.
The purpose of this patch is to bring instant (relatively...)
notifications when an interface is brought down/up.
The patch works with a prior version of
In testing Vyatta router, we found snmpd gets bogged down looking
up routing table. Converting the code to use netlink fixed that.
http://sourceforge.net/tracker/index.php?func=detail&aid=1991406&group_id=12694&
ML> My apologies ahead of time for the vintage of net-snmp that I've
ML> applied this to. The patch is relatively small, and should hopefully
ML> be easily adaptable to more recent versions.
We appreciate the submission none the less (we'd love a more recent
patch, but we will take what we can ge
Greetings SNMP coders and users,
Every once in a while someone complains about having to wait for the 60 second
timer to elapse before getting their 'linkUpDownNotifications'. The attached
patch causes snmpd to register with the linux RT-NETLINK facility in order to
be notified of
Greetings all,
Here is the scenario: I have (lightly) modified a version of snmpd - 5.2.3
(under debian) to listen to RT-NETLINK and thereby trigger "monitor" items
for link up/down status immediately instead of using the "-r " option.
I now receive traps immediately
Michael Leslie wrote:
> Last March, Robert Story, Peder Norgaard and some others were discussing the
> possibility of having the snmp agent receive interface status directly from
> the linux kernel using the netlink interface, as opposed to polling on a
> relatively infrequent bas
Greetings All,
Last March, Robert Story, Peder Norgaard and some others were discussing the
possibility of having the snmp agent receive interface status directly from
the linux kernel using the netlink interface, as opposed to polling on a
relatively infrequent basis.
Has anyone had a chance
32 matches
Mail list logo
