If your question is not answered here, please consult our mailing list.
netsniff-ng is a high performance Linux networking toolkit. The project started during my B. Sc. thesis at the Max Planck Institute (actually just by accident and out of curiosity), and continued to grow into a useful toolkit ever since. At the time of its initial development, the famous libpcap library did not support zero-copy extensions of the Linux kernel. Therefore, we closed this gap by developing an analyzer and further tools around it, which had a significantly better performance than existing ones that used libpcap at that time. To be fair, later on zero-copy support was added to libpcap. However, we had/have a lot of fun with this project, so it grew and is on a good way to become mature. Nowadays, it's used by many professionals, it runs on quite a lot of servers or routers on production systems, and even is as a backend for Linux network security distributions. It really got quite serious. ;-)
netsniff-ngs main goal is to be a high performance network toolkit that focuses on usability, robustness and functionality. Its aim is to support the daily work of networking engineers, developers, administrators or Linux users by providing support with or in network monitoring, protocol analysis, reverse engineering, network debugging, traffic generation, measurement and penetration testing.
Sure, we're always happy to hear that. If you think this software is good, then please consider sending / buying us hardware like high-end 10Gbit/s capable servers, switches, routers, or access points, wireless cards or other (also exotic) kind of embedded systems in order to do research, test our software and integrate new features. You are welcome to leave us an email to .
New releases will be announced on our homepage, mailing list and Freshmeat. We have a project page at Freshmeat where you can subscribe.
Yes, of course there is. It's a moderated, spam-free mailing list on Google where you can post your questions to .
Nope, there is no offical one.
Nope, sorry. We rather like spending our time hacking the code. (I know, in the past, we had one.)
What blog? No, sorry. ;-)
Because we like HTML too much. ;-) Moderating all those comments costs too much time that we could also spend on development. If you'd like to discuss certain issues, then please use our mailing list.
For instance, on commodity hardware with Gigabit-Ethernet, you can reach wirespeed with trafgen (64 Byte, 1.34 Mio pps). Measurement results on 10GBit/s will come soon.
Yes. The statistics are extracted from the kernel directly (procfs), so this is what the NICs device driver gets to see. There is no sniffing or the like involved to generate these figures, such as iptraf does.
It's netsniff-ng's Documentation folder in the repository. Everything that needs to be known for using the toolkit is documented there. There are more general documents to get an overview and tool specific ones with a higher degree of details.
Currently only operating systems running on Linux kernels with CONFIG_PACKET_MMAP enabled. This feature can be found even back to the days of 2.4 kernels. Most operating systems ship pre-compiled kernels that have this config option enabled and even the latest kernel versions got rid of this option and have this functionality built-in. However, we recommend using a kernel >= 2.6.31, because the TX_RING support has been added since then. Ideally, you compile a kernel on your own from the latest Git tree.
Look at INSTALL in the repository.
The latest one from our Git tree, if possible.
Yes, if the dumps are formatted as pcap files. This is default on Wireshark, for instance. Vice versa, Wireshark can also read netsniff-ng dumps.
If you want to run netsniff-ng in combination with -f or --filter <file> you need to build a so called Berkeley Packet Filter program within a plaintext file (here, marked as: <file>). The Berkeley Packet Filters language description can be obtained from netsniff-ngs documentation section. One way to create a custom filter for the non-lazy people is to hack the opcodes by hand according to the specification. In this case you have all the freedom to build your filters for your needs. The alternative way is to use tcpdumps -dd option. Simply pipe the output into a textfile and pass this to netsniff-ng.
Furthermore, we already ship some common filters and we are planning our own filter compiler! Most distributions put these files into /etc/netsniff-ng/rules/.
If you try to create custom socket filters with tcpdump -dd, you have to edit the ret opcode (0x6) of the resulting filter, otherwise your payload will be cut off:
0x6, 0, 0, 0xFFFFFFFF instead of 0x6, 0, 0, 0x00000060
The Linux kernel now takes skb->len instead of 0xFFFFFFFF. If you do not change it, the kernel will take 0x00000060 as buffer length and packets larger than 96 Byte will be cut off (filled with zero Bytes)! It's a bug in libpcaps filter compiler. Detailed information about this issue can be found on our blog post.
I rudely refer to the dSniff documentation that says:
The easiest route is simply to impersonate the local gateway, stealing client traffic en route to some remote destination. Of course, the traffic must be forwarded by your attacking machine, either by enabling kernel IP forwarding or with a userland program that acccomplishes the same (fragrouter -B1).
Several people have reportedly destroyed connectivity on their LAN to the outside world by arpspoof'ing the gateway, and forgetting to enable IP forwarding on the attacking machine. Don't do this. You have been warned.
Yep, again, look at INSTALL.
Nope, it's the GPL version 2.0 and this is not negotiable.
Yes, if you mean "I work for a commercial organization and I'd like to use netsniff-ng for capturing and analyzing network traffic in our company's networks or in our customer's networks.".
It depends, if you mean "Can I use netsniff-ng as a part of my commercial product?". See below.
As long as your commercial product then stays compatible with the GNU GPL, version 2.0, then it should be no problem. Have a look at the frequently asked questions of gnu.org in order to clarify your questions.
netsniff-ng is "free software"; you can download it without paying any license fee. The version of netsniff-ng you download isn't a "demo" version, with limitations not present in a "full" version; it is the full version. And the good thing is: it will always stay that way!
netsniff-ng is licensed under the GNU GPL, version 2.0. Read more about this here.
For the fun of hacking on great software and contributing to the open source community. And also, to fill the gap with some useful missing tools that can replace expensive commerical ones with even better features.
No, actually we don't. We should. Well, we used to, but since netsniff-ng is a spare time project and sometimes there's lots of other stuff to do and sometimes not, we are more flexible and independant this way without making hard deadline promises. Nevertheless, netsniff-ng is a long-term project, so even if there's hard times for weeks of not pushing to Git, there will be others with the opposite situation. We think netsniff-ng is useful for our daily network engineering work and research and we will do our best that it stays this way! This should be your take-home message! ;-)
Well, that depends. If it's a good feature and you make us think that adding this would make sense, then why not. You are also free to discuss this specific feature with us and post patches or pull requests.
Nope, consider it as dead.
Sure, we'd be happy about that. Send us your ideas or code and we're going to evaluate and probably integrate it. Have a look at the HACKING file. The release Git repository is located at http://repo.or.cz/w/netsniff-ng.git, so you are free to clone and hack.
Have a look at the Documentation folder of netsniff-ng's source for further instructions.
Have a look at the Git documentation at http://www.kernel.org/pub/software/scm/git/docs/.
Nope, GUIs suck.
Not sure yet.
Probably not, because a vanilla kernel must be enough to run the toolkit.
Well, no. There are two reasons for this: First reason is, that it's not part of the mainline kernel. A interesting discussion about getting PF_RING into the kernel can be found at the netdev lists (http://lists.openwall.net/netdev/2009/10/14/37) and obviously there are no further efforts (browse the netdev/LKML, also netfilter) from the ntop project to merge both architectures or add features to PF_PACKET. Second reason is that we've evaluated the PF_RING (without the commercial Direct NIC Access [DNA]) regarding its performance and came to the conclusion, that there is no significant performance enhancement on our IBM HS21 Bladeserver test system. ntopi's DNA ships its own versions of some modified device drivers like Broadcoms tg3 and NetXtreme, Intels e1000(e), igb and ixgbe. Since these modifications are not official, neither to the kernel, nor to the vendors and cover only a small amout of what is out there, we're not doing further investigations at the moment. Also, netsniff-ng users have reported similar observations. A benchmark with PF_RING in transparent_mode 0 and 1 is even slower than netsniff-ng and in transparent_mode 2 both have the same performance. The test was done on a Dell PowerEdge 2850. Nevertheless, ntop is a very interesting project you definately should check out!
Yes, but only for Red Hat and Debian GNU/Linux, which then automatically gets updated in some other distros like GRML. People that maintain netsniff-ng in other distributions are listed within the MAINTAINERS file.
Nope, what a question. It runs only on real operating systems.
Could be possible for the future. If you have something we can merge, let us know.
Nope. Always patch against the official upstream repository.
No, 8 tools (netsniff-ng, trafgen, mausezahn, bpfc, ifpps, flowtop, curvetun, astraceroute) are enough. We now rather focus on improving them and their features, clean up the code and fix bugs.
$ flite -o play -t "netsniff n g"
Yes, here (note: we do not take any commission for the products).
Great! We'd very much like to see it. Please mail it to us ;-)