DEV Community: Frank Zhang

Do You Know What’s Connected to Your Wi-Fi?

Frank Zhang — Sun, 25 Oct 2026 05:48:33 +0000

You can probably name every phone and computer in your home without thinking twice.

But what about the TV, printer, cameras, smart speakers, NAS, and that old tablet you occasionally pull out of a drawer?

As more devices get connected, your home network becomes a small collection of systems quietly working in the background. Then one day, you want to identify an unfamiliar device or troubleshoot a connection—and realize you could use a clearer picture of what’s there.

WiFi Health Check brings device discovery, network diagnostics, walk tests, and stability testing to iPhone and iPad, so you can explore your network directly from your mobile device.

01 | Start by Seeing Who’s on Your Network

Running a LAN scan and watching devices appear in the list is one of the most direct ways to get to know your network.

Phones, computers, printers, cameras, network equipment—devices scattered across different rooms and management interfaces can now be viewed in one place. Device category counts also make it easier to see how your network is made up.

If you have a NAS, virtualization hosts, or smart home devices, this inventory is especially useful. After connecting a new device, you can check whether it has been discovered and view its IP address and identification details.

02 | What Exactly Is That Unfamiliar Device?

The entries that make you pause are often the ones with names you don’t recognize: an unfamiliar hostname, an IP address, or a record that shows only a manufacturer.

WiFi Health Check combines multiple clues to help identify devices, including their manufacturer, device category, model, and discoverable services.

Multicast Discovery is particularly useful here. Devices can announce information through local discovery protocols, and the app combines those details with other probe results to build a more informative device list.

For example, mDNS / Bonjour, SSDP, and WS-Discovery can provide useful clues for identifying Apple devices, printers, media devices, and cameras.

Once you’ve identified a device, you can give it a memorable alias. The next time you see “Office Printer” or “Living Room TV,” you won’t have to work out what it is all over again.

03 | What Has Changed Since the Last Scan?

You’ve installed a new camera, replaced a phone, or rearranged your network equipment. What’s different from your previous scan?

Scan history and device change comparisons let you review results from different points in time, see newly discovered devices, and check which devices were not found in the current scan.

For a home network with plenty of devices—or a small studio—this saves you from repeatedly scrolling through lists and manually comparing addresses. Giving important devices recognizable aliases makes the changes even easier to follow.

Your network inventory now has a timeline: you can inspect the current results and look back at earlier records.

04 | Same Wi-Fi, Different Room—Why Does It Feel Different?

Video streams smoothly in the living room but occasionally stutters in the office. Meetings work well at your desk, yet moving to another room makes the connection feel less dependable.

Start with a network diagnostic to check the current connection. Then use a walk test to test the same target from different locations and compare the results.

You can take measurements in the living room, office, and bedroom, then use those results alongside your everyday needs to decide which location works best for video calls, remote work, or accessing your NAS.

Instead of relying only on “the connection feels unstable here,” you have test records you can revisit when making changes.

05 | It Connects Now. Will It Stay Stable?

A webpage loading successfully tells you that it’s reachable at that moment. For a long video call, a remote connection, or access to services at home, you may also want to know how the connection behaves over time.

Stability testing repeatedly checks a chosen target and tracks metrics such as connection success rate, latency, and jitter.

You can test a service you use regularly or specify an IP address and port to see whether connections keep succeeding and whether latency fluctuates noticeably.

Run a test before and after a network adjustment, and the difference becomes easier to see.

From Knowing Your Devices to Understanding Your Connection

A device inventory helps you get to know your local network. A diagnostic check, a set of walk test results, and a stability test help you understand how it performs in everyday use.

WiFi Health Check brings these tools together on iPhone and iPad, so you can discover devices, explore identification details, review network changes, and check connection performance.

Curious about what’s connected to your own Wi-Fi? Open the app and start with a LAN scan.

Explore WiFi Health Check · View on the App Store

You know your Wi-Fi password. How well do you know the devices behind it?

How to Use Subnet CIDR Pro to Plan IPv4 Networks

Frank Zhang — Mon, 19 Oct 2026 04:56:08 +0000

Subnetting is one of those everyday networking tasks that looks simple until you need to plan multiple VLANs, check address boundaries, or fit several networks into a limited IP range.

A subnet calculator helps with the arithmetic. A good workflow should also help you understand the results and turn them into a usable addressing plan.

In this guide, we'll walk through practical IPv4 subnet calculations, CIDR notation, VLSM planning, and wildcard masks using Subnet CIDR Pro, an offline subnetting tool for iPhone and iPad.

Website: https://subnet.opshome.run/

App Store: https://apps.apple.com/us/app/subnet-cidr-pro/id6816397989

1. Calculate a subnet from an IP address

Let's start with a common example:

192.168.1.100/26

The /26 prefix means that 26 bits identify the network, leaving 6 bits for host addresses.

That gives us:

Total addresses: 64
Conventionally usable host addresses: 62
Subnet mask: 255.255.255.192

Using Subnet CIDR Pro

Open the subnet calculator.
Enter 192.168.1.100 and select the /26 prefix.
Review the calculated network information.
Copy the individual values you need or copy the complete summary.

The result should look like this:

Field	Result
Network	`192.168.1.64/26`
Subnet mask	`255.255.255.192`
First usable address	`192.168.1.65`
Last usable address	`192.168.1.126`
Broadcast address	`192.168.1.127`
Wildcard mask	`0.0.0.63`
Usable hosts	62

Notice that the entered address, 192.168.1.100, is a host address inside the subnet. It is not the network address itself.

This distinction matters when configuring VLAN interfaces, DHCP scopes, firewall rules, and static routes.

2. Understand what happens when the prefix changes

The prefix determines how much address space belongs to a subnet.

For example, compare /24, /26, and /28.

Prefix	Total addresses	Conventional usable hosts
`/24`	256	254
`/26`	64	62
`/28`	16	14

A /24 provides a larger address pool, while a /28 is better suited to a smaller network segment.

In Subnet CIDR Pro, adjust the prefix and review the updated network boundaries, mask, address range, and host capacity.

This is useful when deciding whether a subnet has enough room for the devices you expect to connect.

For example, a VLAN requiring 40 host addresses needs at least a /26 under conventional IPv4 subnetting rules. A /27 only provides 30 usable host addresses.

Don't choose a prefix based only on how many devices are connected today. Leave reasonable room for growth.

3. Plan multiple VLANs with VLSM

Calculating individual subnets is straightforward. Designing an entire addressing plan is more challenging.

Imagine a homelab or small office using the parent network:

10.20.0.0/24

You need separate networks for:

Servers: 100 hosts
Workstations: 50 hosts
Management: 20 hosts
Printers and other devices: 10 hosts

Allocating the same subnet size to every VLAN would waste address space.

This is where Variable Length Subnet Masking (VLSM) becomes useful.

A practical allocation

Start with the largest host requirement and work downward.

Network	Required hosts	Allocation	Usable range
Servers	100	`10.20.0.0/25`	`.1–.126`
Workstations	50	`10.20.0.128/26`	`.129–.190`
Management	20	`10.20.0.192/27`	`.193–.222`
Printers	10	`10.20.0.224/28`	`.225–.238`

The remaining block is 10.20.0.240/28, which can be reserved for future use.

How to use the VLSM planner

Open the VLSM planning feature.
Specify the parent network and the required host counts.
Add meaningful labels for each network.
Generate the allocation plan.
Review the proposed prefixes and address boundaries before deploying them.

The important principle is to allocate the largest requirements first, then fit smaller networks into the remaining address space.

Always verify that every allocated subnet fits within the parent network and that no two allocations overlap.

A structured plan is easier to maintain than a collection of manually calculated addresses.

4. Convert subnet masks and wildcard masks

Subnet masks and wildcard masks are closely related, but they serve different purposes.

For example, a /26 subnet uses:

Subnet mask: 255.255.255.192
Wildcard mask: 0.0.0.63

A wildcard mask is the bitwise inverse of a subnet mask. It is commonly used in Cisco-style access control lists and routing configurations.

Instead of calculating each octet manually, use the mask converter to move between subnet masks, wildcard masks, and CIDR prefixes.

This is especially useful when translating an IP addressing plan into device configurations.

Remember that a wildcard mask is not interchangeable with a subnet mask in every command. Always check the syntax required by the target network device.

5. Use the CIDR reference for quick checks

Sometimes you don't need to calculate a complete subnet. You simply need to answer a question:

How many addresses does /27 contain?
Which subnet mask corresponds to /29?
What wildcard mask should I use for /24?
How many usable hosts are available in a particular prefix?

The built-in CIDR reference lets you look up prefixes from /0 through /32 without repeatedly opening a separate browser-based calculator.

It's useful during troubleshooting, certification study, network planning, and configuration reviews.

6. Pay attention to special prefixes

Not every IPv4 subnet follows the conventional usable-host calculation.

Two important examples are /31 and /32.

/31 — Point-to-point links

RFC 3021 defines the use of /31 prefixes on IPv4 point-to-point links. Both addresses can be used as endpoint addresses in that context, without reserving a traditional network and broadcast address.

/32 — Single-host routes

A /32 identifies one IPv4 address. It is commonly used for host routes and other configurations that refer to a single address.

Subnet CIDR Pro handles these prefix boundaries explicitly, helping avoid incorrect assumptions when working with point-to-point links or single-host routes.

