WIKIABOUT

FOR TIPS, gUIDES & TUTORIALS

subscribe to our Youtube

GO TO YOUTUBE

14455 questions

17168 answers

28195 comments

0 members

Most popular tags

rut955 rut240 rut950 rutx11 rms vpn to openvpn wifi not sms trb140 firmware connection - ipsec on rutx12 rutx09 modbus
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.

SNMP Changes to Mobile Connection in RUTX_R_00.07.04.2

+2 votes
681 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 totally agree to you - going back is just a temporary solution.

i found, that oid  1.3.6.1.4.1.48690.2.1.0 (called "SimState.0") is returned with value "0" in RUTX_R_00.07.04.2 - in RUTX_R_00.07.04.1 the value is "1".

So in RUTX_R_00.07.04.1 values / OIDs under 1.3.6.1.4.1.48690.2.2.1.* are working - in the new version all of them are missing. Any other OID seems to work well.
by anonymous

Hello,

  

A troubleshoot file would be appreciated, as I've updated from v7.4.1 to v7.4.2 and everything works as expected (1.3.6.1.4.1.48690.2.2.1.* included). Perhaps the issue could be with a particular mode (v2c, v1, etc.). Once I have the troubleshoot file, I will try replicating your exact setup and perhaps find the issue here.

  

Best regards,
DaumantasG

by anonymous
I've just sent you the troubleshoot file for analysis.

This issue is not related to SNMP mode (v2c), as a few snmp entries are still working.

Thank you.

PM.
by anonymous

I'have just bought new RUT241, make upgrade FW to last version RUT2M_R_00.07.04.2 and found out, that
modemNum (1.3.6.1.4.1.48690.2.1.0) returns 0. Thats incorrect, because RUT241 has 1 modem.

/usr/bin/snmpwalk -v 2c -c public x.x.x.x:161 1.3.6.1.4.1.48690.2
SNMPv2-SMI::enterprises.48690.2.1.0 = INTEGER: 0

Info:
/usr/bin/snmpwalk -v 1 -c public x.x.x.x:161 1.3.6.1.4.1.48690.1
SNMPv2-SMI::enterprises.48690.1.1.0 = STRING: "1127482699"
SNMPv2-SMI::enterprises.48690.1.2.0 = STRING: "XYZ"
SNMPv2-SMI::enterprises.48690.1.3.0 = STRING: "RUT24101XXXX"
SNMPv2-SMI::enterprises.48690.1.4.0 = STRING: "0005"
SNMPv2-SMI::enterprises.48690.1.5.0 = STRING: "0002"
SNMPv2-SMI::enterprises.48690.1.6.0 = STRING: "RUT2M_R_00.07.04.2"
 

by anonymous

Hi,

Following the troubleshoot file sent last week, can we have an update on this issue ?.

As a reminder, snmp counters are not working any more since upgrade to RUTX_R_00.07.04.2

For instance:

.1.3.6.1.4.1.48690.2.2.1.12.1

1.3.6.1.4.1.48690.2.2.1.18.1

Thank you.

PM.

by anonymous
Hello,

  

Sorry for the delayed response.

As mentioned, I'm not able to replicate the issue, thus I will ask for a remote AnyDesk session to further troubleshoot the issue on the device. Please message me the time when you are available and can investigate the issue further.

  

Best regards,
DaumantasG
by anonymous
Hello @pm9292,

   

I've checked on your exact device but was also unable to replicate the issue.

Could you send a troubleshoot file to me via a private message? Could you also clarify if the modem is detected on the Overview page?

If possible, please try resetting the device to factory defaults and check if the issue reappears.

  

Best regards,
DaumantasG
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.