Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

More NetBSD/OpenBSD TCP-MIB fun...

21 views
Skip to first unread message

Brian A. Seklecki

unread,
Sep 24, 2005, 11:24:14 PM9/24/05
to

After all of that last night, the original problem persists.

There are 14 attributes in both the TCP-MIB:: on NetBSD/OpenBSD:

The problem is that TCP-MIB::tcpCurrEstab.0 is always 0 or 1. It works
fine in FreeBSD.

TCP-MIB::tcpCurrEstab.0 is one of only a thousand variables that don't get
populated properly as a result of the general support issue.

If I specify --with-mib-modules="mibII/tcpTabled [...]", it doesn't
matter. It seems to be a default.

At first I thought this was related to a lack of tcp_var.h / struct
tcpstat.*, but I was wrong.

struct tcpstat {
u_quad_t tcps_connattempt; /* connections initiated */
u_quad_t tcps_accepts; /* connections accepted */
u_quad_t tcps_connects; /* connections established */
.... }

tcps_connects is actually histortical total of connects since the kernel
booted...

Linux "netstat -s" does indeed have a "Current Open TCP connection"
structure.
#netstat -s
Tcp:
49 active connections openings
12 passive connection openings
2 failed connection attempts
4 connection resets received


*BSD does not have such a structure. Therefore, I'm assuming that it's
determining the value on FreeBSD by simply counting the rows in the
"tcpTable".

The problem is that the tcpTable is either not present, or improperly
popualted. The behavior is the same on NetBSD.

Here's an snmptable(1) on a FreeBSD box v.s. an OpenBSD box:

# /opt/net-snmp/bin/snmptable -v 2c 192.168.1.51 TCP-MIB::tcpConnTable
SNMP table: TCP-MIB::tcpConnTable

tcpConnState tcpConnLocalAddress tcpConnLocalPort tcpConnRemAddress
tcpConnRemPort
listen 0.0.0.0 22 0.0.0.0
0
[.........................snip......................]
timeWait 127.0.0.1 25 127.0.0.1
49686
established 192.168.1.51 22 192.168.2.50
49460
listen 192.168.1.51 2401 0.0.0.0
0
timeWait 192.168.1.51 54361 192.168.1.50
2049
timeWait 192.168.1.51 57482 66.39.2.8
25
timeWait 192.168.1.51 57776 192.168.1.50
445
timeWait 192.168.1.51 58294 66.94.9.228
25


And here's an OpenBSD box:

/opt/net-snmp/bin/snmptable -v 2c 192.168.1.1 TCP-MIB::tcpConnTable
SNMP table: TCP-MIB::tcpConnTable

tcpConnState tcpConnLocalAddress tcpConnLocalPort tcpConnRemAddress
tcpConnRemPort
listen 127.0.0.1 199 0.0.0.0
0

....only one row is listed.

~BAS

openbsd# /opt/net-snmp/bin/snmpwalk -v 2c -c cfusion 192.168.1.51|egrep
"^TCP-MIB"|grep -v "tcpConn"|egrep -v "tcp\."| more
TCP-MIB::tcpRtoAlgorithm.0 = INTEGER: vanj(4)
TCP-MIB::tcpRtoMin.0 = INTEGER: 3 milliseconds
TCP-MIB::tcpRtoMax.0 = INTEGER: 8192 milliseconds
TCP-MIB::tcpMaxConn.0 = INTEGER: -1
TCP-MIB::tcpActiveOpens.0 = Counter32: 182685
TCP-MIB::tcpPassiveOpens.0 = Counter32: 76855
TCP-MIB::tcpAttemptFails.0 = Counter32: 15079
TCP-MIB::tcpEstabResets.0 = Counter32: 5746
TCP-MIB::tcpCurrEstab.0 = Gauge32: 1
TCP-MIB::tcpInSegs.0 = Counter32: 3140406
TCP-MIB::tcpOutSegs.0 = Counter32: 3774472
TCP-MIB::tcpRetransSegs.0 = Counter32: 2460
TCP-MIB::tcpInErrs.0 = Counter32: 0
TCP-MIB::tcpOutRsts.0 = Counter32: 124976

