FOR TIPS, gUIDES & TUTORIALS

subscribe to our Youtube

GO TO YOUTUBE

14455 questions

17168 answers

28195 comments

0 members

We are migrating to our new platform at https://community.teltonika.lt. Moving forward, you can continue discussions on this new platform. This current platform will be temporarily maintained for reference purposes.
+2 votes
619 views 17 comments
by anonymous

Where can i find the correct new OIDs for monitoring the MobileConnection Parameters in RUTX_R_00.07.04.2? 

For example in RUTX_R_00.07.04.1 i was able to monitor:

  • mobile data connection type = .1.3.6.1.4.1.48690.2.2.1.16.1
  • Signal strength level = .1.3.6.1.4.1.48690.2.2.1.12.1
  • SINR value in dB = .1.3.6.1.4.1.48690.2.2.1.19.1
  • RSRP value in dBm = .1.3.6.1.4.1.48690.2.2.1.20.1
  • RSRQ value in dB = .1.3.6.1.4.1.48690.2.2.1.21.1

and now i'm getting a no such instance exception. Any ideas?

by anonymous

Hi,

I just upgraded from RUTX_R_00.07.04.1 to RUTX_R_00.07.04.2; and all SNMP counters I use are now down

(such as .1.3.6.1.4.1.48690.2.2.1.12.1 or 1.3.6.1.4.1.48690.2.2.1.16.1 )

Can you advise before rolling back ?.

Thank you.

PM.

by anonymous
Hello,

Not really sure what could be the issue here. Could you try factory resetting the device? A downgrade will cause it to factory reset either way, so it's worth a shot.

Best regards,
DaumantasG

3 Answers

0 votes
by anonymous

Hello,

The SNMP variables list can be found on our Wiki here.

Alternatively, these values are also available in the .mib file which can be downloaded from the RUTX50 SNMP page.

Best regards,
DaumantasG

by anonymous

Hi DaumantasG,

I know these OID-values (my ids are quite the same as in the mentioned wiki-article) but can anyone confirm that they are working in RUTx50 Release RUTX_R_00.07.04.2? 

I just updated today because the Router came unresponsive on WAN-IP two times and only a reboot helped to get back functionality.

BR, Sebastian

by anonymous
Hello,

  

Sorry for the misunderstanding.

I've tested these parameters on RUTX_R_00.07.04.2 and they do seem to be the same as on RUTX_R_00.07.04.1:

OID: .1.3.6.1.4.1.48690.2.2.1.16.1
Value: 5G-NSA
Type: OctetString

OID: .1.3.6.1.4.1.48690.2.2.1.12.1
Value: -59
Type: Integer

OID: .1.3.6.1.4.1.48690.2.2.1.19.1
Value: 9
Type: Integer

OID: .1.3.6.1.4.1.48690.2.2.1.20.1
Value: -83
Type: Integer

OID: .1.3.6.1.4.1.48690.2.2.1.21.1
Value: -12
Type: Integer

  

Best regards,
DaumantasG
0 votes
by anonymous
Hi DaumantasG,

A factory reset is not a acceptable solution/try - i'm not able to reconfigure it from scratch currently mounted on top of a tower ...

i tried a snmp-walk on two different RUTx50 - running firmware RUTX_R_00.07.04.1 (=working) and RUTX_R_00.07.04.2 (=broken).

