Skip to content

Latest commit

 

History

3 Commits

Folders and files

NameName
Last commit message
Last commit date
 
 
 
 
 
 

Repository files navigation

OpenWrt on Cudy WR3000 V1

Cudy WR3000 V1 router

A personal collection of files, technical data, and notes related to the completed OpenWrt installation and home-network configuration for a Cudy WR3000 hardware revision V1 running OpenWrt 25.12.5, maintained for my own use and future reference.

Router Specifications

Specification Value
Model Cudy WR3000 v1
CPU architecture ARMv8 Processor rev 4
OpenWrt platform MediaTek Filogic
Wireless chipset MediaTek MT7981
System-visible memory 233.95 MiB
Ethernet interfaces 3 × LAN and 1 × WAN
LAN interface names lan1, lan2, lan3
WAN interface name wan
Wireless bands 2.4 GHz and 5 GHz
Wi-Fi generation Wi-Fi 6 / IEEE 802.11ax

Wireless Hardware

Radio Band Chipset Supported standards reported by OpenWrt
radio0 2.4 GHz MediaTek MT7981 IEEE 802.11ax/b/g/n
radio1 5 GHz MediaTek MT7981 IEEE 802.11ax/ac/n

The specifications above were detected by OpenWrt on the installed Cudy WR3000 v1. The reported 233.95 MiB value represents memory available to the operating system, not necessarily the exact physical RAM capacity advertised by the manufacturer.

Overview

The current network is split into three logical networks:

  • MyHome for trusted household devices and router administration;
  • MyIoT for home-automation and less-trusted devices;
  • MyLab for development boards, prototypes, and network experiments.

Important

This repository documents Cudy WR3000 V1 only. The WR3000 model and V1 or 1.0 revision were verified on the label underneath the router. These images are incompatible with WR3000 V2, WR3000E, WR3000H, WR3000P, WR3000S, and other models. WR3000 V2 uses different hardware, and firmware intended for another model or revision can render the router unusable.

Contents

Software and administration

Item Value
OpenWrt version used in this repository 25.12.5
Configuration interface LuCI
Main administration address 192.168.1.1 from MyHome

This record covers the initial installation and the current network configuration. OpenWrt 25.12.5 is the version used here; the document does not identify it as the latest available version.

Repository files

.
├── README.md
└── openwrt/
    └── cudy-wr3000-v1/
        ├── 00-intermediate-firmware/
        │   └── openwrt-mediatek-filogic-cudy_wr3000-v1-sysupgrade.bin
        └── 01-official-openwrt/
            └── openwrt-25.12.5-mediatek-filogic-cudy_wr3000-v1-squashfs-sysupgrade.bin
Order File Purpose Locally calculated SHA-256
1 openwrt/cudy-wr3000-v1/00-intermediate-firmware/openwrt-mediatek-filogic-cudy_wr3000-v1-sysupgrade.bin Cudy-signed intermediate firmware used from the original Cudy interface 8EE579D1B970488EE06F47964AC27EF88BC627B563CEA00B88F1CB3A2917EC64
2 openwrt/cudy-wr3000-v1/01-official-openwrt/openwrt-25.12.5-mediatek-filogic-cudy_wr3000-v1-squashfs-sysupgrade.bin Official OpenWrt 25.12.5 sysupgrade image BE876CF5335AB757874CD19F806B01F2271D8C20A1A0E68F1680019346C4408A

The second local hash matches the value published in the official OpenWrt 25.12.5 download directory. A file-tree.txt file is not present in the current repository tree, so no content is assumed for it.

OpenWrt installation

The initial installation requires two firmware writes in this exact order:

  1. the Cudy-signed intermediate image that removes the original signature restriction;
  2. the official OpenWrt 25.12.5 sysupgrade image.

Use Ethernet throughout the procedure. Keep the WAN port disconnected, temporarily disable Wi-Fi on the administration computer, and never interrupt power while firmware is being written.

Prerequisites and temporary topology

Required items:

  • Cudy WR3000 V1 confirmed from its physical label;
  • original power supply and stable power;
  • computer with an Ethernet interface;
  • Ethernet port or USB-to-Ethernet adapter;
  • working Ethernet cable;
  • current web browser;
  • PowerShell;
  • both firmware files listed above;
  • physical access to the Reset button for emergency recovery only;
  • modem and WAN connection disconnected during initial installation.

