Kismet Wireless

Kismet Forums

 

Posted by:dragorn
Subject:A few questions I didn't find in the FAQ
Date:15:43:26 28/03/2011

> I read over the documentation for Kismet, but I seem to be having trouble finding out what language it is written in. (Yes, yes- look at the source files they might say, while pointing a finger and laughing). I was just hoping to find this out quickly while at work.
>
> The reason I ask is because several of my colleagues and I are planning to create a GUI frontend for kismet (We've yet to decide if we're going to take the GTK, AJAX/JS, etc route). We've been long time Linux users and want to actually contribute something back to the community even if it may not be much.
>

I've messed around with that before - it's fairly simple, it'd be fun to see a proper gui. Generally you'll want to write a daemon that functions as a kismet client (see the client examples in the ruby/ directory for starters) and either provide a webservice from the client code, or dump json/xml to a directory for the webui.

> Yes, it might be argued that the effort is futile because you can simply SSH into the box and run Kismet remotely. We say nay, however, and believe this would be beneficial regardless. Therefore:
>
> -What language(s) is Kismet written in?

C++, but if you talk to it as a client you can write it in whatever

> -Major dependencies?

Rfmon drivers, pcap, support libraries for interface management, and root access (for some portions). For a client, nothing, except TCP to the server.

> -Any advice as to which direction to start in for this undertaking?

I'd definitely approach this in 3 ways:

1 - A client daemon that talks to kismet and presents a webservice or files for the UI to collect over ajax. This could be in any language and would probably be trivial in ruby, for example.

2 - A kismet server plugin which creates a webserver, which exposes directly the internal data as json or xml for a ui, so that your ui issues ajax queries to the kismet server. This would have to be written in C++ and would be a fair bit more difficult, but would be a more tightly integrated system.

3 - If you're using a framework which allows persistent tcp connections (I don't know what xulrunner allows or if it's sane at all) you can look at talking to kismet directly on the client protocol. This would really only work if it can maintain a continual connection.


Reply to this message