Searching for packet catpuring and interface manipulation library for Python...

I needed a script that would monitor network traffic and capture and process only DHCP traffic. It turned out I couldn't find such script so I decided to write one (more about that script in another post). For a language I decided to use Python. That was the easy part. Now, I had to decide which libraries I will use that will allow me to capture network traffic, decode DHCP request and responses, and manipulate IP addresses on interfaces.

I started with the network traffic capturing. pcap library is the library for network capture, so it was natural for me to search for a Python interface to this library. I found several such interfaces, i.e. pcap, pylibpcap, pypcap, and pcapy. There is also library interface specifically for Python 3, i.e. py3kcap. While searching for pcap interface, three other Python libraries poped out: libdnet (here is the old project page), dpkt and scapy.

But, not all libraries are equal, nor they serve the same purpose. libdnet allows sending packets, manipulation with kernel's routing tables, firewall and arp cache. So, besides Ethernet and IP, it doesn't offer much more in term of supported protocols. dpkt, on the other hand, is made just for this purpose! It supports easy creation and parsing of different TCP/IP protocols. Finally, Scapy is a swiss army knife of network manipulation. It offers shell in which one can manipulate packets, but also can be used within other scripts. Unfortunately, while browsing the source of Scapy I realized that it uses os.popen interface and calls external programs. So, this actually was enough for me to eliminate scapy from further consideration.

The next elimination criteria is availability of the packages within CentOS and Fedora. I try to hold on prepackaged software as much as possible, so quick search (yum search) showed that on both, CentOS 6 and Fedora 17, there are packages for pcapy and dpkt (named python-dpkt). For some reason, there is dnet, but python interface isn't packaged. I found this bugzilla entry, but without any answer!

So, I settled on pcapy and dpkt. The only piece of puzzle that was missing now is how to manipulate interface addresses. I stumbled on netifaces, which allows me to obtain information about interfaces and also on this post for Windows. But all the results I got were on how to obtain IP address. In the end, I gave up and decided that I'll try to use libdnet even though I'll have to compile it from the source. Either that, or I'll use raw sockets and ioctls which are accessible from Python using standard libraries.

And for the end, as a curiosity, I'll mention that there is Python interface to IPTables, python-iptables, which is also packaged for Fedora.

ntop 5 on CentOS 6...

Last week I decided to install ntop on one of my CentOS 6 machines and, to much of my surprise, it turned out that there is no ntop package in the standard CentOS6 repositories (i.e. Base, EPEL, RPMFusion). Then, I looked into Fedora repository and it turned out that there is package, but for the older version, i.e. 4.0 (the newest version of ntop at the time this post was written was 5.0). So, I downloaded that older version, placed new version of ntop, modified a bit SPEC file and tried to build it. It didn't work intermediately, but after few more tweaks it worked. I filled a bug report on RedHat's bugzilla so that maintainter can upgrade a package, if he wishes so.

In the mean time, I decided to build package for CentOS 6. The main problem is that Fedora introduced Systemd instead of traditional SysV init used by CentOS. To cut the story short, I managed to do that, too. The resulting SPEC file can be used in both Fedora and EPEL6. I uploaded new SPEC file (and init file) to bugzilla, so you can fetch them there if you wish.

Until maintainers decide what to do, and if anything to do with it, here are the SRPM file and resulting binary RPM file for 64-bit CentOS6.

A case against wizards...

Well, I mean on those configuration wizards that allow you to quickly setup and get on going with something.

They have their advantages, but also disadvantages. In my opinion one big disadvantage is that they take away one very important thing from you and that is making mistakes. Yes, because we learn by making mistakes, and if everything goes right, we haven't learned much. In short term, you won, but in long term, I think you lose. Namely, when something doesn't go right - and things have a huge tendency not to go right - then, if you show a problem to a person that did a lot of mistakes, and the one that used wizard and didn't have a clue of what can go wrong, I think that the one that made mistakes will be more efficient in solving a problem.

So, what would be a conclusion? Well, I think you should first try a harder way and only after you mastered it, take a shortcuts to be as quick as possible.