More on moving WIDS to the Raspberry Pi 2.

So I’m using the Raspberry Pi 2 and Kali 2 for this project so far. As I said last time, I had to expand the image to use the full disk. I have a script for that now. I was actually trying to script the whole deployment. These scrips can be found on my WIDS github repository. But fair warning they are still a work in process.

The first script expand_image.sh downloads the packages needed for Kali 2 to expand the full disk using raspi-config. (wiggle is no longer maintained). It then drops the user in to the raspi-config program to make the changes needed.

The second script, doesn’t quite work right. Mainly because of SystemD. So what conf_drone.sh is supposed to do, is download needed software, run certain commands, and reboot in to a working Kismet Drone.

For the most part it works. It does download the commands, works with the user to set up password, date, system name, and other things. It even creates a working kismet_drone.conf file. It takes would would be 30 to 45 minutes of work and cuts it down to under 10 minutes.

The downside is when the box reboots, the kismet_drone doesn’t run right, and stops. After spending about 8 hours working on it, here is why:

The way we did things with sysvinit, the drone started in daemon mode by changing the /etc/rc.local file to include the start command. This was the last file ran on boot, by the init system starting Kismet.

Kali 2.0 uses SystemD. What SystemD does, is run it’s system unit files and calls /etc/rc.local last. If it takes to long to start, it fails. One can try to run kismet-drone –dameon & to put it in the background, a comment that some sites said to do if the command runs to long. But that doesn’t work either. Mostly because of WPASupplicant And NetworkManager, according to the logs on the Pi.

Breaking this down in to steps, I created a unit file for kismet on the Raspberry Pi. What caused more problems, because it exits with an error (status 1), since we are running it as root. SystemD expects commands to to exit status 0.  I adjusted the unit file to include that exit error as normal, and it now works. I also disabled WPAsupplicant and Network Manager by masking them in SystemD.

But the kismet_drone command still doesn’t work at boot. It starts, puts the interface card in to promiscuous mode, so I get wlan0mon, but it doesn’t appear to stay running. If I disable the unit file and start kismet_drone by hand it works fine.

Once I get the pi working, I’ll update conf_drone.sh script. In the meantime, Ian has an interesting workaround that seems to work, I haven’t tried it yet. He thinks the Raspberry Pi 2 boots too fast. I disagree. Yest it boots faster, but I don’t think that’s the actual problem, I’m thinking it is something with SystemD and kismet starting.

Leave a Reply

Your email address will not be published.