netbsd# snmpwalk -c virgilasnmp -v 2c 192.168.1.1|egrep "^TCP-MIB"
TCP-MIB::tcpRtoAlgorithm.0 = INTEGER: vanj(4)
TCP-MIB::tcpRtoMin.0 = INTEGER: 1000 milliseconds
TCP-MIB::tcpRtoMax.0 = INTEGER: 64000 milliseconds
TCP-MIB::tcpMaxConn.0 = INTEGER: -1
TCP-MIB::tcpActiveOpens.0 = Counter32: 30565
TCP-MIB::tcpPassiveOpens.0 = Counter32: 103344
TCP-MIB::tcpAttemptFails.0 = Counter32: 109
TCP-MIB::tcpEstabResets.0 = Counter32: 1123
TCP-MIB::tcpCurrEstab.0 = Gauge32: 0
TCP-MIB::tcpInSegs.0 = Counter32: 33366080
TCP-MIB::tcpOutSegs.0 = Counter32: 33763547
TCP-MIB::tcpRetransSegs.0 = Counter32: 236555
TCP-MIB::tcpInErrs.0 = Counter32: 17
TCP-MIB::tcpOutRsts.0 = Counter32: 23181

-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server.
Download it for free - -and be entered to win a 42" plasma tv or your very
own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Net-snmp-coders mailing list
Net-snm...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Brian A. Seklecki

unread,
Sep 25, 2005, 1:13:14 AM9/25/05
to

The value gets populated in agent/migroups/mibII/tcp.c. There are a
number of #ifdef's for different possible type of the internal "tcpstat"
structure that Net-SNMP can use.

The outputs of the pre-processor:

http://digitalfreaks.org/~lavalamp/tcp.o-5.2.1.2-preproc-freebsd
http://digitalfreaks.org/~lavalamp/tcp.o-5.3.dev-preproc-openbsd

From that output, I can't see how the FreeBSD tcp table is getting
populated. I assume it has something to do with:

case TCPCURRESTAB:
#ifdef USING_MIBII_TCPTABLE_MODULE
ret_value = TCP_Count_Connections();
#else
ret_value = 0;
#endif
type = ASN_GAUGE;
break;

...and TCP_Count_Connections will presumably fail. tcpTable.c seems to
pretty popular.


FreeBSD has a small patch for the function:

http://www.freebsd.org/cgi/cvsweb.cgi/ports/net-mgmt/net-snmp/files/patch-tcpTable.c?rev=1.4&content-type=text/x-cvsweb-markup

--- agent/mibgroup/mibII/tcpTable.c.orig Wed Jun 9 05:53:17 2004
+++ agent/mibgroup/mibII/tcpTable.c Thu Jun 24 23:21:32 2004
@@ -275,6 +277,9 @@

int
TCP_Count_Connections( void ) {
+#if (defined(CAN_USE_SYSCTL) && defined(TCPCTL_PCBLIST))
+ tcpTable_load(NULL, NULL);
+#endif
return tcp_estab;
}


Notes:
o Implement tcp.tcpCurrEstab to return correct value.
o Fix tcp.tcpCurrEstab.0 counting.


...but applying that to the 5.3.dev source on OpenBSD doesn't resolve the
problem.

NetBSD has this fix:
http://cvsweb.netbsd.org/bsdweb.cgi/pkgsrc/net/net-snmp/patches/patch-ai?rev=1.2&content-type=text/x-cvsweb-markup

OpenBSD has this fix:
http://www.openbsd.org/cgi-bin/cvsweb/ports/net/net-snmp/patches/patch-agent_mibgroup_mibII_tcpTable_c


~BAS

l8*
-lava

x.25 - minix - bitnet - plan9 - 110 bps - ASR 33 - base8

0 new messages