
Libtins – High-level and multiplatform C++ network packet sniffing and crafting - adulau
http://libtins.github.io/
======
jzwinck
The linked page says "High level != inefficient" and shows an example program
which will print "every TCP packet".

With no "if" anywhere in the code, I wondered how it knew to print only TCP
packets and not others. And the answer turns out to be that it throws a C++
exception on every non-TCP packet!

If most of the packets on your network are TCP, this is sort of OK. But if you
have mostly non-TCP packets, this toy program costs about 10x the CPU
utilization that it would if it used "if" instead of magic.

~~~
_wmd
There are plenty of ways they can keep the current API while eventually
approaching optimal, for example, a chain of exceptions could incrementally
refine the framework's idea of what the callback function expects, which could
be turned into a BPF filter.

So for the cost of a few expensive frames at start, afterwards no exceptions
get thrown.

Generally speaking though, I'm only replying because I hate people negging on
minutia of new projects. If you're going to be critical of something
especially when it's a lone wolf effort (or even a small team), try to be
constructive, there are real people on the other end of the wire.

~~~
jzwinck
A more charitable reading of my comment would be that I am recommending the
use of "if" instead of C++ exceptions for hot-path control flow in high-
performance libraries.

Heuristic construction of a packet filter based on previously seen exceptions
is infeasible with the current API because rejection of the first N non-TCP
packets does not guarantee rejection of the next one.

~~~
to3m
There appears to be an alternative API that doesn't throw exceptions:
[https://github.com/mfontanini/libtins/blob/37c92fcf5c83b034a...](https://github.com/mfontanini/libtins/blob/37c92fcf5c83b034a280fd6070fb467e3d0c87bd/include/tins/pdu.h#L75)

(rfind_pdu uses it internally:
[https://github.com/mfontanini/libtins/blob/37c92fcf5c83b034a...](https://github.com/mfontanini/libtins/blob/37c92fcf5c83b034a280fd6070fb467e3d0c87bd/include/tins/pdu.h#L369))

------
hacknat
If anybody is interested I wrote a zero-copy socket wrapper in golang it's
pretty fast and has built in layer detection and checksum functions:

[https://github.com/nathanjsweet/zsocket](https://github.com/nathanjsweet/zsocket)

------
ktta
Also check out packit[1] a command line packet crafter. It is very easy to use
once you really understand how to use it. Also it has no 'restrictions' on
what packets can be crafted. It lets you get away with as much as possible.

It should be readily available on most package managers, atleast debian based
last time I checked.

[1]:[http://packetfactory.openwall.net/projects/packit/](http://packetfactory.openwall.net/projects/packit/)

~~~
mariuolo
The active version appears to be hosted here:
[https://github.com/eribertomota/packit](https://github.com/eribertomota/packit)

~~~
ktta
No, I thought so too initially. The person is just hosting the project looking
for a maintainer(he is hosting other abandoned projects too). Debian project
is also looking for someone to maintain the package.

~~~
mariuolo
Still, Debian packages the (updated) github version.

At least in Sid.

------
01572
Since commenters are weighing in on packet construction libraries, what say
you in re: libnet1.0/libnet1.1?

libnet-based modular utilities that can be used in shell scripts:

[http://nemesis.sourceforge.net/docs.html](http://nemesis.sourceforge.net/docs.html)

Also, earlier was nc-data. Slow but allows constructing any packet from the
command line. Not limited to known packet formats.

[http://nc110.sourceforge.net](http://nc110.sourceforge.net)

Let us hear your criticisms.

------
ktta
>Note: the scapy benchmarks look like it takes almost the same time as the
impacket ones, but it actually doesn't. In fact, it takes so much time that
the maximum Y-axis value had to be restricted. Otherwise the rest of the bars
couldn't almost be seen. If you hover over each bar, you will see the actual
times in seconds.

wow, they weren't kidding. In the first and the last graph, scapy is ten times
slower than the next slowest lib.

~~~
d33
Well, scapy's code is not of the highest quality - it still uses os.popen and
calls tcpdump:

[https://github.com/secdev/scapy/blob/728177bff883f170e9ac004...](https://github.com/secdev/scapy/blob/728177bff883f170e9ac0042fa9723888ef6888d/scapy/arch/linux.py)

------
vram22
Somewhat related: pcapy is a useful Python library for network packet
handling. We used it recently in a project after evaluating it and a few
others (not very thoroughly, though). dpkt is useful too.

pcapy can read from a live stream or from a packet capture file (.pcap
format).

~~~
jcul
I've found pyshark to be great too, especially for reading from a pcap. Scapy
is great but has too many performance issues.

~~~
vram22
Thanks, will check out pyshark. I read the same about scapy somewhere,
otherwise its interface seemed good (on only a little trying).

------
jaimehrubiks
How flexible it is despite being high level? I mean, can I use any field on
those supported protocols? Can I tunnel TCP inside, say, dns? can I
implement/send custom protocols without touching the lib?

------
CoC_CRUSHER
Would love to see a header only version of this library.

