What does the gen err (6) message mean when doing an SNMPwalk on a device.

I have a Cambium 4500L AP and imported the MIB file into The Dude but when I walk this MIB it get nothing but this error. The device returns data for other MIBs like RFC1213 ect, but always fails on the Cambium Mib file.

Do not open multiple topic for same argument.
https://community.cambiumnetworks.com/t ... le/93887/3


Ohh... sorry, is on another forum

Use CAMBIUM-ePMP-4.7.0.1-MIB is more recent despite the version number, and do not have that problem...

What does the gen err (6) message mean when doing an SNMPwalk on a device.

I have a Cambium 4500L AP and imported the MIB file into The Dude but when I walk this MIB it get nothing but this error. The device returns data for other MIBs like RFC1213 ect, but always fails on the Cambium Mib file.

I just tried that and I get the same 'gen err (6)' error. What does that error mean?

I do not know, I do not have that error...
I have ePMP 1000... (the last one, with only 2 clients, I removed all the rest, they are toilets....)

It could also be how quickly you try to walk the MIB. Some devices aren't that "quick" or have limits on the processing of SNMP requests & being UDP-based, it doesn't wait before making a new request. i.e. A snmpwalk can make thousands of requests, if too many are "pending" you'd get errors like.

If you increase the polling time and/or limit the walk to only one part of the MIB (e.g. use a "subtree"), that might avoid.

A snmpwalk can make thousands of requests, if too many are "pending" you'd get errors like

How???
snmpwalk does not blindly send a large number of requests! It asks for "the next" item, gets the value for that item returned and then uses the OID of that returned item as another "get next" request. It cannot send thousands of requests when the device does not return thousands of replies!

There are plenty problems with MikroTik SNMP, like OID values not monotonically increasing. THAT causes problems with snmpwalk. But not the rate of requests.

A snmpwalk can make thousands of requests, if too many are "pending" you'd get errors like

How???
snmpwalk does not blindly send a large number of requests!

Didn't mean to imply it's blindly sending thousands at one time. More I've just seem some SNMP device where the SNMP on the other end is still processing the last request when another walk request comes in & Dude's snmpwalk will make the next request after the timeout (but the device is still processing previous ones)...

To clarify my recommendation is to try using "subtree" in Dude's snmpwalk tool and pick just the Cambrian subtree to see if the errors go away.

As I explained, that cannot happen. "the next request" depends on the results from the current request, so a next request can never be sent before the results are returned. There is never more than one pending request.
Now what can happen is that SNMP requests are processed by a slow processor that also should perform other tasks, and working only on SNMP handling can starve other device functions. Not so likely in a device running Linux (such as a MikroTik router).

I get the same error if I increase polling time or just select the Cambium subtree to scan.

It is not the device as I can SNMP walk other MIB files for this device like the old Canopy MIB or the RFC MIBs it just gives this error when trying to scan the ePMP Cambium Mib file.

I was able to walk the device using a third party SNMP browser (FramFlow SNMPBrowser) and the ePMP 4500L device walked fine using the Cambium MIB. It must be an issue on Mikrotik's side I guess.

I will open a ticket with them and see if they can explain what gen err (6) means.

Lost time: The Dude is not under development & Cambium is not one MikroTik product...

Lost time: The Dude is not under development & Cambium is not one MikroTik product...

OP can still file a bug... Maybe with a sufficient number of requests, they'll actually update the Dude

Dude's smnpwalk should not care about the vendor, SNMP is a standard & if another tool is reading the Cambium SNMP data, Dude, theoretically, should too. But yeah the reality is Dude's snmpwalk does seem to be "flaky" with some devices IMO & and I won't put a lot of hope in Mikrotik fixing it anytime soon .

While The Dude's snmpwalk is kinda useful to quickly create a probe from an OID... you can workaround this by cut-and-pasting the needed OID into a new probe manually.

Note that snmpwalk is NOT related to an MIB. It does not use the MIB to know where to walk. That information is exchanged with the device itself, you only provide a starting point and the MIB may help you to choose it (by mapping a name to a numeric value).

I might have found my problem. I have two mib folders in The Dude and under one of them is an old Canopy MIB file that I think is conflicting with the Cambium MIB file. However, I cannot delete anything from that folder as when I try to remove the Canopy MIB file I get and -action failed (6) error.

How can I remove that file or remove all the files under that folder.

One folder is /dude/files/default/mibs (I cannot add or remove anything from this folder). The other mib folder is /dude/files/mibs (I can add and remove files from this folder.

It looks like the Canopy MIB file that appears to be conflicting with the ePMP mib file cannot be deleted as it is part of the default Dude installation.

What is happening is The Dude is reading from the Canopy-SYS-MIB file first before trying the Cambium-PMP80211-MIB file and before it finishes the Canopy MIB it errors out. If I could removed the Canopy-SYS-MIB file or have it scan the Cambium MIB file first it would work properly.

Why Mikrotik made the Canopy-SYS-MIB file part of the default install and unable to be deleted or disabled is beyond me.

See this post. https://community.cambiumnetworks.com/t ... bs/40174/6

Basically the issue is the Canopy-SYS-MIB file. On the older Dude that ran as a windows application you could delete the file. However, it seems since the dude server is now a ROS package it automatically creates the file and you cannot delete it, so I can never get The Dude to properly SNMP scan ePMP devices.