Connect the computer to a LAN port, not the WAN port.

Administration computer
    |
Ethernet cable
    |
Cudy WR3000 V1 LAN port

WAN port: disconnected

Configure IPv4 and DNS on the Ethernet adapter to obtain addresses automatically through DHCP. Check the current address in PowerShell:

ipconfig

Expected networks:

  • original Cudy firmware: 192.168.10.0/24, normally with the router at 192.168.10.1;
  • OpenWrt after the first write: 192.168.1.0/24, normally with the router at 192.168.1.1.
Verify the firmware files with PowerShell

Open PowerShell in the repository root and calculate the first image hash:

Get-FileHash `
    -Path ".\openwrt\cudy-wr3000-v1\00-intermediate-firmware\openwrt-mediatek-filogic-cudy_wr3000-v1-sysupgrade.bin" `
    -Algorithm SHA256

Calculate the official image hash:

Get-FileHash `
    -Path ".\openwrt\cudy-wr3000-v1\01-official-openwrt\openwrt-25.12.5-mediatek-filogic-cudy_wr3000-v1-squashfs-sysupgrade.bin" `
    -Algorithm SHA256

The calculated hashes identify corruption or accidental file replacement. The official OpenWrt image matches the hash published in the OpenWrt 25.12.5 download directory; the intermediate-image value records the identity of the local file.

Step 1 — Confirm the physical hardware revision
  1. Power off the router.
  2. Inspect the label underneath the device.
  3. Confirm that the model is WR3000.
  4. Confirm that the revision is V1 or 1.0.
  5. Stop immediately if the label states V2 or 2.0.

A store listing, advertisement, invoice, or product-page title is not sufficient confirmation. Read the revision from the router itself.

Step 2 — Prepare the administration computer
  1. Disconnect the computer from other networks.
  2. Temporarily disable Wi-Fi.
  3. Connect the computer to a Cudy LAN port through Ethernet.
  4. Leave the Cudy WAN port disconnected.
  5. Set IPv4 and DNS to automatic DHCP assignment.
  6. Power on the router.
  7. Wait for it to finish booting.

Use these PowerShell commands to inspect and renew connectivity:

ipconfig
ipconfig /release
ipconfig /renew
Test-NetConnection 192.168.10.1 -Port 80

The port-test result can vary because some firmware versions use HTTPS or a different port. Test the address in a browser even if the port check is inconclusive.

Step 3 — Open the original Cudy interface

Open http://192.168.10.1/.

Complete only enough of the initial wizard to reach the main interface:

  • select Wireless Router if an operating mode is required;
  • if Internet details are mandatory, enter temporary static values only to proceed, with WAN still disconnected;
  • leave final SSIDs, segmented networks, and services for the post-installation configuration.

The known menu path is:

System > Firmware

The following direct address is documented, although availability varies between OEM versions:

http://192.168.10.1/cgi-bin/luci/admin/panel

Step 4 — Write the intermediate firmware

The first file to write is:

openwrt/cudy-wr3000-v1/00-intermediate-firmware/openwrt-mediatek-filogic-cudy_wr3000-v1-sysupgrade.bin
  1. Select the intermediate image in System > Firmware.
  2. Reserve the official OpenWrt 25.12.5 image for the second write.
  3. Upload the intermediate file after rechecking its filename, router model, and physical revision.
  4. Confirm the update.
  5. Keep power and the Ethernet connection uninterrupted.
  6. Leave the Reset button untouched and avoid continuously reloading the page.
  7. Allow several minutes for the write and device reboot.

The interface can remain temporarily unavailable while flash memory is written and the router restarts; do not assume an exact duration.

Step 5 — Restore connectivity after the first write

The management address changes from 192.168.10.1 to 192.168.1.1.

Renew the DHCP lease in PowerShell:

ipconfig /release
ipconfig /renew
ipconfig

If a stale ARP entry interferes, clear it from an elevated PowerShell session:

arp -d *

Then:

  1. Reconnect the Ethernet cable.
  2. Confirm that the computer received a 192.168.1.x address.
  3. Open the intermediate interface at http://192.168.1.1/.

Wireless interfaces are disabled at this stage, so continue through Ethernet.

Step 6 — Open the intermediate OpenWrt interface

For the intermediate image used in this procedure, the expected initial behavior is:

  • username: root;
  • password: empty if no password has been set;
  • a warning that no administrative password is configured.