7. Why use an offline subnet calculator?

Network addressing information often appears in internal documentation, private infrastructure plans, and troubleshooting notes.

Subnet CIDR Pro performs its subnet calculations locally on the device. The calculation workflow does not require an account or a backend service, and results are copied only when you choose to copy them.

That makes it convenient when working in a lab, on-site, or in environments where connectivity is limited.

It also means you can calculate subnets without depending on an external website being available.

Final thoughts

Subnetting is not just about finding a network address. It is about making reliable decisions about address capacity, network boundaries, and future growth.

A practical workflow is simple:

Calculate the subnet for an individual IP address.
Adjust the prefix to evaluate address capacity.
Use VLSM to plan multiple networks efficiently.
Convert masks when working with routing or ACL configurations.
Verify special prefixes before deploying the configuration.

Subnet CIDR Pro brings these IPv4 calculation and planning tasks into one focused iPhone and iPad workflow.

If you regularly work with VLANs, homelabs, routing, or small-office networks, having these calculations available offline can make address planning quicker and less error-prone.

Disclosure: Subnet CIDR Pro is my app. This article focuses on practical subnetting workflows rather than a complete feature review.

#devops #homelab #cidr

Does `docker compose down` Delete Your Data?

Frank Zhang — Fri, 16 Oct 2026 14:06:02 +0000

Two commands can have very different consequences for your database:

docker compose down
docker compose down --volumes

The difference comes down to how Docker Compose manages volumes.

Containers are temporary. Named volumes persist.

Consider this PostgreSQL configuration:

services:
  db:
    image: postgres:17
    environment:
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD:?Set a password}
    volumes:
      - db_data:/var/lib/postgresql/data

volumes:
  db_data:

The database files live in db_data, a named volume with a lifecycle separate from the container.

Running docker compose down removes the containers and project networks, but keeps the named volume. Starting the same project again with docker compose up -d reuses the existing data.

Adding --volumes requests removal of the project’s managed volumes too.

Command	Containers	Managed named volumes
`docker compose stop`	Stopped	Kept
`docker compose down`	Removed	Kept
`docker compose down --volumes`	Removed	Removed if possible

Treat --volumes as an intentional data reset.

External volumes are handled differently

To manage storage independently of the Compose stack, create it first:

docker volume create postgres_data

Then update the volume declaration:

volumes:
  db_data:
    external: true
    name: postgres_data

Compose now expects postgres_data to exist and will leave it untouched—even during down --volumes.

However, external volumes can still be deleted manually. Also, pointing an existing application at a new volume does not migrate its old data.

“Empty database” does not always mean deleted data

Compose normally prefixes managed volume names with the project name:

homelab_db_data

Changing the project name—or moving the Compose file when the directory determines that name—can cause the application to use a different volume.

Before assuming data loss, check:

docker volume ls
docker volume inspect homelab_db_data

The original data may still exist in the previous volume.

For routine shutdowns, use stop or down. Reserve down --volumes for deliberate cleanup, and maintain backups for anything you cannot afford to lose.

Three SSIDs, Three VLANs, One AP: How Industrial Wi-Fi Really Works

Frank Zhang — Mon, 12 Oct 2026 11:15:32 +0000

When multiple wireless networks share one access point, where does the traffic actually go?

Imagine a modern manufacturing plant.

AGVs transport materials between production lines. Operators use industrial PDAs to manage daily tasks. Visiting engineers connect to a guest Wi-Fi network.

All three services share the same industrial wireless access point.

But should they also share the same network?

Not necessarily.

One AP, Multiple Networks

Consider this wireless configuration:

SSID	Purpose	VLAN
Factory-AGV	Automated vehicles	10
Factory-PDA	Industrial handhelds	20
Factory-Guest	Visitors	90

The AP broadcasts three SSIDs, each mapped to a different VLAN.

All three networks reach the wired infrastructure through a single Ethernet uplink.

The key question is: Should the switch port connected to the AP be configured as Access or Trunk?

The answer depends on how wireless traffic is forwarded.

Local Forwarding Changes Everything

In a Local Forwarding architecture, wireless client traffic is bridged directly from the AP into the local wired network.

 AGV ───── SSID 1 ─── VLAN 10 ──┐
                                │
 PDA ───── SSID 2 ─── VLAN 20 ──┼── AP
                                │    │
 Guest ─── SSID 3 ─── VLAN 90 ──┘    │
                                     │
                               802.1Q Trunk
                                     │
                              Industrial Switch

The AP uses IEEE 802.1Q tagging to distinguish traffic belonging to different VLANs.

Therefore, the connected switch port must permit VLANs 10, 20, and 90, typically using a Trunk configuration.

And don't forget the AP management VLAN, which may require its own tagged or untagged configuration.

What About Centralized Forwarding?

With Centralized Forwarding, the data path is different.

Instead of bridging wireless client traffic locally, the AP encapsulates it in a tunnel, commonly CAPWAP, toward a wireless controller.

The wireless client VLANs are then handled at the controller or centralized gateway.

As a result, the AP's switch port does not necessarily need all three service VLANs.

This is an important distinction:

Local Forwarding: Client traffic enters the wired VLANs at the AP.
Centralized Forwarding: Client traffic is transported to the controller before entering the service networks.

Local Forwarding can still use CAPWAP for AP management and control. It does not mean the wireless controller disappears.

VLAN Separation Is Not Security Isolation

Here's another detail worth remembering.

Three VLANs provide three separate Layer 2 broadcast domains.

But if a Layer 3 gateway allows unrestricted inter-VLAN routing, the guest network might still reach production systems.

In an industrial environment, this can create unnecessary exposure.

Proper segmentation also requires firewall policies or ACLs to control traffic between AGVs, industrial terminals, and guest devices.

VLANs separate networks. Security policies determine who can communicate.

Final Thoughts

One AP can support multiple SSIDs and VLANs through a single physical connection.

But the switch configuration must match the wireless forwarding architecture.

For locally forwarded SSIDs, the AP uplink typically needs to carry the corresponding VLANs through 802.1Q tagging.

For centrally forwarded SSIDs, those service VLANs may instead be handled at the wireless controller.

The real design question isn't how many SSIDs an AP broadcasts. It's where their traffic enters the wired network.

In your industrial Wi-Fi deployments, do you prefer Local Forwarding or Centralized Forwarding?

If Making OT Easier to Manage Also Makes It Easier to Reach, Is That Still a Good Design?

Frank Zhang — Fri, 02 Oct 2026 07:33:22 +0000

In an IT/OT environment, would you choose easier operations — or stronger security?

Most engineers would probably answer: both.

But in real environments, the two often start pulling in different directions.

A Windows workstation needs patches, so someone opens access to WSUS.

Then DNS is added.

Then NTP.

Then Active Directory.

Then remote support.

Each change looks reasonable on its own.

But after enough small exceptions, the OT network is still called “isolated” while depending on half of the enterprise network.

That is where the real problem begins.

And that is exactly why Purdue Level 3.5 — the Industrial DMZ — matters.

OT Does Need IT Services

A secure OT network cannot simply disconnect from everything.

Production environments still need:

Windows updates
DNS and NTP
identity services
antivirus updates
remote maintenance
logging
file exchange

The question is not whether OT should use these services.

The question is:

How do we provide them without turning IT into a direct path into OT?

A simplified architecture looks like this:

Corporate IT
     |
  Firewall
     |
+----------------------+
|   Industrial DMZ     |
|      Level 3.5       |
+----------------------+
     |
  Firewall
     |
     OT

The DMZ becomes the controlled boundary between the two environments.

Not just another VLAN.

Not just another subnet.

A service boundary.

WSUS Is a Simple Example

Imagine several Windows systems inside OT:

engineering workstations
HMI servers
SCADA servers
historian systems

They need updates.

The easiest solution is:

OT Host
   |
   v
Corporate WSUS

It works.

But now OT depends directly on a Level 4 service.

A cleaner approach is:

Microsoft Update
      |
      v
Corporate WSUS
      |
      v
DMZ WSUS
      |
      v
OT Windows Hosts

Now OT systems only need access to the WSUS service in the DMZ.

The DMZ server handles the upstream relationship.

That is an important difference.

Instead of giving OT access to the corporate network, we give OT access to one specific service.

Think in Services, Not Networks

This is probably the simplest way to understand Level 3.5.

Avoid this:

OT ---> Corporate Network
OT ---> Internet

Prefer this:

OT ---> DMZ WSUS
OT ---> DMZ NTP
OT ---> DMZ DNS
OT ---> DMZ Jump Host
OT ---> DMZ File Gateway

The first model grants network reachability.

The second grants controlled service access.

That is a much healthier security model.

Active Directory Is Where Things Get Complicated

Identity is harder.

It is tempting to say:

“We already have a corporate domain. Why build something separate?”

The problem is that Active Directory is not just a login service.

It may also involve:

Kerberos
LDAP
DNS
Group Policy
service accounts
machine accounts
privileged credentials

Once OT becomes deeply dependent on enterprise identity, the boundary between the two environments becomes much weaker.

Putting a corporate domain controller directly into a lower OT zone is not really solving the problem.

It is moving enterprise trust deeper into OT.

Depending on the environment, a better design may involve:

Corporate Identity
       |
       v
