Hi Benjamin,
do you mean that the problem disappered, when you used libpcap over
PF_RING to store captured packets to a file, instead of processing them
on the fly (without first storing them to a file)?
Thanks a lot.
Regards,
Sven Ubik
On Thu, 19 Apr 2007, Benjamin Small wrote:
I recall facing the same problem. However, I ruled out PF_RING a. I was and
was left with assuming it to be a problem with lib to write the pcap to a
file and then read it without corruption. I also observed no corruption in my
snort alerts.
On Thursday 19 April 2007 05:58, Sven Ubik wrote:
Hi,
we have a problem with PF_RING 3.2.1 on Linux 2.6.19.2. First 62 bytes of
each packet are captured correctly. The rest of packet is corrupted. The
problem does not depend on packet size or bucket_len.
For instance, the following is comparison of tcpdump without PF_RING and
with PF_RING for UDP packet that includes increasing bytes in payload (00,
01, 02, etc.):
Without PF_RING:
# tcpdump -s 128 -n -XX -i eth2
tcpdump: WARNING: eth2: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth2, link-type EN10MB (Ethernet), capture size 128 bytes
23:57:26.102231 IP 0.0.0.0.63 > 0.0.0.0.63: UDP, length 82
0x0000: 0001 0500 0100 0001 0500 0000 0800 4500 ..............E.
0x0010: 006e 0000 0000 4011 7a80 0000 0000 0000 [EMAIL PROTECTED]
0x0020: 0000 003f 003f 005a 9025 0001 0203 0405 ...?.?.Z.%......
0x0030: 0607 0809 0a0b 0c0d 0e0f 1011 1213 1415 ................
0x0040: 1617 1819 1a1b 1c1d 1e1f 2021 2223 2425 ...........!"#$%
0x0050: 2627 2829 2a2b 2c2d 2e2f 3031 3233 3435 &'()*+,-./012345
0x0060: 3637 3839 3a3b 3c3d 3e3f 4041 4243 4445 6789:;<=>[EMAIL
PROTECTED]
0x0070: 4647 4849 4a4b 4c4d 4e4f 5051 FGHIJKLMNOPQ
With PF_RING:
# ./tcpdump -s 128 -XXX -n -i eth2
Open HAVE_PF_RING(eth2)
tcpdump: WARNING: eth2: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth2, link-type EN10MB (Ethernet), capture size 128 bytes
23:57:26.102231 IP 0.0.0.0.63 > 0.0.0.0.63: UDP, length 82
0x0000: 0001 0500 0100 0001 0500 0000 0800 4500 ..............E.
0x0010: 006e 0000 0000 4011 7a80 0000 0000 0000 [EMAIL PROTECTED]
0x0020: 0000 003f 003f 005a 9025 0001 0203 0405 ...?.?.Z.%......
0x0030: 0607 0809 0a0b 0c0d 0e0f 1011 1213 a128 ...............(
0x0040: 834f 5503 068a 8b5b 7a77 502d c924 4a24 .OU....[zwP-.$J$
0x0050: 6a57 1c4d d1a9 debc 68b9 f21b 3ec5 7533 jW.M....h...>.u3
0x0060: da77 ae55 7152 0100 0000 0600 0000 0100 .w.UqR..........
0x0070: 0000 0100 0000 0000 0000 0000
More information about PF_RING:
# dmesg
...
Welcome to PF_RING 3.2.1
(C) 2004-06 L.Deri <[EMAIL PROTECTED]>
NET: Registered protocol family 27
PF_RING: bucket length 128 bytes
PF_RING: ring slots 4096
PF_RING: sample rate 1 [1=no sampling]
PF_RING: capture TX No [RX only]
PF_RING: transparent mode Yes
PF_RING initialized correctly.
PF_RING: registered /proc/net/pf_ring/
Did anybody experience a similar problem?
Regards,
Sven
_______________________________________________
Ntop mailing list
[email protected]
http://listgateway.unipi.it/mailman/listinfo/ntop
_______________________________________________
Ntop mailing list
[email protected]
http://listgateway.unipi.it/mailman/listinfo/ntop
