Summary:

Please test latest snapshot for PF regressions

Details:

This is a request for people to test PF with the most recent snapshots,
which contain a rather substantial rearrangment of PF's internals, and
completes the split between the layer 3/4 addressing information (state
key) and the "extra" tracking information held in the state.

There should be no real functionality changes in this, it does not make
anything magic happen, and there should be no regressions. However, it
changes the ABI and is a flag-day for pfsync and userland utilities that
print states - you have to update userland with the kernel, and things
like pftop and pfflowd will be broken until they're updated.

These changes are necessary for a number of interesting things we're
planning on tackling during the hackathon in a few weeks, but we need it
to be solid and committed very soon to have that happen. It's been
tested in some high-load and production environments, but we'd like to
get some more test coverage, particularly in non-trivial configurations:
route-to/reply-to, pfsync, relayd, huge numbers of states, etc.

Hi tech@,

"mount /mnt/svnd0a" must be wrong. The author meant either /dev/svnd0a
or /mnt.

I think this is right. Nothing is using it, and it compiles.

--- /usr/src/sys/arch/amd64/include/cpu.h 2008/05/25 23:43:25 1.1
+++ /usr/src/sys/arch/amd64/include/cpu.h 2008/05/25 23:49:32
@@ -339,8 +339,7 @@
#define CPU_APMWARN 9 /* APM battery warning percentage */
#define CPU_KBDRESET 10 /* keyboard reset under pcvt */
#define CPU_APMHALT 11 /* halt -p hack */
-#define CPU_USERLDT 12
-#define CPU_MAXID 13 /* number of valid machdep ids */
+#define CPU_MAXID 12 /* number of valid machdep ids */

#define CTL_MACHDEP_NAMES { \
{ 0, 0 }, \
@@ -355,7 +354,6 @@
{ "apmwarn", CTLTYPE_INT }, \
{ "kbdreset", CTLTYPE_INT }, \
{ "apmhalt", CTLTYPE_INT }, \
- { "userldt", CTLTYPE_INT }, \
}

/*

Is this something on the roadmap? Network device polling is used to
tune/mitigate network interrupts.

The many vr fixes in FreeBSD committed in April haven't yet made it to
OpenBSD. Are these on the map as well?

Pierre

We're having some major electrical work done in our data centre.
While I have UPS, the nature of the work means I don't have air conditioning ;)

The result is some of the OpenBSD sites (ftp, www, anoncvs, etc.)
may be unavailable for much of this morning - potentially into the afternoon.

-Bob

Hi tech@,

In umsm_attach(), the case when usbd_get_interface_descriptor()
returns NULL is not handled correctly.

Index: umsm.c
===================================================================
RCS file: /OpenBSD/src/sys/dev/usb/umsm.c,v
retrieving revision 1.25
diff -u -r1.25 umsm.c
--- umsm.c 12 May 2008 12:24:43 -0000 1.25
+++ umsm.c 25 May 2008 11:49:01 -0000
@@ -193,8 +193,8 @@
*/
printf("%%s: umass only mode. need to reattach\n",
sc->sc_dev.dv_xname);
- return;
}
+ return;
}

uca.bulkin = uca.bulkout = -1;

hello wim,

thanks for your intervention.

the problem is that all WRAP boards worked very well.

now I have installed a pcengines ALIX board (same chipset and design as
soekris) with OpenBSD 4.3. everything is working fine just to that point when
configuring isakmpd. to eliminte configuration failures I took the
isakmpd.conf and the few neccessary files from a IPSec working WRAP system and
copied them to the new ALIX with the VIA chipset.

this configuration now does not establish a tunnel, so I traced the IKE
traffic and discovered a difference in the IKE communication which is probably
responsible for the failure that phase II of IKE does not complete and
therefore no IPSec security association is generated.

greetings from austria
arno hechenberger
citydata

trace: new ALIX machine with vr interfaces

No. Time Source Destination Protocol Info
1 0.000000 194.208.37.21 194.208.33.217 ISAKMP
Identity Protection (Main Mode)
2 0.058193 ...