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 <[email protected]>
> # 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="[email protected]" \
> --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
> [email protected]
> 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
[email protected]
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.