Hi Dave,
   I think I spoke too soon without testing with other snmptools. The
snmpd (from net-snmp) as well as our proprietary "trapd" gets the
response for INFORM from the other hand only if the remote end uses
the source-port of 162 like snmptrapd does.

We tried with other snmptools ("Unbrowse Snmp" for example) which only
guarantees that the udp dest port is the same as the udp orig port in
the INFORM request. The products use ports like 1048 as udp source
port and even snmpd does not get the response to INFORM messages
coming from the other end.

  Would like to know whether this is the expected behavior and whether
you have any suggestions for the issue.

Thanks,
Fatima

On Mon, Feb 22, 2010 at 2:27 AM, Dave Shield <[email protected]> wrote:
> On 20 February 2010 19:20, Fatima Peter <[email protected]> wrote:
>>
>> The problem happens with sending "inform" messages as the INFORM  response
>> comes to snmpd and not to our "trapd" process.
>
> How are you generating the INFORM requests?
> Do you use the agent 'snmp_trap_api(3)' calls, or are you
> constructing and sending the notification yourself?
>
>
>>                                          One idea was to use
>> what "snmptrap" was doing but we cannot wait for timeout period in our
>> daemon(like snmptrap does) as we need to process alerts at the rate of
>> 10 per seconds.
>
> It might be worth looking at an asynchronous approach.
> I.e. using "snmp_sess_async_send()"
>   That would allow you to send multiple notifications without
> having to wait for the acknowledgement for each one.
>
> There's a simple tutorial for coding asynchronous applications
> on the project website (under the 'Tutorials' section).  That should
> get you started
>
> Dave
>

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Net-snmp-coders mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Reply via email to