Industrial DMZ
       |
       v
OT Identity Services
       |
       v
OT Systems

This could mean a separate OT domain, carefully restricted trust, or another controlled authentication design.

There is no single Active Directory architecture that fits every plant.

But the principle is simple:

Enterprise identity should not quietly become a bridge into OT.

Even NTP Deserves Attention

Allowing an HMI or PLC to reach a public NTP server may look harmless.

After all, it only needs the time.

But architecturally, this still means:

OT Device ---> Internet

A cleaner design is:

External Time Source
        |
        v
Enterprise / DMZ NTP
        |
        v
OT Time Source
        |
        v
HMI / SCADA

The same logic applies to DNS, software repositories, antivirus updates, logging, and other shared services.

The closer a system is to the physical process, the fewer external dependencies it should normally have.

Remote Access Is Another Common Shortcut

Maintenance teams need access.

That is normal.

But this:

Engineer Laptop ---> OT Server

creates direct trust between environments.

A stronger design is:

Engineer
   |
   v
DMZ Jump Host
   |
   v
OT Management Host
   |
   v
Target System

Now we have a place to enforce:

MFA
privileged access
session logging
approval workflows
time-based access

The DMZ is not simply forwarding traffic.

It is breaking direct trust.

A DMZ Is Not the Same as a VLAN

Another common assumption is:

“IT and OT are already on different VLANs, so they are isolated.”

Not necessarily.

This:

IT VLAN
   |
 Router
   |
OT VLAN

is not automatically equivalent to this:

IT
 |
Firewall
 |
Industrial DMZ
 |
Firewall
 |
OT

The important question is not whether the networks use different subnets.

It is:

What communication paths are actually allowed between them?

A real DMZ normally gives you a place to enforce policy, inspection, logging, proxies, jump hosts, and other controls.

A VLAN gives you segmentation.

A DMZ gives you a security boundary.

Keep the Firewall Rules Boring

A good IT/OT firewall policy should be easy to explain.

For example:

OT Windows Hosts -> DMZ WSUS
DMZ WSUS         -> Upstream WSUS
OT Hosts         -> DMZ NTP
Admin Workstation -> DMZ Jump Host
DMZ Log Relay    -> SIEM

What you do not want is:

OT-NETWORK -> CORPORATE-NETWORK -> ANY

If the DMZ exists but broad rules allow everyone to bypass it, then it is mostly decoration.

A good starting point is still:

DENY BY DEFAULT

Then allow only the specific services that have a clear operational reason.

The Question I Like to Ask

When reviewing an IT/OT architecture, one question quickly reveals whether the segmentation is meaningful:

If the DMZ is compromised, how far can an attacker move?

If the answer is:

“Anywhere in OT.”

then the DMZ is not doing enough.

If the answer is:

“Only to a small number of explicitly permitted services.”

then the architecture is much healthier.

The same question works in reverse.

If an OT workstation is compromised, how much of corporate IT can it reach?

Ideally:

very little.

Security First — Without Making Operations Miserable

In OT, I would still put security first.

But “security first” should not mean making everyday operations painful.

A good architecture should make the safe path the normal path:

Engineer
   |
  MFA
   |
Jump Host
   |
OT Management Zone
   |
Target Device

That is better than forcing engineers to choose between:

secure but unusable

and

convenient but exposed.

The goal should be both.

Final Thought

Purdue Level 3.5 is not really about memorizing another network layer.

It is about deciding where trust stops.

Instead of:

IT <-------------> OT

we want:

IT
 |
DMZ
 |
OT

with every connection having a clear reason to exist.

WSUS, identity, NTP, DNS, remote access, logging, and file transfer all follow the same principle:

Do not provide broad network access when a narrowly defined service is enough.

That is the real value of the Industrial DMZ.

It lets IT support OT without quietly becoming part of the OT attack path.

Hardening Enterprise Layer 2: How DHCP Snooping, DAI, and IP Source Guard Work in Tandem

Frank Zhang — Thu, 24 Sep 2026 02:24:45 +0000

When engineering network security, teams often fixate on perimeter firewalls, WAFs, and endpoint EDR agents. Yet, inside flat campus and branch networks, the Layer 2 broadcast domain remains one of the softest targets. Once a rogue actor plugs into an open Ethernet jack or lands on an internal SSID, the absence of Layer 2 verification turns the entire local subnet into a playground.

Without proper safeguards, an unprivileged attacker can:

Stand up a rogue DHCP server to distribute malicious default gateways and DNS servers.
Broadcast forged Gratuitous ARPs to execute Man-in-the-Middle (MitM) eavesdropping.
Forge arbitrary source IPs to launch spoofed volumetric attacks or bypass IP-based ACLs and log audits.

Access layer switches must do more than blindly forward frames—they must act as zero-trust gatekeepers for network identity. In enterprise designs, this resilience is built on three tightly coupled mechanisms: DHCP Snooping, Dynamic ARP Inspection (DAI), and IP Source Guard (IPSG).

The Dependency Chain: One Source of Truth

These three features do not operate as isolated silos. Instead, they form a strict, hierarchical enforcement chain:

               +----------------------------------+
               |          DHCP Snooping           |
               | (Builds the Trusted State Table) |
               +-----------------+----------------+
                                 │
                 ┌───────────────┴───────────────┐
                 ▼                               ▼
  +-----------------------------+ +-----------------------------+
  | Dynamic ARP Inspection(DAI) | |   IP Source Guard (IPSG)    |
  |  Validates ARP frames via   | |  Injects dynamic TCAM PACLs |
  |       Control Plane         | |     to filter Source IPs    |
  +-----------------------------+ +-----------------------------+

If DHCP Snooping fails to build or maintain an accurate binding database, both DAI and IPSG lose their reference point and fail to operate correctly.

Architectural Scenario & Packet Enforcement Flow

Below is a breakdown of how an access switch armed with this triad inspects both legitimate endpoints and hostile traffic across trusted and untrusted interfaces:

+--------------------------------------------------------------------------------------------------+
|                                    ENTERPRISE L2 SWITCH FABRIC                                   |
|                                                                                                  |
|   [Port Gi1/0/24: TRUSTED] <=============================> Legitimate Core / DHCP Server         |
|   - Allows incoming DHCP Offer / ACK messages                                                    |
|   - Bypasses DAI & IPSG inspection filters                                                       |
+--------------------------------------------------------------------------------------------------+
          ▲                                                   ▲
          │                                                   │
[Port Gi1/0/1: UNTRUSTED]                           [Port Gi1/0/2: UNTRUSTED]
          │                                                   │
+---------┴-----------------------+                 +---------┴-----------------------+
|        LEGITIMATE CLIENT        |                 |            ATTACKER             |
| MAC:  00:aa:bb:cc:dd:01         |                 | MAC:  00:de:ad:be:ef:99         |
| IP:   10.10.10.101 (via DHCP)   |                 | IP:   Self-assigned / Rogue     |
+---------------------------------+                 +---------------------------------+
  │                                                   │
  ├─ 1. DHCP DORA Handshake                           ├─ [ATTACK A] Rogue DHCP Server
  │     └─► Switch builds Binding Entry:              │     └─► Sends DHCP Offer
  │         [00:aa:bb:... | 10.10.10.101 | Gi1/0/1]   │         └─► DROPPED by DHCP Snooping
  │                                                   │
  ├─ 2. ARP Request / Reply                           ├─ [ATTACK B] ARP Poisoning / Spoofing
  │     └─► DAI checks Binding Database:              │     └─► Sends: "10.10.10.1 is at 00:de:ad:..."
  │         Matches entry -> PASSED                   │         └─► DROPPED by DAI (Sender mismatch)
  │                                                   │
  └─ 3. Standard IP Data Frames                       └─ [ATTACK C] IP Impersonation
        └─► IPSG checks TCAM filter:                        └─► Forges Source IP: 10.10.10.100
            Src IP = 10.10.10.101 -> FORWARDED                  └─► DROPPED by IPSG (Hardware line-rate)

1. DHCP Snooping: Establishing the Binding Database

DHCP Snooping acts as a layer-2 stateful inspection engine for DHCP traffic. It performs two critical tasks:

Rogue DHCP Mitigation: Switch ports are designated as either Trusted or Untrusted. All end-user access ports are Untrusted by default. If a DHCP server message (such as DHCPOFFER, DHCPACK, or DHCPNAK) arrives on an untrusted port, the switch discards it immediately. Only ports connecting directly to legitimate upstream DHCP servers or DHCP relays are configured as Trusted.
Dynamic Database Construction: As valid endpoints complete the standard DORA exchange (Discover, Offer, Request, ACK), the switch snoops on the DHCPACK packet and records an entry in the DHCP Snooping Binding Table:
- Client MAC Address
- Leased IP Address
- Lease Duration
- VLAN ID
- Ingress Physical Port

MAC Address          IP Address       Lease(sec)  Type            VLAN  Interface
------------------   ---------------  ----------  --------------  ----  ------------------
00:aa:bb:cc:dd:01   10.10.10.101     86400       dhcp-snooping   10    GigabitEthernet1/0/1

This binding database is the single source of truth for downstream filtering engines.

2. Dynamic ARP Inspection (DAI): Eliminating ARP Poisoning

