If you are using a typical MTU on your network of 1500 bytes, then set the bucket_len to 1540 (to account for VLAN tagging, etc.). num_slots=4096 should be fine. The bucket_len option is akin to the -n option for tcpdump in that it specifies how deep into the packet it should record. If you are doing something like ntop where you only want to look at the packet headers, then a bucket_len of 64 works. But if you want to inspect the entire packet (see the entire email), then you will have to make sure that the bucket_len is at least as big as the MTU of the network.
Could you show me some output of the scambled emails so that I can see what form they appear to be in? --Martin ________________________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of WILLIAMS, Paul Sent: Wednesday, December 06, 2006 9:39 AM To: [email protected] Subject: RE: [Ntop-misc] PF_RING: scrambled packets??? [Kernel 2.6.18.3] Hi Martin, thanks for your reply. I have switched sampling off and now do not see the high lost figure (Thanks), So, now I see a lost value of 0, which is good. But I still seem to get scrambled packet data, as mentioned in the addition email. I have tried various setting (with and without sampling). The initial values I used, which were the values used on the other machines I mentioned, were... Configure with: insmod ring.ko bucket_len=4096 num_slots=4096 INFO Version : 3.2.1 Bucket length : 4096 bytes Ring slots : 4096 Sample rate : 1 [1=no sampling] Capture TX : No [RX only] Total rings : 1 These were also the settings I used when I did the tcpdump test (Additional info email). (These values gave the best capture results on the old PC & Sun v20z mentioned in my original email). I have tried various combinations between bucket length from 96 to 65535 and number of slots from 64 to 9000. But I always get the same scrambled result. With the data scrambled as it is, libnids is unable to reconstruct the emails and therefore all I get to see is the occasional begining chunk of email header. Initially, when I only saw a few email headers (much less than I expected) and the high lost rate, I assumed that it was purely a packet dropping issue, but now I see it is a data scrambling issue. Cheers, PBW. -----Original Message ----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Holste, Martin C - DOA Sent: Mittwoch, 6. Dezember 2006 15:32 To: [email protected] Subject: RE: [Ntop-misc] PF_RING: 67% of packets lost [Kernel 2.6.18.3] I don't use sampling and so I'm not sure if this is true, but it's possible that because you are using a sample rate of 3, it records the 2 packets PF_RING lets past as drops. Try changing the sample_rate to 1 and see if that will fix the problem. If this is a link over 150 Mb and 30 Kpkts/sec, I would expect to see some drops, especially with the big slot lengths you've defined. It depends mostly on the speed at which the app can pull the packets from memory as opposed to the speed at which PF_RING can insert them into memory. --Martin ________________________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of WILLIAMS, Paul Sent: Wednesday, December 06, 2006 8:04 AM To: [email protected] Subject: [Ntop-misc] PF_RING: 67% of packets lost [Kernel 2.6.18.3] Hi, Has anyone seen this PF_RING problem before? I have recently compiled a 2.6.18.3 Kernel with PF_RING patch (source from 26.11.2006) on a Sun X2100 server. I then compiled the various libraries and our smtp sniffing app. When I try to capture data I see that most of the packets are lost (example below) Configure with: insmod ring.ko bucket_len=9000 num_slots=9000 sample_rate=3 transparent_mode=1 INFO Version : 3.2.1 Bucket length : 9000 bytes Ring slots : 9000 Sample rate : 3 [1=no sampling] Capture TX : No [RX only] Total rings : 1 0 Bound Device : eth0 Version : 6 Sampling Rate : 0 Cluster Id : 0 Tot Slots : 465 Slot Len : 9018 Data Len : 9000 Tot Memory : 4194304 Tot Packets : 860309 Tot Pkt Lost : 574371 Tot Insert : 285938 Tot Read : 285478 Note: I have tried various configurations, including values that have worked on other machines. This just happens to be the current setting whilst writing this email. From the figures in the log '0' you can see that appr 67% of packets are lost. All i seem to get are the beginings of the occational email header. If I set the bucket_len & num_slots to 0 (therefore not using PF_RING) ... Configure with: insmod ring.ko bucket_len=0 num_slots=0 INFO Version : 3.2.1 Bucket length : 0 bytes Ring slots : 0 Sample rate : 1 [1=no sampling] Capture TX : No [RX only] Total rings : 0 No ring log I do capture emails (smtp packets). But, ofcourse data is lost, hence the need of the PF_RING. On previous machines PC PII 400Mhz (kernel 2.6.17) Sun v20z 1.8Ghz (kernel 2.6.9) The PF_RING patch was installed and capture performance improvements were seen. Has anyone see a similar problem? And, more importantly (well for me) has anyone got any ideas what might be causing this/how to fix this? Cheers, PBW. ------------------------------------------------------------------------ ------------------ Software: Kernel: 2.6.18.3 + PF_RING patch (from 26.11.2006) Libpcap: 0.9.4 Libnids: 1.20 Libdnet: 1.11 Hardware: Server: Sun X2100 CPU: Dual-Core AMD Opteron(tm) Processor 1214 (cpu MHz: 2211.419) RAM: 2Gb Hdrive: SATA 250GB NetCard: Intel 1000e (NAPI enabled in Kernel)
_______________________________________________ Ntop-misc mailing list [email protected] http://listgateway.unipi.it/mailman/listinfo/ntop-misc
