Howdy- I've recently built scli (looks to be an excellent tool), but it is not functioning for me. Specifically, it does not appear to be actually communicating with the requested devices. Here are the details:
- scli version 0.2.5 - compiled on/tried with Solaris 2.6 and 8 - attempting to communicate with several Cisco devices (Cat 5000, 5500, 7507) and an HP printer (8000DN) for good measure - can communicate with same devices, using same community string, via the NET-SNMP utilities - build appeared to complete just fine (use the following configure command string):
CFLAGS="-I/arch/gnu/include" LDFLAGS="-R/arch/Xapps/packages/gnome-1.2/lib -L/arch/gnu/lib -R/arch/gnu/lib" ./configure --prefix=/arch/adm/packages/scli-0.2.5 --with-glib-prefix=/arch/Xapps/packages/gnome-1.2 --with-xml-prefix=/arch/unix/packages/libxml2-2.4.6
Example scli session:
scli version 0.2.5 (c) 2001 Juergen Schoenwaelder scli > set scli debugging .* scli > open trillian <ourcorrectreadcommunitystring> session 10b4f8: new Trying SNMPv2c ... session 10b4f8: g_sync_getnext pdu 1037c0 session 10b4f8: g_sync_send failed to send PDU good! (trillian) scli > show system info session 10b4f8: g_sync_getnext pdu 1037c0 session 10b4f8: g_sync_send failed to send PDU session 10b4f8: g_sync_getnext pdu 1037c8 session 10b4f8: g_sync_send failed to send PDU session 10b4f8: g_sync_getnext pdu 1037d0 session 10b4f8: g_sync_send failed to send PDU session 10b4f8: g_sync_getnext pdu 1037d0 session 10b4f8: g_sync_send failed to send PDU session 10b4f8: g_sync_getnext pdu 1037d0 session 10b4f8: g_sync_send failed to send PDU session 10c020: g_async_getnext pdu 1037e0
(hang for a very long time, perhaps forever?)
example session to same device with NET-SNMP:
(note SNMP2c forced just to try and stay consistent w/scli's autodiscovery of the protocol)
% snmpget -v 2c trillian <ourcorrectreadcommunitystring> sysDescr.0 system.sysDescr.0 = Cisco Systems WS-C5000 Cisco Catalyst Operating System Software, Version 4.5(12) Copyright (c) 1995-2001 by Cisco Systems
A truss of the process while it appears to hang:
% truss -p 17097 poll(0x000FF708, 2, 1000) = 0 time() = 1008630430 poll(0x000FF708, 2, 1000) = 0 poll(0x000FF708, 2, 0) = 0 time() = 1008630431 poll(0x000FF708, 2, 1000) = 0 time() = 1008630432 poll(0x000FF708, 2, 1000) = 0 time() = 1008630433 poll(0x000FF708, 2, 999) = 0 time() = 1008630434 poll(0x000FF708, 2, 1000) = 0 poll(0x000FF708, 2, 4) = 0 time() = 1008630435 poll(0x000FF708, 2, 1000) = 0 time() = 1008630436 poll(0x000FF708, 2, 1000) = 0 poll(0x000FF708, 2, 0) = 0 time() = 1008630437 ...
On the querying machine, tcpdump (tcpdump -x dst trillian) does not see any traffic destined for the target agent.
My guess is that scli is waiting for an answer to a question it never asked.
Any other data I can provide that might help debug this situation?
Thanks again for all of your hard work on this tool.
Respectfully, David N. Blank-Edelman Director of Technology College of Computer Science Northeastern University
-- !! This message is brought to you via the `scli' mailing list. !! Please do not reply to this message to unsubscribe. To subscribe or !! unsubscribe, send a mail message to scli-request@ibr.cs.tu-bs.de. !! See http://www.ibr.cs.tu-bs.de/projects/scli/ for more information.