improvements for pypcap wrapper

[getxsick]

wrapper pypcap doesn't support findalldevs() this support should be added (the wrapper is written partialy in pyrex)

anyway, the way how e.g. scapy works with findalldevs() is obscure, it just check interfaces in /proc and it doesn't have anything with libpcap. this way is wrong.

[getxsick]

Not tested under Windows.

[ignotus]

Also added support to pcap_lookupnet(). That can be used with pcap_findalldevs() to choose the correct interface to sniff.

[getxsick]

I'm changing summary to be more general about pypcap wrapper.

ignotus: please reedit your patch. it should be seperated from pcap_findalldevs.patch

[getxsick]

support CNT for pcap_loop()

[getxsick]

I attached 2 patches for dump supporting. Both of them work in the same way (internally). But API is different. First one is more like C pypcap, second one is more OO but still I'm not sure if it's optimal. Maybe I should use second one but add these functions as dump_open() and dump_close() anyway?

Because now, to use dump feature we have to pass a file path to pcap constructor. There is no other way to create dump file later. <--this is for 2nd patch.

Propably the solution is trivial, but it's 3:40am and hmmm I'm not sure now.

[getxsick]

Replying to getxsick:

Because now, to use dump feature we have to pass a file path to pcap constructor. There is no other way to create dump file later. <--this is for 2nd patch. Propably the solution is trivial, but it's 3:40am and hmmm I'm not sure now.

But hey, it's the same as with an interface. We pass it to the consructor and can't change later. Hmm it's not a big deal to leave it as it is. Unless someone would like to use 2 different files for the same sniffing. But why?

[getxsick]

And another question is...should we flush buffer to save it to the disk during dump() call or leave it?

[getxsick]

dump support - different idea (more OO)

[luis]

I attached 2 patches for dump supporting. Both of them work in the same way (internally). But API is different. First one is more like C pypcap, second one is more OO but still I'm not sure if it's optimal. Maybe I should use second one but add these functions as dump_open() and dump_close() anyway?

Because now, to use dump feature we have to pass a file path to pcap constructor. There is no other way to create dump file later. <--this is for 2nd patch.

Propably the solution is trivial, but it's 3:40am and hmmm I'm not sure now.

You're changing a wrapper, then you need to keep consistency with already exists. Support both can be misunderstood API.

But hey, it's the same as with an interface. We pass it to the consructor and can't change later. Hmm it's not a big deal to leave it as it is. Unless someone would like to use 2 different files for the same sniffing. But why? 

Could have a method set_file or something like that, OOP approach?

And another question is...should we flush buffer to save it to the disk during dump() call or leave it?
pcap_dump(self.__dump, self.__hdr, self.__pkt) 
# should we call pcap_flush() here? 

After dump it should be written on disk. Chunk it from buffer seems good idea.

[getxsick]

Replying to luis:

Could have a method set_file or something like that, OOP approach?

method set_file() instead of dump_open()? the name dump_open() is from libpcap directly...

anyway, you mean that you don't like the idea of 2nd patch? where we can pass path to a file in constructor? why?

After dump it should be written on disk. Chunk it from buffer seems good idea.

Please remember, that it's usual in common operating systems and other functions. that's why people involve buffers to avoid a situation to using IO too often (which is a bottleneck in general). of course flush it all the time after another calling of dump() has a nice effect but i'm not sure if we should follow this way.

Hmmm maybe I could write a special Dump class which all methods like flush(), open(), close(), dump() ?

[luis]

Replying to getxsick:

Replying to luis:

Could have a method set_file or something like that, OOP approach?

method set_file() instead of dump_open()? the name dump_open() is from libpcap directly... anyway, you mean that you don't like the idea of 2nd patch? where we can pass path to a file in constructor? why?

No. I prefer 2nd patch. And I suggested adding a new method to set_file if is necessary.

After dump it should be written on disk. Chunk it from buffer seems good idea.

Please remember, that it's usual in common operating systems and other functions. that's why people involve buffers to avoid a situation to using IO too often (which is a bottleneck in general). of course flush it all the time after another calling of dump() has a nice effect but i'm not sure if we should follow this way.

shame on me. :) I get it wrong. flush for each packet is not good.

Hmmm maybe I could write a special Dump class which all methods like flush(), open(), close(), dump() ?

Yeah. It sounds better. It is in the direction of 2nd patch.

[getxsick]

Replying to luis:

No. I prefer 2nd patch. And I suggested adding a new method to set_file if is necessary.

OK...but then we have 2 functions instead of 1. and still more corner cases like "what if someone want to stop dumping in the middle of time?" then add another method like dump_finish()? i think we have to solutions:

1. keep it simple as 2nd patch is. we can pass a name to the constructor and get dumping. that's all
2. create a Dumper class which can have as many methods related to dumping as we want

Hmmm maybe I could write a special Dump class which all methods like flush(), open(), close(), dump() ?

Yeah. It sounds better. It is in the direction of 2nd patch.

But where to keep the object? I mean should we have an access to this class straight from pcap module? so user has to carry about it by hisself or pack it into pcap class and make closer relation to pcap object?

[luis]

Replying to getxsick:

Replying to luis:

No. I prefer 2nd patch. And I suggested adding a new method to set_file if is necessary.

