SSID Broadcast Rate and Order

[Skinny]

I'm doing a bit of research using Wireshark to examine the behavior of the Tetra in different modes of operation. I'm getting results, but I don't trust that my equipment is reacting fast enough to the packets being broadcast. Can anyone tell me the rate at which the broadcast packets occur (number / sec) when the Pool Interval is set to Normal and the order the SSIDs are broadcast. With my Wireshark capture it indicates a rate of roughly 40 packets per second.

Also, from the packet capture it looks as though the SSIDs start out broadcasting alphabetically, but as the capture progresses, SSIDs begin to get broadcast more randomly. The randomness is what makes me think I'm not seeing everything.

If I'm not seeing everything, this brings up a bigger question. Can the devices being targeted in the wild keep up with all those broadcasts? Would it be better to start slowing down the Pool Interval for a more productive chance at snagging a targeted client? All fun things I hope to explore.

Edit: If you're curious about the other two settings, I'm currently getting 7 to 10 SSIDs broadcast per second at the low interval and approximately 100 per second at Aggressive.

Edited September 8, 2016 by Skinny

[Skinny]

Results from Yesterday's Questions

Here's a followup from yesterday. My setup for this experiment was screwed up. Everything is corrected now. The Pineapple broadcasts SSIDs in the following order. Names starting with:

1) Special Characters

2) Numbers

3) Capital letters

4) Lower-case letters

The rate of broadcast is also a bit more encouraging than yesterday. I get roughly 175 SSIDs per second in the Normal interval mode. It looks as though I am receiving every Beacon frame from the Pineapple. I know this because there is no random nature to the SSIDs being broadcast. Everything is being received as outlined above.

So if you have an SSID bank of 3000 names, it will take appoximately 17 seconds to broadcast everything on the list. The Low interval came in at about 115 SSIDs per second and the Aggressive was a blistering 275 per second.

Why Does Any of This Matter?

Lets say you are targeting a specific mobile device. That device will send out a probe request once every 30 seconds to 20 minutes depending on the device. My hypothesis is that when that request goes out, you have a certain amount of time to respond. If the list of SSIDs is too large, I think you might miss that window. Therefore, there would be a certain list size that is optimal that will be based on the amount of time devices are willing to wait for a response. 

Of course, I could be wrong. I may find out that many devices are always listening, therefore it wouldn't matter when you responded with the correct SSID. Intuitively though, this feels wrong because my daily experience tells me that most devices seem to finally attach to the Pineapple during or in sequence with their probe request interval.

Next Steps

For my next trick I'm hoping to see if I can experimentally identify the longest time a range of devices is willing to wait for a probe response. I'll let you know how it goes.

[Skinny]

I knew that WiFi implementations were different from manufacturer to manufacturer but yesterday I got to see it at the packet level. The question I wanted to answer was the following:

After a device send outs a probe request or a broadcast, how long does the Pineapple have to send an SSID the device is looking for?

Round 1: The first experiment was carried out with a Motorola Moto E tracfone. The phone's preferred network list (PNL) was preloaded with 4 common SSIDs. The pineapple had about 200 SSIDs in it's list. PineAP was running.

Initially, I turned on all of PineAPs options to force the phone to connect, but after sifting through the packets, I noticed that before the Pineapple had broadcast the phone's intended SSID, the phone had already connected to the Pineapple. Going back, I did the experiment again but this time just checked Allow Associations (No Broadcast SSID or Beacon Response). The packets showed that all the phone did was send out a probe request to everyone with the SSID it was looking for. With only the Allow Association option checked, the Pineapple sent back a Probe Response validating that it was that SSID. The association followed.

Classically, this is how the Pineapple is supposed to work.

ANS 1) So in these cases, the pineapple is always watching for and will respond immediately to a probe request with an SSID tagged along with it. Even if the pineapple is in the middle of broadcasting a huge list of SSIDs, it will stop and service this probe request with a matching SSID to ensnare the client.

Round 2: The second experiment was carried out using an Amazon Kindle Fire (the cheap model). In this case Allow Associations was not enough to cause an association because the Fire did not broadcast out a probe request with an SSID but just a probe request with a Broadcast. It was asking for all the other APs to respond with their SSID. It was performing a roll call.

I'm told this is the reason Beacon Response was created, so I turned it on without activating Broadcast SSID. In hindsight, this was silly, because Beacon Response can not respond if you aren't allowing SSIDs to be broadcast in the first place. The result was that nothing was sent out, so nothing happened.

For kicks though, I flipped it around and turned on Broadcast SSID but did not allow Beacon Response. The results were interesting. The Fire finally saw the SSID it was looking for and sent a Probe Request directed at the Pineapple. The Pineapple responded with a Probe Response, but then the Fire never took it further. After waiting awhile, the Fire sent out the same Probe Request but it refused to authenticate to the Pineapple. It was as if the Fire didn't believe the Pineapple to be it's true AP.

As soon as Beacon Response was activated, things changed quickly. After the initial Probe Request from the Fire, the Pineapple absolutely hammered the Fire was probe responses. There were hundreds of  repeat responses. This overwhelming onslaught convinced the Fire that this was the correct AP. The Fire authenticated.

ANS 2) Unlike the Motorola, the Fire responded only after seeing the SSID it was interested in. Another interesting tidbit is that the Fire has a broadcast interval of 10s. This is pretty short, so it would preclude me from being able to find out if the Fire would react to a pineapple responding 45s after a broadcast. As it is, response times came just seconds after a request.

Conclusion

More testing is needed but I can see from just these two devices what the outcome will probably be. Since each manufacturer has its own way to implement WiFi, there will most likely be a range of responses. You'll probably have devices that will respond to the pineapple because they are always listening for a probe request and others, in an effort to save battery, that may only listen in certain intervals. The way forward for me will be to look back over my archive and see what devices are more common in the environments I've been encountering and learn how those devices operate under test conditions. At least now I know how to run the test.