I'm trying to access a TP link access point to get some basic data from
it.
According to TP Link, I need the rfc1213 mib, which I've downloaded and
put in my ~/.snmp/mibs directory
However :
$ snmpget -v 1 -Cf -c public $IPADDRESS rfc1213.mib::ifInOctets rfc1213.mib::ifInOctets: Unknown Object Identifier
greping on the file shows that I do have entries for ifInOctets.
Changing ifInOctets to something else (e.g. Time ticks) gives me the
same result, but using the long number (1.3.6.1.2.1.1.3.0) works. As
I'm not sure what ifInOctets translates to, I can't readily use the
number instead.
Having spent half the afternoon rummaging around on the 'net with no
clear (to me) answer, I'm here.
Suggestions on where to continue welcomed.
Having spent half the afternoon rummaging around on the 'net with no
clear (to me) answer, I'm here.
On 2025-02-17, Adrian <bulleid@ku.gro.lioff> wrote:
I'm trying to access a TP link access point to get some basic data from
it.
According to TP Link, I need the rfc1213 mib, which I've downloaded and
put in my ~/.snmp/mibs directory
However :
$ snmpget -v 1 -Cf -c public $IPADDRESS rfc1213.mib::ifInOctets
rfc1213.mib::ifInOctets: Unknown Object Identifier
greping on the file shows that I do have entries for ifInOctets.
Changing ifInOctets to something else (e.g. Time ticks) gives me the
same result, but using the long number (1.3.6.1.2.1.1.3.0) works. As
I'm not sure what ifInOctets translates to, I can't readily use the
number instead.
Having spent half the afternoon rummaging around on the 'net with no
clear (to me) answer, I'm here.
Suggestions on where to continue welcomed.
Yes SNMP can be a pain. The info in that mib often is a table of values,
one per interface, and you need to know the interface table index to get
one value.
However you can get all the table in one go by doing an snmpwalk. It a
long time since I did snmp monitoring - I have written C-code to gather
and display interface data stats, but the numbers are not at my finger
tips any more. However I googled and got the number string
1.3.6.1.2.1.2.2.1.10
so try
snmpwalk -v1 -c public $IPadd 1.3.6.1.2.1.2.2.1.10
Here's what my VDSL router gave back ...
IF-MIB::ifInOctets.49 = Counter32: 0
IF-MIB::ifInOctets.50 = Counter32: 1622068159
IF-MIB::ifInOctets.51 = Counter32: 0
IF-MIB::ifInOctets.52 = Counter32: 1989775457
IF-MIB::ifInOctets.53 = Counter32: 3244444578
IF-MIB::ifInOctets.54 = Counter32: 3582643404
IF-MIB::ifInOctets.55 = Counter32: 46130557
IF-MIB::ifInOctets.56 = Counter32: 3610089600
IF-MIB::ifInOctets.1000 = Counter32: 0
IF-MIB::ifInOctets.1001 = Counter32: 0
IF-MIB::ifInOctets.1002 = Counter32: 0
IF-MIB::ifInOctets.1003 = Counter32: 0
and if you want the mib numbers ...
snmpwalk -On -v1 -c public $IPadd 1.3.6.1.2.1.2.2.1.10
.1.3.6.1.2.1.2.2.1.10.49 = Counter32: 0
.1.3.6.1.2.1.2.2.1.10.50 = Counter32: 1622073446
.1.3.6.1.2.1.2.2.1.10.51 = Counter32: 0
.1.3.6.1.2.1.2.2.1.10.52 = Counter32: 1989775457
.1.3.6.1.2.1.2.2.1.10.53 = Counter32: 3244454443
.1.3.6.1.2.1.2.2.1.10.54 = Counter32: 3582665247
.1.3.6.1.2.1.2.2.1.10.55 = Counter32: 46131353
.1.3.6.1.2.1.2.2.1.10.56 = Counter32: 3610126193
.1.3.6.1.2.1.2.2.1.10.1000 = Counter32: 0
.1.3.6.1.2.1.2.2.1.10.1001 = Counter32: 0
.1.3.6.1.2.1.2.2.1.10.1002 = Counter32: 0
.1.3.6.1.2.1.2.2.1.10.1003 = Counter32: 0
And to dump all the interface numbers is all the gory details try ...
snmpwalk -v1 -c public O 1.3.6.1.2.1.2.2.1
or add -On for the number numbers.
Happy playing it can be quite fun and often very frustrating!
Jim
Changing ifInOctets to something else (e.g. Time ticks) gives me the
same result, but using the long number (1.3.6.1.2.1.1.3.0) works.
As I'm not sure what ifInOctets translates to, I can't readily use
the number instead.
Having spent half the afternoon rummaging around on the 'net with no
clear (to me) answer, I'm here.
Suggestions on where to continue welcomed.
On 2/17/25 11:16, Adrian wrote:
Changing ifInOctets to something else (e.g. Time ticks) gives me the
same result, but using the long number (1.3.6.1.2.1.1.3.0) works.
According to the OID repository, 1.3.6.1.2.1.1.3.0 is sysUpTimeInstance
and doesn't seem to have anything to do with -- what I assume to be -- >interface inbound octets.
Link - OID repository - 1.3.6.1.2.1.1.3.0 = {iso(1) >identified-organization(3) dod(6) internet(1) mgmt(2) mib-2(1)
system(1) sysUpTime(3) sysUpTimeInstance(0)}
- https://oid-base.com/get/1.3.6.1.2.1.1.3.0
It seems as if ifInOctets is 1.3.6.1.2.1.2.2.1.10
Link - OID repository - 1.3.6.1.2.1.2.2.1.10 = {iso(1) >identified-organization(3) dod(6) internet(1) mgmt(2) mib-2(1)
interfaces(2) ifTable(2) ifEntry(1) ifInOctets(10)}
- https://oid-base.com/get/1.3.6.1.2.1.2.2.1.10
As I'm not sure what ifInOctets translates to, I can't readily use
the number instead.
Are you looking for the system's up time or the number of octets
received on interfaces?
Adrian wrote:
Having spent half the afternoon rummaging around on the 'net with no
clear (to me) answer, I'm here.
I'd get a GUI MIB browser and poke around, not sure if there are any
good Linux ones, I've use Windows ones ...
I'm after both. Uptime on a daily basis, and octets in (and out,
ideally on both Ethernet and WiFi) on a more regular basis.
The Uptime is easy to identify when doing a snmpwalk (so I can get the
id number), but there are a number of lines that come back that could
be the dataflow values.
I've just tried using snmpget on 1.3.6.1.2.1.2.2.1.10 to get
ifInOctets, and I get :
No such Object available in this agent at this OID
Looking at that with snmpwalk, there are 10 sub-values >(1.3.6.1.2.1.2.2.1.10.x), of which 6 are zero, and the other 4 (x = 1,
6, 7, 8) have differing values. The first seems to be constant at 480.
It looks as though I can now get the info I want, albeit using the long number rather than a MIB identifier.
On 2/18/25 09:10, Adrian wrote:
It looks as though I can now get the info I want, albeit using the
long number rather than a MIB identifier.
I'm glad that you got it working.
I wonder if you could modify the MIB or add your own MIB to the
collection. -- I thought you said that you needed to use the name,
not the OID.
My understanding -- could easily be wrong -- is that not all
manufacturers follow well known / published standards. So maybe you
ran into a not quite as standard as desired edge case.
In message <slrnvr70hg.3ku.jj@iridium.wf32df>, Jim Jackson
<jj@franjam.org.uk> writes
On 2025-02-17, Adrian <bulleid@ku.gro.lioff> wrote:
I'm trying to access a TP link access point to get some basic data from
it.
According to TP Link, I need the rfc1213 mib, which I've downloaded and
put in my ~/.snmp/mibs directory
However :
$ snmpget -v 1 -Cf -c public $IPADDRESS rfc1213.mib::ifInOctets
rfc1213.mib::ifInOctets: Unknown Object Identifier
greping on the file shows that I do have entries for ifInOctets.
Changing ifInOctets to something else (e.g. Time ticks) gives me the
same result, but using the long number (1.3.6.1.2.1.1.3.0) works. As
I'm not sure what ifInOctets translates to, I can't readily use the
number instead.
Having spent half the afternoon rummaging around on the 'net with no
clear (to me) answer, I'm here.
Suggestions on where to continue welcomed.
Yes SNMP can be a pain. The info in that mib often is a table of values, >>one per interface, and you need to know the interface table index to get >>one value.
However you can get all the table in one go by doing an snmpwalk. It a
long time since I did snmp monitoring - I have written C-code to gather
and display interface data stats, but the numbers are not at my finger
tips any more. However I googled and got the number string
1.3.6.1.2.1.2.2.1.10
so try
snmpwalk -v1 -c public $IPadd 1.3.6.1.2.1.2.2.1.10
Here's what my VDSL router gave back ...
IF-MIB::ifInOctets.49 = Counter32: 0
IF-MIB::ifInOctets.50 = Counter32: 1622068159
IF-MIB::ifInOctets.51 = Counter32: 0
IF-MIB::ifInOctets.52 = Counter32: 1989775457
IF-MIB::ifInOctets.53 = Counter32: 3244444578
IF-MIB::ifInOctets.54 = Counter32: 3582643404
IF-MIB::ifInOctets.55 = Counter32: 46130557
IF-MIB::ifInOctets.56 = Counter32: 3610089600
IF-MIB::ifInOctets.1000 = Counter32: 0
IF-MIB::ifInOctets.1001 = Counter32: 0
IF-MIB::ifInOctets.1002 = Counter32: 0
IF-MIB::ifInOctets.1003 = Counter32: 0
and if you want the mib numbers ...
snmpwalk -On -v1 -c public $IPadd 1.3.6.1.2.1.2.2.1.10 >>.1.3.6.1.2.1.2.2.1.10.49 = Counter32: 0
.1.3.6.1.2.1.2.2.1.10.50 = Counter32: 1622073446
.1.3.6.1.2.1.2.2.1.10.51 = Counter32: 0
.1.3.6.1.2.1.2.2.1.10.52 = Counter32: 1989775457
.1.3.6.1.2.1.2.2.1.10.53 = Counter32: 3244454443
.1.3.6.1.2.1.2.2.1.10.54 = Counter32: 3582665247
.1.3.6.1.2.1.2.2.1.10.55 = Counter32: 46131353
.1.3.6.1.2.1.2.2.1.10.56 = Counter32: 3610126193
.1.3.6.1.2.1.2.2.1.10.1000 = Counter32: 0
.1.3.6.1.2.1.2.2.1.10.1001 = Counter32: 0
.1.3.6.1.2.1.2.2.1.10.1002 = Counter32: 0
.1.3.6.1.2.1.2.2.1.10.1003 = Counter32: 0
And to dump all the interface numbers is all the gory details try ...
snmpwalk -v1 -c public O 1.3.6.1.2.1.2.2.1
or add -On for the number numbers.
Happy playing it can be quite fun and often very frustrating!
Jim
Thanks for the reply.
Trying that I get :
snmpwalk -v1 -c public $IPadd 1.3.6.1.2.1.2.2.1.10
iso.3.6.1.2.1.2.2.1.10.1 = Counter32: 480
iso.3.6.1.2.1.2.2.1.10.2 = Counter32: 0
iso.3.6.1.2.1.2.2.1.10.3 = Counter32: 0
iso.3.6.1.2.1.2.2.1.10.4 = Counter32: 0
iso.3.6.1.2.1.2.2.1.10.5 = Counter32: 0
iso.3.6.1.2.1.2.2.1.10.6 = Counter32: 47834339
iso.3.6.1.2.1.2.2.1.10.7 = Counter32: 28162230
iso.3.6.1.2.1.2.2.1.10.8 = Counter32: 21747742
iso.3.6.1.2.1.2.2.1.10.9 = Counter32: 0
iso.3.6.1.2.1.2.2.1.10.10 = Counter32: 0
and
snmpwalk -On -v1 -c public $IPadd 1.3.6.1.2.1.2.2.1.10 .1.3.6.1.2.1.2.2.1.10.1 = Counter32: 480
.1.3.6.1.2.1.2.2.1.10.2 = Counter32: 0
.1.3.6.1.2.1.2.2.1.10.3 = Counter32: 0
.1.3.6.1.2.1.2.2.1.10.4 = Counter32: 0
.1.3.6.1.2.1.2.2.1.10.5 = Counter32: 0
.1.3.6.1.2.1.2.2.1.10.6 = Counter32: 47855251
.1.3.6.1.2.1.2.2.1.10.7 = Counter32: 28168496
.1.3.6.1.2.1.2.2.1.10.8 = Counter32: 21766531
.1.3.6.1.2.1.2.2.1.10.9 = Counter32: 0
.1.3.6.1.2.1.2.2.1.10.10 = Counter32: 0
Sorry for late response ....
There are others. Hope you are getting results.
On 2/18/25 09:10, Adrian wrote:
It looks as though I can now get the info I want, albeit using the long
number rather than a MIB identifier.
I'm glad that you got it working.
I wonder if you could modify the MIB or add your own MIB to the
collection. -- I thought you said that you needed to use the name, not
the OID.
My understanding -- could easily be wrong -- is that not all
manufacturers follow well known / published standards. So maybe you ran
into a not quite as standard as desired edge case.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 480 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 253:33:19 |
| Calls: | 9,532 |
| Files: | 13,650 |
| Messages: | 6,138,131 |