Electronics has a safe bench: low voltage, no mains, a fuse. Networking needs one too. A connected device you are still debugging will do odd things: reconnect a hundred times a minute, flood a broker, print a password to a log. On your own network, those are bugs. On someone else's, the same experiments can break things for other people and break the law. This section sets up the networking equivalent of a safe bench before the first lab touches Wi-Fi.
Your devices, your network
Picture the network in your home as a shared kitchen. Everyone in the house uses it. A lab network is your own workbench in the garage: your tools, your mess, nobody else's dinner at risk. It's a network you own, or that you control the router for, used only for your experiments.
There are three ways to build one.
The simplest is a second Wi-Fi network on your own router. Many routers offer a "guest" network. Put your boards and the computer you work on there, together. One catch: guest networks often stop devices from talking to each other, as a safety feature. If your laptop can't reach your board, switch that off for this network, or use the third way.
The second way splits one network into separate ones using special switches. Only bother if you already own that kind of equipment.
The third way is a cheap extra router, plugged into your home router. Everything you plug into the extra router is on its own small network. Your family's phones and laptops stay on the other side.
Now the firm rule. Never scan, test or snoop on a network that isn't yours. Not a school, a job, a café or a neighbour. Looking at other people's traffic without permission is a crime in most countries, and it's wrong anyway. Only the owner's written permission changes that.
A safe network lab is a lab network: a network you own or administer, used only for experiments, and kept apart from devices that matter to other people. Owning or administering it means you control its router: you can see which devices are on it, change its settings and its password. Three ways to set one up, from simplest to most flexible:
- A separate SSID on your own router. Many home routers can run a second Wi-Fi network, often called a guest network. Put the boards and the computer running your broker on it together. Guest networks often enable client isolation, which stops devices on the same SSID from reaching each other; if your laptop can't reach a board, turn that off for the lab SSID or use option 3.
- A VLAN (virtual LAN): one physical network split into separate logical ones by a managed switch or router. Useful if you already run that kind of equipment; never required.
- A separate cheap router (a small travel router is enough) plugged into your home network. Everything on its side shares one private network of its own, and the household's devices are on the other side of it. Chapter 2 §4 explains why the household can't reach in.
The rule behind all three: experiments run on equipment you control, and the household's laptops, phones, cameras and smart speakers are not part of them.
Never scan, probe or capture traffic on a network you don't own or administer: a school, an employer, a café, a neighbour's Wi-Fi, a public hotspot. Watching other people's traffic or probing their devices without permission is illegal in most countries (in the United States, under the Computer Fraud and Abuse Act and wiretap laws; in the United Kingdom, the Computer Misuse Act), and it is wrong whatever the law says. Written permission from the network's owner is the only thing that changes this. This is not legal advice; it is the line this course holds.
Your bench or not?
Sort each action. Decide before you drag, then check.
Loading interactive…
Right on try — credit. Right — the answer had already been shown, so no credit this time. Next try is worth Answer shown after three tries — this one no longer earns credit. You chose to see the answer — this one earns no credit.
What this task checks
Structure checked automatically. Whether your ideas are convincing isn't graded, so reread with the checklist.
The compiler says
A model answer
Correct answer
Also accepted:
Why
Why
Worked example
The board on the guest network can't be reached
-
1
A learner puts an ESP32 on the router's guest SSID and leaves the laptop running Mosquitto on the main SSID. The board never connects to the broker. Why, and what are the two fixes?
-
2
Two networks. Guest networks are usually kept apart from the main one, so a device on one can't reach a device on the other.
-
3
Fix 1: put the laptop on the guest SSID too, and check that client isolation is off for it, so devices on that SSID can reach each other.
-
4
Fix 2: use a separate travel router. Laptop and boards both join it, and the household stays on the other side.
Secrets stay out of code, repos, logs and screenshots
A secret is anything that lets someone in: a Wi-Fi password, a password for a server, or a long code a service gives you to prove who you are, often called a key or a token. Secrets escape in four ways.
Through your code. If the Wi-Fi password is typed into your sketch and you share the sketch, you've shared the password. For early labs, keep it in a separate small file that you never share. Later, Chapter 4 shows the proper way: the device is told the password after it's built, so it's never in the code at all.
Through version history. Tools like Git remember every version of every file. Deleting the password later doesn't remove the old copy. If a password ever lands in a shared history, change the password.
Through logs. Never print a password, even while testing. People paste logs into help forums.
Through screenshots. A screen grab of your setup can show a password in a corner. Crop it before you post it.
A secret is any value that grants access: a Wi-Fi password, a broker password, an API key or token, a private key. Secrets leak through four routes, and a lab needs a rule for each.
- Code. Keep secrets out of source files that are shared. For the
labs before Chapter 4, put them in a separate
secrets.h(or.envfor Python) that is listed in.gitignore, and ship asecrets.example.hwith placeholders. This is a lab stopgap only: Chapter 4 replaces it with provisioning, where a device receives its credentials after it is built, and a product never has them compiled in. - Repositories. Git keeps every version of every file. A password committed once and deleted in the next commit is still in the history for anyone who clones it. The only fix is to treat the secret as public and change it.
- Logs. Never print a secret over Serial or to a log file. Logs get pasted into forums and bug reports.
- Screenshots and screen shares. A Serial Monitor window, a router's admin page or a terminal with a config file open can show a password. Crop or blur before posting, and assume a video call is recorded.
#pragma once
// Lab only, until Chapter 4's provisioning. This file is in .gitignore:
// it is never committed, shared, printed or screenshotted.
#define WIFI_SSID "YOUR_WIFI_SSID"
#define WIFI_PASSWORD "YOUR_WIFI_PASSWORD"
#include <WiFi.h>
#include "secrets.h"
void setup() {
Serial.begin(115200);
WiFi.mode(WIFI_STA);
WiFi.begin(WIFI_SSID, WIFI_PASSWORD);
Serial.println("joining the lab network"); // the SSID at most, never the password
}
void loop() {}
The repository holds a copy named secrets.example.h with the same two
placeholder lines, and its .gitignore holds the line secrets.h.
Worked example
A password reached GitHub
-
1
A learner commits a sketch with the home Wi-Fi password in it, pushes it to a public repository, notices an hour later, deletes the line and pushes again. Is the password safe now?
-
2
No. The first commit is still in the history. Anyone who cloned the repository in that hour has it, and anyone can still read the old commit.
-
3
Change the Wi-Fi password. That is the only step that makes the leaked one worthless. Every device on the network then needs the new one.
-
4
Then stop it happening again. Move the secret to
secrets.h, add that file to.gitignore, and commit onlysecrets.example.hwith placeholders.
Why these pages never connect to anything
Nothing on these pages ever connects to a network, a message server or a board. That's on purpose.
Each interactive diagram is one of two kinds. Some are models: small simulations that run inside your browser and tell you what they leave out. Others replay a recording. Real software exchanged real messages on the machine that built this site, the exchange was saved, and the build checks that the saved copy is still correct.
So reading a lesson can never send a message, scan a network or touch a device, yours or anyone else's. When a lab does need a real network, it's a project you download and run yourself. Then you can see, and stop, everything it does.
No page in this course opens a network connection, talks to a broker, or reaches a board. Every widget is one of two things: a model that computes in your browser and says on its face what it leaves out, or a capture, a record of a real exchange that real software produced when the site was built, on the build machine's own loopback address, and that the build checks still matches. Your browser never sends a message to Mosquitto, never scans your network, and never touches your devices. The site has no way to, by design.
That is a safety property, not a missing feature. It means following a lesson can't affect any network, yours or anyone else's. Every lab that does touch a network is a project you download and run yourself, on your own computer and your own lab network, where you can see and stop everything it does.
May I capture this traffic?
A learner wants to capture packets on the Wi-Fi at their college library to see how their phone talks to the network. Answer each question to land on what they may do.
Loading interactive…
Right on try — credit. Right — the answer had already been shown, so no credit this time. Next try is worth Answer shown after three tries — this one no longer earns credit. You chose to see the answer — this one earns no credit.
What this task checks
Structure checked automatically. Whether your ideas are convincing isn't graded, so reread with the checklist.
The compiler says
A model answer
Correct answer
Also accepted:
Why
Check your understanding (counts toward your progress)
Which of these can a page in this course do?
Right on try — credit. Right — the answer had already been shown, so no credit this time. Next try is worth Answer shown after three tries — this one no longer earns credit. You chose to see the answer — this one earns no credit.
No page opens a network connection, to your laptop or anywhere else.
No page can scan a network. The site has no way to, by design.
Pages never touch your devices. Flashing is something you do with your own tools.
Why
Pages compute models in your browser or replay captures checked at build time. Anything that touches a network is a lab you run yourself.
A widget is either a model or a capture.
A learner puts a board on the router's guest SSID and the laptop running Mosquitto on the main SSID. The board can't reach Mosquitto. What is the best fix?
Right on try — credit. Right — the answer had already been shown, so no credit this time. Next try is worth Answer shown after three tries — this one no longer earns credit. You chose to see the answer — this one earns no credit.
That works, but it mixes your experiments with the household's devices, which is what the lab network avoids.
That makes the network less safe and doesn't join the two SSIDs.
Anything sent to a public server is public, and it doesn't fix the split.
Why
The board and the computer running the broker must share the lab network, and devices on it must be allowed to reach each other.
Both ends of the lab have to be on the same side.
A learner posts a screenshot of the Serial Monitor to a forum to ask for help. What should they check first?
Right on try — credit. Right — the answer had already been shown, so no credit this time. Next try is worth Answer shown after three tries — this one no longer earns credit. You chose to see the answer — this one earns no credit.
Useful for helpers, but not a safety check.
Helpful context, but a leaked secret is the risk here.
Harmless either way. A secret is not.
Why
Screenshots leak secrets easily. Crop or blur before posting.
What can't be taken back once posted?
A Wi-Fi password was committed to a public repository and removed in the next commit. What makes the leak harmless?
Right on try — credit. Right — the answer had already been shown, so no credit this time. Next try is worth Answer shown after three tries — this one no longer earns credit. You chose to see the answer — this one earns no credit.
The first commit still holds it, and anyone who cloned it has a copy.
Copies made while it was public still exist.
The password is in the file contents, not the message.
Why
Treat a leaked secret as public. Only changing it makes the leaked copy worthless.
Assume someone already has the old password.
Practice: A safe network lab (5 problems · doesn’t affect your progress)
Which setup keeps a learner's experiments apart from the household's devices with the least special equipment?
Right on try — credit. Right — the answer had already been shown, so no credit this time. Next try is worth Answer shown after three tries — this one no longer earns credit. You chose to see the answer — this one earns no credit.
That mixes experiments with the household's devices.
Not yours: never experiment on it.
Not yours, and shared with strangers.
Why
A separate router gives the lab its own network, with the household on the other side.
A travel router with the laptop and boards on it
Why can't a board on a guest SSID always reach a laptop on the same guest SSID?
Right on try — credit. Right — the answer had already been shown, so no credit this time. Next try is worth Answer shown after three tries — this one no longer earns credit. You chose to see the answer — this one earns no credit.
They do hand out addresses; that isn't the block.
A guest SSID is an ordinary Wi-Fi network to a board.
A laptop joins it like any network.
Why
Client isolation is a guest-network safety feature. Turn it off for a lab SSID, or use a separate router.
Guest SSIDs often block devices from reaching each other
What should secrets.example.h contain?
Right on try — credit. Right — the answer had already been shown, so no credit this time. Next try is worth Answer shown after three tries — this one no longer earns credit. You chose to see the answer — this one earns no credit.
That file is committed and shared: a real password in it is a leak.
Then a new user doesn't know what to fill in.
Never pass secrets around in email.
Why
The example file shows the shape with placeholders; each person fills in a private secrets.h.
The same definitions, with placeholder values
A sketch prints connecting to bench-lab with password hunter2 at boot. Which two problems does that line create?
Right on try — credit. Right — the answer had already been shown, so no credit this time. Next try is worth Answer shown after three tries — this one no longer earns credit. You chose to see the answer — this one earns no credit.
Neither of those is a problem here.
A leaked password is not cosmetic.
Logs and code get shared; that is how leaks happen.
Why
Print the SSID at most. The password belongs in an ignored secrets file and never in output.
The password is in the log and in the code
Why is it a safety property that no page in this course connects to a network?
Right on try — credit. Right — the answer had already been shown, so no credit this time. Next try is worth Answer shown after three tries — this one no longer earns credit. You chose to see the answer — this one earns no credit.
Speed is a side effect, not the reason.
The point is safety, not cost.
Speed has nothing to do with it.
Why
Anything that touches a network is a lab you run yourself, where you can see and stop everything it does.
Reading a lesson can never affect any network or device
Where this goes next
Your lab network is first used in Chapter 2 §8, where you capture your
own device's traffic on it. Chapter 4 §4 replaces secrets.h with
provisioning, so no password is built into firmware. Chapter 10 gives
each device its own password for the message server. Chapter 19 §4
turns the separate lab network into a rule for real systems: devices
that don't need to talk to each other are kept on separate networks.