Librenms problem snmp community

Help
2

the problem is in discovery.php stp module

SNMP['/usr/bin/snmpget' '-M' '/opt/librenms/mibs:/opt/librenms/mibs/huawei' '-v2c' '-c' 'COMMUNITY' '-OQXUt' 'udp:HOSTNAME:161' 'BRIDGE-MIB::dot1dBaseBridgeAddress.0' 'BRIDGE-MIB::dot1dStpProtocolSpecification.0' 'BRIDGE-MIB::dot1dStpPriority.0' 'BRIDGE-MIB::dot1dStpTimeSinceTopologyChange.0' 'BRIDGE-MIB::dot1dStpTopChanges.0' 'BRIDGE-MIB::dot1dStpDesignatedRoot.0' 'BRIDGE-MIB::dot1dStpRootCost.0' 'BRIDGE-MIB::dot1dStpRootPort.0' 'BRIDGE-MIB::dot1dStpMaxAge.0' 'BRIDGE-MIB::dot1dStpHelloTime.0' 'BRIDGE-MIB::dot1dStpHoldTime.0' 'BRIDGE-MIB::dot1dStpForwardDelay.0' 'BRIDGE-MIB::dot1dStpBridgeMaxAge.0' 'BRIDGE-MIB::dot1dStpBridgeHelloTime.0' 'BRIDGE-MIB::dot1dStpBridgeForwardDelay.0']
Exitcode: 1 ["Timeout: No Response from udp:192.168.224.192:161.\n"]



SNMP['/usr/bin/snmpget' '-M' '/opt/librenms/mibs:/opt/librenms/mibs/huawei' '-v2c' '-c' 'COMMUNITY' '-OQXUt' 'udp:HOSTNAME:161' 'BRIDGE-MIB::dot1dBaseBridgeAddress.0' 'BRIDGE-MIB::dot1dStpProtocolSpecification.0' 'BRIDGE-MIB::dot1dStpPriority.0' 'BRIDGE-MIB::dot1dStpTimeSinceTopologyChange.0' 'BRIDGE-MIB::dot1dStpTopChanges.0' 'BRIDGE-MIB::dot1dStpDesignatedRoot.0' 'BRIDGE-MIB::dot1dStpRootCost.0' 'BRIDGE-MIB::dot1dStpRootPort.0' 'BRIDGE-MIB::dot1dStpMaxAge.0' 'BRIDGE-MIB::dot1dStpHelloTime.0' 'BRIDGE-MIB::dot1dStpHoldTime.0' 'BRIDGE-MIB::dot1dStpForwardDelay.0' 'BRIDGE-MIB::dot1dStpBridgeMaxAge.0' 'BRIDGE-MIB::dot1dStpBridgeHelloTime.0' 'BRIDGE-MIB::dot1dStpBridgeForwardDelay.0']
Exitcode: 1 ["Timeout: No Response from udp:192.168.224.191:161.\n"]

Timeout: No Response from udp:192.168.224.191:161.

will appear after this command

Jan 31 2022 18:09:39+01:00 k17-optika %%01SNMP/4/SNMP_IPLOCK(s)[0]:The source IP was locked because of the failure of login through SNMP.(SourceIP=192.168.224.61, VPN= )
Jan 31 2022 18:09:39+01:00 k17-optika %%01SNMP/4/SNMP_FAIL(s)[1]:Failed to login through SNMP. (Ip=192.168.224.61, Times=1, Reason=the community was incorrect, VPN= )
3

We have the same problem.

4

We have the same problem, I think the issue is this code pull: Stp module rewrite by murrant · Pull Request #13570 · librenms/librenms · GitHub

I’ve commented and I hope @murrant will check the code as soon as possible.

1 Like
5

according to the log, it also does this on other devices
this is edgecore switch

#### Load disco module stp ####
Instances:
2022-01-31 08:52:52,709 :: ERROR :: Thread Thread-2 exited with code -254
2022-01-31 08:52:52,709 :: ERROR :: Timeout of 900 seconds expired for command "/usr/bin/env php /opt/librenms/discovery.php -h 9" execution. Original output was: LibreNMS Discovery
6

Same problem here, have about 500 devices acting crazy? Any response?

7

I’ve commented in the /etc/cron.d/librenms line before this is resolved

#33   */6  * * *   librenms    /opt/librenms/cronic /opt/librenms/discovery-wrapper.py 1