as you can see (i've now attatched a screenshot), the whole tree under oid "1.3.6.1.4.1.48690.2.2.1" is missing. but all these values are the most importend to monitor the mobile connectivity. Maybe it is based on the oid value "1.3.6.1.4.1.48690.2.1.0" on the RUTX_R_00.07.04.2  it is set to zero - but the mobile connection is the only way i could reach the router, sim and mobile uplink is definitly working...

there is the need for a new (patched) firmware release.

br, Sebastian
by anonymous

snmpwalk will not tell you the whole story by default, instead of:

snmpwalk -v 2c -c public 192.168.1.1

you should use:

snmpwalk -v 2c -c public 192.168.1.1 .1

to get the whole tree.

0 votes
by anonymous

Is there a way to save the current parameters before proceeding to a factory reset ?.

Obviously, going back to RUTX_R_00.07.04.1 will make SNMP works, but the point is to

make if work on RUTX_R_00.07.04.2.

Btw, I just noticed that some SNMP counters are still working (such as uptime .1.3.6.1.4.1.48690.2.2.1.20.1 ), but

most of them are not working anymore. (MIB missing ?)

Do you want some troubleshooting file ?.

PM.

by anonymous

I have just bought second RUT241 and every think is OK with SNMP on FW RUT2M_R_00.07.04.2.

Also, I make on first problematic device:

  • Downgrade to RUT2M_R_00.07.04.1
  • Again upgrade from server to RUT2M_R_00.07.04.2
  • Reinstall SNMP (after upgrade, it is in failed state, it is neccessary to reinstall it)
SNMP is working correctly now on both devices.
(I don't tested direct upgrade from older FW to RUT2M_R_00.07.04.2 without upgrade to RUT2M_R_00.07.04.1 in first place)
by anonymous
Hello,

I've contacted another user to try and get remote access to a device with the SNMP issue, as it seems to occur after updating the device to v7.4.2 with the option to keep settings enabled. Will post an update here when we determine a root cause.

Best regards,
DaumantasG
by anonymous

I'm having the same issue after upgrading one of my Rutx09 routers to RUTX_R_00.07.04.3. Before the upgrade it was running RUTX_R_00.07.04.1 and all was fine. After the upgrade, all modem related SNMP queries started to fail. All non-modem related queries run just fine. I was and am using SNMPv3. These are the OID's that worked on version RUTX_R_00.07.04.1:

1.3.6.1.4.1.48690.2.2.1.20.1  (MRSRP)
1.3.6.1.4.1.48690.2.2.1.21.1 (MRSRQ)
1.3.6.1.4.1.48690.2.2.1.19.1 (MSINR)
1.3.6.1.4.1.48690.2.2.1.16.1 (Mobile network)
1.3.6.1.4.1.48690.2.2.1.13.1 (Mobile provider)
1.3.6.1.4.1.48690.2.2.1 (Modem status)
1.3.6.1.4.1.48690.2.2.1.17.1 (Modem temp)

When I run a walk on non-upgraded Rutx09:

19-May-23 16:49:54 (33 ms) : Walk 1.3.6.1.4.1.48690.2

19-May-23 16:49:55 (157 ms) : 1.3.6.1.4.1.48690.2.1.0 = "1" [ASN_INTEGER]

19-May-23 16:49:55 (287 ms) : 1.3.6.1.4.1.48690.2.2.1.1.1 = "1" [ASN_INTEGER]

19-May-23 16:49:55 (390 ms) : 1.3.6.1.4.1.48690.2.2.1.2.1 = "3-1" [ASN_OCTET_STR]

19-May-23 16:49:55 (517 ms) : 1.3.6.1.4.1.48690.2.2.1.3.1 = "868759038293066" [ASN_OCTET_STR]

19-May-23 16:49:55 (646 ms) : 1.3.6.1.4.1.48690.2.2.1.4.1 = "EG06-E" [ASN_OCTET_STR]

19-May-23 16:49:55 (756 ms) : 1.3.6.1.4.1.48690.2.2.1.5.1 = "Quectel" [ASN_OCTET_STR]

19-May-23 16:49:55 (870 ms) : 1.3.6.1.4.1.48690.2.2.1.6.1 = "EG06ELAR04A04M4G" [ASN_OCTET_STR]

19-May-23 16:49:55 (987 ms) : 1.3.6.1.4.1.48690.2.2.1.7.1 = "868759038293066" [ASN_OCTET_STR]

19-May-23 16:49:55 (1096 ms) : 1.3.6.1.4.1.48690.2.2.1.8.1 = "204041013112367" [ASN_OCTET_STR]

19-May-23 16:49:56 (1207 ms) : 1.3.6.1.4.1.48690.2.2.1.9.1 = "inserted" [ASN_OCTET_STR]

19-May-23 16:49:56 (1317 ms) : 1.3.6.1.4.1.48690.2.2.1.10.1 = "OK" [ASN_OCTET_STR]

19-May-23 16:49:57 (2203 ms) : 1.3.6.1.4.1.48690.2.2.1.11.1 = "Registered, home" [ASN_OCTET_STR]

19-May-23 16:49:57 (2327 ms) : 1.3.6.1.4.1.48690.2.2.1.12.1 = "-71" [ASN_INTEGER]

19-May-23 16:49:58 (3165 ms) : 1.3.6.1.4.1.48690.2.2.1.13.1 = "vodafone NL" [ASN_OCTET_STR]

19-May-23 16:49:59 (4147 ms) : 1.3.6.1.4.1.48690.2.2.1.14.1 = "20404" [ASN_OCTET_STR]

19-May-23 16:49:59 (4259 ms) : 1.3.6.1.4.1.48690.2.2.1.15.1 = "Connected" [ASN_OCTET_STR]

19-May-23 16:49:59 (4387 ms) : 1.3.6.1.4.1.48690.2.2.1.16.1 = "LTE" [ASN_OCTET_STR]

19-May-23 16:49:59 (4567 ms) : 1.3.6.1.4.1.48690.2.2.1.17.1 = "390" [ASN_INTEGER]

19-May-23 16:50:00 (5207 ms) : 1.3.6.1.4.1.48690.2.2.1.18.1 = "27715339" [ASN_OCTET_STR]

19-May-23 16:50:00 (5327 ms) : 1.3.6.1.4.1.48690.2.2.1.19.1 = "10" [ASN_INTEGER]

19-May-23 16:50:01 (6207 ms) : 1.3.6.1.4.1.48690.2.2.1.20.1 = "-98" [ASN_INTEGER]

19-May-23 16:50:01 (6327 ms) : 1.3.6.1.4.1.48690.2.2.1.21.1 = "-8" [ASN_INTEGER]

19-May-23 16:50:01 (6437 ms) : 1.3.6.1.4.1.48690.2.2.1.22.1 = "-489779017" [ASN_INTEGER]

19-May-23 16:50:01 (6547 ms) : 1.3.6.1.4.1.48690.2.2.1.23.1 = "1773386125" [ASN_INTEGER]

19-May-23 16:50:01 (6667 ms) : 1.3.6.1.4.1.48690.2.2.1.24.1 = "10.171.115.163" [ASN_OCTET_STR]

19-May-23 16:50:01 (6787 ms) : 1.3.6.1.4.1.48690.2.2.1.25.1 = "121121070" [ASN_INTEGER]

19-May-23 16:50:01 (6907 ms) : 1.3.6.1.4.1.48690.2.2.1.26.1 = "105000597" [ASN_INTEGER]

19-May-23 16:50:02 (7207 ms) : 1.3.6.1.4.1.48690.2.2.1.27.1 = "8931440301469658460F" [ASN_OCTET_STR]

When I run the same walk on the upgraded Rutx09:

19-May-23 16:51:00 (45 ms) : Walk 1.3.6.1.4.1.48690.2

19-May-23 16:51:00 (155 ms) : 1.3.6.1.4.1.48690.2.1.0 = "0" [ASN_INTEGER]

by anonymous
Hello @leon,

  

I will contact you via a private message.

  

Best regards,
DaumantasG
by anonymous
A restart of the snmpd service (/etc/init.d/snmpd restart) seems to fix the post upgrade snmp problem. I was able to “catch” the issue on a support call with Teltonika. They are working on a solution.