Hi can you mail me a simple pcap file I can use for reproducing the problem?
The problem is not fragmentation per-se, but its rate Luca On Feb 13, 2010, at 11:45 AM, Canope wrote: > Hi, > > The 5.2.9 seem to be ok but in have another issue as explained with it. > The netflows generated dont contain the real bytes exchanged. > Always 46 bytes. > > PS: > I agree about the fragmentation but a lot of applications protocols > use the IP fragmentation schem when using UDP. > SIP, UDP VPN, are parts one of them. > > > > > > > Luca Deri > Fri, 12 Feb 2010 14:13:34 -0800 > > Hi > please download nProbe 5.5 that contains some improvements for flow handling. > I > have not done much changes in the fragment code but 400k fragments/sec is an > indicator that the problem is not on nProbe but on the networks. So I would > start investigating here first as having so many fragments is a source of > problems > > Luca > > On Feb 12, 2010, at 9:55 PM, Canope wrote: > >> Hi, >> >> I've made some tests with nprobe 4.9.4 and nprobe 5.2.9 and i've >> encountered two issues :o(. >> >> The first one is with the 4.9.4 version: >> >> When a great amount of udp fragmented (more than 400000/s) packets is >> analysed, nprobe start to loose packets. >> I've checked the code and the problem seem to be located on the >> fragmented subroutine. >> If i reduce the delay for the "lastSeen" from 30 seconds ( hardcoded) >> to less, the issue disapear but the probe produce more flows per >> seconds. >> >> The second one with the 4.9.4 version: >> >> I have to change imcrement the MAX_EXPORT_QUEUE_LEN to a bigger value >> (524280) of handling the workflow :o( >> >> The first one is with the 5.2.9 version: >> >> - the netflow v9 generated packets dont contain the "right" size of >> the messages on the "in_bytes" section. >> - The flow generated with the 4.9.4 are "ok" but i'm looking for >> something possibily better since i've seem some interresting change on >> the fragment handling method. >> >> The second one with the 5.2.9 version: >> I have to change imcrement the MAX_EXPORT_QUEUE_LEN to a bigger value >> (524280) of handling the workflow :o( >> >> >> I'm available if someone whant more informations. >> >> >> >> >> Thanks in advance, >> _______________________________________________ >> Ntop-misc mailing list >> [email protected] >> http://listgateway.unipi.it/mailman/listinfo/ntop-misc > > --- > > "Debugging is twice as hard as writing the code in the first place. Therefore, > if you write the code as cleverly as possible, you are, by definition, not > smart enough to debug it. - Brian W. Kernighan > _______________________________________________ > Ntop-misc mailing list > [email protected] > http://listgateway.unipi.it/mailman/listinfo/ntop-misc --- We can't solve problems by using the same kind of thinking we used when we created them - Albert Einstein _______________________________________________ Ntop-misc mailing list [email protected] http://listgateway.unipi.it/mailman/listinfo/ntop-misc