and made a reboot server with librenms.
this prevented discovery and huawei does not block snmp

8

same problem here using v22.1.0-34-ga3bd1b9a6

as per tcpdump:

IP 192.168.2.1.57480 > 192.168.2.100.snmp: C=“public@21” GetRequest(240)
IP 192.168.2.1.57480 > 192.168.2.100.snmp: C=“public@21” GetRequest(240)
IP 192.168.2.1.57480 > 192.168.2.100.snmp: C=“public@21” GetRequest(240)
IP 192.168.2.1.57480 > 192.168.2.100.snmp: C=“public@21” GetRequest(240)
IP 192.168.2.1.57480 > 192.168.2.100.snmp: C=“public@21” GetRequest(240)
IP 192.168.2.1.57480 > 192.168.2.100.snmp: C=“public@21” GetRequest(240)
IP 192.168.2.1.32852 > 192.168.2.100.snmp: C=“public@22” GetRequest(240)
IP 192.168.2.1.32852 > 192.168.2.100.snmp: C=“public@22” GetRequest(240)
IP 192.168.2.1.41233 > 192.168.2.100.snmp: C=“public@2504” GetRequest(240)
IP 192.168.2.1.41233 > 192.168.2.100.snmp: C=“public@2504” GetRequest(240)
IP 192.168.2.1.41233 > 192.168.2.100.snmp: C=“public@2504” GetRequest(240)
IP 192.168.2.1.41233 > 192.168.2.100.snmp: C=“public@2504” GetRequest(240)
IP 192.168.2.1.41233 > 192.168.2.100.snmp: C=“public@2504” GetRequest(240)
IP 192.168.2.1.41233 > 192.168.2.100.snmp: C=“public@2504” GetRequest(240)

somehow “@nn” is added to the community (=> failed snmp logins/requests → ip blocked after multiple attemps)

disabling the stp discovery module resolvs the issue

1 Like
9

This worked fine for me as well, thanks for providing a workaround to the problem.

10

Thanks for the workaround. As I thought the bug is in the new STP discovery code, will try
$config[‘discovery_modules’][‘stp’] = false;

and see if it resolves the issue.

11

When we can except repair of this bug? It is important to us with lot of huawei and also edgecore switches.

12

silent treatment

13

No - nobody works for librenms it is all volunteer-based.

So meaning if someone wants to submit a fix for this they can if not then it stays.

Submit a PR

https://github.com/librenms/librenms/pulls

14

we have the same problem with our Huawei devices. seems like the device is blocking the librenms IP for a while and during this time they appear as down in libre…

Feb 8 2022 08:04:53+02:00 BPoP-1 %%01SNMP/4/SNMP_IPUNLOCK(s)[9]:The source IP was unlocked.(SourceIP=x.x.x.x, VPN= )
Feb 8 2022 08:04:35+02:00 BPoP-1 %%01SNMP/4/SNMP_IPLOCK(s)[10]:The source IP was locked because of the failure of login through SNMP.(SourceIP=x.x.x.x, VPN= )
Feb 8 2022 08:04:35+02:00 BPoP-1 %%01SNMP/4/SNMP_FAIL(s)[11]:Failed to login through SNMP. (Ip=x.x.x.x, Times=4, Reason=the community was incorrect, VPN= )

15

unfortunately the only solution yet is to turn off stp in discovery
conifg.php

$config['discovery_modules']['stp'] = false;
16

This also causes problems with SNMPv3 AuthPriv and invalid context: it always sets the -n vlan-$vlanid option when calling snmpget, which causes login failures.

My workaround was to remove all lines where it sets the option.

17

Hi @erotel

  • First option is to ask huawei how to disable this behaviour. If the community is not available, fine, but blocking the monitoring system is probably not appropriate.
  • Second action: list the devices that are involved.
  • Third option is to suggest a fix:
    – One fix could be to add a piece of detection code, and flag the device as “not supporting this feature”
    – Other option, create a manual flag (or an OS specific flag) to define which device is supporting or not this feature.

Bye

18

these switches from huawei doesnt enable to disable autoblocking fuction on snmp community brute force attack.

19

affected devices:

huawei s5720, s1720 series
edgecore 4120, 4510, 3528M

20

For that part, opening a case at huawei TAC could help. The more people are asking, the more chances of getting a fix (like a setting to disable the behaviour) we have.

21

A quick and dirty fix is on tracks here :