Compiling DCERPC error after SD 541060425

[yelwoci]

NG AI R55 HFA17 Linux WGL-X 2.4.9-34.13pdsv #1 Mon Dec 1 12:50:10 CST
Same thing on this and one other firewall same OS/CP, different policies.

2003 i686 unknown
After Smart Defense Update 28apr06 (I think)

1 error in preprocessor
#include "fwui_head.def"
from file /opt/CPfw1-R55/conf/Standard.pf, line 5595:
#include "base.def"
from file /opt/CPfw1-R55/lib/fwui_head.def, line 315:
#include "dcerpc.def"
from file /opt/CPfw1-R55/lib/base.def, line 738:
DCERPCt_NDR_LABEL_RFFU=0)
cpp: line 421, Error: Redefining defined variable "DCERPCt_NDR_OK"

Have tried D Barcon's submission:-
rm inspect.C and updates.def
reset the asm_update_version
re update SD
reinstall policy
but it fails
do I need to delete the DCE section?

Regards

Ian Cowley

[yelwoci]

I think I've found the problem!

I'd copied the $FWDIR/lib/dcerpc_hfa.def to dcerpc.def to overcome some issues across VPNs and Microsoft Shares.

I wondered if the latest SD hadn't taken the differences in the 'hfa' version.
So I copied the original back and cpstart and reinstalled the policy

all OK...but I now might have my original problems back!

It would be nice to be able roll back and/or inhibit particular SD versions

Ian Cowley

[membree]

I had exactly the same problem on NG AI R55 HFA17 and was able to resolve it by reverting to the previous saved policy database revision. I didn't know what the problem was but expect that your explanation is correct as I also am using the updated dcerpc.def. Hopefully Check Point will updated the SmartDefense code to recognize both versions of dcerpc.def and re-release it sometime soon.

Saving a policy database revision prior to installing a SmartDefense update as described in the SmartDefense thread "Best practice for SmartDefense update" really is an excellent idea as I have been burned by SmartDefense updates that broke policy installation twice now.


The D Barcon submission was to deal with a somewhat different issue (this was the previous time I was burned). Check Point issued a SmartDefense update with a bug that prevented policy compilation and then re-released an undocumented corrected version a few hours later using the same version number as the original broken version. Those unfortunate enough to have installed the new version prior to it being corrected (like us) were stuck, SmartDefense didn't recognize the corrected version because it had the same version as what was installed so wouldn't install the correction. The D Barcon submission was Check Point's solution, a description of how to back out a SmartDefense update so that the same SmartDefense version can be reinstalled. In the current case, there hasn't been a corrected version so following this procedure would have no effect. Since that time, I generally wait a few days before installing a SmartDefense release so that others can bear the pain. Waiting didn't save us this time though.

[yelwoci]

I have to admit there were a few FLAME mails from me to Checkpoints Support team.
If you don't have an Enterprise Support package, they won't talk to you.
Even if you find a bug - like R60A update_export/import package doesn't work from R55.

Then they give you an update, that you've paid for, that breaks the firewall.
They won't fix it unlesss you pay them money.
That in any commercial or legal framework is extortion IMHO

Any road...I've bypassed the problem..so I've cooled down a bit!!

Ian Cowley

[membree]

I noticed that SmartDefense update version 541060430 was available today. There is no documentation on the SmartDefense site for this version (541060425 is the most recent documented version). I installed it and my Firewall policies install with no problems. Check Point appear to have resolved the dcerpc_hfa.def incompatibility that was present in 541060425.