SSID names are padded with spaces at the end - making them all 31 characters long.

[neilbrookins]

I noticed that the length of the SSID never changes. They are always padded with spaces. Perhaps this was intentional. But if you want to truncate them after the last letter, and not have trailing spaces, just add the code I wrote below:

Existing code: // write new SSID into beacon frame memcpy_P(&beaconPacket[38], &ssids[i], j - 1);

New code: // change SSID length to match new SSID used above beaconPacket[37] = (uint8_t)(j - 1);

[spacehuhn]

~~Thanks! You're absolutely right. I will update the source code~~

Edit: I confused this with your second issue https://github.com/spacehuhn/esp8266_beaconSpam/issues/15

The spaces are intentional. Without it, you need to copy a lot more bytes back and forth. Slowing the whole thing down.

What you changed now will create a faulty beacon frame. Saying the SSID is shorter than the packet is (because I made it always 32chars long).

A better alternative could be to fill it with \0 instead of spaces, but then you also get some crazy behaviour on some devices. WiFi implementations are weird and you can expect different scan results on different devices.

[neilbrookins]

OK, I agree. So, there is not a perfect solution. I guess to make the SSID field truly variable length, you'd have to do a copy of the bytes in the beaconPacket after the SSID parameter forward or back based on the new length needed. I wouldn't think that would take very long, but I haven't tested it to measure the impact.

I wonder if the sending of longer SSID with trailing space padding (always 32 bytes) is also slower than sending a shorter SSID? If so, perhaps some of the extra time overhead of the copying bytes for a variable length beacon packet is regained back by sending fewer bytes over the air?