Probe Request Frequency / Channel Hopping Timing

[hooded_warrior]

Hi,

I've written a script in python to sniff packets on an MR-3020 running OpenWRT. Since there is only one radio I hop through channels 1 - 11 and then every 10 minutes get out of monitor mode, connect to the internet, and send the data up to my server.

I can see lots of packets in the area, but when I filter for probe requests the amount of activity becomes MUCH more sparse. Every now and then I'll pick something up, but I'm sitting here with like 5 phones, an iPad, Sonos, a couple computers, etc. and would think that I should be picking up a probe request every couple seconds / minutes.

I'm wondering if I'm jumping channels or calling the sniff method too fast or slow and I'm just missing them all? Is there something else that I may be doing wrong? Thanks in advance!

class Main():
    while run:
        logger.debug("Starting Sensor Run Loop.")
        sniffer.stop()
        hopper.stop()
        time.sleep(2)

        execute_command("wifi up")
        time.sleep(10)

        logger.debug("Do Internet Things.")
        try:
            logger.debug("Calling Saver.")
            Saver.save()
            logger.debug("Done with Saver.")
        except e:
            logger.error("There was a different error: %r" % e)
            pass

        start_monitor_mode()

        time.sleep(2)

         hopper_thread = Thread(target=hopper.start, name="hopper_thread")
         hopper_thread.start()

         sniffer_thread = Thread(target=sniffer.start, name="sniffer_thread")
         sniffer_thread.start()

         time.sleep(60*10)

class Sniffer(Thread):
 
    def start(self):
        self.run = True
        logger.info("Starting Sniffer Loop.")
        while self.run:
            try:
                sniff(iface=self.monitor, prn=self.process_packet, timeout=1)
                logger.debug("Sniffing")
            except:
                e = sys.exc_info()[0]
                logger.error(e)
            time.sleep(2)
 
    def process_packet(self, pkt):
        logger.debug(str(pkt.addr2))
        if pkt.haslayer(Dot11ProbeReq):
            PacketQueue.add_packet(self._process_probe_request(pkt))

class Hopper(Thread):

    def start(self):
        logger.info("Starting Hopper Loop.")
        self.run = True
        max_channel = 11
        
        while self.run:
            try:
                self.channel += 1
                if self.channel > max_channel:
                    self.channel = 1
                    self.execute_command('iw ' + self.monitor + ' set self.channel ' + str(self.channel))
                logger.debug("Channel: " + str(self.channel))
                time.sleep(1)
            except:
                e = sys.exc_info()[0]
                logger.error(e)

[cooper]

When probe requests are sent, they are sent on a specific channel. If at this moment in time you're not actively listening on that channel there's a fair chance you'll miss the request. Since you're scanning channels 1-11 in order there's a 9% chance of seeing a specific probe request. The probability goes up somewhat due to the overlapping nature of the channels and you might see a probe request on channel 5 when listening on channel 6, but the better your radio, the smaller the chance of this happening.

Also, I'm fairly confident that my phone isn't sending anything unless I'm actively using it. Just because I'm home now doesn't mean it's automatically constantly connected to my wifi - that would chew through the battery WAY too quickly. Instead, when I unlock my phone will it start to seek out wifi networks, which would presumably imply the sending of probe requests. I can see this because initially when I unlock my phone the wifi icon isn't on. Instead, it shows the 3G icon (old phone).

And finally, when a device is connected with a Wifi AP and this connection is sound, does it still send out probe requests? I'm asking because I honestly don't know, but it would seem like a complete waste of bandwidth.

[digip]

AS far as I know, every device has it's own probe timing interval and a response frame associated from the AP if it replies, so you should see both when this happens but you should only see them when the devices are scanning for the AP, which it sends a probe to the broadcast address of the AP and then gets a reply. Beacons are just the AP broadcasting hello world, I'm here. If the reply from the AP isn't seen during a certain time frame, the client will continue to probe for it though, especially if it was just associated with it, which is why we do things like a deauth attack to force clients to reconnect and look for their known associated AP allowing us to capture stuff like a handshakes for WPA(2) access points or IV's for WEP.

If you cause the AP to go down too much, you can cause a probe flood if enough clients are associated with it and get knocked off, which most clients will try to automatically reconnect by default.

To get better results from your scanning, occasionally send a few deauths every so often during your scripted process so you can watch for the probe requests. This will give you better results in seeing what is out there, and some of the devices when they get disconnected, will start scanning for other known AP's as well, so the probes will start to stack up for more than one AP from the same device if they use more than one regularly and have them stored on them. I wouldn't know how to write this into your code above, but if you have the aircrack-ng suite installed, this becomes very easy to monitor with little scripting needed to automate the tools and write it all to a pcap file for later dissecting in wireshark or whatever tool you like for reading packets.

Edited May 10, 2015 by digip