On Fri, May 4, 2012 at 12:27 PM, Kapetanakis Giannis <[email protected]> wrote: > On 03/05/12 22:56, mxb wrote: >> >> I'd suggest you to experiment with the src and try to rollback if_pfsync.c >> to, >> say rev. 1.179, >> then roll forward with revisions until you can pinpoint one which breaks >> it. >> >> //maxim > > > Ok, I've traced the problem back to r1.180 of if_pfsync.c > > If I remove 1.180 and apply 1.181, 1.182, 1.183, 1.184 > then everything works fine. > > According to my understanding 1.180 introduces the following two problems: > > 1) When one firewall reboots, the other one is initiating a bulk transfer > thus demoting his carp/pfsync groups. > I don't understand why this is needed. > > 2) When the firewall boots it sets his demotion counter on groups > carp/pfsync to 0 (instead of 1) before his bulk transfer > is finished. > > The diff bellow removes 1.180 > Feel free to send me diffs to try. > > regards, > > Giannis >
hi, yes, there's no doubt that this is a problem. btw, can you try the unpatched kernel and put a switch between the firewalls, i.e. connect pfsync interfaces through the switch. will that work for you?
