The next part of this story started with a computer I had almost forgotten about. Around 2012, I found an old Gateway computer in a dumpster. It was a 2010-era machine with an Intel Atom processor. Someone else had already decided it was not worth keeping, but I brought it home anyway and put it under the bed, where it stayed for years.
I always meant to get it running, but there was always something else to do. Eventually it became one of those projects I remembered every once in a while and then forgot again. That changed when I had a brief month off work while recovering from knee surgery. I was getting bored, so I pulled the Gateway out and started figuring out whether it still had any life left in it.
It was not a modern computer, and I was not expecting it to perform like one. It was a 2010 Atom machine designed for basic everyday tasks rather than heavy workloads. By current standards, it was slow. Programs took their time opening, updates were not something I wanted to rush, and running several things at once made the limitations obvious.
The processor was never going to handle a modern desktop workload, a large database, and several heavy services all at the same time. That did not mean it was useless; it meant I had to be deliberate about what I asked it to do. I had to pay attention to what was running, how much storage it used, and whether a process really needed to stay active.
The ESP32 honeypot had already shown me how quickly an exposed device could attract activity. It was small, inexpensive, and surprisingly capable, but it had limits. Its event log was temporary, its storage was limited, and it was never designed to become a full-time collection server. The Gateway gave me somewhere to put the pieces that did not fit comfortably on the ESP32.
It could hold logs on disk instead of relying only on the board’s rolling memory. It could run scripts in the background, keep a notification watcher alive, and give me a place to save reports and review activity without constantly downloading everything from the ESP32 by hand. That changed the way I thought about the project: the ESP32 was the sensor, while the Gateway could become the place where the sensor’s activity was collected, organized, and reviewed.
I started thinking about the system in separate parts:
ESP32 honeypot
↓
event log
↓
notification watcher
↓
saved evidence
↓
review and reporting
That separation mattered. The device collecting the traffic did not need to do everything. It only needed to respond, record the important details, and stay small enough to understand. The computer could handle the longer-term work.
The Gateway also gave me a separate place to experiment without putting everything on my everyday computer. I could try services, scripts, dashboards, and notification tools without mixing them into the rest of my normal work. I still had to keep the boundaries clear, because an old computer is not automatically safe just because it is old. If it was going to be connected to a lab network, I needed to know what it was running, what it could reach, and what could reach it.
The point was not to turn a discarded computer into an unrestricted internet server. The point was to give the project a controlled place to grow. The old Gateway was never going to win a speed contest, and I had to work around that, but it was more than fast enough to teach me something important: useful security work does not always require new equipment.
The ESP32 gave me a small sensor. The Gateway gave me a place to keep the history. It also made the project feel more personal. The ESP32 was something I bought for the experiment; the Gateway had already been written off as junk. Bringing it back gave the whole project a different direction.
I was no longer just asking whether an exposed device would be noticed. I was starting to build a place where I could study what happened afterward. The Gateway became the next step in that process, giving me storage for logs, room for background services, and a platform for the tools that eventually became part of the larger honeypot system.
I did not know where the project was going when I first pulled it out from under the bed. I only knew that I had a month to fill, an old 2010 Atom computer in front of me, and a question I wanted to answer:
What could I build with something that someone else had already discarded?
The answer started with getting the hardware ready. The original battery was no longer useful, so I replaced it before treating the Gateway like a working lab machine. I also upgraded the memory from 1 GB to 2 GB. That may not sound like much now, but on a small Atom computer it made a noticeable difference when the system had more than one task to handle.
I installed antiX Linux because I needed something lightweight enough for the hardware. I was not trying to turn the Gateway into a modern desktop computer. I wanted a practical system that could boot reliably, give me a terminal, run Python scripts, keep logs, and stay out of the way while the honeypot did its work.
The machine was still slow, but it became usable. The upgrades did not transform it into a fast computer; they gave me enough breathing room to use it as a small lab system instead of fighting it every time I opened a program. The goal was not speed. The goal was stability and a place to keep the work organized.
Once the battery, memory, and operating system were sorted out, the Gateway stopped being a forgotten computer under the bed and started becoming part of the lab. That was when the ESP32 project began turning into something larger than a single device. The next step was figuring out what this old machine could actually do.
I had to keep the jobs small and separate. The Gateway did not need a heavy desktop environment running all the time, and it did not need every tool I had ever heard of installed on it. Its job was to keep the event records, run the background watcher, and give me a dependable place to review what the ESP32 was seeing.
I also kept the roles separate on the network. The ESP32 was the device exposed to the traffic I wanted to observe. The Gateway was the collection and management machine. I did not need to expose the Gateway itself just because the ESP32 was part of the experiment.
That arrangement made the old computer much more useful than its specifications suggested. It was not powerful, but it was available, understandable, and dedicated to the project. I could leave it running, let it collect information, and come back later without losing the history every time the ESP32 restarted.
That was the point where the project stopped being just a board on a desk. It became a small system made up of a sensor, a collection machine, saved logs, notification tools, and a process for deciding what the activity meant. The hardware was old, but the lessons coming from it were still useful.
In the next post, I’ll walk through how I actually put the Gateway to work: getting antiX configured, connecting it to the lab, deciding which services belonged on the machine, and tying its logs and notifications back to the honeypot. The dumpster find was the beginning, but getting that old Atom computer to become a dependable part of the lab was where the real work started.
Leave a Reply