10-31-2002 12:23 AM - edited 03-09-2019 12:53 AM
Hi All:
I got CSPM error message on sensor -> command -> generation status
"WARNING MESSAGES
Specified IDS Sensor Version 3.0(5)S22 is not an exact match to
a supported version. All features may not be supported."
i am sure IDS and CSPM verion are correctly ,then i check that IDS /usr/nr/var/log.200210311620 found the file no increase space, but if i used snoop -d iprb0, i can see many packet
i had recovery IDS again , but still problem
Pls anyone help me
10-31-2002 02:54 AM
This is just a warning message and is a cosmetic bug. You can ignore the message and click on generated commands to push the config.
hope this helps,
-Nairi
10-31-2002 06:11 AM
Thanks for you reponse , but i main issue is the log.200210311632 file of IDS don't increase the files space , i am sure i can see many traffic when i used "snoop -d iprb0" , Could you tell me what does other thing need to do.
Thanks for you help
10-31-2002 06:47 AM
When you first install the sensor and configure it to be managed by a CSPM or Unix Director, the packetd process is intentionally not started.
The packetd process is the process that monitors the network and generates alarms.
If the packetd process were started before CSPM is communicating with the sensor, then packetd could generate large amounts of alarms that will sit in queue waiting to be sent to CSPM.
When CSPM connects to the sensor for the first time it could be flooded with alarms that would prevent it from being able to reconfigure the sensor.
So the intial configuration on the sensor prevents packetd from starting up.
This way CSPM can connect to the sensor and an initial configuration can be pushed from CSPM to the sensor. This initial configuration from CSPM will modify the sensor configuration to start up the packetd process, and then you should start seeing alarms in CSPM and the sensor log files.
So since you haven't pushed a configuration from CSPM, the packetd process is not running. Once you successfully push a config from CSPM to the sensor then you shoudl be fine.
Also realize that the log file you are referring to is a memory mapped file. It is created to be a certain size and never groes. Instead when the file is first written it is filled with null bytes and as alarms are written the null bytes are then over written with the actual data from the alarms.
Once the log fills up it is closed and moved to the new directory and a new log is opened.
So you can't use the size of the log file to determine if alarms are being created. You could try "cat log.*" and look at the last entry, and then type "cat log.*" again and see if the last entry changes in order to tell if there are alarms being generated.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide