spacehuhn / esp8266_beaconSpam

Creates up to a thousand WiFi access points with custom SSIDs.
MIT License
1.04k stars 202 forks source link

Beacon interval #41

Open atom-smasher opened 2 years ago

atom-smasher commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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