ToDo: Create own packet-parsing library

[GoogleCodeExporter]

Open ToDo nobody is currently working on:

We use like 15% of the scapy-library above libpcap to parse packets. Scapy
has numerous problems, most notably performance-wise. Parsing network
packets is a tough job, especially in C. 

Create a class (in _cpyrit_cpu.c) that can detect, parse and present
packets of our interest to pckttools.py in a pythonic way.

Original issue reported on code.google.com by lukas.l...@gmail.com on 1 Jan 2010 at 3:35

• Blocking: #261

[GoogleCodeExporter]

Regarding alternatives 
(https://pyrit.wordpress.com/2010/12/18/we-need-just-another-packet-parser-in-py
thon/#comment-414):

I don't see any decent packet-parsing library out there. Also, as I'd like to 
reduce external dependencies in Pyrit, I'll favor an internal solution. I see 
two possibilities:

1) Create packet-parsing classes inside Pyrit that can dissect 80211-packets 
(including radiotap-headers and what not). We'll have to rely heavily on the 
already implemented dynamic bpf-code to get decent performance.

2) Write a single parser in C that takes packets and spews out information that 
is of interest for us and available in the packet (e.g. a tuple of (stmac, 
apmac, essid, authentication_phase, nonce).

The second approach would be very fast but requires a *lot* of C-code that is 
not easy to maintain and debug.

Original comment by lukas.l...@gmail.com on 20 Dec 2010 at 12:41

[GoogleCodeExporter]

I think the best option is to create a packet-parsing classes. If you start it, 
I would help make code and use it on my own projects.

I am interested in this feature because I like to use in guifidecrypter 
project. (http://code.google.com/p/guifidecrypter/)

Original comment by NachE.NachE on 20 Dec 2010 at 5:07

[GoogleCodeExporter]

its not that scapy is based on bad ideas. its just that it is bloated beyond 
hope

Original comment by lukas.l...@gmail.com on 21 Dec 2010 at 7:39