Turned out to be vacm related. Thanks!
D. > Update: it IS parsing the packets. It just isn't sending anything. > > sess_process_packet: session 0x229d58 fd 8 pkt 0x27bc90 length 48 > > Received 48 byte packet from UDP: [172.17.6.74]:44104->[172.17.4.3]:1161 > 0000: 30 2E 02 01 01 04 0B 72 6F 63 6F 6D 6D 75 6E 69 > 0......rocommuni > 0016: 74 79 A0 1C 02 04 1E 47 30 E9 02 01 00 02 01 00 > ty.....G0....... > 0032: 30 0E 30 0C 06 08 2B 06 01 02 01 01 03 00 05 00 > 0.0...+......... > > Received SNMP packet(s) from UDP: [172.17.6.74]:44104->[172.17.4.3]:1161 > snmp_api: Parsing SNMPv2 message... > sess_process_packet: received message id#0 reqid#507982057 len 48 > GET message > -- SNMPv2-MIB::sysUpTime.0 > > This has to turn out to be something silly or network related. > > D. > > >> >> >> Hi, >> >> I am trying to get snmpd running on an ARM (cross compile config >> below) chip and consistently see the snmpd daemon "give up" and >> not process the packet. The behavior is consistent across all >> transports >> (including UNIX) and from both the local machine and a remote linux >> client >> (udp and tcp). >> >> Below the most recent client, agent, .conf and configure info, the >> latter >> which I got from a previously posted question on building for ARM. I've >> read the FAQ (how else could I get the debug strings?!) and I've looked >> through the code myself and nothing jumps out at me. >> >> Everything seems to be working, loading, it just doesn't process the >> packets. The only possibly relevant clue is that while the >> "sess_process_package" reqid seems right, the message id is always 0. >> But >> that may just be because the server will assign it. what look like >> loopback tests fill up the log when I specify -DALL. >> >> I've been hitting my head against this for two days now. I hope it's >> painfully obvious. >> >> Thanks for a great package and thanks for your help! >> >> Dave >> >> >> CLIENT COMMAND: >> >> ./snmpwalk -M /root/mibs -c rocommunity -v 2c -r 0 -d localhost -DALL >> >> Note: I have tried many possible variations on that command, including >> -u >> test, -v 1, protected and public ports, etc. >> >> [snip snip] >> >> sess_process_packet: sending message id#2039961885 reqid#467162415 len >> 45 >> transport:send: 45 bytes to UDP: [127.0.0.1]:161->[0.0.0.0]:0 >> >> Sending 45 bytes to UDP: [127.0.0.1]:161->[0.0.0.0]:0 >> 0000: 30 2B 02 01 00 04 0B 72 6F 63 6F 6D 6D 75 6E 69 >> 0+.....rocommuni >> 0016: 74 79 A1 19 02 04 1B D8 55 2F 02 01 00 02 01 00 >> ty......U/...... >> 0032: 30 0B 30 09 06 05 2B 06 01 02 01 05 00 >> 0.0...+...... >> >> trace: netsnmp_udpbase_send(): transports/snmpUDPBaseDomain.c, 330: >> netsnmp_udp: send 45 bytes from 0xe966b to UDP: >> [127.0.0.1]:161->[0.0.0.0]:0 on fd 3 >> trace: snmp_sess_select_info2_flags(): snmp_api.c, 6325: >> sess_select: for all sessions: 3 (to in 946686840.542523 sec) >> verbose:sess_select: timer due in 0.999476 sec >> verbose:sess_select: setting timer to 0.999476 sec, clear block (was 1) >> trace: snmp_synch_input(): snmp_client.c, 176: >> snmp_synch: Response (ReqID: 467162415 - Cmd 161) >> Timeout: No Response from localhost >> >> AGENT: >> >> Invocation: >> >> ./snmpd -M /root/mibs -f -Lf ./snmpd.log -c snmpd.test.conf >> -Dsnmpd,transport_callback,sess_read,sess_process_packet,sess_select,ip_interface,recv,snmp_api,snmp_parse >> & >> >> Logging of (non)event: >> >> snmpd/select: returned, count = 1 >> sess_process_packet: session 0x241570 fd 8 pkt 0x27bfc8 length 45 >> snmp_api: Parsing SNMPv2 message... >> sess_process_packet: received message id#0 reqid#1592707923 len 45 >> sess_read: not reading 6 (fdset 0xbec7ca68 set 0) >> sess_read: not reading 7 (fdset 0xbec7ca68 set 0) >> sess_read: not reading 4 (fdset 0xbec7ca68 set 0) >> sess_select: for all sessions: 8 6 7 4 >> sess_select: next alarm at 946687334.544205 sec >> snmpd/select: select( numfds=9, ..., tvp=0xbec7cb70) >> snmpd/select: returned, count = 0 >> sess_select: for all sessions: 8 6 7 4 >> ... >> >> AGENT CONFIG: >> >> I have also tested with -rocommunity "test default" (or whatever). >> >> # egrep -v '^\w*#|^\w*$' snmpd.test.conf >> agentAddress udp:1161 >> rocommunity public >> sysLocation Ninth Circle of Hell >> sysContact Dave <d...@powerstandards.com> >> # Application + >> End-to-End layers >> sysServices 72 >> # At least one 'mountd' process >> proc stunnel >> proc /usr/sbin/dropbear >> # 10MBs required on root disk, 5% free on >> /var, 10% free on all other disks >> disk / 10000 >> disk /var 5% >> includeAllDisks 10% >> # Unacceptable 1-, 5-, and 15-minute load >> averages >> load 12 10 5 >> >> CONFIGURE: >> >> This has been attempted with innumerable options, including "endianess" >> (tried both) and various versions of the "host, build and target" >> options, >> and even "re-entrant". This is the configuration that printed out the >> log >> messages above, as they all seem to. >> >> ./configure --enable-mini-agent \ >> --with-mib-modules="mibII ucd_snmp" \ >> --enable-static --disable-shared \ >> --prefix=`pwd`/install --exec_prefix=`pwd`/install-arm \ >> --host=arm-none-linux-gnueabi --target=arm-none-linux-gnueabi >> --build=i686-linux \ >> --with-cc=arm-none-linux-gnueabi-gcc \ >> --with-linkcc=arm-none-linux-gnueabi-gcc \ >> --with-ld=arm-none-linux-gnueabi-ld \ >> --with-ar=arm-none-linux-gnueabi-ar \ >> --with-sys-contact="d...@powerstandards.com" \ >> --with-sys-location="ip-psl" --with-default-snmp-version="2" \ >> --with-logfile="/var/log/snmpd.log" \ >> --with-persistent-directory="/var/net-snmp" \ >> --without-rpm --disable-embedded-perl --disable-deprecated >> --disable-manuals --disable-ipv6 >> >> >> >> >> ------------------------------------------------------------------------------ >> Better than sec? Nothing is better than sec when it comes to >> monitoring Big Data applications. Try Boundary one-second >> resolution app monitoring today. Free. >> http://p.sf.net/sfu/Boundary-dev2dev >> _______________________________________________ >> Net-snmp-users mailing list >> Net-snmp-users@lists.sourceforge.net >> Please see the following page to unsubscribe or change other options: >> https://lists.sourceforge.net/lists/listinfo/net-snmp-users >> > > > ------------------------------------------------------------------------------ Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev _______________________________________________ Net-snmp-users mailing list Net-snmp-users@lists.sourceforge.net Please see the following page to unsubscribe or change other options: https://lists.sourceforge.net/lists/listinfo/net-snmp-users
