Problem daemonizing KISMET_DRONE for auto-start on boot. Any ideas?

[Ian]

Hey all,

I'm setting up some Raspberry Pi 2 devices for the purposes of rogue acccess point detection.
So far so good, I've installed kismet on the Pis and can run kismet_drone and have them report back to another kismet server off-box.

My set up.
Raspberry Pi 2 - setup with the custom Kali Linux 2.0 image. - ALFA AWUS051NH v2 USB WIFI NICs
ESXi guest - setup from scratch using Kali Linux 2.0 ISO

So far, so good.

However the problem occurs when I attempt to daemonize the kismet_drone binary to launch on boot.
I have attempted to add it as a a direct entry in both a @reboot crontab job and an entry in /etc/rc.local.
I have also attempted to pass full args in the command (eg. /usr/bin/kismet_drone -s -c wlan0:type=rt2800usb -f /etc/kismet/kismet_drone.conf --daemonize )
I've also attempted to stop the wlan0 adaptor, put it into monitor mode, restart it and then launch kismet_drone in a shell script via both of the startup options above.

When I reboot the external Kismet server appears to connect to the drones however no data is received even though the connection is established.
If I run the script / command when logged into the machine however it works.

The only odd behavour I can see from the output is that I get the following messages:
INFO: Bringing down primary interface 'wlan0' to prevent wpa_supplicant and NetworkManager from trying to configure it.
Followed by cannot connect to wlan0mon - the interface is not up
Then finally, restarting wlan0

Then everything kicks in. Perhaps this isnt happening when I daemonize it?

Occasionally I will get: Source 'wlan0' : channel get ioctl failed 22:Invlaid argument.
Restarting (with the wlan0mon having already been created) works. Perhaps this is whats happening on daemon launch, no idea.

Any gurus out there with any ideas? Thanks very much in advance.

[Ian]

Thought I'd update this post as I managed to resolve it after a lot of hair pulling.

It turns out that the raspberry Pi with Kali just boots too **** quickly! :-) The NIC was obviously still finishing their startup routines and although the kismet_drone app starts and responds to the master server, it was unable to work with the NIC when envoked.

The simple solution was to put a sleep statement in my script. I called this from a @reboot cronjob and it ended up looking like this to get everything working:


#!/bin/sh
sleep 3
ifconfig wlan0 down
iwconfig wlan0 mode monitor
/usr/bin/kismet_drone --daemonize


Although a painfully easy solution, hopefully it might assist someone else trying to achieve the same thing at some stage.

[rattis]

Hi Ian,

I finally got around to playing with Wifi Intrusion Detection using Raspberry Pi 2 and Kali 2.0.1.

There are some changes that need to be made to the config file. adding networkmanagersleep=false takes care of "Source 'wlan0' : channel get ioctl failed 22:Invlaid argument" error. I also had to add channellists. Neither of those were needed with the article on Linux Journal were written.

I still can't get the daemon to start from rc.local, even with a 10 second sleep in it. Doing some trouble shooting, and trying to start it in the background, like the Raspbian site say for long running scripts, is leading me to believe it is a systemd issue. Creating a systemd service is getting an error about status 1/Failure. have a feeling because kismet drone is throwing an error about starting as root.

[rattis]

Solved so Systemd (which replaced init in Kali 2.0) starts at boot.

create file /etc/systemd/system/kalidrone.service

[Unit]
Description=Kismet Drone Daemon
After=network.target auditd.service

[Service]
SuccessExitStatus=0 1
ExecStart=/usr/bin/kismet_drone

[Install]
WantedBy=multi-user.target

Then tell systemd to use that file.

systemctl enable kismetdrone.service

reboot.

several things caused the problem:
1) we are running as root which causes non "exit 0" status. Systemd doesn't like that.
2) need to wait for networking to be up before starting kismet_drone
3) systemd doesn't seem to handle daemons very well (I noted that ssh service had ssh -D (no daemon)).