Re-sending, I'd forgotten about the changed posting policy. -- I'm having troubles getting net/net-snmp working on 5.2-RELEASE -- I've tried both 5.1 and 5.0.9, and both are exhibiting the same behaviour. This is with 5.0.9 (communities changed to protect the innocent): newhost# snmpd -d -D -f -L newhost# Sending 45 bytes to 10.10.10.2 0000: 30 2B 02 01 00 04 06 70 75 62 6C 69 63 A4 1E 06 0+.....public... 0016: 0B 2B 06 01 04 01 BF 08 03 02 81 7F 40 04 40 07 .+.........._at_._at_. 0032: 99 1B 02 01 00 02 01 00 43 01 04 30 00 ........C..0. NET-SNMP version 5.0.9 Received 64 bytes from 10.10.11.2 0000: 30 3E 02 01 00 04 07 70 75 62 6C 69 63 20 A0 30 0>.....public..0 0016: 02 04 82 C7 18 D1 02 01 00 02 01 00 30 22 30 0F ............0"0. 0032: 06 0B 2B 06 01 04 01 8F 65 0A 01 05 01 05 00 30 ..+.....e......0 0048: 0F 06 0B 2B 06 01 04 01 8F 65 0A 01 05 02 05 00 ...+.....e...... newhost# The debugging output of 5.1 is much, much more verbose, but still exhibits the same quit-without-error-nor-coredump behaviour. The querying host doesn't ever get any response. (Flag order seems to be important -- this one actually /did/ fork from the shell.) And a similar run from 5.1: newhost# snmpd -d -DALL -Lo -f <snip very verbose debugging> dumph_send: SNMPv1 Message Sending 46 bytes to 10.10.10.2 0000: 30 2C 02 01 00 04 06 70 75 62 6C 69 63 A4 1F 06 0,.....public... 0016: 0B 2B 06 01 04 01 BF 08 03 02 81 7F 40 04 00 00 .+.........._at_... 0032: 00 00 02 01 00 02 01 00 43 02 00 96 30 00 ........C...0. trace: netsnmp_udp_send(): snmpUDPDomain.c, 150: netsnmp_udp: send 46 bytes from 0x80e87d2 to 10.10.10.2 on fd 11 trace: snmp_call_callbacks(): callback.c, 131: callback: END calling callbacks for maj=1 min=6 (1 called) trace: snmp_call_callbacks(): callback.c, 111: callback: START calling callbacks for maj=1 min=7 trace: snmp_call_callbacks(): callback.c, 119: callback: calling a callback for maj=1 min=7 trace: send_notifications(): notification/snmpNotifyTable.c, 95: send_notifications: starting: pdu=805a900, vars=80e7000 trace: get_target_sessions(): target/target.c, 32: target_sessions: looking for: internal0 trace: get_target_sessions(): target/target.c, 36: target_sessions: for: 0=internal0 trace: get_target_sessions(): target/target.c, 75: target_sessions: found one: internal0 trace: snmp_call_callbacks(): callback.c, 131: callback: END calling callbacks for maj=1 min=7 (1 called) NET-SNMP version 5.1 trace: main(): snmpd.c, 963: snmpd/main: We're up. Starting to process data. trace: snmp_sess_select_info(): snmp_api.c, 5570: sess_select: for all sessions: 12 11 8 6 trace: receive(): snmpd.c, 1100: snmpd/select: select( numfds=13, ..., tvp=0x0) trace: receive(): snmpd.c, 1102: snmpd/select: returned, count = 1 trace: netsnmp_udp_recv(): snmpUDPDomain.c, 117: netsnmp_udp: recvfrom fd 12 got 64 bytes (from 10.10.11.2) trace: _sess_process_packet(): snmp_api.c, 4840: sess_process_packet: session 0x813e0f0 fd 12 pkt 0x8143000 length 64 Received 64 bytes from 10.10.11.2 0000: 30 3E 02 01 00 04 07 70 75 62 6C 69 63 20 A0 30 0>.....public..0 0016: 02 04 1A F2 D6 02 02 01 00 02 01 00 30 22 30 0F ............0"0. 0032: 06 0B 2B 06 01 04 01 8F 65 0A 01 05 01 05 00 30 ..+.....e......0 0048: 0F 06 0B 2B 06 01 04 01 8F 65 0A 01 05 02 05 00 ...+.....e...... newhost# Any pointers or suggestions? - DamianReceived on Thu Jan 15 2004 - 09:49:35 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:38 UTC