Inspirated

During the course of my work on botnet security we have had to deal with mammoth traffic traces captured at a local ISP. While analyzing the traffic we needed to extract traffic for some certain hosts out of large pcap files. An obvious solution would be to run tshark once for each host, filtering the traffic for that particular IP and writing it to a separate pcap file. However with the number of hosts approaching thousands and the pcap traces approaching terabytes in size tshark didn’t really fit the bill.

Initially I thought of writing a splitter in Python but my colleague’s aversion for using Python on large network traces coupled with lack of maintenance of libpcap bindings resulted in me going for C/libpcap directly. The new C-based slicer is available at our GitHub respository. It needs glib to compile though, as I needed a hash table implementation for maintaining the list of hosts that need to be sliced. The Makefile in the repository should take care of compiling with the appropriate flags.

Onto the performance, the speed of slicing is only throttled by libpcap‘s own read/write throughput as most of the remaining work is done in constant time. It took only 71 minutes (or 1.1 hours) to slice 1019 hosts out of a 180 GB pcap file on 2.5 GHz CPU. In simpler words, it’s lightning fast.

Right now the script does its job well enough. If someone needs to package it I’ll prefer removing the glib dependency in favor of perhaps glibc‘s own hash table implementation (search.h). In any case, I hope it proves helpful for other people playing with large pcap files.

More often than not, Linux users will end up in a situation where they’d need to access their Windows neighbors on LAN. This can easily be accomplished using IP addresses, but using NetBIOS names is just too convenient to be overlooked.

The Xandros distro on Asus’ Eee PC does not resolve NetBIOS names by default. To make it perform that, you can do the following:

[user@host ~]$ sudo apt-get install samba samba-common smbclient winbind
[user@host ~]$ sudo kwrite /etc/nsswitch.conf

Once the editor opens, spot the line:

hosts: files dns

And append “wins” at its end, making it:

hosts: files dns wins

Save the file, exit the text-editor, back on command-line:

[user@host ~]$ sudo /etc/init.d/samba start
[user@host ~]$ sudo /etc/init.d/networking restart

Reconnect your network, and viola — easy peasy, Eee PC!

(Click on the thumbnail for larger version.)

(Or: Using Wine where plain-water should have been more than enough.)

Packet Tracer is a network simulator for Cisco devices. Caveat: It runs only on Windoze. Hence, there are three possible solutions for someone in need of using Cisco simulation on Linux:

• Wine: Wine’s setup varies from distribution to distribution. If you’re using Ubuntu, following commands should do the trick:

  [user@host ~]$ sudo apt-get install wine [user@host ~]$ winecfg

  [user@host ~]$ sudo apt-get install wine [user@host ~]$ winecfg

  Alternatively, for Fedora/RHEL/CentOS, use:

  [user@host ~]$ sudo yum install wine [user@host ~]$ winecfg

  [user@host ~]$ sudo yum install wine [user@host ~]$ winecfg

  Followed by:

  [user@host ~]$ wine /path/to/PacketTracerSetup.exe

  [user@host ~]$ wine /path/to/PacketTracerSetup.exe

  Once installed, you end up with:

  
  (Click on the thumbnail for larger version.)

  Pretty much usable. Although, fonts appear hideously ugly on default settings. Fortunately, you can change their sizes by going to Options >> Preferences >> Fonts from the Main Menu.

• GNS3: Setting up this particular piece of software is considerably difficult and definitely an overkill for newbies. This blog attempts to bridge the difficulty by providing video tutorials for installation, but that does not make GNS3 any lesser intimidating for users not already familiar with Cisco terminology or network simulation. For example, you’ll have to scavenge the Internet for IOS images you want to use, something you’d never have to think about in Packet Tracer for its supported devices.
• Pursue Cisco to release Packet Tracer on Linux: I was a bit surprised when I spotted that Packet Tracer is actually based on the cross-platform Qt GUI toolkit which would make porting it to Linux a trivial task for developers. Regrettably, knocking some sense in Cisco execs’ head is likely to be a far more laborious task than either of the solutions before.

“Sparrows who emulate peacocks are likely to break a thigh.” — Burmese Proverb Some geek Buddha annoyed at the trend of software developers relying on emulation for portability

Update: Cisco had after all started providing a native Linux version of Packet Tracer since last summer which I somehow missed because of its lack of appearances in my initial Google search. Here are the download links:

Fedora RPM: Rapidshare Part 1, Rapidshare Part 2
Debian/Ubuntu Installer: Rapidshare Part 1, Rapidshare Part 2
Linux Addons: Rapidshare

Google is obsessed with AJAX.

No, really. It’s starting to get on my nerves now. For those who’re unfamiliar with the term AJAX, it’s a combination of technologies (like Javascript) that, in essence, allow you to navigate on a web-page quickly without reloading the whole thing. The most prominent example people may recall is of Gmail’s interface.

So, why is it such a bad thing? Here’s the answer: it isn’t. When used properly, it can be great. Gmail, once again stands out as one of the leading examples here. Nevertheless, like any other technology, it has the potential of being abused. And, AJAX, when abused, can only be surpassed in terms of pure annoyance by Flash and Java. Quite surprisingly, the most effective example of “what not to do with AJAX” is also provided by Google, with its recent redesign of the social networking website Orkut.

In my opinion, Orkut is already a lost cause. No, not because Facebook is better. When Facebook started taking Orkut’s share, it wasn’t because Facebook was technologically superior to Orkut. And until just yesterday, I considered Orkut to be superior in at least that regard.

But now, Google decides to make all of Orkut’s pages empty. That’s right. Empty. All stuff would be loaded in those pages using AJAX and here’s the insane thing: they’re uniquely identified by anchors. That’s batshit insane. From a browser’s point of view, all of Orkut is a single page now. Stuff is just loaded on it dynamically using identifiable anchors like #Home.aspx. And no, there isn’t any fallback version. You just can’t use Orkut without Javascript now. All CGI-proxy access to Orkut (using sites like KProxy) is also broken now. My Orkut login frequency, thus, has taken a considerable hit and I really don’t think I’ll be using it even on weekly bases.

Aeternum vale, Orkut.