On 30 April 2010 11:07, Bart Van Assche <bvanass...@acm.org> wrote:
>> > The 5.4.3rc2 Cygwin IPv6 build was broken but has been fixed via r18607.
>> > Regression tests do not yet pass though -- see also
>> >
>> > https://sourceforge.net/tracker/?func=detail&aid=2993522&group_id=12694&atid=112694.
I've now had a chance to look at your logs, as well as running my own tests.
The results I'm seeing aren't quite as bad as yours - there are only five
tests that fail (#s 19, 35, 45, 46 & 58)
Checking the output, there seem to be two separate problems:
a) Test 19 (T030) works fine until the agent is signalled with HUP to
reload the configuration. The query that follows then fails.
This is the first test that signals such a reload.
This also appears to underly my failure for test 35
(but the logs from the tracker entry show a different problem)
b) All tests attempt to use the utility function PROBE_FOR_PORT
to identify suitable, unused port numbers for the various servers.
This consistently fails.
(Or rather, identifying a port number works, OK but assigning this
to the variables SNMP_SNMPD_PORT, SNMP_SNMPTRAPD_PORT,
etc fails)
All tests therefore try to run both agent and trap receiver using the
listening socket address "udp:localhost:" rather than
"udp:localhost:$PORT"
In the case of tests 45 & 46 (T120/121), this means that the second
proxy agent attempts to listen on the same port as the master agent
is already using. It cannot, and hence the proxy delegation fails.
This problem also explains the failure of test 58 (T160) - the client
command walks the UDP listening table, and looks for an entry with
the port number SNMP_SNMPD_PORT. But since this variable is
empty, there is no such matching entry in the table.
I believe that the same problem underlies the rest of the failures that
you are seeing. In each case, snmptrapd.log complains
couldn't open udp:localhost: -- errno 1 ("Operation not permitted")
so the trap receiver isn't listening for incoming traps.
I strongly suspect that hardwiring a suitable port
number would allow
these tests to succeed. (That's probably the next thing to check)
I'm also seeing complaints from our anti-virus software whenever backquotes
are used to invoke a sub-command (both here, and when running "config.status").
I don't know if this is causing the second problem, or whether this is
a red herring.
How do you want to proceed? Assuming that hardcoding port numbers will
allow the tests to succeed, is this problem serious enough to warrent delaying
the releases until it's fixed?
Dave
------------------------------------------------------------------------------
_______________________________________________
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
