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