The Address Resolution Protocol (ARP) is stateless and insecure by design. Any host can transmit an unsolicited Gratuitous ARP declaring ownership of an IP address, and adjacent hosts will blindly update their local ARP caches.

DAI remedies this by validating ARP traffic on all untrusted interfaces:

When an ARP frame enters an untrusted port, the switch intercepts it and checks the payload's Sender MAC and Sender IP fields against the DHCP Snooping Binding Table.
Match Found: The frame is forwarded normally.
Mismatch or Missing Record: The frame is dropped, and a violation is logged.

Operational Note on Control Plane Protection:

Unlike standard line-rate frame switching handled by ASICs, DAI requires the switch CPU to parse the ARP payload. A malicious host can easily flood thousands of forged ARP packets to overwhelm the switch processor. Always enforce ARP rate limiting on untrusted ports (typically 15–30 packets per second) to prevent control plane denial of service.

3. IP Source Guard (IPSG): Stopping Spoofed Packets in Hardware

DAI defends against ARP manipulation, but an attacker can still configure a static IP on their network interface and transmit raw IP packets directly (e.g., launching UDP floods or evading identity-based firewalls).

IP Source Guard addresses this vulnerability in the data plane:

When IPSG is enabled on an access interface, the port initially blocks all IP traffic except essential DHCP exchanges.
Once an endpoint receives an IP via DHCP, IPSG reads the snooping table and dynamically compiles a Port Access Control List (PACL) straight into the switch’s TCAM (Ternary Content-Addressable Memory).
Only frames whose source IP (and optionally, source MAC) match the active hardware entry are permitted. Mismatched packets are dropped at wire speed by the ASIC without consuming CPU cycles.

DAI  ──► Inspects ARP payloads in software/CPU plane
IPSG ──► Filters IP packet headers in hardware/TCAM plane

4. The Fallacy: Why Port Security Is Not Enough

A frequent misconception among administrators is that enabling Port Security eliminates the need for DHCP Snooping, DAI, and IPSG.

Port Security operates strictly at Layer 2:

It tracks how many source MAC addresses appear on a physical port and limits unauthorized MAC learning.
It is completely blind to Layer 3 and Layer 2.5 protocols.

If an employee brings an unauthorized device and clones their company-issued laptop’s MAC address, Port Security sees a legitimate MAC and permits the frame. That rogue device can then forge ARP packets or hijack another node's IP unimpeded.

Port Security prevents physical port piggybacking (such as an unmanaged mini-hub under a desk); it does not protect the integrity of network identities.

5. Production Pitfalls and Failure Modes

Deploying these protocols in enterprise environments without proper planning can easily cause network outages. Keep the following gotchas in mind:

Pitfall 1: Silent Drops on Static-IP Endpoints

Not every enterprise asset uses DHCP. Printers, IP cameras, video endpoints, building management systems, and specialized industrial controllers are often assigned static addresses.

Because these devices bypass the DHCP handshake, they never register in the DHCP Snooping database. Turning on DAI or IPSG indiscriminately will instantly blackhole them.

Mitigation:

Audit all non-DHCP assets prior to rollout. Define static bindings manually in the switch configuration or construct tailored ARP Access Lists (ARP ACLs) to explicitly authorize static hosts.

ip source binding 00:11:22:33:44:55 vlan 10 10.10.10.50 interface Gi1/0/5

Pitfall 2: The "All Trunks Are Trusted" Assumption

A naive rule of thumb claims that Access ports are Untrusted, and Trunk ports are Trusted. This is dangerous.

The Trusted designation must be reserved exclusively for uplinks heading directly toward legitimate DHCP infrastructure. If an inter-switch trunk leading to a downstream access switch is marked as Trusted, any untrusted client connected to that downstream switch can bypass snooping checks if the edge switch is misconfigured.

Pitfall 3: Err-Disable Outages Caused by ARP Bursts

Operating systems frequently send sudden bursts of ARP requests upon waking from sleep or renegotiating connections. Furthermore, dual-homed setups (such as a laptop tethered to an IP Phone’s passthrough port) can generate bursts that exceed conservative rate limits.

If a port exceeds its configured ARP threshold, many switches automatically transition the interface to the err-disable state, causing complete loss of connectivity.

Mitigation:

Tune the burst rate thresholds based on port workload, and always enable automated recovery timers so ports recover without administrative intervention:

errdisable recovery cause arp-inspection
errdisable recovery interval 30

6. Phased Rollout Blueprint

Do not enable all three features at once on an active production network. Adopt an Observe → Validate → Enforce strategy across distinct phases:

Phase 1: Foundation (DHCP Snooping) Enable DHCP Snooping globally and define upstream uplinks as Trusted. Let the network run undisturbed for several days while reviewing the binding table to confirm leases are reliably captured.
Phase 2: Static Inventory Reconciliation Cross-reference the binding table against network inventory. Create static binding entries or ARP ACLs for all non-DHCP infrastructure devices.
Phase 3: DAI Canary Deployment Enable DAI on a single non-critical VLAN. Configure generous ARP rate limits and set DAI logging to notify on drops. Review the Syslog output to ensure legitimate nodes are not triggering violations before rolling it out across access VLANs.
Phase 4: Hardware-Level Lockdown (IPSG) Apply IP Source Guard to client-facing access ports to seal IP spoofing vectors in the TCAM.
Phase 5: Complementary Access Hardening Layer on supplemental port-level defenses:
- 802.1X (NAC) for client authentication.
- BPDU Guard & Root Guard to prevent spanning-tree manipulation.
- Storm Control to suppress broadcast storms.

Summary

Layer 2 security cannot rely on a single magic toggle. True defense-in-depth requires cohesive, layered enforcement:

Threat Vector	Mitigation Engine	Inspection Layer
Rogue DHCP / Man-in-the-Middle	DHCP Snooping	Layer 7 (DHCP Payload)
ARP Cache Poisoning / Spoofing	Dynamic ARP Inspection (DAI)	Layer 2.5 (ARP Payload)
Source IP Impersonation / Leakage	IP Source Guard (IPSG)	Layer 3 (IP Header / TCAM)
MAC Flooding / Unauthorized Hardware	Port Security / 802.1X	Layer 2 (MAC / EAPOL)

By tying Layer 3 IP allocations to physical switch ports and Layer 2 MAC addresses, you transform your access switches from unauthenticated dumb pipes into an integrated zero-trust perimeter.

Enterprise WLAN Architecture: 802.1X Dynamic VLAN Assignment and Zero-Trust Guest Isolation

Frank Zhang — Mon, 21 Sep 2026 00:06:10 +0000

Enterprise wireless networks frequently fall victim to one of two major architectural anti-patterns:

SSID Proliferation: Deploying dedicated SSIDs for individual departments (Engineering, Finance, HR) or distinct functional units.
The Shared-PSK Flat Network: Funneling all users and endpoints into a flat, shared-key network under a single pre-shared key (PSK).

The former triggers catastrophic beacon overhead that saturates limited RF airtime, degrading overall channel capacity. The latter completely forfeits identity-based network access control and leaves the internal perimeter exposed to lateral movement.

A scalable, high-security enterprise WLAN architecture must enforce a strict separation of concerns across three layers:

Air Interface (Access Layer): Managed by the SSID, responsible solely for physical RF attachment and baseline frame delivery.
Identity & Authentication (Control Layer): Driven by 802.1X and centralized RADIUS services to validate directory credentials and device posture.
Policy & Authorization (Data Plane Isolation): Enforced via RADIUS-pushed dynamic VLAN assignment and upstream firewall access control lists (ACLs).

Architectural Core: The Minimalist Dual-SSID Model

To eliminate SSID proliferation, the wireless footprint is consolidated into two distinct radio access profiles: Corporate (Internal) and Guest (External).

                           Enterprise WLAN RF Access
                                      │
         ┌────────────────────────────┴────────────────────────────┐
         ▼                                                         ▼
 Corporate Access (Internal)                               Guest Access (External)
┌───────────────────────────┐                             ┌───────────────────────┐
│ WPA3/WPA2-Enterprise      │                             │ Open / OWE (Enhanced) │
│ 802.1X EAP Authentication │                             │ Captive Portal Auth   │
└─────────────┬─────────────┘                             └───────────┬───────────┘
              │                                                       │
              ▼                                                       ▼
      RADIUS Server / IdP                                     Guest Edge Gateway
   (AD / OpenLDAP / Cloud IdP)                             (L2 Isolation + L3 ACLs)
              │                                                       │
              ▼                                                       ▼
  Dynamic Attribute Injection                                Strict Outbound Only
     (RFC 2868 / RFC 3580)                                (Allow: DHCP/DNS/Internet)
              │
   ┌──────────┼──────────┐
   ▼          ▼          ▼
Eng VLAN   Fin VLAN   Mgmt VLAN

Under this operational model, Access Points (APs) broadcast a maximum of two SSIDs across all radios. Airtime utilization is maintained at peak efficiency, while segmentation and access policies are offloaded entirely to identity-driven backend systems.

Corporate Network: 802.1X and Dynamic VLAN Assignment

Corporate endpoints authenticate via 802.1X enterprise frameworks (EAP-TLS with mutual PKI certificates, or transitional EAP-PEAP-MSCHAPv2), enabling a single SSID to dynamically route diverse user roles into isolated segments.

1. Authentication & Dynamic Assignment Flow