Credentials can differ between intermediate images. The behavior above describes the image used in this installation. Continue using Ethernet.

Step 7 — Write official OpenWrt 25.12.5

The second file to write is:

openwrt/cudy-wr3000-v1/01-official-openwrt/openwrt-25.12.5-mediatek-filogic-cudy_wr3000-v1-squashfs-sysupgrade.bin

In LuCI, open:

System > Backup / Flash Firmware > Flash new firmware image

  1. Select the official sysupgrade image and wait for compatibility validation.
  2. Confirm that the image is recognized as compatible.
  3. Leave Keep settings and retain the current configuration unchecked.
  4. Do not use Force upgrade. If validation fails, stop and verify the model, revision, filename, and hash.
  5. Confirm the write.
  6. Keep power and Ethernet uninterrupted until the router has restarted completely.

Do not retain the intermediate firmware settings.

Step 8 — Complete the first definitive login and installation verification

Open the definitive interface at http://192.168.1.1/. If necessary, renew the computer's address:

ipconfig /release
ipconfig /renew
  1. Sign in as root.
  2. Set an administrative password in System > Administration.
  3. Keep the administration interface inaccessible directly from the Internet.
  4. Keep WAN disconnected until the basic configuration is complete.

In Status > Overview, verify:

  • Model: Cudy WR3000 v1;
  • Target or platform: mediatek/filogic;
  • Firmware Version: OpenWrt 25.12.5.

Start an SSH session from PowerShell with:

ssh root@192.168.1.1

The SSH client requests host-key confirmation on the first connection. After connecting, run the following commands inside the OpenWrt shell, not in local PowerShell:

ubus call system board
cat /etc/openwrt_release

Structural output example with variable build details omitted:

{
        "model": "Cudy WR3000 v1",
        "release": {
                "distribution": "OpenWrt",
                "version": "25.12.5",
                "target": "mediatek/filogic"
        }
}

DISTRIB_ID='OpenWrt'
DISTRIB_RELEASE='25.12.5'
DISTRIB_TARGET='mediatek/filogic'
Online upgrade checking and expected final state

The Check online for firmware upgrades dialog provides:

  • Yes, enable checking: check for available versions when the status page opens;
  • No, disable checking: disable the check;
  • Close: close without saving a definitive preference.

Yes, enable checking enables availability checks without installing updates automatically. The saved preference remains visible in System > Attended Sysupgrade configuration.

Recorded installation state:

  • Cudy WR3000 V1 confirmed from the physical label.
  • Intermediate firmware installed first.
  • Official OpenWrt 25.12.5 installed second.
  • LuCI available at 192.168.1.1.
  • root password configured.
  • Model and target verified.
  • Old settings were not retained.
Emergency recovery reference

This is an emergency reference and is not part of the normal installation procedure documented in this repository.

No recovery procedure was performed during the installation. The recorded emergency reference describes a TFTP server on the administration computer and the following parameters commonly mentioned by official documentation:

  • computer address 192.168.1.88;
  • recovery file named recovery.bin;
  • holding the Reset button while applying power.

The complete recovery sequence remains untested in this repository. Its parameters depend on the documentation included with the specific Cudy recovery package.

Current network architecture

Note

The current configuration does not use active IEEE 802.1Q VLANs, tagged traffic, or Bridge VLAN Filtering. Segmentation is implemented with independent bridges, separate routed subnets, independent DHCP services, firewall zones, and SSIDs mapped to their corresponding interfaces.

Network OpenWrt interface Device Subnet Purpose
MyHome lan br-lan 192.168.1.0/24 TVs, computers, and phones
MyIoT iot br-iot 192.168.20.0/24 Lights, smart plugs, Alexa, and automation
MyLab lab br-lab 192.168.30.0/24 Boards, prototypes, and network testing
flowchart TB
    Internet((Internet))
    ISP[ISP modem/router]
    PhysicalWAN[Cudy physical WAN port]
    WAN[OpenWrt wan interface<br/>DHCP client / firewall zone wan]
    Router[OpenWrt / Cudy WR3000 V1]
    Home[MyHome<br/>192.168.1.0/24]
    IoT[MyIoT<br/>192.168.20.0/24]
    Lab[MyLab<br/>192.168.30.0/24]

    Internet --> ISP
    ISP -->|Ethernet| PhysicalWAN
    PhysicalWAN --> WAN
    WAN -->|NAT and routing| Router
    Router --> Home
    Router --> IoT
    Router --> Lab
    Home -->|may initiate connections| IoT
    Home -->|may initiate connections| Lab
    IoT -. blocked from initiating .-> Home
    IoT -. blocked from initiating .-> Lab
    Lab -. blocked from initiating .-> Home
    Lab -. blocked from initiating .-> IoT
