Ok, heres my status: Running without -M, but with -i eth0,eth1, Ntop doesn't segfault. It also doesn't give the sanity check error on startup. (It has been running for 14 hours now - the output log file is 200 Megs).
Awaiting your wonder-patch :) Cheers Chris On Thu, 2002-01-17 at 03:49, Burton M. Strauss III wrote: > This is a summary of problems with Ntop 2.0 that I am aware of, and have > > 8. "Unbalanced" problem... Chris Picton et al... > ========================== > > Briefly, there are a couple of global variables relating to the device a > packet is seen from. There are also multiple paths to some places like name > resolution. It's possible to create the hash index based on the WRONG hash > table and then get sanity checks, etc. > > Symptom: various. It CAN include a lot of things, but the giveaway seems > to be these in the log: > > 15/Jan/2002 17:05:08 WARNING: Index 46 out of range [0..32] @ pbuf.c:550 > > Also, two different sized hashes (one is 48 the other 32) (more activity on > one side of your network than the other?)... what I call an "unbalanced" > network. > > The -M (merge) flag seems to make it worse. Maybe... > > Here is what I ****THINK**** is happening. The session purge is invoked > every 60 seconds (interesting, given it's dying between 1 and 2 minutes into > the run...) The Session purge loops through all the devices and follows a > tortured path through to getHostInfo, where it computes the index. However, > the code in pbuf.c uses a global variable actualDeviceId to indicate which > device and which hash table to use. The code in the purge loops using i and > does not set actualDeviceId. > > Basically, this is a "wild" pointer and Ntop will (probably) crash at some > point, possibly much later... > > This isn't new - there are a number of "FIXME" type comments about the > problem. It's just HUGE. Basically, the global variable needs to die and > be passed as a parameter around throughout dozens of routines. Thus when it > gets to places like getHostInfo, it's using the RIGHT hash. The -M flag > just makes it more complex. The problem is that it's all through the code. > I've spent a day editing it, and just barely gotten a clean compile. > > ACTION: I'm working on it. > > > ========================================================== > ========================================================== > > -----Burton > > _______________________________________________ > Ntop-dev mailing list > [EMAIL PROTECTED] > http://listmanager.unipi.it/mailman/listinfo/ntop-dev > -- Chris Picton Tangent Systems [EMAIL PROTECTED] _______________________________________________ Ntop-dev mailing list [EMAIL PROTECTED] http://listmanager.unipi.it/mailman/listinfo/ntop-dev
