[prev in list] [next in list] [prev in thread] [next in thread] 

List:       tcpdump-workers
Subject:    Re: [tcpdump-workers] libpcap linux mmap patch
From:       "Alexander 'Leo' Bergolth" <leo () strike ! wu-wien ! ac ! at>
Date:       2008-02-02 19:04:30
Message-ID: 47A4BEBE.70506 () strike ! wu-wien ! ac ! at
[Download RAW message or body]

Hi!

On 01/31/2008 02:39 PM, Abeni Paolo wrote:
> on Thu 1/31/2008 10:37 AM Alexander 'Leo' Bergolth wrote:
>> I just gave your new linux mmap patch a try
> 
> thanks for the review :-)

Bad news...
I've also tested it on debian etch (kernel 2.6.22-2-686).
Unfortunately, the same patch seems to cause some displacement of the 
frames, starting with the first captured frame, when using the "any" 
interface. tcpdump outputs somethink like that:

-------------------- 8< --------------------
listening on any, link-type LINUX_SLL (Linux cooked), capture size 96 bytes
19:26:43.525207   ? ethertype Unknown (0x9094), length 100:
         0x0000:  89d0 5942 0016 aa5e 7068 e1c8 51d7 c2f9  ..YB...^ph..Q...
         0x0010:  8018 006e 2f9f 0000 0101 080a 2305 0cbf  ...n/.......#...
         0x0020:  5502 6dd2 db18 87bc 7c32 0db1 f8bf 3631  U.m.....|2....61
         0x0030:  e851 a95a b3da fb8d a943 0052 6dee 324e  .Q.Z.....C.Rm.2N
         0x0040:  0100 0000 5400 0000 5000 0000 5000 5000  ....T...P...P.P.
-------------------- 8< --------------------

ngrep (already patched with cnt=-1 ;-)) shows something like that:

-------------------- 8< --------------------
# env 
LD_LIBRARY_PATH=/home/software/libpcap-mmap/0.9.8-mmap/libpcap0.8-0.9.8 
ngrep -d any -p -x "" port 80 | head
interface: any
filter: (ip or ip6) and ( port 80 )
#
? műˇ/ ->,v
   c3 ca 90 94 00 50 e3 e7    3d 50 bc 0a d2 42 7b 6a    .....P..=P...B{j
   80 10 21 80 b2 fa 00 00    01 01 08 0a 26 b7 1f 19    ..!.........&...
   11 75 61 57 48 54 54 50    2f 31 2e 30 20 32 30 30    .uaWHTTP/1.0 200
   20 4f 4b 0d 0a 44 61 74    65 3a 20 46 72 69 2c 20     OK..Date: Fri,
   30 31 20 46 65 62 20 32    30 30 38 20 31 38 3a 35    01 Feb 2008 18:5
   36 3a 35 35 20 47 4d 54    0d 0a 53 65 72 76 65 72    6:55 GMT..Server
-------------------- 8< --------------------

When using a specific interface, everything works as expected.

Maybe that's because on my test-box there are some "normal" eth 
interfaces mixed with vlan interfaces? The other box (Fedora core 5), 
where everything is fine, only has one active interface (eth0).

>> *) There is a typo in the macro RING_GET_FRAME(h) (handle instead of h).
>> The attached patch fixes that.
> 
> Your patch looks good to me. I hope that Guy Harris or some other may apply it. 
> BTW it's funny that the current cvs works regardless of the typo :-)

Yes, since RING_GET_FRAME currently is always called with "handle" as 
argument...

>> *) If pcap_loop is called with cnt=0 (ngrep erroneously does that), it
>> will busy-loop forever. pcap_read_linux_mmap doesn't handle that case,
>> it returns 0, which is asymmetric to pcap_read_linux's behavior, which
>> reads one packet.
> 
> I think there is a little confusion about the 'cnt' parameter.
> According to man page a value of 0 should cause no packet to be read,
> but into pcap_loop a value of '0' is handled like negative values
> (i.e. loop forever).

Yes, the behavior depends on the underlying pcap_read* function. It is 
called in a loop with a cnt argument of 0.

> If the behavior described into the man page is
> the preferred one, than also your second patch looks correct to me
> (but it can break application which 'misused' the pcap API using a
> value of cnt == 0 to loop forever).

Thats true. I don't know how many applications like ngrep erroneously 
use cnt=0 to loop forever...

Cheers,
--leo
-- 
e-mail   ::: Leo.Bergolth (at) wu-wien.ac.at
fax      ::: +43-1-31336-906050
location ::: Computer Center | Vienna University of Economics | Austria

-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
[prev in list] [next in list] [prev in thread] [next in thread]