#28 closed defect (wontfix)
router's snmp return values/10 after 1GByte traffic reached
Reported by: | human | Owned by: | somebody |
---|---|---|---|
Version: | Keywords: | ||
Cc: |
Description
hi, I've used mrtg for years in my home routers without problem, until I changed to a D-LINK DSL-G624T... and I noticed that after some hours, the graphics suddenly drop. I investigated the problem, even with a sniffer, and I saw these two consecutive snmp network packets returned by the router (mrtg 5min interval):
...
Object identifier 1: 1.3.6.1.2.1.2.2.1.10.3 (IF-MIB::ifInOctets.3) Value: Counter32: 981764540
...
Object identifier 1: 1.3.6.1.2.1.2.2.1.10.3 (IF-MIB::ifInOctets.3) Value: Counter32: 100250466
...
So after this router reaches 1GByte of accumulated traffic in an interface, it counts only in amounts of (whahever/10)... as mrtg seems to unknow/undetect this, it makes the graphics as if only tenth of the traffic is being transmitted (that's what it really sees)... I'm using mrtg-2.9.22, and I haven't seen such a characteristic in any version of mrtg (just looked CHANGES file), so I don't know if it's a proper behavior or not.
is there any mrtg option to manage this situation (latest mrtg versions perhaps)? or, could I modify mrtg perl code in order to "patch" this? (just a hint of the file, and I could code and contribute it)
thank you for your time.
Attachments (1)
Change History (7)
comment:1 Changed 16 years ago by human
comment:2 Changed 16 years ago by human
- priority changed from major to minor
- Type changed from defect to enhancement
comment:3 Changed 16 years ago by human
- priority changed from minor to major
- Type changed from enhancement to defect
comment:4 Changed 16 years ago by human
- priority changed from major to minor
As nobody seems to have this very same problem, I've created a small piece of code in order to patch it in my case. I've upload it here as: manage_DLINK_SNMP_behaviour.20070729.tgz
The tgz file contains a readme file with instructions, my pl code, and a modified mrtg v2.15.2.
nevertheless, I leave this open, just in case anyone want to add more info.
bye
comment:5 Changed 12 years ago by oetiker
- Resolution set to wontfix
- Status changed from new to closed
this 'bug' is too weired to have it fixed within mrtg. BUT what you could do, is to produce an external monitoring script which fixes the counter values prior to handing them to mrtg using the backtick target syntax (script).
comment:6 Changed 10 years ago by human
- Grosir Baju Batik
- Baju Batik Wanita
- Baju Batik Pria
- Baju Batik Modern
- Baju Batik Sarimbit
- Baju Batik Pasangan
- Baju Batik Muslim
- Baju Batik Couple
- Baju Batik Tulis
- Baju Batik Terbaru
- Baju Batik Remaja
- Baju Batik Pekalongan
- Baju Batik Couple
- Dokar Balap
- Jasa SEO Murah
- Berita Terkini
- Berita Terbaru
- Berita Hari Ini
- Berita Terupdate
- Kumpulan Berita
I've tried to use mrtg's manual indication about SNMPv2c; in my case, in mrtg.cfg: Target[192.168.1.1_3]: 3:public@192.168.1.1:::::2
But, though the router specs claim to support SNMPv2c (ftp://ftp.dlink.es/Adsl/DSL-G624T/Data_sheet/DSL-G624T_Data%20Sheet.pdf), it returns NULL values (as seen with a sniffer (and also log states that the router hasn't understood it)):
So 64 bit counters aren't available...
any hint will be appreciated.