Is anyone else using SNMP to pull configs from ePMP AC?

We have been using SNMP to pull backup configs from ePMP radios for years. As of v6.4 and up this stopped working on ePMP AC (and never worked on AX). Started a ticket with Cambium but they say they can’t reproduce so I guess we are doing something wrong even though it worked for years and we didn’t change anything. We can roll an AC radio back to anything before v4.6 and it starts working again.

If you are using SNMP to pull configs from the ePMP AC radios running v4.6 or later, would you share how you are doing it ?

This worked for us for years, we didn’t change anything and then v4.6 and it stopped working on AC radios:

Works on N

~ # snmpset -v 2c -c private radio.management.IP .1.3.6.1.4.1.17713.21.6.4.10.0 i 1
.1.3.6.1.4.1.17713.21.6.4.10.0 = INTEGER: 1
~ # snmpget -v 2c -c private radio.management.IP .1.3.6.1.4.1.17713.21.6.4.11.0
.1.3.6.1.4.1.17713.21.6.4.11.0 = INTEGER: 4
~ # snmpget -v 2c -c private radio.management.IP .1.3.6.1.4.1.17713.21.6.4.13.0
.1.3.6.1.4.1.17713.21.6.4.13.0 = STRING: "http://radio.management.IP/dl/4.6.1_2201stuff

But on AC Clients since v4.6 step two either either hangs / returns 1 (exporting JSON config but never goes past that to 4 Success) or it returns -1 error with no explanation.

Thanks

1 Like

This sounds like either an oid issue or you need to update your mibs.

We are pulling current configs off AC gear now and no issues.

1 Like

MIBs are the 4.6.2 MIBs , it works fine on all N radios and was working on all AC radios right up until the upgrade to v4.6 . I don’t know what you mean by “OID issue” ? What OIDs are you using ? Would you be willing to share how you are doing it differently than us ? And are you sure it’s working ? Since we have mostly N radios and we don’t actually need the backups that often we had no idea until recently it had broke on AC.

1 Like

Hi,

we use the same snmp command and we didn’t have any issue.
What radio model are you using?

Oid issues are simply when the client receives a request but only a portion of the full oid is sent.
We use a script in linux to pull the config into a text file, we are also only doing this for the APs since we push the SM configs by radius during authentication/authorization of eap-ttls.

The script does a few other things but the pertinent part just uses snmp -v2 private radio.ip oid/mib.statement > device-id.txt

Mibs are loaded automatically using net-snmp config

Well that may explain it because it works on 3000AP and 3000L just not on any AC or AX client radios including f300 CSM.

2 Likes

It works on all ePMP N radios and AC “Access Points” 3000 and 3000L . It does not work on any ePMP AC client radio nor the two Connectorized AX radios we have. Up until v4.6 it worked on all N and AC client and AP radios.

1 Like

So we have figured out that the SNMP works to pull the config of AC radios so long as they are in BRIDGE mode. All of our customer radios are NAT / PPPoE Auto with separate management interface. If I change one to Bridge then it starts working.

So the SNMP OIDs to grab the config from a radio works on-

(1) All AC and N radios running any version of software previous to v4.6.
(2) All AC and N radios in Bridge mode regardless of software version
(3) All N radios regardless of software version or mode.

The SNMPGET errors / does not work on -
(1) Any AC Radio in NAT / PPPoE Auto using v4.6 or later. This is regardless of “Separate Management Interface” being enabled and configured or disabled (when disabled the radio is accessed by the IP handed to it by PPPoE).

Vlans or not seems irrelevant, it’s broken simply by using NAT / PPPoE Auto mode. No matter what settings we try when the radio is in bridge mode the OIDs work and no matter what settings we use when the Radio is in NAT / PPPoE mode " ~ # snmpget -v 2c -c private radio.management.IP .1.3.6.1.4.1.17713.21.6.4.11.0
.1.3.6.1.4.1.17713.21.6.4.11.0 = INTEGER: " returns -1 error.

1 Like

Is it just the config retrieval OIDs that don’t work in that situation, or is it all OIDs? (ie. is SNMP completely broken for AC radios in NAT/PPPoE mode?)

Just one of the OIDS used to pull the config as far as I can tell since our cacti graphs are still working.

Thank you for the detailed investigation. I see you have already sent this as a follow-up to your ticket - hopefully the details you have provided will be enough to allow engineering to reproduce and fix it.

I just pulled your OID from one of my servers to an F300-25 running 4.6.1 and it returned correctly.
ran:
snmpget -v 2c -c Community-Redacted Radio-management-Vlan-IP .1.3.6.1.4.1.17713.21.6.4.11.0

Returned:
iso.3.6.1.4.1.17713.21.6.4.11.0 = INTEGER: 0

Radio is in NAT mode, but no PPPoE.

The possible results for SNMPGET on that OID are:

Code Description
-1 Error
0 Idle
1 Exporting JSON config
2 Moving config into upload directory
3 Preparing link for uploading
4 Success

If you SNMPGET that OID without having SNMPSET 1 the other OID first it will , without error and regardless of configuration or PPPoE on/off, correctly return 0 which means IDLE or nothing there.

I did test it though. If I set a radio to NAT DHCP or NAT Static in both cases after doing the SNMPSET 1 to start the process of exporting the config the GET returned 4 both times which means “Success” the config has been (1) Exported (2) Moved to the upload directory (3) A link has been prepared for download.

Just enabling PPPoE breaks it. With PPPoE enabled if you SNMPSET 1 the first OID then try to GET the 2nd OID it just sets at 1 forever or -1 (error).

1 Like

You should not need to set an snmp oid parameter first unless your intention is to create the jason file and download that file.

If you do a full snmpget walk you will find that all of the current parameters are available and can be parsed into a config file.

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.