Bad trap packet received from Node with IP X.X.X.X. Error description : No more data.

Sounds like it's sending traps to solarwinds, but SWinds doesn't know what to do with it because you don't have it set as a node.

If you check your trap viewer, or trap history in the DB, you might be able to find the OID or MIB this is coming from and set up rules on how to process it. That might help(?).

We are getting the same error message with our Dell Sonicwall TZ-215, & 2600 series.  We are have no issues with getting the device to connect and report data to our Solarwinds Server.  However we are getting this error from all of our Sonicwalls. 

here is example of the Trap Message Error that we are recieving:

Sorry for the late reply. The issue we were having happened to be originating from the host machine "Dell Kace 1000". It scanned subnets looking for new machines every 3 hours and it was not playing nice with solarwinds. We had to disable our Solarwinds management IP from being included in the scan.

I am not familiar with the Sonicwall but seeing as how its a Dell box, it may have a similar discovery method being used. If you have not figured out the problem by now, check to see if it is doing any sort of host/subnet discovery.

Although it is very likely you've already solved your problem, one of the other reasons SolarWinds may react this way is a conflict between configured SNMP versions.

For instance, if the node is configured for SNMPv2 and SNMPv3, and you're only polling in SolarWinds for SNMPv2, the SNMPv3 messages will be considered a bad packet.

HTH!

ahutch43​ & I work for the same company.  I have been dealing with SolarWinds and Dell SonicWALL support on the matter over the past weeks.  We have done multiple packet captures and have given the information to Dell SonicWALL Support.   Dell SonicWALL engineer is working with their escalation team.  The data stream being sent to the SonicWALL has no real data in it and it seems to be appearing about every hour.  We are not sure if something else with the SonicWALL is doing this matter or not.   It has no MIB data tied to it.

We have found a way to stop the messages temporarily is to remove the NPM server in the Dell SonicWALL SNMP host field to get it to stop.   This is just temporary as it will not send any trap packets to NPM.

More to come!

Update on this issue.  I have been working with SonicWALL engineers and development team on this matter.    I believe there is a resolution coming soon if you are running Gen6 (6.2.5) code or higher.  They are to be providing me hotfix soon to correct the problem.   It did not matter if it was SolarWinds or just sending the data raw to a IP address, it would send it randomly around an hour time interval.

This problem has been resolved by SonicWALL on my case.   They are putting the hot fix is 6.2.6.2 release that is coming out for new TZ units and current NSA models.   The trap messages have stopped being invalid to the SolarWinds server and we are back to normalcy now.

I'm also getting the same error and using an NSA3600, but the latest firmware version in the download center is 6.2.6.1 - was this a special hotfix by request only?  I could open a ticket, but wanted to ask.  Thanks so much for your post, this is an annoying event error

Have you checked the full post below ?

When you say "That server is not being monitored specifically by NPM " do you mean the server is not been added as node in the Orion and you are still sending the Traps ?

Bad trap packet received from Node with IP XX.XX.XX.XX. Error description : Unknown user and engine. Packet discarded

ISSUE # 2.

You will  noticed that the IP address in the error message was actually assigned to an interfaces on the routers and that the traps were being sent from this  interfaces.

Since the SNMPv3 credentials are used by the router and not the interfaces you then  needed to find a way to source all traps from the router's Loopback address themselves.

RESOLUTION

The easiest way to do this was to enter the following line within the SNMP portion of the router configuration.

"snmp-server trap-source Loopbackxxxx" Where xxxx is the loopback # that the router's IP address is assigned to.