I'm sure you did. Did you test it with one patched and one not? -Toby.
On Wed, Jun 22, 2011 at 1:37 AM, Stefan Rinkes <[email protected]> wrote: > On Tue, Jun 21, 2011 at 9:42 PM, Tobias Weingartner <[email protected]> wrote: >> On Tue, Jun 21, 2011 at 11:52 AM, Stefan Rinkes >> <[email protected]> wrote: >>> >>> while playing around with carp and pfsync I spotted >>> two minor bugs. >>> >>> 1. Not all pfstate flags are synced, cause pfsync uses >>> u_int8_t, while pf uses u_int16_t for state_flags. >>> Currently that means PFSTATE_SCRUB_TCP flags don't >>> get synced. >>> >>> retrieving revision 1.333 >>> diff -u -p -r1.333 pfvar.h >>> --- sys/net/pfvar.h 20 Jun 2011 19:03:41 -0000 1.333 >>> +++ sys/net/pfvar.h 21 Jun 2011 17:33:31 -0000 >>> @@ -892,13 +892,13 @@ struct pfsync_state { >>> u_int8_t proto; >>> u_int8_t direction; >>> u_int8_t log; >>> - u_int8_t state_flags; >>> + u_int16_t state_flags; >>> u_int8_t timeout; >>> u_int8_t sync_flags; >>> u_int8_t updates; >>> u_int8_t min_ttl; >>> u_int8_t set_tos; >>> - u_int8_t pad[4]; >>> + u_int8_t pad[3]; >>> } __packed; >> >> Does this change the on-wire format? Also, would the state_flags need to >> have htons/ntohs done to it? >> >> -Toby. >> > > Hi, > > I tested this diff quite carefully and used it for over a week now and > checked that all > state_flags are synced by adding a new flag which triggered a printf in pf(4) :) > > No issues/crashes have been seen so far. > > Stefan
