On Wed, May 5, 2010 at 5:14 PM, Dave Shield <d.t.shi...@liverpool.ac.uk>wrote:
> 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? > The free port number detection issue has been fixed in r18651. With this fix the only test that still fails is test 58 because the Cygwin port of snmpd.exe reports incorrect information in the udpTable. See also https://sourceforge.net/tracker/?func=detail&aid=2997492&group_id=12694&atid=112694. Another issue that I discovered and that is not covered by any regression test is that the information reported in tcpConnTable does not match the output of netstat. See also https://sourceforge.net/tracker/?func=detail&aid=2997495&group_id=12694&atid=112694 . Bart.
------------------------------------------------------------------------------
_______________________________________________ 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