Loading

All three networks can access the Internet. Only MyHome can initiate connections to MyIoT and MyLab.

WAN uplink
ISP modem/router
    |
Ethernet cable
    |
Cudy physical WAN port
    |
OpenWrt `wan` interface
    |
Firewall zone `wan`
    |
NAT to the internal networks
Setting Value
Physical uplink Cudy WAN port
Upstream device ISP modem/router
OpenWrt interface wan
Protocol DHCP client
Firewall zone wan
IPv4 masquerading Enabled
MSS clamping Enabled

The wan interface is attached to the wan firewall zone. The earlier connectivity failure occurred because the WAN zone had no active interface attached until the ISP modem cable was connected to the physical Cudy WAN port.

Logical segmentation versus IEEE 802.1Q VLANs

The current segmentation works as follows:

  1. br-lan, br-iot, and br-lab are independent bridges.
  2. lan, iot, and lab are Layer 3 interfaces with distinct subnets.
  3. Each subnet has its own DHCP service.
  4. The lan, iot, and lab firewall zones control inter-network traffic.
  5. Each SSID is attached to its corresponding network interface.

There is no active tagged traffic, PVID assignment, or Bridge VLAN Filtering. VLAN IDs 10, 20, and 30 are reserved only for the future Ethernet plan documented later.

Purpose of each network

MyHome

  • household use;
  • 2.4 GHz and 5 GHz access;
  • TVs, computers, and phones;
  • Internet access;
  • OpenWrt administrative access;
  • permitted access to MyIoT and MyLab.

MyIoT

  • automation devices;
  • lights, smart plugs, and Alexa;
  • potentially less-trusted devices;
  • 2.4 GHz only, using AX mode;
  • WPA2-PSK with CCMP/AES;
  • Internet access;
  • DHCP through UDP destination port 67;
  • DNS through TCP/UDP destination port 53;
  • no connections initiated toward MyHome or MyLab.

MyLab

  • development boards and prototypes;
  • DHCP and static-IP tests;
  • device-blocking and bandwidth-restriction tests;
  • MQTT experiments;
  • temporary configurations;
  • initially 2.4 GHz only;
  • WPA2-PSK with CCMP/AES;
  • Internet access;
  • DHCP through UDP destination port 67;
  • DNS through TCP/UDP destination port 53;
  • no connections initiated toward MyHome or MyIoT.

Bridges, interfaces, and DHCP

Two empty bridge devices were created without Ethernet ports attached:

  • br-iot;
  • br-lab.

They serve as devices for the logical interfaces and receive their respective wireless SSIDs.

Interface configuration

lan

Setting Value
Device br-lan
Subnet 192.168.1.0/24
Router address 192.168.1.1

iot

Setting Value
Protocol Static address
Device br-iot
IPv4 address 192.168.20.1
Netmask 255.255.255.0
IPv4 gateway Not configured
IPv6 assignment length Disabled
Firewall zone iot

lab

Setting Value
Protocol Static address
Device br-lab
IPv4 address 192.168.30.1
Netmask 255.255.255.0
IPv4 gateway Not configured
IPv6 assignment length Disabled
Firewall zone lab

No IPv4 gateway is configured on the internal iot or lab interface. The router itself is the gateway advertised to clients on those networks.

DHCP configuration
Interface Client gateway First lease Last lease Lease time
lan 192.168.1.1 Existing LAN setting Existing LAN setting Existing LAN setting
iot 192.168.20.1 192.168.20.100 192.168.20.249 12 hours
lab 192.168.30.1 192.168.30.100 192.168.30.199 12 hours

In LuCI, iot uses start 100, limit 150, and lease time 12h within 192.168.20.0/24. The resulting lease range is 192.168.20.100 through 192.168.20.249. The documented lab pool remains start 100, limit 100, and lease time 12h within 192.168.30.0/24.

Firewall