OK...but then we have 2 functions instead of 1. and still more corner cases like "what if someone want to stop dumping in the middle of time?" then add another method like dump_finish()? i think we have to solutions: 1. keep it simple as 2nd patch is. we can pass a name to the constructor and get dumping. that's all 2. create a Dumper class which can have as many methods related to dumping as we want

Hmmm maybe I could write a special Dump class which all methods like flush(), open(), close(), dump() ?

Yeah. It sounds better. It is in the direction of 2nd patch.

But where to keep the object? I mean should we have an access to this class straight from pcap module? so user has to carry about it by hisself or pack it into pcap class and make closer relation to pcap object?

Regarding the API proposed by you in IRC:

import pcap

p = pcap.pcap("any")
p.dump.open("/tmp/x.cap")
p.next()
p.dump.dump()
p.dump.flush()
p.dump.close()

pcap.dump is create in pcap.pcap, right?

p = pcap.pcap("any")
d = pcap.dump
d.open("/tmp/x.cap")
p.next()
d.dump()
d.flush()
d.close()

if we look this way it looks more beaty.

What do you think?

[getxsick]

Firstly, I don't think that "beaty" is the most important thing. Anyway, as I said, I don't know. Both solutions have some pros and cons. I would like to hear ignotus opinion here.

[luis]

Replying to getxsick:

Firstly, I don't think that "beaty" is the most important thing. Anyway, as I said, I don't know. Both solutions have some pros and cons. I would like to hear ignotus opinion here.

It is a design issue. What counts is the quality of API, and what API does.

[getxsick]

current using patch for dumping

[getxsick]

with dump class

[getxsick]

I created tickets and attached patch in the official issure tracker of pypcap

findalldevs() - http://code.google.com/p/pypcap/issues/detail?id=17 loop() + cnt - http://code.google.com/p/pypcap/issues/detail?id=18 dump - http://code.google.com/p/pypcap/issues/detail?id=19 lookupnet() - http://code.google.com/p/pypcap/issues/detail?id=20

[getxsick]

I created tickets and attached patch in the official issure tracker of pypcap

• findalldevs() - http://code.google.com/p/pypcap/issues/detail?id=17
• loop() + cnt - http://code.google.com/p/pypcap/issues/detail?id=18
• dump - http://code.google.com/p/pypcap/issues/detail?id=19
• lookupnet() - http://code.google.com/p/pypcap/issues/detail?id=20

[getxsick]

I'm closing this ticket.

For futher development issues please follow URLs listed above to code.google.com

For user issues, please read: http://trac.umitproject.org/wiki/UMPA/PypcapModified

[getxsick]

this is a README which we include for our modified binaries of pypcap

[getxsick]

fixation for a timeout bug

[getxsick]

pcap_timeout.patch fix a bug for a timeout. so far the application never break so it looks like a freezing.

here is a code to reproduce a bug:

import pcap
descr = pcap.pcap("eth0", timeout_ms=10000)
descr.setfilter("host 1.1.1.1")
descr.next()

[getxsick]

it contains all patches (pcap_findalldevs.patch, pcap_lookupnet.diff, pcap_loopcnt.patch, pcap_dump3.patch, pcap_timeout.patch)

[luis]

the patch works fine.

I got yet the error compiling the pypcap:

$ make
(...)
pcap.c:1572: warning: pointer targets in passing argument 3 of ‘pcap_dump’ differ in signedness
gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fPIC -I/usr/include -I/usr/include/python2.6 -c pcap_ex.c -o build/temp.linux-i686-2.6/pcap_ex.o
pcap_ex.c: In function ‘pcap_ex_fileno’:
pcap_ex.c:165: error: dereferencing pointer to incomplete type
pcap_ex.c: In function ‘pcap_ex_next’:
pcap_ex.c:253: error: dereferencing pointer to incomplete type
pcap_ex.c: In function ‘pcap_ex_compile_nopcap’:
pcap_ex.c:292: warning: implicit declaration of function ‘mktemp’
error: command 'gcc' failed with exit status 1
make: *** [all] Error 1

Proposed solution by Francesco (tested on Linux and Mac OS):

Index: pcap_ex.c
===================================================================
--- pcap_ex.c	(revision 85)
+++ pcap_ex.c	(working copy)
@@ -12,7 +12,7 @@
 # include <signal.h>
 # include <unistd.h>
 #endif
-
+#define HAVE_PCAP_FILE
 #include <pcap.h>
 #ifdef HAVE_PCAP_INT_H
 # include <pcap-int.h>

Probably it should also be included, on tarball?

[getxsick]

this error during compilation depends on used operating system. it's worth to mention how to solve the issue but i dont know if it's correct solution to every system

[kosma]

add bindings for pcap_sendpacket() function

[kosma]

Attached patch adds bindings for pcap_sendpacket() function. The libpcap API has a second one, pcap_inject(), which returns the number of bytes sent; however, it uses a size_t argument, and presently using this type under Pyrex is problematic and hard to get right.

[kosma]

Gentlemen, we're in!

http://code.google.com/p/pypcap/people/list

Bartosz and me just got commit rights to the pypcap repository and we're going to merge the changes ASAP. Stay tuned.