cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
516
Views
0
Helpful
2
Replies

Strange Packetd.conf Fragment Reassembly error

gpoer
Level 1
Level 1

I keep getting this error in my error logs.

08/20/2001 23:45:40UTC E NrConfigData::readConfigFile : unrecognized token 'Reas

sembleOverwriteHead' in config file '/usr/nr/etc/packetd.conf'

I am also recieveing these errors when I try appling a new version with nrConfigure.

>Warning! nrConfigure could not parse the following line(s)

in /org100/host2/cfg/version.17/packetd.conf:

Reason: unrecognized token.

ReassembleOrderBy Time

ReassembleOverwriteHead Off

ReassembleOverwriteTail Off

ReassembleOverwriteTotal Off

ReassembleMaxTotalFragments 5000

>java.lang.NullPointerException

at COM.wheelgroup.netranger.nrconfigure.nrdlgs.configmgr.CfgItemDlg.applyLocally(CfgItemDlg.java:2262)

at COM.wheelgroup.netranger.nrconfigure.nrdlgs.configmgr.CfgItemDlg.access$3(CfgItemDlg.java:2226)

at COM.wheelgroup.netranger.nrconfigure.nrdlgs.configmgr.CfgItemDlg$FileApplier.run(CfgItemDlg.java:2361)

at java.lang.Thread.run(Thread.java)

Any thoughts on what this may be?

thanks,

Geoff

2 Replies 2

marcabal
Cisco Employee
Cisco Employee

These tokens are additional tokens that can used to configure the fragment reassembly mode for the sensor. Most users do not use them, and they were not added to the nrConfigure configuration windows. Instead users who needed these tokens for their specific environment were told how to add them their packetd.conf file manually using vi.

I am not sure why packetd is creating the error for the ReassembleOverwriteHead.

nrConfigure should create the Warning about not being able to parse the lines, and then nrConfigure will ignore the tokens and simply add them to the bottom of the packetd.conf file.

They should not be causing the java.lang.NullPointerException you are seeing.

Does the java error happen all of the time?

If not then you may run across a bug that has nothing ot do with the extra tokens.

If so then you might try the following:

1) telnet to the sensor as user netrangr

2) cp /usr/nr/etc/packetd.conf /usr/nr/etc/packetd.conf.original

3) vi /usr/nr/etc/packetd.conf

Temporarilly remove the tokens that nrConfigure is complaining about. They are at the bottom of the packetd.conf file.

4) On the director start nrConfigure

5) Double click on the sensor

6) You should be prompted to download the changed conf files from the sensor. Say yes to download the changes.

7) Then see if you still keep getting the same java error as before.

Every thing you said was correct concerning the fragment reassembly, but you probably knew that :) It seems that packetd keeps dieing and the reason I was looking into the fragment reassembly errors was because they are the only ones in the errors.packetd.# file. Is there some place else I should be looking for to find out why packetd keeps dieing?

As to the java errors..

After following your steps I noticed the java errors seem to be coming from the director when it tries to apply the new changes. However, the new changes never actually get applied and the sensor needs to be restarted manually before they take effect.

Right now, packetd has been running for 7 hours without failure. They only change that was made was me removing the items from packetd.conf as you suggested. If packetd does not die today then I will put them back in and see if it kills it.

thanks,

Geoff

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: