Jump to content

dvarapala

Active Members
  • Posts

    6
  • Joined

  • Last visited

Posts posted by dvarapala

  1. I'm seeing similar issues. For unknown reasons the Karma AP on wlan0 will vector off into la-la land after some apparently random period of time (could be minutes, could be hours). Once it goes south, probes are no longer reported in the Karma log and devices can no longer connect to the AP. Rebooting the Pineapple restores normal functionality for another variable period of time until the next failure occurs. Generally my Pineapple sits in my office running 24/7, but I also take it out for a WarWalk about once per day, so the power cycles associated with that activity help to avoid the issue. However, as things currently stand, my Mark V is unusable for long-term unattended deployments.

  2. Update: It turns out I can poll the DIP switches from a Python script in exactly the same way that the Pineapple startup scripts do when the Mark V first boots up. So I stole some code and produced this:

    #!/usr/bin/python
    #
    # NOTE: CURRENTLY HARD-CODED TO WATCH THE MIDDLE DIP SWITCH (#3)
    #
    
    import os
    import time
    
    # DIP SWITCHES 2, 3, AND 4 CORRESPOND TO THESE GPIO PORTS
    #gpio_list = [13, 15, 16]
    
    def export_gpio (gpio):
      file = open('/sys/class/gpio/export', 'w')
      file.write( str(gpio) )
      file.close()
    
    def unexport_gpio (gpio):
      file = open('/sys/class/gpio/unexport', 'w')
      file.write( str(gpio) )
      file.close()
    
    def get_gpio_states (gpio_list):
      states = []
      for gpio in gpio_list:
        export_gpio(gpio)
        file = open('/sys/class/gpio/gpio'+str(gpio)+'/value', 'r')
        if gpio == 16:
          states.append(int(file.read())*(-1)+1)
        else:
          states.append(int(file.read()))
        file.close()
        unexport_gpio(gpio)
      return states
    
    def get_gpio_state(gpio):
      export_gpio(gpio)
      file = open('/sys/class/gpio/gpio'+str(gpio)+'/value', 'r')
      state = int(file.read())
      file.close()
      unexport_gpio(gpio)
      return state
    
    def wait_gpio (gpio):
      state = initial_state = get_gpio_state(gpio)
      while (state == initial_state):
        time.sleep(5)
        state = get_gpio_state(gpio)
    
    def main():
      wait_gpio(15)
    
    if __name__ == "__main__":
      main()
    

    The main shell script then becomes:

    #!/bin/bash
    
    # START CLEAN
    /usr/bin/pkill hostapd
    /usr/bin/pkill gpsd
    /usr/bin/pkill kismet
    /sbin/ifconfig wlan0 down
    /sbin/ifconfig wlan1 down
    
    # START GPSD
    /usr/sbin/gpsd -n /dev/ttyUSB0
    
    # MONITOR GPS STATUS AND WAIT FOR SAT LOCK
    /usr/bin/gpspipe -l -w -n 10 | grep -qm 1 '"mode":3'
    
    # PARSE THE CURRENT UTC TIME FROM THE GPSD OUTPUT
    UTCDATE=`/usr/bin/gpspipe -w -n 10 | grep -m 1 "TPV" | sed -r 's/.*"time":"([^"]*)".*/\1/' | sed -e 's/^\(.\{10\}\)T\(.\{8\}\).*/\1 \2/'`
    
    # SET THE PINEAPPLE'S CLOCK
    /bin/date -u -s "$UTCDATE"
    
    # LAUNCH KISMET DAEMON
    /usr/sbin/iwconfig wlan0 mode Monitor
    /usr/sbin/iwconfig wlan1 mode Monitor
    /usr/bin/kismet_server --daemonize
    
    # WAIT UNTIL DONE
    /bin/pineapple led blue on
    /sd/logs/dip-wait.py
    
    # SHUT STUFF DOWN
    /usr/bin/pkill kismet_server
    
    # WAIT FOR KISMET TO SAVE FILES AND EXIT CLEANLY
    /usr/bin/pgrep kismet
    while [ $? = 0 ]
    do
    /bin/sleep 1
    /usr/bin/pgrep kismet
    done
    
    # SHUT EVERYTHING ELSE DOWN
    /usr/bin/pkill gpsd
    /sbin/ifconfig wlan0 down
    /sbin/ifconfig wlan1 down
    /bin/pineapple led amber off
    /bin/sleep 5
    /sbin/poweroff
    

    So when I want to go WarWalking I flip the middle DIP switch down and aplpy power; when I get back, I flip the middle DIP switch back up, wait for the LEDs to go out, and then turn off the power switch on the battery. It works as expected for the most part, although for reasons I still don't understand the .gpsxml file that Kismet produces still gets truncated sometimes even though Kismet was existed cleanly with a SIGINT and I waited for any disk buffers to be flushed to the SD card. Either 5 seconds isn't long enough or there's something else going on.

  3. tl;dr: I've had a couple instances of my WarWalking data being corrupted when shutting off the Pineapple at the end of a session. Any suggestions for a method to cleanly shut down the Mark V without having to SSH in and type commands? For example, I believe the DIP switches are currently only read at power-up; maybe there's a way to configure one of them to generate a GPIO interrupt and have the interrupt handler signal a shutdown script?

    Full Story:

    I purchased the "Tactical Bundle" a while back and have been using it, along with the awesome GlobalSat BU-353S4 USB GPS puck, to do a little WarWalking. I ran into some problems along the way and thought I would share my solutions here in case others are having the same issues.

    Problem: I wanted to capture using both radios for fewer missed packets. Kismet supports this and will automatically coordinate the channels on each radio so that each one is always listening to a different channel.
    Solution: Kill hostapd process and put both radios into monitor mode.

    Problem: I wanted to auto-start in WarWalking mode at powerup, so I don't have to SSH in to type commands or start anything manually.
    Solution: Configure the DIP swiches to run a script (attached below).

    Problem: Pineapple has no RTC, so when it boots up without a network connection the NTP daemon cannot set the clock. This results in all the Kismet output files having the same "January 1st" date.
    Solution: Get the time from the GPS data stream. In my startup script I added a few lines to 1) Wait for gpsd to acquire a 3D satellite lock, and 2) to parse the output of gpsd for the time and use that info to set the system clock.

    Problem: Heat buildup inside the messenger bag. The Tactical Bundle comes with a very nice bag, but it has zero airflow through the interior, and the Pineapple runs a bit warm.
    Workaround: Limit duration of war walks. Most of mine last under an hour, so it hasn't really been an issue. Still, heat is the enemy of electronics' longevity, so I'd like to keep things as cool as possible.
    Solution: Different bag with better airflow. I've seen bags with mesh pockets on the outside which looks like they would have good airflow, but then the Pineapple is basically out in plain sight so stealth goes out the window. Plus there's no protection in case of a sudden rain shower or lawn sprinkler.

    Problem: Shutting down cleanly to avoid file corruption. I've discovered it's possible to have the Pineapple lose power just as Kismet is writing out its data files, resulting in a zero-length .netxml file and complete data loss. Don't ask me how I know this. :wacko:
    Workaround: Upon returning home, plug into the network, SSH in and shut Kismet down manually. A bit of a pain, but it works.
    Solution: ??? Looking for ideas here! :smile:

    Here is my startup script that gets executed when the middle DIP switch is in the down position.

    #!/bin/bash
    
    # START CLEAN
    pkill hostapd
    pkill gpsd
    pkill kismet
    /sbin/ifconfig wlan0 down
    /sbin/ifconfig wlan1 down
    
    # START GPSD
    /usr/sbin/gpsd -n /dev/ttyUSB0
    
    # WAIT UNTIL IT'S READY TO ACCEPT CLIENT CONNECTIONS
    sleep 1
    
    # MONITOR GPS STATUS AND WAIT FOR SAT LOCK
    gpspipe -w | grep -qm 1 '"mode":3'
    
    # PARSE THE CURRENT UTC TIME FROM THE GPSD OUTPUT
    UTCDATE=`gpspipe -w | grep -m 1 "TPV" | sed -r 's/.*"time":"([^"]*)".*/\1/' | sed -e 's/^\(.\{10\}\)T\(.\{8\}\).*/\1 \2/'`
    
    # SET THE PINEAPPLE'S CLOCK
    date -u -s "$UTCDATE"
    
    # LAUNCH KISMET DAEMON
    /usr/sbin/iwconfig wlan0 mode Monitor
    /usr/sbin/iwconfig wlan1 mode Monitor
    /usr/bin/kismet_server --daemonize
  4. I would like to use my Mark V for some WarWalking but I'm having some issues.

    I installed the kismet-server package via opkg, but it's an old version (2010-07-R1-2) and not the latest (2013-03-R0) - is there a way to get the latest version?

    The main issue I'm having is that Kismet cannot change channels on either wlan1 or wlan0, even after I kill the hostapd process. It dumps out an endless stream of error messages of the form

    ERROR: mac80211_setchannel() could not set channel 5/2432 on interface
    'wlan1mon' err -25
    ERROR: mac80211_setchannel() could not set channel 9/2452 on interface
    'wlan1mon' err -25
    ERROR: mac80211_setchannel() could not set channel 2/2417 on interface
    'wlan1mon' err -25

    In searching the web for a solution, I read on the Kismet forums that the new version of Kismet may solve this issue (if only I could find a newer package).

    BTW, this issue seems to have cropped up only recently. I'm pretty sure Kismet was working fine with the original 1.4 firmware that came with my Mark V, but now that I've upgraded it to 2.0.4 I'm having this issue; is it possible that this is related to PineAP, which is now using wlan1 which wasn't in use before?

    All suggestions appreciated!

×
×
  • Create New...