Hello Bonno,


Friday, July 18, 2008, 2:27:59 PM, you wrote:


>

Hi,

 

Well I did it, upgraded to 3.0 as well. The automatic rule panic feature and all the other stuff seemed a good idea. :-)

Setting it up turned out to be straight forward, just follow the instructions. Ran into just 2 things and one question.


Thanks for the details.


>

 

1)

Forgot to set correct path to identity file, was set to a nonexisting path. Started server.

-----<start screenshot>------------------------------

C:\IMail\declude\Sniffer3>c:\IMail\declude\Sniffer3\SNFServer3.0.exe c:\IMail\declude\Sniffer3\snf_engine.xml

SNF Server Version 3.0 Build: Jun 26 2008 13:25:19

SNFMulti Engine Version 3.0 Build: Jun 26 2008 13:25:06

Launching with c:\IMail\declude\Sniffer3\snf_engine.xml

Unhandled Exception: snf_LoadNewRulebase() Zero length SecurityKey Thrown!

-----<end screenshot>------------------------------

Should have said something like "error in path to identity file"


I will consider adding an error case for a missing identity file.


As a side note, there are a lot of ways to provide identity information to the SNF engine -- so that's why it throws this exception. An error message for a bad identity file path will be specific to that case.


>

 

2)

On page

http://www.armresearch.com/support/articles/software/snfServer/core.jsp

resultcode 63 is still listed as "Received IPs from spamtraps & research." in stead of "Black......"

Question:

Is there still a log file for me to ZIP every night or is all logging now at ARM research?


The new version provides us with rule-hit statistics when it checks in to share GBUdb data and check for new rules. Once you are running the new version you do not need to upload log files.


>

 

p.s. Aren't we at version 3.01? This one I just downloaded still reports 3.0 as it's version. Ot was that just the *nix version?


The change to 3.01 in the *nix distribution is not required for Win* systems which are all pre-compiled. The change was to remove "casting" in one line of code concerned with printing out thread status when in debug mode. The effect of the change is:


* It prevents 64 bit GNU compilers from complaining about a loss of resolution. Specifically casting a pointer to (int) which on a 64 bit system essentially drops half of the data. (64 bit pointer, 32 bit integer).


* It changes the output format of the thread ID slightly when running in debug mode. The updated version displays thread object numbers in HEX while the 3.00 version displays them as decimal (base 10) integers.


Since the change does not effect any critical functions we didn't see the need to make a new release for the other (non source) distributions. When the next general revision is produced this change will be rolled in.


Best,


_M





-- 

Pete McNeil

Chief Scientist,

Arm Research Labs, LLC.

#############################################################
This message is sent to you because you are subscribed to
  the mailing list <[email protected]>.
To unsubscribe, E-mail to: <[EMAIL PROTECTED]>
To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]>
To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]>
Send administrative queries to  <[EMAIL PROTECTED]>



Reply via email to