Firewall zones
Zone Input Output Forward Permitted forwarding destinations
lan Accept Accept Accept wan, iot, lab
iot Reject Accept Reject wan
lab Reject Accept Reject wan

Input controls connections destined for the router itself. Forward controls connections routed between networks. Consequently, iot and lab require explicit input rules for essential DHCP and DNS services even though both zones can forward to wan.

Essential router-access rules
Name Protocol Source Source port Destination Destination port Family Action
Allow-DHCP-IoT UDP zone iot Any Device/Input 67 IPv4 Accept
Allow-DNS-IoT TCP and UDP zone iot Any Device/Input 53 IPv4 and IPv6 Accept
Allow-DHCP-Lab UDP zone lab Any Device/Input 67 IPv4 Accept
Allow-DNS-Lab TCP and UDP zone lab Any Device/Input 53 IPv4 and IPv6 Accept

Enabled diagnostic rules

Name Protocol Source Destination Family Action
Allow-Ping-IoT ICMP zone iot Device/Input IPv4 Accept
Allow-Ping-Lab ICMP zone lab Device/Input IPv4 Accept

These confirmed rules allow clients in MyIoT and MyLab to ping the router itself. Their scope is limited to router-directed ICMP and excludes unrestricted traffic between MyHome, MyIoT, and MyLab.

Communication matrix and stateful behavior
Source Destination Result
MyHome Internet Allowed
MyHome MyIoT Allowed
MyHome MyLab Allowed
MyIoT Internet Allowed
MyIoT MyHome Blocked
MyIoT MyLab Blocked
MyLab Internet Allowed
MyLab MyHome Blocked
MyLab MyIoT Blocked

OpenWrt uses a stateful firewall. When a MyHome device starts an allowed connection to MyIoT or MyLab, response traffic belonging to that connection is accepted. This does not permit MyIoT or MyLab devices to initiate new connections in the reverse direction.

Wi-Fi networks

The repository records only the following password placeholders; the actual wireless credentials are not included:

<MYHOME_PASSWORD>
<MYIOT_PASSWORD>
<MYLAB_PASSWORD>
2.4 GHz radio
├── MyHome → lan → 192.168.1.0/24
├── MyIoT  → iot → 192.168.20.0/24
└── MyLab  → lab → 192.168.30.0/24

5 GHz radio
└── MyHome → lan → 192.168.1.0/24
2.4 GHz radio

Radio settings

Setting Value
Mode AX
Channel 1
Frequency 2412 MHz
Width 20 MHz
Country Code BR - Brazil
Maximum transmit power Driver default
Current reported transmit power 26 dBm
Legacy 802.11b rates Disabled
WMM Enabled
Client isolation Disabled
Bridge port isolation Disabled
DTIM interval 2
GTK rekey interval 600 seconds
Disassociate on low acknowledgement Enabled

MyHome, MyIoT, and MyLab share this physical 2.4 GHz radio. Its mode, channel, width, country code, transmit-power setting, and legacy-rate setting therefore apply to all three SSIDs.

MyHome

Setting Value
Mode Access Point
Network lan
Encryption WPA2-PSK/WPA3-SAE Mixed Mode
Cipher CCMP/AES
Hidden SSID No
Client isolation No
Password placeholder <MYHOME_PASSWORD>

MyIoT

Setting Value
Mode Access Point
ESSID MyIoT
Network iot
Band 2.4 GHz
Radio mode AX
Channel 1
Width 20 MHz
Encryption WPA2-PSK
Cipher CCMP/AES
802.11w management frame protection Disabled
Hidden SSID No
WMM Enabled
Client isolation Disabled
Legacy 802.11b rates Disabled
Password placeholder <MYIOT_PASSWORD>

MyIoT uses only 2.4 GHz for broader compatibility with home-automation devices. Client isolation remains disabled because some devices depend on local communication, multicast, or discovery between clients on the same network. The validated configuration uses AX mode with legacy 802.11b rates disabled; neither changing the radio to N mode nor enabling legacy rates was required for the lamp or Alexa.

MyLab

Setting Value
Mode Access Point
Network lab
Encryption WPA2-PSK
Cipher CCMP/AES
Hidden SSID No
Client isolation No
Password placeholder <MYLAB_PASSWORD>

Client isolation remains disabled on MyLab so development boards, computers, MQTT brokers, servers, debugging tools, and other lab devices can communicate locally.

