RS> That should be fairly reliable. I think it would be a fairly extreme
RS> condition where a trap would be lost. Mainly, you'd have to make
sure
RS> your application read the traps fast enough, so that the buffer
doesn't
RS> get full. You would definitely want to look into the new socket
buffe
On Wed, 09 Mar 2005 12:25:01 -0500 Olsson, wrote:
OS> RS> I'm also unclear on whether or not using tcp would create/tear-down a
OS> RS> connection for each trap, or establish the connection once.
OS>
OS> Ok, I implemented a SNMP trap receiver (minimal version of snmptrapd)
OS> and found that the
RS> That is a good question. I know udp will work. You'd have to test
RS> TCP (and make sure tcp was enabled in the agent at configure time).
RS> I'm also unclear on whether or not using tcp would create/tear-down
a
RS> connection for each trap, or establish the connection once. You'd
have
RS> to
On Fri, 2005-02-25 at 15:56, Olsson, Sten wrote:
> I assume you can specify the protocol to use too? TCP/UDP?
Yes.
The destination is specified using the usual
protocol:host:port
syntax, so has the same range
of valid destination addresses.
> I think what it
On Fri, 25 Feb 2005 10:56:23 -0500 Olsson, wrote:
OS> RS> Bad news. While trying to figure out better names for the tokens, I
OS> RS> Realized that there is already a 'forward' token for forwarding traps.
OS> RS> This already allows specifying an IP address and a port. The big
OS> RS> difference
OS> One last thing. Since the address and port of the trap publisher
will
OS> need to be configurable (snmpd.conf, etc...)
RS> Bad news. While trying to figure out better names for the tokens, I
RS> Realized that there is already a 'forward' token for forwarding
traps.
RS> This already allows s
On Fri, 2005-02-25 at 15:21, Robert Story wrote:
> Bad news. While trying to figure out better names for the tokens, I realized
> that there is already a 'forward' token for forwarding traps. This already
> allows specifying an IP address and a port. The big difference between it and
> your scheme
On Wed, 23 Feb 2005 14:35:31 -0500 Olsson, wrote:
OS> RS> Another good idea. My only question is, how is it published? As a PDU?
OS> RS> the formatted text string?
OS>
OS> It publishes a PDU (netsnmp_pdu) that has been packed into a byte stream
OS> and then can be unpacked on the other end.
On T
On Thu, 24 Feb 2005 16:02:29 -0500 Olsson, wrote:
OS> RS> Also, you changed the priority such that external events are
OS> RS> handled before snmp events. The order shouldn't change.
OS>
OS> The reason I did this is because snmp_read() didn't return the count of
OS> events left to be processed.
On Wed, 23 Feb 2005 14:35:31 -0500 Olsson, wrote:
OS> RS> Good idea. I only see a few minor changes, but I don't see why this
OS> RS> couldn't make it into 5.3.
OS> Cool. If you let me know I can make the changes and resubmit the patch.
Let's see..
- fd_event_manager -> external_fd_manager
- ne
RS> Let's see..
RS> - fd_event_manager -> external_fd_manager
RS> - netsnmp_external_event_info -> netsnmp_external_fd_info
RS> - netsnmp_dispatch_external_events -> netsnmp_external_fd_read
OK, cool. Thanks.
RS> Also, you changed the priority such that external events are
RS> handled before sn
On Wed, 23 Feb 2005 14:35:31 -0500 Olsson, wrote:
OS> RS> Another good idea. My only question is, how is it published? As a PDU?
OS> RS> the formatted text string?
OS>
OS> It publishes a PDU (netsnmp_pdu) that has been packed into a byte stream
OS> and then can be unpacked on the other end. I su
OS> should be left alone. I mostly packed and unpacked everything in
the
OS> netsnmp_pdu struct. Through trial and error (and memory leaks) I
found
OS> that some data was not really owned by the pdu, and didn't need to
be
OS> packed/unpacked.
RS> What did you end up leaving out?
Pointers to f
OS> This function previously existed for snmpd, but was
OS> coded right in snmpd.c and agent_registry.c. This
OS> change, moves these changes to a new unit called
OS> fd_event_manager.c which can then be used in other
OS> places (snmptrapd).
RS> Good idea. I only see a few minor changes, but I
On Tue, 22 Feb 2005 17:38:16 -0500 Olsson, wrote:
OS> This patch allows the user to register for activity on
OS> external (non-SNMP) file descriptors and have callbacks
OS> called in snmpd and snmptrapd applications.
OS>
OS> This function previously existed for snmpd, but was
OS> coded right in
About two years ago I modified some net-snmp code for my
Project and am now finally able to post this patch.
I have another patch that depends on this one that I will
post next. Comments are appreciated. Actual patch is
submitted to sourceforge tracker->patches.
Patch is for clean-cvs-V5-2-pat
16 matches
Mail list logo
