esp8266_beaconSpam icon indicating copy to clipboard operation
esp8266_beaconSpam copied to clipboard

Beacon interval

Open atom-smasher opened this issue 2 years ago • 3 comments

I'm trying to understand this line:

  /* 32 - 33 */ 0xe8, 0x03,                         // Interval: 0x64, 0x00 => every 100ms - 0xe8, 0x03 => every 1s

As I understand the code, this does not set the actual interval of the beacons, but rather it sets an "expected" time, and within that expected time, a node should expect to see another beacon from this BSSID.

IIUC, the code is running as fast as the wifi chip can send beacons, and it could (presumably) be slowed down with some kind of sleep command (this code is not my first language).

Is that correct?

Maybe that should be documented in the comments of the code.

atom-smasher avatar Jun 15 '22 18:06 atom-smasher

Going through it, is this line what's serving to keep it from running too fast?

  if (currentTime - attackTime > 100) {

IIUC, instead of just sleeping for a period, regardless of how long it takes to send out x beacons, it uses this to just make sure it's not running too fast, without delay that would make it run too slow.

When it's running "fast enough", I'm wondering if that test at the start of that loop function is consuming excessive resources, and might be more power efficient (with negligible loss of speed) as this:

  if (currentTime - attackTime < 100) {
    delay (10);
  } else {

atom-smasher avatar Jun 15 '22 22:06 atom-smasher

I'm wondering if this might be the perfect throttle:

  if (currentTime - attackTime < 100) {
    delay ((100 - (currentTime - attackTime)) % 100);
  } else {

The way it was originally, with about 10-15 SSIDs, it would bang on the test/loop about 800 times per iteration. As above, it just sleeps until it's ready, once per iteration.

atom-smasher avatar Jun 15 '22 23:06 atom-smasher

Perfectly throttled here - https://github.com/atom-smasher/esp8266_beaconSpam

atom-smasher avatar Jul 26 '22 04:07 atom-smasher