Supplicant (Client)   Authenticator (AP/WLC)   Auth Server (RADIUS)    Directory (AD/LDAP)
        │                       │                       │                       │
        │── 802.1X EAPOL ──────>│                       │                       │
        │                       │── RADIUS Access- ────>│                       │
        │                       │   Request             │── Verify Identity ───>│
        │                       │                       │<── Identity & Groups ─│
        │                       │<── Access-Accept ─────│                       │
        │                       │    (RFC 3580 VLAN)    │                       │
        │<── EAP-Success ───────│                       │                       │
        │                       │                       │                       │
        │[Client mapped to target VLAN; initiates DHCP DORA on respective subnet]│

2. Standard RADIUS Response Attributes

Upon successful authentication, the RADIUS server (e.g., FreeRADIUS, Cisco ISE, Aruba ClearPass, or Windows NPS) injects standard IETF authorization attributes into the Access-Accept payload as defined by RFC 2868 and RFC 3580:

RADIUS Attribute	Attribute ID	Typical Value	Purpose
Tunnel-Type	64	`13` (VLAN)	Specifies the encapsulation tunneling protocol as 802.1Q VLAN.
Tunnel-Medium-Type	65	`6` (802)	Defines the transport medium as IEEE 802 Local Area Network.
Tunnel-Private-Group-Id	81	`100` or `VLAN_Name`	The target VLAN ID or named VLAN string assigned to the session.

Dynamic Mapping Logic:

Software Engineer authenticates $\rightarrow$ RADIUS returns Tunnel-Private-Group-Id = 100 $\rightarrow$ AP binds traffic to R&D VLAN.
Finance Officer authenticates $\rightarrow$ RADIUS returns Tunnel-Private-Group-Id = 200 $\rightarrow$ AP binds traffic to Finance VLAN.
Untrusted entity or expired account $\rightarrow$ RADIUS returns Access-Reject $\rightarrow$ Association terminated at L2.

Guest Network: Zero-Trust Defense-in-Depth

All guest devices must be treated as hostile endpoints. The guest deployment model requires deterministic Layer 2 east-west blocking coupled with strict Layer 3 egress gating.

1. Layer 2 Client Isolation (Mitigating Lateral Threats)

When multiple untrusted devices reside within the same broadcast domain, malicious actors can perform ARP spoofing/poisoning, passive packet sniffing, and subnet-wide reconnaissance.

Mandatory L2 Mitigations:

AP-Level Client Isolation: Enable Client Isolation / Station-to-Station Blocking. The AP drops direct intra-BSS and inter-BSS frame forwarding between wireless clients.
Switch-Level Port Isolation: Configure Private VLANs (PVLANs) on edge switch ports terminating APs. Set AP access ports as Isolated Ports, ensuring traffic can only traverse upstream toward the Promiscuous Port (Default Gateway/Firewall).
Broadcast/Multicast Suppression: Enable ARP Proxy on APs/controllers to intercept and satisfy ARP requests locally, suppressing mDNS, LLMNR, and broadcast floods.

2. Layer 3 Perimeter Control (North-South Firewall Policies)

The guest default gateway (Layer 3 switch SVI or firewall security zone interface) must enforce an uncompromising egress access control list (ACL):

Guest VLAN (Subnet: 192.168.100.0/24)
  │
  ├── [PERMIT] UDP 67/68  -> Local DHCP Relay / Server
  ├── [PERMIT] UDP/TCP 53 -> Approved Public DNS Resolvers
  ├── [PERMIT] TCP 80/443 -> Captive Portal Gateway Controller
  ├── [PERMIT] IP ANY     -> WAN Egress Interface (Internet Access)
  │
  └── [DENY]   IP ANY     -> RFC 1918 Private Address Space:
                             - 10.0.0.0/8
                             - 172.16.0.0/12
                             - 192.168.0.0/16

By explicitly dropping all RFC 1918 traffic by default, the guest subnet is cryptographically and logically isolated from internal production workloads, office LANs, and management subnets (OOB, switch/AP management planes).

Architecture Comparison Matrix

Evaluation Vector	Shared PSK Flat Subnet	Multi-SSID Per Group	MAC Address Filtering	802.1X Dynamic VLAN + Guest Isolation
Authentication	Static Pre-Shared Key	Multiple Pre-Shared Keys	None / PSK + MAC List	802.1X (EAP-TLS / EAP-PEAP)
Airtime Efficiency	High (Minimal beacons)	Very Low (Beacon bloat)	High (Minimal beacons)	Optimal (Strict dual-SSID footprint)
Access Control	None (Single flat domain)	Coarse (Static SSID-to-VLAN)	Weak (Access permit only)	Granular (Identity-driven dynamic mapping)
User Offboarding	Requires global key rotation	Requires group-wide rekeying	Requires manual MAC removal	Immediate on directory account deprovisioning
Spoofing Resistance	Negligible (Key leakages)	Negligible (Easily shared)	Zero (MAC headers unencrypted)	High (Tied to user tokens or PKI certificates)
Operational Overhead	Scales quadratically	High configuration drift	Unmanageable at scale	Low (Automated policy-driven enforcement)

Implementation & Hardening Checklist

Corporate Network Implementation

[ ] RF Profile: Disable legacy WEP, WPA-TKIP, and 802.11b rates. Default to WPA3-Enterprise (or WPA2/WPA3 Enterprise transition mode).
[ ] RADIUS Handshake: Configure robust shared secrets between APs/WLC and RADIUS nodes, with health monitoring and failover clusters.
[ ] Attribute Delivery: Verify directory group mappings to RFC 2868 (Tunnel-Type, Tunnel-Medium-Type) and RFC 3580 (Tunnel-Private-Group-Id).
[ ] Trunk Infrastructure: Ensure edge switch ports terminating APs are provisioned as 802.1Q trunks permitting all dynamically allocated VLAN IDs.
[ ] Certificate Authority (PKI): For EAP-TLS deployments, distribute machine/user certificates and RADIUS trusted roots via MDM or Active Directory Group Policy.

Guest Network Implementation

[ ] Radio Security: Deploy Captive Portal over Open, or prioritize Wi-Fi Enhanced Open (OWE / Opportunistic Wireless Encryption) for authenticated encryption over public airwaves.
[ ] L2 Isolation: Enforce Station-to-Station isolation on the APs and configure Private VLANs (Isolated Ports) on intermediate Layer 2 switches.
[ ] Egress Firewall Rules: Apply stateful outbound filtering. Place the explicit deny rule for RFC 1918 directly above the WAN default permit.
[ ] Bandwidth & Resource Protections: Implement client-level upstream/downstream rate limiting (QoS) and enforce DNS snooping/anti-spoofing to prevent airtime denial-of-service.

Summary: Decoupling Physical Access from Logical Policy

Building a high-performance, defensible enterprise wireless infrastructure requires an architectural paradigm shift: completely decoupling physical radio access from logical network permissions.

This is achieved through three core engineering principles:

Airtime First (Channel Conservation) Retire multi-SSID configurations. Consolidating the RF footprint into a dual-SSID model reclaims essential channel airtime otherwise lost to repetitive beacon broadcasts.
Identity-Driven Authorization (Policy Automation) Rely on 802.1X and RADIUS attribute injection for dynamic network assignment. An endpoint's network placement must not depend on the SSID it selects, but on who the user is and what device posture they demonstrate.
Zero-Trust Boundary Enforcement (Containment by Default) Treat all guest devices as compromised by design. Implement L2 station isolation at the edge to block lateral movement and strictly drop RFC 1918 routing paths at the gateway to restrict traffic exclusively to public WAN destinations.

Modern enterprise WLAN engineering is not about expanding SSIDs to solve organizational boundaries; it is about deploying a minimalist RF entry point governed by dynamic, identity-aware backend policy.

Wi-Fi 6 in High-Density Networks: Diagnosing CCI and Improving Airtime Efficiency

Frank Zhang — Sun, 20 Sep 2026 01:34:48 +0000

Modern Wi-Fi deployments face a common challenge:

Adding more access points does not always improve wireless performance.

In high-density environments, the limiting factor is often not signal
coverage, but airtime contention caused by Co-Channel Interference
(CCI).

This article explains how Wi-Fi 6 technologies such as BSS Coloring,
Spatial Reuse, and RX-SOP tuning can help improve wireless efficiency,
and how to avoid common RF optimization mistakes.

Understanding Co-Channel Interference (CCI)

Co-Channel Interference occurs when multiple access points operate on
the same channel.

Unlike traditional interference caused by noise, CCI happens because
multiple Wi-Fi devices share the same spectrum and must coordinate
channel access.

Typical symptoms include:

High channel utilization
Increased latency
Slow application response
Reduced throughput during busy periods
Frequent roaming events

The problem is often not weak signal strength, but too many devices
competing for the same airtime.

Why Increasing Transmit Power Can Make Things Worse

A common troubleshooting action is increasing AP transmit power.

However, higher power also increases the coverage area of each AP,
creating larger overlap zones.

This can result in:

More CCI
More channel contention
More waiting time
Lower airtime efficiency

A well-designed wireless network focuses on controlled coverage overlap
rather than maximum signal strength.

Wi-Fi 6 Improvement: BSS Coloring and Spatial Reuse

Wi-Fi 6 introduces BSS Coloring to help devices distinguish between
their own network traffic and neighboring BSS traffic.

