MerVLAN v0.52.1 (dev 0.52.7) Simple and Powerful VLAN Management **BETA**

[r80xcore]

MerVLAN VLAN Manager – Simple and Powerful VLAN Management

---

LATEST CHANGELOG (often condensed, full log: main | dev

mervlan v0.52.7

This update resolves critical UI logout issues, stabilizes node sync reliability, and optimizes VLAN healing with a new escalation logic. It also introduces a major installation overhaul featuring interactive branch selection and tarball management.

NOTABLE FIXES:

UI Logout Resolution:

• Removed httpd restarts from mervlan_manager.sh to prevent session termination.
• Users can now save VLAN settings without being logged out of the web interface.

Node Sync Reliability:

• Replaced byte-count comparisons with structural JSON validation to fix false mismatch errors.
• Improved logic preserves node-specific hardware sections and prevents SSH-based corruption.

UPDATED FILES:

mervlan_manager.sh:

• Removed httpd calls to ensure continuous GUI access during configuration.

execute_nodes.sh & sync_nodes.sh:

• Implemented semantic JSON verification (structure/content/sections).
• Added automatic trunk reset logic to ensure trunking remains main-router exclusive.
• Optimized SSH communication to prevent JSON corruption during pushes.

heal_event.sh:

• Fixed syntax errors and improved trunk VLAN parsing for comma-separated values.
• Enhanced bridge detection to recognize trunked interfaces (ethX.Y) as edge members.
• Optimized monitoring timing to 10 passes at 3s intervals (30s window).
• Added cron escalation: instant fast-check followed by full validation only if damage is detected.
• Added --cron-test mode to verify escalation logic without actual healing.

lib_json.sh:

• Added trunk-reset functions for node configuration safety.

mervlan_trunk.sh:

• Fixed unterminated strings and multi-line printf syntax errors.

index.html:

• Updated UI to hide trunk configuration options on node-specific tabs.

install.sh:

• Added interactive branch selection (main/dev) and version-based tarball naming.
• New interactive menu for selecting, downloading, and deleting tarball archives.
• Added support for "full dev" fresh installs and enhanced error cleanup.

SUPPORTED INSTALL MODES:

./install.sh

• Standard upgrade using local files; no downloads or credential prompts.

./install.sh full [dev]

• Fresh install from main or dev branch; configures directories and prompts for SSH credentials.

./install.sh download

• Interactive session to download and rename branch-specific tarballs without installing.

./install.sh tarball

• Interactive menu to manage and install from locally stored archives.

IMPORTANT!

If you are updating from v0.52.5 or earlier, you must transition via the CLI. See this

---

MerVLAN is an addon for Asuswrt-Merlin that adds a graphical VLAN manager inside the web UI (LAN section).
It’s built for AP-mode deployments and helps you tag/bridge VLANs for:

• Per-SSID VLAN assignment
• Per-LAN-port VLAN assignment (access ports)
• (Experimental) Trunk ports for daisy-chained APs
• Syncing VLAN config to other APs/nodes over SSH

MerVLAN is not a router or managed switch. You still need a VLAN-aware upstream firewall/switch for routing, DHCP, and policy.

---

Status

• Public beta – expect bugs and occasional breaking changes.
• AP-mode only (main and any nodes/APs must be running as APs, not router mode).

---

Supported Topologies

• • Single unit: 1x Asuswrt-Merlin AP running MerVLAN.
  • AiMesh: 1x main Merlin AP + up to 5 AiMesh nodes (Ethernet backhaul only for VLAN tags).
  • Standalone AP nodes: 1x Merlin “controller” AP + up to 5 standalone AP units (non-AiMesh), synced over SSH.

SSH key behavior

• • AiMesh: the main AP typically shares its SSH keys with AiMesh nodes automatically.
  • Standalone AP nodes (non-AiMesh): you must install the same public key on each unit (same method as the main AP) so MerVLAN can sync and run commands remotely. Only main needs to install MerVLAN.

---

Requirements

• • Asuswrt-Merlin firmware with addon support (on every device that will tag VLANs).
  • AP-mode on all participating units.
  • JFFS enabled (persistent storage).
  • SSH enabled on main + any standalone AP nodes.
  • Ethernet backhaul only between VLAN-aware nodes/APs (Wi-Fi backhaul cannot preserve VLAN tags).
  • Mandatory: VLAN-aware upstream device (managed switch + router/firewall such as OPNsense/pfSense/etc).

---

Key Features

• • UI-driven VLAN config inside the Merlin GUI.
  • SSID ↔ VLAN mapping and LAN port ↔ VLAN mapping.
  • (Experimental) Trunk ports for Ethernet daisy-chain.
  • Multi-node sync over SSH (push config/scripts to nodes).
  • SSID-agnostic VLAN mapping:
    On multi-node setups, MerVLAN applies mappings only to SSIDs present on each AP, allowing different nodes to advertise different SSIDs while preserving VLAN behavior.
  • Self-healing: hooks re-apply VLAN wiring after reboot and certain system events.
  • Built-in logs + UI-visible command output for debugging.

---

Limitations / Notes

• • VLAN usage is practically limited by SSID slots your hardware supports.
  • Some models have guest SSID/mesh quirks (certain SSIDs may only broadcast on the main node).
  • Wi-Fi backhaul cannot carry VLAN tags (Ethernet only for VLAN-aware nodes).
  • MerVLAN does not provide routing/firewall/DHCP.

---

Install
Only install if you’re comfortable with beta software (and factory reset recovery if needed).

SSH into the AP and run:

mkdir -p /jffs/addons/mervlan && /usr/sbin/curl -fsL --retry 3 "https://raw.githubusercontent.com/r80xcore/mervlan/refs/heads/main/install.sh" -o "/jffs/addons/mervlan/install.sh" && chmod 0755 /jffs/addons/mervlan/install.sh && /jffs/addons/mervlan/install.sh full

To run the newest dev version, run this command instead:

mkdir -p /jffs/addons/mervlan && /usr/sbin/curl -fsL --retry 3 "https://raw.githubusercontent.com/r80xcore/mervlan/refs/heads/dev/install.sh" -o "/jffs/addons/mervlan/install.sh" && chmod 0755 /jffs/addons/mervlan/install.sh && /jffs/addons/mervlan/install.sh dev full

The UI will appear under LAN → MerVLAN.

---

Update
Run on the main AP:

/jffs/addons/mervlan/functions/update_mervlan.sh update main

for dev version, run:

/jffs/addons/mervlan/functions/update_mervlan.sh update dev

Or Update via the GUI

Updater keeps settings/SSH keys, refreshes files, and re-syncs nodes (if configured).

---

Uninstall
From `/jffs/addons/mervlan`:

• • Standard (keep addon data):
    

     ./uninstall.sh

  • Full (remove addon dirs + temp workspace):
    

     ./uninstall.sh full

---

Logs & Debugging

• Primary log directory: `/tmp/mervlan_tmp/logs`
• Common logs:
  • `vlan_manager.log` – VLAN apply pipeline, heal checks, and node execution
  • `cli_output.log` – commands executed from the UI and installer
• Logs are also accessible via the UI under `view logs` in info.
• Bug reports: please include relevant log files (or excerpts) when reporting issues — missing logs make problems much harder to diagnose.

Links / Support

• • MerVLAN on Discord
  • MerVLAN on Github
  • Report issue on Github

---

See `changelog.txt` for full version history.
See `LICENSE` for license details.

 

[RaccoonNL]

I am interested in following this project, unfortunately the discord invitation link is not valid anymore.
Can you tell me if your VLAN manager also works when the router is setup in ap-mode?

 

[r80xcore]

I am interested in following this project, unfortunately the discord invitation link is not valid anymore.
Can you tell me if your VLAN manager also works when the router is setup in ap-mode?

Hi!
I will update the link tonight when I'm home, sorry for that.

The vlan manager is specifically made for routers in AP mode as running vlan in router mode generally isn't recommended and can introduce double NAT (as you need another firewall/router routing the vlans.

So if you're running in Ap mode you're hopefully good to go.

I'm currently in the process in porting this program to a real Addon where it's accessible from within the merlin GUI. It probably ready in a week or so. Until then, feel free to try the beta that uses it's own gui and adress.

 

[RaccoonNL]

Thanks for getting back at me so promptly.

I was asking because I am exploring the posibility to run an OPNsense mini pc as router/firewall and want to re-use my two Asus routers as access points in combination with VLAN tagging over Wifi and multiple SSID's (Main, Guests, IoT).

I will follow this thread with much interest.
Thanks for investing your time in what promisses to be a great addon.

Keep up the good work.

 

[r80xcore]

Thanks for getting back at me so promptly.

I was asking because I am exploring the posibility to run an OPNsense mini pc as router/firewall and want to re-use my two Asus routers as access points in combination with VLAN tagging over Wifi and multiple SSID's (Main, Guests, IoT).

I will follow this thread with much interest.
Thanks for investing your time in what promisses to be a great addon.

Keep up the good work.

No problems!

I'm running OPNsense myself and using this addon to tag three different guest networks in mesh and vlan 187,188,189, and it works great. then the plan is to run the untagged as 186 in the switch so everything ends up tagged in opnsense.

 

[Tech9]

Mesh users: VLAN tagging is only supported when nodes are connected via Ethernet backhaul.

But... this is not technically Mesh anymore and whoever has Ethernet available may find AP Mode much better with more control per AP and better spectrum utilization with up to 2x higher aggregate throughput to wirelessly connected clients. So when Ethernet is available and there is VLAN capable APs (native or via custom script) this AiMesh option is actually a limitation and has to be avoided.

Thanks for sharing your work! It may save someone money by reusing available hardware.

 

[r80xcore]

But... this is not technically Mesh anymore and whoever has Ethernet available may find AP Mode much better with more control per AP and better spectrum utilization with up to 2x higher aggregate throughput to wirelessly connected clients. So when Ethernet is available and there is VLAN capable APs (native or via custom script) this AiMesh option is actually a limitation and has to be avoided.

Thanks for sharing your work! It may save someone money by reusing available hardware.

What I mean by that is that the WiFi in these devices does not support vlan trunking which means that the tagged VLAN packets is stripped if they travel from the mesh node using WiFi backhaul. So you need to connect the the mesh nodes via ethernet to a managed switch. Daisy chaining is planned but not something I will start with until everything is up and running.

When setting up mesh you do that via the gui as normal. This addon only tags traffic on the chosen SSID.

So TLDR.
Mesh is supported but only if device is connected via cable. Which honestly is the preffered way anyhow for an AP, especially when using VLAN.

My devices work on mesh VLAN at home.

 

[Tech9]

Mesh is supported but only if device is connected via cable.

Some terms mismatch. Mesh is wireless only in networking. Wired mesh is consumer products marketing invention.

 

[r80xcore]

Some terms mismatch. Mesh is wireless only in networking. Wired mesh is consumer products marketing invention.

Right, when I said device, I meant the other AiMesh nodes, not client devices like phones or laptops. I was probably a bit unclear there.

You’re correct that mesh in enterprise networking usually means a wireless interconnect between access points. But in ASUS AiMesh (and most consumer systems), the term mesh also includes setups that use Ethernet backhaul — it’s still the same AiMesh control layer, just with wired links instead of wireless ones. In other words, one SSID covered by several APs.

So yes, VLAN Manager fully supports AiMesh, but only when the nodes are connected via Ethernet backhaul. That ensures VLAN tags are preserved end-to-end while keeping the roaming benefits without breaking isolation. This setup must use Ethernet backhaul only so VLAN tags travel correctly. Mixed Ethernet + Wi-Fi backhaul can break VLAN isolation.

The key difference is that AiMesh can’t “control” or steer clients on a VLAN-tagged SSID. Those SSIDs still broadcast on all nodes, but AiMesh’s smart-connect and steering logic won’t apply to them. Clients just roam naturally between nodes.

 

[jksmurf]

But... this is not technically Mesh anymore

Can you please expand on why not? Asus WebGui makes no differentiation as to how nodes are connected. Is there a standardized Mesh definition?

 

[Tech9]

There is nothing to expand. Mesh is wirelessly connected re-transmitters. It was invented long before Wi-Fi. Consumer products marketing invented wired mesh. It's a key word. What ASUS (or others on the same market) have in their App or Web GUI is whatever they decided to call specific feature. There are many strictly marketing terms like Game Boost (QoS), Game Accelerator (QoS), OpenNAT (port forwarding), WTFast (some paid VPN service), as well as mimicking common abbreviations like SDN (as per ASUS - Self-Defined Network), Ai/AI (as per ASUS for some products - Always Incredible), etc. Part of the learning curve when moving to more business oriented products comes from technically incorrect terms used in consumer products.

 

[jksmurf]

There is nothing to expand.

OK thanks.

 

[r80xcore]

I am interested in following this project, unfortunately the discord invitation link is not valid anymore.
Can you tell me if your VLAN manager also works when the router is setup in ap-mode?

Sorry for the delay. I got caught up in work and forgot to send you the link. Here's a new link for you.

Join the r80xcores-Merlin-VLAN Discord Server!

Check out the r80xcores-Merlin-VLAN community on Discord - hang out with 5 other members and enjoy free voice and text chat.

discord.gg

The version available there is v0.44 with its own ui on another Web adress. I would suggest you wait until v0.45 is done. It will be installed as an addon and be a part of the official Gui under the "Tools". Has been a learning curve to get it right but it should be finished and ready for use by the weekend.

Full changelog will be available when released as there are a lot of changes under the hood. It's more sturdy, self-contained and most important following the addon api and guidelines as well as a new GUI following the system css.

See you on Discord!

 

[r80xcore]

Update v0.45

* Name change from Merlin VLAN Manager to MerVLAN.
* full transition to real addon instead of standalone lighttpd site.
* rewrite of most scripts.
* github repository
* hunted down a lot of bugs but as the transition was quite extensive bugs might be present. Please send logs and info if you run into any.

 

[r80xcore]

MerVLANn v0.46

Changelog:

# execute_nodes.sh v0.45 - v0.46
# Reworked to fix broken paths

# mervlan_boot.sh v0.45 -> v0.46
# Added SSH-propagated node actions (nodeenable, nodedisable, setupenable, setupdisable) so main commands fan out to satellites.
# Hardened template injection logic; corrected service-event-nodes.tpl handling so the main router service handler no longer receives the node variant.

# mervlan_manager.sh v0.45 -> v0.46
# Queue-aware, timed restarts: skip duplicate restart_wireless/switch/httpd via /tmp/rc_service/ps and enforce timeouts.
# Global mkdir lock: prevents overlapping runs from clobbering bridges/interfaces.
# VAP wait cap: wait_for_interface limited to ~63 s (exponential backoff).
# Clean bridge teardown: detach all member ports before brctl delbr.
# Safer delif: ignore empty bridge names and dedupe in remove_from_all_bridges.
# Fail-fast env: exit if CHANGES or LOCKDIR aren’t set.
# Full cmdlines: use ps w so token matching is reliable.
# Cleaned stray braces and adjusted client-refresh conditions in mervlan_manager.sh to Ensured only the main router runs collect_clients.sh

# service-event-handler.sh v0.45 -> v0.46
# Added debounce to deflect multi-clicks or multi-calls.
# Added missing executenodes_vlanmgr

# sync_nodes.sh v0.45 -> v0.46
# Hardened to create all runtime directories remotely before file sync.
# Added missing hw_settings.json, preventing the execution of some scripts.

# service-event-nodes.tpl
# Added TEMPLATE_2 mirroring the service-event-handler.sh on main. Used to prevent accidental writes to the main version.

# var_settings.sh v0.45 -> v0.46
# added several definitions that is used in the updated versions.

# index.html
Updated index.html buttons to send actions through the unified queue, added modal button wiring, and maintained per-action logging/locking.

# mervlan.asp
# Restored action_mode="apply" and built policy-controlled wrappers in mervlan.asp, including sandboxed skip-refresh handling and the shared MVM_trigger pathway.

A lot of other both small and medium bugs fixed in .html .asp and general definitions throughout the scripts.

 

[Seth Harman]

So I'd suggest we just continue in here and maybe you make a final post on the other thread that points at this thread.

One thing that occurred to me is part of the setup involves figuring out the IP addresses of the AiMesh nodes and manually inputting them. Eventually some kind of auto-discovery would be great, if possible, but the bigger question is what happens in the unlikely event the node IP address changes after install/configuration? Those addresses are assigned via DHCP when you add the node under AiMesh so I'm assuming there's still a possibility they could get reassigned by the system itself, of if you remove and then re-add it could change. If the IP changes after install/configuration does this all break?

 

[visortgw]

So I'd suggest we just continue in here and maybe you make a final post on the other thread that points at this thread.

One thing that occurred to me is part of the setup involves figuring out the IP addresses of the AiMesh nodes and manually inputting them. Eventually some kind of auto-discovery would be great, if possible, but the bigger question is what happens in the unlikely event the node IP address changes after install/configuration? Those addresses are assigned via DHCP when you add the node under AiMesh so I'm assuming there's still a possibility they could get reassigned by the system itself, of if you remove and then re-add it could change. If the IP changes after install/configuration does this all break?

Solution: Create DHCP reservation for AiMesh nodes.

 

[Seth Harman]

Ok, installed, everything worked this time including generating the SSH key. One question I have is I see Lan 1-5 in the interface but no reference to which piece of hardware this is applying to. If, for example, I set LAN 2 to VLAN ID 53 is that going to cause Lan 2 on each node to tag 53? And what if you have an AiMesh node that has a different number of LAN ports?

Here's another issue:

 

[Seth Harman]

Ok, log files are telling me it's because of the same thing @visortgw just said in the other thread, the SSH key hasn't been copied to the nodes. Is there a step I'm missing here where I was supposed to manually install that key somewhere on the nodes?

 

[jksmurf]

Solution: Create DHCP reservation for AiMesh nodes.

That’s exactly what I do in both my networks and works even when you delete and later re-add the same node. Easy to manage via SSH as IP is fixed. Even comes up with dinky little icons.

Although have you ever noticed they whilst they appear in the log, they don’t ever get assigned names in the system log, wireless log, if you use wireless backhaul…