5 GHz radio

Radio settings

Setting Value
Mode AX
Channel 36
Width 80 MHz
Country Code BR - Brazil
Maximum transmit power Driver default
WMM Enabled

MyHome

Setting Value
Mode Access Point
Network lan
Encryption WPA2-PSK/WPA3-SAE Mixed Mode
Cipher CCMP/AES
Hidden SSID No
Client isolation No
Password placeholder <MYHOME_PASSWORD>

The SSID, password, security mode, and lan network assignment match the 2.4 GHz MyHome configuration. Clients see one MyHome network and select a band according to device support, signal strength, and client policy.

An 80 MHz channel width was chosen instead of 160 MHz for:

  1. greater stability;
  2. broader compatibility;
  3. less dependence on DFS channels;
  4. fewer interruptions caused by radar detection;
  5. sufficient performance for the router's Gigabit Ethernet connection.

MyIoT is not configured on 5 GHz. MyLab initially uses only 2.4 GHz; a future second MyLab SSID may be added to the 5 GHz radio and mapped to the same lab interface.

Validation

Validation was performed on one SSID at a time. Before each test set, ipconfig confirmed that the active Wi-Fi adapter belonged to the expected subnet.

ipconfig
ping 192.168.1.1
ping 192.168.20.1
ping 192.168.30.1
Test-NetConnection 1.1.1.1 -Port 443
nslookup openwrt.org
Network under test Expected client address Expected gateway Internet New connection initiated toward MyHome
MyHome 192.168.1.x 192.168.1.1 Working Not applicable
MyIoT 192.168.20.x 192.168.20.1 Working Blocked
MyLab 192.168.30.x 192.168.30.1 Working Blocked

Test-NetConnection 1.1.1.1 -Port 443 checks external IP/TCP connectivity. nslookup openwrt.org checks DNS resolution.

The enabled Allow-Ping-IoT and Allow-Ping-Lab rules permit IPv4 pings from those networks to the router itself. A failed ping is not automatic evidence of a DHCP, DNS, or Internet-access failure; each function was tested separately. The rules exclude unrestricted inter-network traffic.

Isolation was validated from MyIoT and MyLab against a known port on a controlled MyHome host. An unanswered ping alone was not treated as proof of isolation because the destination host can also block ICMP.

Discovery and administration

mDNS, SSDP, UPnP, and cross-network discovery

Broadcast and multicast traffic remain within their routed subnet by default. Even though MyHome can initiate connections to MyIoT, an application might not discover a device that relies on:

  • mDNS;
  • SSDP;
  • UPnP;
  • a proprietary discovery protocol.

This does not necessarily indicate a firewall error. Unicast access can work while discovery remains confined to the local subnet.

Possible future discovery support includes umdns, an Avahi reflector, targeted multicast rules, or rules limited to the protocols and devices actually required. No indiscriminate MyIoT-to-MyHome allowance is present in the current configuration.

Router administration and security
  • LuCI and SSH administration is performed from MyHome.
  • MyIoT has no administrative access to the router.
  • MyLab has no administrative access by default because it is used for frequent tests and changes.
  • LuCI and SSH are not exposed directly to the Internet.
  • The administrative account has a password configured.
  • The repository contains no real passwords, private keys, credentials, or configuration backups containing secrets.
  • No configuration backup is stored in the repository.

Future Ethernet VLAN plan

The following IEEE 802.1Q VLAN IDs are reserved only as a future proposal. They are not implemented in the current configuration.

VLAN ID Network
10 MyHome
20 MyIoT
30 MyLab

Conceptual future example:

lan1: MyHome untagged, VLAN 10
lan2: MyLab untagged, VLAN 30
lan3: tagged trunk, VLANs 10, 20, and 30
Requirements before implementing Ethernet VLANs

This future work requires:

  • DSA configuration;
  • Bridge VLAN Filtering;
  • explicit tagged and untagged port membership;
  • PVID assignment;
  • possibly a managed switch;
  • a recovery plan to prevent permanent loss of router access.

The conceptual example has not been applied. A future implementation depends on the port names, devices, and DSA topology reported by the installed OpenWrt version.

References

About

A personal repository documenting my OpenWrt installation, home network configuration, technical specifications, and implementation notes for future reference.

Topics

Resources

Stars

0 stars

Watchers

0 watching

Forks

Contributors