Instead of treating every detected transmission as a reason to wait,
devices can identify whether the transmission belongs to another BSS.

Benefits include:

Better spectrum utilization
Improved performance in dense environments
Reduced unnecessary channel waiting

However, BSS Coloring does not replace proper RF planning.

RX-SOP Optimization

RX-SOP (Receiver Start of Packet) controls receiver sensitivity.

By adjusting the threshold, an AP can ignore weaker neighboring signals
and create more opportunities for spatial reuse.

Example:

Default: -85 dBm
Adjusted: -75 dBm

Potential benefits:

Reduced unnecessary waiting
Better airtime efficiency
Improved reuse opportunities

Potential risks:

Hidden node problems
More retransmissions
Reduced reliability

RX-SOP should only be tuned after RF measurements.

Channel Width: Wider Is Not Always Better

A common assumption is:

80 MHz is always faster than 20 MHz.

In dense deployments, wider channels reduce the number of available
independent channels.

For example:

Home networks may benefit from 40/80 MHz
Small offices often use 40 MHz
High-density environments often perform better with 20/40 MHz

The goal is not maximum single-client speed.

The goal is maximum total network capacity.

Practical Wi-Fi 6 Optimization Process

1. Measure Before Changing

Collect:

Channel utilization
Noise floor
RSSI
SNR
Client distribution
Retransmission rate
Roaming behavior

Without measurements, RF tuning becomes guesswork.

2. Reduce Excessive Coverage Overlap

Review:

AP placement
Transmit power
Antenna direction
Mounting location

3. Optimize Channel Planning

Consider:

Better 5 GHz channel reuse
DFS channels where supported
Avoiding unnecessary 80 MHz deployment

4. Tune Advanced Features Carefully

Consider:

BSS Coloring
Spatial Reuse
RX-SOP adjustment
OFDMA scheduling

Advanced features improve a good RF design. They cannot fix poor
planning.

Common Optimization Mistakes

Maximum Power Everywhere

More power can create larger cells and increase interference.

Maximum Channel Width Everywhere

Wider channels may reduce frequency reuse.

Adding More APs Without Planning

More APs can increase contention instead of improving capacity.

Conclusion

Co-Channel Interference remains one of the biggest challenges in dense
Wi-Fi deployments.

Wi-Fi 6 provides better tools through:

BSS Coloring
Spatial Reuse
Improved scheduling mechanisms

But successful optimization still depends on practical RF engineering:

Measure first
Reduce unnecessary overlap
Control transmit power
Select appropriate channel width
Tune advanced features carefully

The fastest Wi-Fi network is not necessarily the one with the strongest
signal.

It is the one that uses the wireless spectrum most efficiently.

OpsHome NOC + Console: Bringing Infrastructure Monitoring to More Screens

Frank Zhang — Wed, 16 Sep 2026 14:05:33 +0000

OpsHome NOC and Console shown across desktop, tablet and mobile devices

OpsHome NOC has always been centered around iOS.

A phone is ideal for quickly checking service status, asset health, incident changes, and private infrastructure. As the number of monitored resources grows, though, larger screens become useful too: reviewing the whole environment from a computer, browsing incidents on an iPad, or keeping infrastructure status visible on a dedicated display.

That is where OpsHome Console comes in.

With Console, the monitoring, asset, and incident views from OpsHome NOC can also be used in browsers, on tablets, and on larger displays. Windows, macOS, Linux, iPad, and mobile browsers can all become ways to view the same OpsHome environment.

One Console, Multiple Screen Sizes

Console is designed to adapt to different browser and screen sizes.

On desktop browsers, the larger workspace makes it easier to review monitor matrices, infrastructure assets, trends, and incident details.

An iPad in landscape mode works well for viewing a broader operational picture, while portrait mode is convenient for browsing incidents and asset information.

On mobile browsers, the layout reorganizes the information hierarchy so that important status, incidents, and resources remain readable.

For homelabs, workbenches, or long-running monitoring setups, Display Mode can keep Console visible on a dedicated screen.

Desktop, tablet, and mobile all use the same Console experience, with the layout and information density adapting to the available screen space.

OpsHome Console responsive interface across desktop, iPad, iPhone and external display

Overview: See What Is Happening Now

When Console opens, Overview provides a current summary of the OpsHome environment.

The page brings together resource counts, active risks, infrastructure health, Active Incidents, 24-hour trends, and assets that need attention.

You can check Overview first to understand whether the environment is healthy, then move into Monitors, Assets, or Incidents when more detail is needed.

If Critical or Warning conditions are present, they are reflected in the overall status and Priority Assets without requiring you to inspect devices one by one.

For day-to-day monitoring, this reduces a lot of unnecessary navigation.

OpsHome Console Overview showing system health, active risks, infrastructure trends and priority assets

Monitors: Public and Private Monitoring in One View

OpsHome NOC supports monitoring types including HTTP, HTTPS, TCP, ICMP, SSL, and Domain checks.

The Monitors page in Console is designed for reviewing multiple targets on a larger screen. Each monitor can show its current state, latency, availability, and recent trend information.

Alt text: OpsHome Console Monitors view showing public and private service monitoring

Cloud Monitors and Private Probe Monitors are organized separately, keeping public checks and internal network monitoring easy to distinguish.

Homelab and SOHO environments often include a mixture of web services, NAS systems, internal management pages, databases, Docker services, virtualization platforms, and applications that are only available on the local network.

Those internal services do not need to be exposed to the public internet just to be visible in Console.

Private Monitoring without Port Forwarding remains one of the core ways OpsHome handles private infrastructure. Internal resources stay inside the private network, without requiring public port forwarding for NAS systems, databases, or internal web services simply to check their status remotely.

Assets: Monitor the Infrastructure, Not Just the Service

Knowing whether a service is online is useful, but it does not always tell the whole story.

A NAS may still be reachable while its storage is approaching capacity. A virtualization host may remain online while CPU, memory, or datastore conditions require attention. A Linux host can also experience resource pressure while its services continue to respond.

OpsHome therefore includes asset-level monitoring as well.

Current infrastructure coverage includes Synology, Proxmox, VMware, and Linux, together with related virtual machines, containers, storage, and workloads.

The Assets page in Console brings these systems together in a single infrastructure view.

OpsHome Console Assets view showing virtualization, NAS, Linux and infrastructure telemetry

Each platform keeps the information that matters to it. Virtualization environments emphasize compute resources and workloads, NAS systems focus more heavily on storage and disk health, and Linux hosts provide general system-level visibility.

That gives OpsHome coverage across:

Virtualization · NAS · Docker · Linux

Service status and infrastructure health can be reviewed within the same OpsHome environment, making it easier to understand what needs attention.

Incidents: More Context on a Larger Screen

Phone notifications are useful for telling you that something happened.

When you want to look deeper, a larger screen is better suited to showing the full incident context.

Console includes a dedicated Incident Workspace for both active and recovered incidents, with severity, start time, duration, affected resources, incident summaries, and timelines.

OpsHome Console Incident Workspace showing incident details, affected resources and timeline

Incidents can be switched quickly from the list, while the detail area keeps the relevant context and resource information visible.

This layout is especially useful for longer-running Warning or Critical conditions, as well as for reviewing incidents that have already recovered.

Console keeps the experience read-only, allowing users to focus on monitoring results and incident context.

Light and Dark

Console includes both Light and Dark themes.

Light Mode works well for everyday desktop use and bright environments. Dark Mode is better suited to monitoring displays, nighttime use, and long-running Display Mode setups.

Changing themes does not change the underlying features or data; it only changes how the interface is presented.

Theme support is also available across desktop, tablet, and mobile layouts.

OpsHome Console Overview shown in light and dark themes

Sign In With the Same Apple Account

A web service often means another account and another password to manage.

OpsHome Console continues to use the same Apple account experience as OpsHome NOC.

Existing OpsHome NOC users can sign in to Console with the same Apple account, without creating a separate Console username or password.

Authentication is handled by Apple. OpsHome does not receive or store the user's Apple ID password.

The sign-in connection uses encrypted communication, and Console establishes a time-limited browser session.

This keeps the App and Web Console experience consistent without adding another set of login credentials.

Beyond the iPhone, Open a Browser

OpsHome NOC continues to provide the quick, portable monitoring experience on iOS.

Console adds several practical ways to use the same environment:

Review a larger monitoring matrix on Windows or macOS.

Keep an OpsHome view open next to a Linux workstation.

Browse assets and incidents from an iPad.

Run Display Mode on a dedicated screen.

The same OpsHome data can stay visible across phones, desktops, tablets, and larger displays.

For a product that originally used the iPhone as its primary interface, Console expands OpsHome into more everyday monitoring environments.

OpsHome NOC + Console

The current OpsHome experience can be summarized around four areas:

Private Monitoring

No Port Forwarding

Virtualization · NAS · Docker

Secure by Design

OpsHome NOC provides the mobile monitoring experience on iPhone, while Console brings the operational view to browsers, tablets, and larger displays.

For a quick status check, open the app.

For more room to review resources, trends, and incidents, open Console.

For continuous visibility, keep Console running on a dedicated display.

Console: https://console.opshome.run

Website: https://app.opshome.run

Documentation: https://docs.opshome.run

