How can I find and delete these IDB tables?
{gateway}/main/web/status/sys.internaldb
-
Uninstall
0.1.0. -
Drop all the tables that start with
EMBRSNMP:
EmbrSnmpV1DeviceSettingsEmbrSnmpV2cDeviceSettingsEmbrSnmpV3DeviceSettings
-
Delete all corresponding rows in the
DeviceSettingstable -
Install
0.2.0.
1 Like
Go to your > Status > Overview page.
<up><up><down><down><left><right><left><right><B><A>
6 Likes
I tried two device connection with 0.2.0. Devices are connected and tags are good.
Just some minor things.
Normally they resolve after a gateway reboot, if they don't, its definitely a bug.
2 Likes
Reboot helped. Thanks.
1 Like
That's actually one of the bugs that caused 8.3 to remove the hot-loading of modules.
I haven’t included the prefix and it worked. Are they mandatory?
If no transport is provided, the default is UDP.
Will it ever be possible to browse the OIDs? 
There is talk of setting up SNMP Walk functionality for browsing in the tag browser.
Yes, but don’t hold your breath.
It’s something I’d like to add, but I don’t have a personal use case for it so it’s low priority.
I say ”yes” though because I think it’ll be a side effect of wanting better table/write support. For proper table/write support we’ll need to build and track an internal model of the agent’s OID namespace, and at that point we might as well support browsing.
Was playing with this on my home lab with v8.3 reading SNMP v2c to a Cisco Catalyst 3750X-48P and in testing I was reading a few ports data, but then decided to add all 48 ports and that's where I hit the following error and now no data from that switch will update with that many ports attempting to read:
GET failed with errorStatusText: PDU encoding too big
I'm pulling in a mix of strings (port name, description/alias), counters (64-bit), and integers.
Got it.
The module currently creates requests with the largest size possible that fit within the SNMP agent's maxSizeRequestPDU. However, this doesn't do anything to check if the response from the client is going to remain within reasonable size bounds.
In the meantime, try splitting your tags across tag groups with different update rates.
This will force them into separate requests.
EDIT: Currently, this error is probably more likely to popup when reading strings (just because the string response is much larger than than GET request).
2 Likes
Here's an untested fix, if you're up for trying:
Doesn't seem to improve anything. I wasn't able to do a direct upgrade of the module either. After restarting the gateway the old module would still load, so I had to uninstall it, restart the gateway, then install the new module and restart the gateway again.
Probably doesn't help that everything is multiplied by 48 ports. If I enable any one of those (strings are read at 2 minutes currently, and I've got the RxBytes and TxBytes set to unique rates not shared by anything else (1001ms and 1002ms).
1 Like
Yeah, it's a known issue 
1 Like