4210 Sensor with packetd not initializing

shenethia-jones · ‎01-28-2002

I have a 4210 sensor that packetd is not initializing. It is one of 3 4210 sensors in my environment. I would like all possible options other than using the 2.5 software recovery.

rwassom · ‎01-28-2002

Please provide some background information on the sensor you are having problems with... Is this a new sensor that has only recently been configured and isn't working? Or was this sensor already configured and working prior to your current problem? If the latter is the case, have any software upgrades or configuration changes been applied recently? What kind of messages are you seeing in '/usr/nr/var/errors.packetd.*'?

shenethia-jones · ‎01-28-2002

there is no /usr/nr/var/errors.packetd file

under /usr/nr/var/errors there are about 11 errors.packetd files. They are all empty. The packetd process is not running. This sensor has been running for a while and has seen traffic.

stevemurphy · ‎01-29-2002

Verify that nr.packetd is in the /usr/nr/etc/daemons file. If it's there it should try to start packetd when you do an nrstart and would generate an error file if there was a problem.

stbob · ‎01-29-2002

I have a 4230, and after doing a reinstall had no packetd running, turned out the /dev/spwr0 (which does the sniffing) was not configured at all. I had to set it up manually, after which packetd started fine.

chstone · ‎01-29-2002

If there are no errors, then it is possible that the packetd daemon on the sensor was never configured to start. Is it possible that you pushed out a new version from you Director and you did not select "nr.packetd" in the Systems Files folder? You will want to verify this.

Also, check the applied version and make sure that in Intrusion Detection>Data Sources tab, that you have selected /dev/iprb0 as your packet device.

If you can go to your sensor and vi the /usr/nr/etc/daemons file, remove the # sign from in front of nr.packetd, if it exists. Also, vi /usr/nr/etc/packetd.conf. Look for the line "NameOfPacketDevice". It should read "NameOfPacketDevice /dev/iprb0". After you have verified these things, type "nrstop;nrstart". Do this as user "netrangr". Once the services have restarted, the daemons will be listed. You can also verify this by typing "nrstatus".

If packetd is not running at this point, then check the errors.packetd. If you have any errors you should consider contacting the TAC for assistance with this issue.

If packetd is running, then I would suspect something was not configured correctly on the Director. Keep in mind that if you reapply the current version that it will write the current configuration files back to the sensor and you may be facing the same issue again.

When you click on the sensor in the Netranger Configuration Utility, after manually making the changes on the sensor, it should give you a warning to the effect that it has detected changes on the sensor that are different then the applied version from the Director. I would answer yes to this, and this way the working config from the sensor will be updated to the Director.

chris