Same Docker Network Name, But Containers Still Can’t Communicate? Here’s Why

Frank Zhang — Tue, 15 Sep 2026 08:44:58 +0000

Recently, I ran into a Docker networking issue that looked simple at first.

Two independent Docker Compose projects were running on the same host:

a frontend service
a backend API

Both Compose files declared a network called:

networks:
  app-net:

At first glance, the setup looked straightforward.

If both containers use app-net, they should be able to communicate with each other.

But they could not.

The reason is an important Docker Compose detail:

The network name written in compose.yaml is not always the actual Docker network name.

The Example

Imagine two independent projects:

Docker Host
│
├── portal/
│   └── compose.yaml
│
└── backend/
    └── compose.yaml

The frontend project contains:

services:
  portal-web:
    image: example/portal-web:latest
    networks:
      - app-net

networks:
  app-net:

The backend project contains almost the same configuration:

services:
  core-api:
    image: example/core-api:latest
    networks:
      - app-net

networks:
  app-net:

Looking only at the YAML files, it seems like both containers are connected to the same network:

portal-web ─── app-net ─── core-api

But Docker Compose normally creates resources within the scope of a Compose project.

That changes what actually happens.

What Docker Really Creates

Compose projects are usually named after their project directories unless a project name is explicitly configured.

In this example, the projects may be called:

portal
backend

When Compose creates the networks, it may prefix the network names with the project name.

So this:

networks:
  app-net:

inside the portal project may become:

portal_app-net

while the same configuration inside the backend project may become:

backend_app-net

The real structure is therefore closer to this:

Docker Host
│
├── portal-web
│      │
│      └── portal_app-net
│
└── core-api
       │
       └── backend_app-net

They are not connected to the same Docker network.

The network key is identical in both Compose files, but the actual network objects are different.

Verify Instead of Guessing

The easiest way to confirm this is:

docker network ls

You may see something like:

NETWORK ID     NAME
a12bc34de567   portal_app-net
b98dc76fe543   backend_app-net

That immediately explains why the containers cannot communicate directly.

You can also inspect a network:

docker network inspect portal_app-net

The output includes the containers attached to it.

If portal-web appears there but core-api does not, the two services are isolated from each other.

This is why checking the actual Docker network is often more useful than repeatedly reviewing the Compose YAML.

The Cleaner Solution: A Shared Network

If two independent Compose projects intentionally need to communicate, they can share a network managed outside either project.

First, create the network:

docker network create app-shared-net

Then configure the frontend project:

services:
  portal-web:
    image: example/portal-web:latest
    networks:
      - app-shared-net

networks:
  app-shared-net:
    external: true

Use the same network in the backend project:

services:
  core-api:
    image: example/core-api:latest
    networks:
      - app-shared-net

networks:
  app-shared-net:
    external: true

Now both containers attach to the same Docker network:

Docker Host
│
├── portal-web
│       │
│       ├──── app-shared-net
│       │
│       └─────────────┐
│                     │
└── core-api ─────────┘

The important part is:

external: true

This tells Compose:

Do not create a project-specific network. Use an existing Docker network.

That makes the relationship between the two independent projects explicit.

Why Docker DNS Matters

Once both containers share a user-defined Docker network, Docker provides internal DNS-based name resolution.

For example, the frontend can usually access the backend using the service name:

http://core-api:8080

instead of using a container IP such as:

http://172.22.0.5:8080

That is important because container IP addresses can change when containers are recreated.

Service names are much better identifiers.

You can test DNS resolution directly:

docker exec portal-web-1 getent hosts core-api

A successful result may look like:

172.22.0.3    core-api

Then test the application itself:

docker exec portal-web-1 curl http://core-api:8080/health

If the health endpoint responds, you have confirmed:

Shared Network  ✓
Docker DNS      ✓
TCP Connection  ✓
Application     ✓

Port Publishing Is a Different Thing

Another common source of confusion is Docker port mapping.

For example:

ports:
  - "8080:8080"

means the service is exposed through the Docker host:

Host:8080
   │
   ▼
core-api:8080

It does not automatically mean another container can resolve core-api through Docker DNS.

Host port publishing and container-to-container networking are separate concepts.

For internal service communication, sharing a Docker network and using service names is usually cleaner.

A Simple Troubleshooting Workflow

When two Docker containers cannot communicate, these checks usually find the problem quickly.

First, confirm the containers are running:

docker ps

Then check the real networks:

docker network ls

Inspect the intended network:

docker network inspect app-shared-net

Make sure both containers appear in the network.

Then test DNS:

docker exec portal-web-1 getent hosts core-api

Finally, test the application port:

docker exec portal-web-1 curl http://core-api:8080

This sequence helps separate different types of failures:

Docker Network
      ↓
Docker DNS
      ↓
TCP Port
      ↓
Application

If DNS resolution fails, debugging the application itself is probably too early.

The Key Lesson

The main lesson from this issue is simple:

Two Docker Compose files can use the same network key without actually sharing the same Docker network.

This:

networks:
  app-net:

may result in:

portal_app-net
backend_app-net

Those networks are isolated.

If independent Compose projects need direct communication, check the actual Docker network objects and deliberately attach both projects to the same shared network.

The commands worth remembering are:

docker network ls
docker network inspect <network>
docker exec <container> getent hosts <service>

Docker networking becomes much easier to troubleshoot once you stop looking only at compose.yaml and start checking what Docker actually created.

Industrial NAT Design: Connecting Multiple Identical OEM Machines to a Factory OT Network

Frank Zhang — Sun, 13 Sep 2026 02:52:44 +0000

NETWORKING / INDUSTRIAL NAT / OT

Industrial NAT Design: Connecting Multiple Identical OEM Machines to a Factory OT Network

INDUSTRIAL NATPLCOT NETWORKOEMSEGMENTATION

Connecting one OEM machine to a factory network is usually straightforward. Connecting several identical machines becomes more difficult when every PLC and HMI arrives with the same IP address. Industrial NAT provides a practical way to preserve each machine's internal configuration while giving factory systems a unique address for every required device.

Topics: Industrial NAT, PLC, OEM machines, OT networking, network segmentation

Scope of this article

This article explains the network design approach for integrating multiple OEM machines with overlapping internal IP addresses into a factory OT network. It covers address mapping, segmentation and maintenance considerations. The addresses are illustrative; device-specific NAT configuration and industrial protocol compatibility must be checked for the actual deployment.

1. Why identical OEM machines often use identical IP addresses

In modern manufacturing environments, OEM machines are increasingly delivered as complete automation units. A typical skid may include a PLC, an HMI, an industrial switch, a remote maintenance interface and vendor-specific control applications.

To simplify engineering and maintenance, many OEM vendors use a standardized internal network configuration. For example, each machine may contain the following addresses:

Component	OEM-side IP address
PLC	`192.168.1.10`
HMI	`192.168.1.20`
Industrial switch	`192.168.1.254`

This design works well while each machine operates on its own isolated network. The challenge appears when the factory needs to connect several identical production units to shared SCADA, monitoring or engineering systems.

2. The IP conflict problem in multi-OEM deployments

Imagine a factory installs eight identical packaging machines. Every machine contains a PLC at 192.168.1.10, while the factory OT address space uses 10.50.0.0/16.

Machine	Internal PLC address	Factory integration problem
Machine 1	`192.168.1.10`	Address overlaps with the other machines
Machine 2	`192.168.1.10`	Address overlaps with the other machines
Machine 3	`192.168.1.10`	Address overlaps with the other machines

From the OEM perspective, this is normal standardization. From the factory integration perspective, the devices need to be distinguishable. Connecting these internal networks directly into one shared Layer 2 network can introduce duplicate IP addresses, ARP conflicts and PLC communication failures.

Even when the machines remain in separate network segments, shared systems still need an unambiguous way to reach each PLC. Otherwise, SCADA identification and remote maintenance become difficult.

3. Why not simply change every PLC IP address?

Assigning a unique subnet to every machine can work technically. However, in many industrial projects, changing the PLC address also requires reviewing HMI configurations, engineering software, PLC communication settings and remote support procedures.

OEM vendors usually maintain a standard machine template. Changing that template for every installation can increase commissioning work and maintenance complexity. Instead of supporting one familiar configuration, engineers must track a different addressing plan for each machine.

Machine	Example of a redesigned internal subnet
Machine A	`192.168.10.0/24`
Machine B	`192.168.20.0/24`
Machine C	`192.168.30.0/24`

A network redesign may be appropriate when the factory and OEM agree on it. When preserving the delivered machine configuration is a priority, a translation boundary provides another option.

4. Use industrial NAT at the machine boundary

A common approach is to place a NAT router or industrial firewall between each OEM network and the factory OT network. Each machine keeps its original internal subnet, while the NAT device exposes unique factory-facing addresses for the devices that require access.

Factory OT address space	Machine boundary	Isolated OEM network
`10.50.0.0/16`	NAT-1	Machine 1: `192.168.1.0/24`
`10.50.0.0/16`	NAT-2	Machine 2: `192.168.1.0/24`
`10.50.0.0/16`	NAT-3	Machine 3: `192.168.1.0/24`

The following mappings give SCADA a unique address for each PLC, even though all three PLCs retain the same internal address:

Machine	OT-side mapped address	OEM-side PLC address
Packaging Line 1	`10.50.1.10`	`192.168.1.10`
Packaging Line 2	`10.50.2.10`	`192.168.1.10`
Packaging Line 3	`10.50.3.10`	`192.168.1.10`

The duplicate addresses remain inside separate machine networks. Factory systems use the unique mapped addresses. The factory-side routing and the return path through each NAT device must support these mappings.

5. What this design improves

Keep the OEM configuration consistent

The vendor can continue using 192.168.1.10 for the PLC in every machine. Where the communication requirements and NAT behavior support it, the factory can integrate the machines without changing their internal device addressing.

Create a controlled access boundary

When the NAT device also provides firewall policy enforcement, the machine boundary can restrict which systems are allowed to communicate with the PLC. Address translation itself should not be treated as an access-control policy.

Source	Destination	Example policy
Authorized SCADA server	Mapped PLC address	Allow required communications
General office network	Mapped PLC address	Block direct access

Simplify expansion

Adding another machine can follow the same pattern: retain its internal configuration, allocate unique OT-side mappings and apply the required routing and firewall rules. This reduces the need to redesign existing machine networks as production grows.

6. Why VLANs and Proxy ARP are not complete substitutes

VLANs separate networks but do not create unique destination addresses

Putting each machine into a separate VLAN prevents their identical addresses from conflicting on the same Layer 2 segment. However, VLAN separation alone does not give a shared SCADA system a unique destination address for each PLC.

Segment	PLC address	What remains unresolved
VLAN 10	`192.168.1.10`	Shared-system access to overlapping addresses
VLAN 20	`192.168.1.10`	Shared-system access to overlapping addresses

VLANs remain useful for segmentation, but the overall design still needs a way to distinguish the overlapping networks when central systems access them.

Proxy ARP does not provide the required address mapping

Proxy ARP can help in some routing scenarios, but by itself it does not assign a unique factory-facing identity to each device using 192.168.1.10. It therefore does not replace the translation or separate routing context required to handle overlapping machine networks.

7. Industrial NAT compared with other approaches

Method	Result and trade-off
Modify every PLC IP address	Can resolve overlap, but requires coordination with the OEM and updates to dependent configurations.
Put all machine networks in one VLAN	Leaves duplicate addresses in one shared Layer 2 network and can cause conflicts.
Put each machine in a separate VLAN	Provides Layer 2 separation, but alone does not resolve shared access to overlapping destinations.
Use Proxy ARP alone	Does not provide unique per-machine translated addresses.
Use industrial NAT at each machine boundary	Preserves internal addressing and exposes unique mapped addresses, subject to routing and protocol compatibility.

8. Practical design and maintenance considerations

Select a suitable industrial device

Evaluate NAT, firewall, routing and logging capabilities against the actual machine communication requirements. VPN support may also be needed if the boundary device handles remote maintenance. The device should be suitable for its installation environment.

Document every address mapping

Keep the machine name, original OEM address and OT-side mapped address together in the network documentation. The mapping table in Section 4 provides a simple starting point. Clear records help engineers distinguish machines that otherwise have identical internal configurations.

Control remote access

Avoid exposing PLC networks directly to the Internet. A controlled maintenance path can use an authenticated VPN connection followed by an industrial firewall policy that permits access only to the intended machine and required services.

The access path is: remote engineer, VPN, industrial firewall, then the authorized OEM machine. Document this path alongside the address mappings so maintenance staff know which machine they are reaching.

9. Preserve the machine design while making factory access unambiguous

Duplicate IP addressing is a common integration challenge when multiple identical OEM machines join a factory OT environment. Changing every PLC address can resolve the overlap, but it may also increase maintenance work and disrupt the vendor's standardized configuration.

Industrial NAT provides a practical alternative: keep each OEM network isolated, give the required devices unique OT-side addresses and enforce access through a defined firewall boundary.

The key is to preserve a predictable configuration inside each machine while making every factory-facing connection clearly identifiable. With suitable routing, compatible protocols and documented mappings, the same design can be repeated as additional production units are installed.

Industrial Wi-Fi Design in Metal-Rich Manufacturing Environments

Frank Zhang — Sat, 12 Sep 2026 02:23:42 +0000

Introduction

Industrial Wi-Fi deployment is fundamentally different from office
wireless networks.

In factories, warehouses, and production facilities, wireless signals
are affected by:

Large metal structures
Manufacturing equipment
Steel racks
Moving machinery
Dense industrial devices

A common misunderstanding is:

Poor Wi-Fi performance means the signal is not strong enough.

In many industrial environments, the real problem is not signal
strength. It is RF propagation, including metal shielding, multipath
interference, and improper deployment design.

This article discusses practical approaches for designing reliable Wi-Fi
coverage in complex industrial environments.

The Real Challenge: Metal Shielding and Multipath

Metal Structures Create Coverage Problems

Industrial sites contain many objects that affect wireless propagation:

Machine enclosures
Control cabinets
Metal storage systems
Steel structures

Metal can reflect and block radio signals, creating areas where coverage
becomes unpredictable.

A handheld terminal may work normally in an open area but lose
connectivity when moving behind a machine.

The problem is not always distance from the access point.

It may be caused by:

signal attenuation
physical obstruction
unstable propagation paths

Multipath Reflection Causes Unstable Connections

In industrial environments, wireless signals rarely travel through a
single path.

A client device may receive:

direct signals from an AP
reflected signals from machines
signals bounced from walls or metal structures

             Metal Equipment

                  |
                  |

AP  ----------------  Client

        Reflected paths

These signals can combine differently depending on the environment.

The result may include:

unstable throughput
packet retransmissions
latency fluctuations
roaming failures

This is why a strong RSSI value does not always mean a reliable
connection.

Why Increasing TX Power Is Usually Not the Solution

When coverage problems occur, increasing AP transmit power is often the
first action.

For example:

TX Power:
17 dBm → 30 dBm

However, this does not always solve the problem.

Wi-Fi communication is bidirectional.

The AP may transmit a stronger signal:

AP  -------------------->  Client
        Strong signal

But the client device still has limited transmit capability:

Client  ------------->  AP
          Weak signal

Industrial devices such as handheld scanners, tablets, and mobile
terminals cannot always transmit back with the same power level.

This creates an imbalance:

AP can hear the client poorly
retransmissions increase
connection quality decreases

Higher transmit power can also increase:

co-channel interference
channel contention
overall RF noise

The goal of industrial Wi-Fi design should not be maximum signal
strength.

The goal should be:

predictable and stable wireless coverage.

Practical Industrial Wi-Fi Design Strategies

Choose the Right Antenna

Antenna selection is critical in complex environments.

For long and narrow areas such as warehouse aisles, production lines,
and logistics channels, directional antennas are often more effective
than standard omnidirectional antennas.

Directional antennas focus coverage where it is needed.

Benefits:

better signal concentration
reduced interference
more predictable coverage

Optimize AP Placement

AP location often has a greater impact than transmit power.

Avoid placing APs directly next to large metal objects.

Poor design:

AP
 |
Large Metal Machine

Possible results:

signal reflection
shadow areas
unpredictable coverage

Maintain reasonable distance between APs and large metal structures
whenever possible.

Maintain Coverage Overlap for Roaming

Industrial devices are often mobile:

AGVs
barcode scanners
inspection terminals
tablets

Reliable roaming requires overlapping coverage.

A practical design target is:

20%--30% coverage overlap

For many industrial applications, a coverage boundary around:

RSSI >= -65 dBm

is a reasonable target.

However, RSSI alone is not enough.

Engineers should also evaluate:

SNR
interference
packet loss
latency

Do Not Ignore Fresnel Zone

For wireless bridges and long-distance links, signal strength is only
part of the design.

The Fresnel Zone around the transmission path also affects performance.

Objects inside this area can affect the link:

cranes
large machines
steel structures
moving equipment

Even when RSSI appears acceptable, problems may still occur:

packet loss
jitter
unstable latency

This is especially important for factory wireless bridges and
long-distance industrial connections.

A Practical Deployment Approach

A reliable industrial Wi-Fi deployment usually follows four steps.

1. Understand the Environment

Analyze:

factory layout
equipment locations
metal structures
device movement paths
application requirements

2. Perform RF Survey

Measure:

RSSI
SNR
interference
channel utilization
roaming behavior

Do not rely only on controller statistics.

3. Optimize RF Design

Adjust:

AP locations
antenna types
transmit power
channel planning

The objective is balanced coverage, not maximum power.

4. Validate Real Applications

Test actual business scenarios:

mobile terminal roaming
AGV connectivity
latency requirements
production reliability

Common Industrial Wi-Fi Mistakes

Mistake	Impact
Increasing TX power everywhere	More interference and poor client balance
Using only omnidirectional antennas	Difficult coverage control
Checking only RSSI	Missing RF quality issues
Ignoring Fresnel Zone	Unstable wireless links
Installing APs near metal equipment	Reflections and coverage holes

Conclusion

Industrial Wi-Fi is not simply a coverage problem.

It is an RF engineering challenge involving:

physical environment
antenna design
propagation paths
interference control
mobility requirements

In metal-rich manufacturing environments, reliable wireless networks are
built through:

proper AP placement
suitable antennas
controlled coverage overlap
realistic RF targets
field validation

The solution is not always increasing transmit power.

The better approach is to design a predictable RF environment that
supports real industrial operations.