1098c7bfb7
4.1.33 - Release 16 August 2009 2837931 wrong mode selected in ipf program for hash-entries 2826168 load_http can make ippool core dump 2825150 IPL_LOGMAX used to index some arrays 2825084 ipv6 fragments should not be allowed past 64k 2824713 ipfstat top output alternates between entries and nothing 2824712 ipfstat top output is shows negative ttl 2820965 a single bad ipv6 extension header should not impact others 2818197 ignored fragment bits defined as being reserved 2817667 IPv6 fragment header verification needs attention 2817098 fr_getrulen() finds the wrong rule 2817096 fr_rulen is unused 2741019 Lingering states (Established/Listen - 5/0) in state table 2702887 use of PBR/fastroute causes panic with ipv6 2671913 regression test in7 fails to execute 2598625 parsing empty config file results in an error 2698656 test parsing empty config files 2597956 not all pointers in a clone are reset 2543934 nat_t gets assigned ifp too early 2535795 No need to always bump fr_ref 2535778 Bad IPv6 packets droped by default 2031730 4.1.31 Nat drops fragmented packets after the first 2214661 ipf does not handle IPv6 fragments 2473273 NAT removed before RST/ICMP sent 2216500 fin_state serves no purpose 2424604 adding random MD5 data causes panic 2304435 Ineffecient lock usage in logging 2216491 fin_nat serves little purpose 2055619 duplicating a free-d packet will fail 2042949 Excessive locking when creating nat_t 2035610 nat_update does not need to get locks 2214658 ipf mostly ignores locking in NetBSD 1979427 Memory leak in user utilities - token never freed (rel br) * SunOS4 does not have a curproc, but it does have u. * The fix for 2020447 generated random port numbers but not within the range specified in the map rule. Add in a regression test to verify that the "random" part works. 2020447 NAT can undo name server random port selection 1988795 NetBSD does not build with kernel malloc stats 1988782 fr_movequeue can take a short cut 1988669 first nat creation failure prevents further success 1988668 hostmap searching does not work properly * on some 64bit architectures (such as alpha), the addrfamily_t is packed differently, throwing off the calculations for adf_len * one too many READ_ENTERs in ip_sync code. * clean up fr_fastroute a little by removing some #ifdefs and pushing the code around a bit to use the same variables (NetBSD) * more recent NetBSDs use VOP related macros differently |
||
|---|---|---|
| .. | ||
| bin | ||
| gnu | ||
| include | ||
| lib | ||
| libexec | ||
| sys | ||
| usr.bin | ||
| Makefile | ||
| README | ||
$NetBSD: README,v 1.1 2006/03/14 09:46:34 martin Exp $
This part of the source tree contains regression tests. There are special
make targets and rules to follow. Most of these, however, are currently not
enforced, and most tests available are not conforming.
We hope to fix this someday. If you add new tests, please try to be conforming.
What is a regression test?
A regression test is run by a makefile in a test directory (see below).
Each makefile may run multiple tests.
What is a test directory?
A directory in this part of the tree is a regression test directory. It
contains a Makefile which implements the additional "regress" target,
and runs all it's regression tests during this target.
May the make progress be stopped on failures?
No, the "make regress" target should succeed, unless some regression
binaries could not be build, disk is full or other catastrophic failures
outside of the tested subsystem happen. A failing regression test should
log the failure (see below), but not make the target itself fail.
What are the possible results of a regression test?
A test may either
- succeed, in which case it logs "PASSED" (see below for logging details)
- fail, in which case it logs "FAILED"
- not be able to run, in which case it logs "SKIPPED" and the reason
for the skip in the comment field (see below)
Typical reasons for tests to not being run are missing kernel options,
or missing privileges (test needs root, "make regress" is invoked by
mere mortal or vice versa). A test may not fail because of such
environmental issues, it must detect and properly log the problem.
If a test directory contains tests that may be skipped, it should have
a README file explaining the prerequisites (e.g. needed kernel options)
In future, we will mark affected makefiles and optimize run/skipped test
during repeated runs with differing privileges - but currently there is no
make framework in place to handle this.
How and when does a test log results?
If the make/environment variable ${REGRESS_LOG} is defined, the final
results (and only those) should be logged to the file named by that
variable. We will, in the future, add make targets for this purpose.
The log format is line oriented, one line used per test. Each line
consists of the directory where the Makefile lives, followed by the
test name and the result (see above: PASSED, FAILED, SKIPPED).
Following this an optional comment may be added. For SKIPPED tests the
comment is not optional. Fields are separated by spaces.