Updating talk

For Bsides, as mentioned earlier, I’m making some changes for the talk.

For Bsides Detroit I’m swapping out the original Raspberry Pi B devices from the project for the Raspberry Pi 2 B.

The first time I did this, with the RPi-B, I made one image got it working and then cloned it to the others. It caused minor problems with the wireless card naming. I also still had to touch them all to change names, static ip addresses, and the kismet configs.

This week there was a new version of Kali out for the Raspberry Pi 2 when I checked. So I downloaded it, patched it and installed the software. Then created the clone image.

I am going to have to touch each one anyway so figure I will just get the one image with the software, and then load each one and configure it.

4 thoughts on “Updating talk

  1. Ian

    Hey Chris.

    I read your Rogue AP detection on Linux Journel with great interest, great work. I’ve actaully decided to do much the same.

    I’ve got it working just fine, the kismet drones are all reporting back in just fine.

    I have one question though – did you ever manage to get kismet_drone launching automatically on reboot on your Pi devices? I have attempted to create @reboot cron enteries and play with rc.local in an attempt to get it started but failing. I’ve attempted all kinds of args, including -f to specify the config and -s for silent. Whatever I do the kismet server connects to the drone but is unable to receive data.

    I’m wondering if a dependancy is’nt starting correctly. I can see the process when I ‘ps aux | grep kismet’.

    Any ideas? Having the process start automatically on Pi reboot is pretty important for me.

    FYI – Running Pi 2s with custom Kali 2.0 image.
    I’ve attemped to stalk you on linkedin, but perhaps you’ll see this first.

    Thanks very much!

    Reply
    1. Ian

      PS. Your original article suggests rc.local – my first attempt with the following. Fails for me sadly….

      # start kistmet
      /usr/bin/kismet_drone –daemonize

      exit 0

      Reply
      1. Ian

        Found the answer. Phew. Seems the Pi2 just boots too quickly! I guess it needed time for the NICs to settle after boot tasks. I had to put a sleep statment in a script. I ended up calling it from a crontab @reboot job rather than rc.local.

        Not sure if it will be any use to you, but here’s what I ended up with (sleep 3 also appeared to work):

        #!/bin/sh
        sleep 5
        ifconfig wlan0 down
        iwconfig wlan0 mode monitor
        /usr/bin/kismet_drone –daemonize

        Reply
  2. chrisj Post author

    Ian, I saw your request on LinkedIn I accepted, and have been waiting for mail.

    I hadn’t tried the pi 2 yet. I have 6 sitting next to me right now. they have kali 1.10 on them, I’m going to try and upgrade them this weekend. I also have to get them set up as drones.

    ifconfig wlan0 down, and iwconfig wlan0 mode monitor shouldn’t be needed, unless something really funky is going on. Kismet should be starting the devices in monitor mode.

    hmm… now things to watch for this weekend.

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *