On Wed, Jun 22, 2011 at 09:37:58AM +0200, Stefan Rinkes wrote: > On Tue, Jun 21, 2011 at 9:42 PM, Tobias Weingartner <weing...@tepid.org> > wrote: > > On Tue, Jun 21, 2011 at 11:52 AM, Stefan Rinkes > > <stefan.rin...@googlemail.com> 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
You didn'ty answer the questions... What Tobias is asking is: - will the break compatibility between an old and an updated machine - will this break compatiblity between machines with different byte order? I suspect the answer will be 'yes' to both questions. So while the initial observation is good, the work to fix it is not done yet. -Otto