I’m running a SNMP application on ConnectCore 9P9215 with NET+OS 7.4.2.
This application send SNMP V2 traps to a destination. While the application is running I’m changing the IP address for trap destination.
First, I create the new trap using “naSnmpAddTrap”; the return of this function give me NA_SUCCESS.
Then I call “naSnmpDeleteTrap” with the old NaSnmpTrap_t structure. Return of this function is NA_SUCCESS.
However, the new IP address destination receive properly the traps, but the old IP address destination keep receiveing the traps too.
It seems “naSnmpDeleteTrap” doesn’t delete the old trap.
I hesitate to ask this but are you sure the order of operations that you describe in the entry IS the order in which you performed the delete and the add. That is add a new one and then delete an old one. Why do I ask? The API reference guide states that if you are down to the last entry in the list of trap sinks, you will not be allowed to delete the last entry.
Yes, I do add the new trap first and then delete the old trap. I’ve done in reference of the API reference guide stating you can’t delete the trap entry if it is the only one in the pool. (as you mention).
In fact, I’ve got only one trap entry when the application is running. When I want to change the IP address of this entry, I create the new trap entry. At this moment, I’ve got 2 trap entries in the pool. Then I delete the old one, and should come back to 1 entry in the pool.
I’ve noticed I can do this operation only 4 times. That make me think the “naSnmpDeleteTrap” function doesn’t delete the trap entry. After 4 times, I would have 5 entries in the pool. This matches the size of the pool.
If possible please provide me with either (or both) the community name you are using in the traps or the length in bytes of said community name (realizing that a community name can be used as a weak password).
Now before I ask my next question, I want to preface it by stating that I do not want to see your entire application. What I would like to see is the code that creates your initial trap entry and your code that attempts to delete said entry. And maybe code that attempts to create additional trap entries. But again, please do NOT send me your entire application. Only send the snippet of code that interacts with naSnmpAddTrap and naSnmpDeleteTrap.
I checked with Digi support. The documentation is a little misleading.
That first trap entry that you add using naSnmpAddTrap BEFORE starting the agent is not deletable or modifiable. That is probably why you are having the trouble you have been. Any entries you add after the agent is started, you can add/delete. So you can not do what you want to do, which is add an entry before the agent is up, and then change that entry’s ip address by creating a second entry and deleting the first entry. That first entry can not be deleted.
Thanks for your clarification. I’ve added a dummy trap entry before to start the SNMP server, and then added the real trap once the SNMP server has started.
Then this second trap is modified as it uses to be. (such as in SNMP trap delete sample).
It does resolve the issue of changing the trap only 4 times. I can now change the trap settings as many times as I want.
But I’ve got the following behaviour:
My computer receiving the traps has an IP address 10.1.0.11.
If the application starts with the trap destination 10.1.0.11, my computer receives the traps. Then I change the trap destination to 10.1.0.12 (without restarting the application), my computer doesn’t receive the traps anymore. Normal. But then, I change back the trap destination to 10.1.0.11, and my computer is still not receiving the traps. Not normal.
If the application starts with the trap destination 10.1.0.12, my computer doesn’t receive the traps. Then I change the trap destination to 10.1.0.11 (without restarting the application), my computer receives the traps. Normal. But then, I change back the trap destination to 10.1.0.12, and my computer is still receiving the traps. Not normal.
Moreover, I understood the first trap entry created before the SNMP starts, is the one used for authentication failure and cold start. Does it mean others trap entry are not used for authentication failure?
For the time being, I’m going to do an automatic reset when the trap destination is changed. That should temporally resolve the problem.
I tested using an authentication callback. I changed trap entries within the callback. In all cases I got authentication traps being sent to any of the sinks that I set within the authentication callback. So I can’t explain why you are not seeing such traps. The only reason I could possibly come up with to explain such behavior would be it the sink machine to which you have set up a trap entry is not available (not pingable from the subnet where the device resides) then the agent would try to send out a trap, would arp that machine, get no answer and not send out a trap.
Are you checking for traps using some protocol analyzer software (etherpeek or wireshark for example). If not how are you checking for traps being sent out?
You re right. Authentication failure traps are properly sent to my IP destination.
I couldn’t see them during the test as the trap destination has been changed. I was having the problem described in my previous post.
Right now, traps are working fine with the automatic reset.