On Wed, Jun 22, 2011 at 09:37:58AM +0200, Stefan Rinkes 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
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
