Hmmm... I decided to try this myself since I'm also running Fedora Core 2. I'm seeing the same results.
I ran configure make make install
I configured two trap2sink targets, one to localhost and the other to a remote system. When I start and stop snmpd, the trap is delivered locally but tcpdump does not show any traffic leaving the box. If I send the trap using the snmptrap command to the same target, tcpdump does see it.
Darren Gamble wrote:
Good day,
Thank you very much for your reply. Comments are inline.
Did a previous version of Net-SNMP work on this same system and
stop working when you upgraded to 5.2, or is this a whole new system
(or one where you upgraded the OS and Net-SNMP at the same time)?
This is an upgrade from 5.1 . I am testing this on my workstation machine before deploying it. My workstation is configured very similarly as the servers are.
When you say "mostly works" does that mean most traps get to their
intended destinations, but only the coldStart and what you are calling
a "cold stop" are missing? Or do you mean traps in general don't reach
their destinations?
By "mostly works", I meant, "The SNMP agent looks like it's returning right values for CPU, disk, processes, and so on, but it doesn't send a coldstart trap when I turn it on, instead producing the error message.".
Sounds like it could be a network problem, so...
Do you have multiple interfaces (eth0, eth1, ...) so the trap
could be routed out the wrong interface?
Nope, one interface, plus loopback. I posted an ifconfig -a earlier this morning.
Do you have any net filtering software running on your box or
between you and the trap destination that could be preventing
delivery?
No, no firewall. tcpwrappers is configured for incoming packets to the snmp agent. I did take out the ALL: ALL line in hosts.deny just in case, to no effect.
Have you run tcpdump on the system running the agent to see
if the traps are being sent?
Yep, I did that before posting. No trap packets are put on the wire for either eth0 or lo. Unless I use the loopback address for the destination... then a capture sees the packet go over loopback.
Have you inspected debug logs from the agent?
Sure. Here's the relevant portion. There's not much that's useful there (to me), other than knowing that it processed the config file properly. The machine in question there is reachable, FWIW.
dumpv_send: Integer: 1 (0x01) trace: _snmp_build(): snmp_api.c, 2924: dumph_send: SNMPv2c Message trace: netsnmp_udp_send(): snmpUDPDomain.c, 167: netsnmp_udp: send 96 bytes from 0x8124160 to UDP: [10.0.78.10]:162 on fd 11 snmpd: send_trap: Failure in sendto (Invalid argument) trace: snmp_call_callbacks(): callback.c, 231: callback: END calling callbacks for maj=1 min=7 (1 called) NET-SNMP version 5.2 trace: main(): snmpd.c, 990: snmpd/main: We're up. Starting to process data. trace: snmp_sess_select_info(): snmp_api.c, 5702: sess_select: for all sessions: 12 11 8 6 sess_select: next alarm -16784420.1170828724 sec sess_select: blocking:no session requests or alarms. trace: receive(): snmpd.c, 1115: snmpd/select: select( numfds=13, ..., tvp=(nil))
Is there anything else that I can do here? I can try looking at the code, although C socket code is not my strong suit...
Thanks,
============================
Darren Gamble
Planner, Regional Services
Shaw Cablesystems GP
630 - 3rd Avenue SW
Calgary, Alberta, Canada
T2P 4L4
(403) 781-4948
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/
_______________________________________________
Net-snmp-users mailing list
[EMAIL PROTECTED]
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users
