MerVLAN v0.50 Simple and Powerful VLAN Management **BETA**

[jksmurf]

Yea sorry forgot to answer that.
Simply put:
In AP mode you lose all features like DHCP, firewall and many other features and the units only work is to pass the traffic to another unit that does that.

As an example I run OPNsense as my firewall/DHCP trafficker.
So my APs goes to a managed switch via cable and that switch passes the traffic/vlans to opnsense. More advanced but often provides much more stability, security & longevity.

I think we're talking at cross-purposes a little bit here and the reference to OPNSense/Firewall/DHCP etc is (hopefully) a bit of a red herring:

• I am guessing Tekko (certainly me) and I believe @Seth Harman and @visortgw all have a Main Router in the Default Wirelss Router Mode, that does all the DHCP, Firewall etc. work. This is the first item on the Router setup list.
• Connected to that Primary Router are AiMesh Nodes, configured using the last item on the list; AFAIK, while many still use AP mode, as AiMesh got (a bit) better, AP Mode is not as prevalent or favoured as it once was.
• AP Mode (2nd item), if applied to the Nodes, fits your script. You say that ONLY AP Mode does.
• Where the confusion lies (at least for me) is if I change all my AiMesh nodes to APs just to run the script on them, what happens to the Primary Router?
• In your example(s) above you refer to a Main Router; does this retain all ROUTING/DHCP/FIREWALL functions?
• I ask as it appears none of your own Asus devices are actually used as Routers, simply as APs and all your Routing/DHCP is done by OPNSense, correct?

So the question is, if folks do not want to delve into OPNSense or some other system that replaces their primary router (which perfoms all those functions capably well), can they leave their Asus Router as a ROUTER, change their AiMesh Units to APs AND put in a Managed Switch* (where the examples above requires it) and have it work? Because I know this is what I was thinking how it might work, and I think @Tekko did too.

* As above the same end result of VLAN Tagging at the Nodes Ethernet ports can be achieved by simply putting that same managed switch behind the non-VLAN node; and it works wirelessly.

Sorry, not trying to burst your bubble here, I think I may have (mis)interpreted, from your original posts, what the script does, but mainly what is required to be able to make it do so.

 

[r80xcore]

I think we're talking at cross-purposes a little bit here and the reference to OPNSense/Firewall/DHCP etc is (hopefully) a bit of a red herring:

• I am guessing Tekko (certainly me) and I believe @Seth Harman and @visortgw all have a Main Router in the Default Wirelss Router Mode, that does all the DHCP, Firewall etc. work. This is the first item on the Router setup list.
• Connected to that Primary Router are AiMesh Nodes, configured using the last item on the list; AFAIK, while many still use AP mode, as AiMesh got (a bit) better, AP Mode is not as prevalent or favoured as it once was.
• AP Mode (2nd item), if applied to the Nodes, fits your script. You say that ONLY AP Mode does.
• Where the confusion lies (at least for me) is if I change all my AiMesh nodes to APs just to run the script on them, what happens to the Primary Router?
• In your example(s) above you refer to a Main Router; does this retain all ROUTING/DHCP/FIREWALL functions?
• I ask as it appears none of your own Asus devices are actually used as Routers, simply as APs and all your Routing/DHCP is done by OPNSense, correct?

So the question is, if folks do not want to delve into OPNSense or some other system that replaces their primary router (which perfoms all those functions capably well), can they leave their Asus Router as a ROUTER, change their AiMesh Units to APs AND put in a Managed Switch* (where the examples above requires it) and have it work? Because I know this is what I was thinking how it might work, and I think @Tekko did too.

* As above the same end result of VLAN Tagging at the Nodes Ethernet ports can be achieved by simply putting that same managed switch behind the non-VLAN node; and it works wirelessly.

View attachment 68882

I'm using my two XT8 in ap-mode. One is in Access Point mode and the other other in AiMesh mode.


To be able to route the VLANs you need an VLAN-aware device that can route them. This is something that is NOT included in MerVLAN Manager and frankly, if you only want to isolate clients, Guest SSIDs already so this for you.

I would be interested in adding or at least try to add this feature in a future release. As of now the only thing that will happen if you run this addon and apply VLANs without a managed switch or a Vlan-aware unit (like the pro) that can route this is that the traffic will dissappear as there is no dhcp leases available.

Adding a feature like this would involve a lot of work with both dhcp and firewall as the vlans isolates the traffic from Asus own system.

 

[Tekko]

I think we're talking at cross-purposes a little bit here and the reference to OPNSense/Firewall/DHCP etc is (hopefully) a bit of a red herring:

• I am guessing Tekko (certainly me) and I believe @Seth Harman and @visortgw all have a Main Router in the Default Wirelss Router Mode, that does all the DHCP, Firewall etc. work. This is the first item on the Router setup list.
• Connected to that Primary Router are AiMesh Nodes, configured using the last item on the list; AFAIK, while many still use AP mode, as AiMesh got (a bit) better, AP Mode is not as prevalent or favoured as it once was.
• AP Mode (2nd item), if applied to the Nodes, fits your script. You say that ONLY AP Mode does.
• Where the confusion lies (at least for me) is if I change all my AiMesh nodes to APs just to run the script on them, what happens to the Primary Router?
• In your example(s) above you refer to a Main Router; does this retain all ROUTING/DHCP/FIREWALL functions?
• I ask as it appears none of your own Asus devices are actually used as Routers, simply as APs and all your Routing/DHCP is done by OPNSense, correct?

So the question is, if folks do not want to delve into OPNSense or some other system that replaces their primary router (which perfoms all those functions capably well), can they leave their Asus Router as a ROUTER, change their AiMesh Units to APs AND put in a Managed Switch* (where the examples above requires it) and have it work? Because I know this is what I was thinking how it might work, and I think @Tekko did too.

* As above the same end result of VLAN Tagging at the Nodes Ethernet ports can be achieved by simply putting that same managed switch behind the non-VLAN node; and it works wirelessly.

Sorry, not trying to burst your bubble here, I think I may have (mis)interpreted, from your original posts, what the script does, but mainly what is required to be able to make it do so.

View attachment 68882

Thx for doing the heavy lifting
@r80xcore was explaining the difference between AP and router (which I'm well aware of) instead of the much more relevant difference between AP and Mesh node.

In essence I indeed believe we're trying to achieve something similar @jksmurf, the difference might be that I dont have GNP so no native/full VLAN support on my router to start with.

What I thought this does is offer full, proper, VLAN (at least for wireless) across nodes (In this case AP's only so it would seem) for all guest networks setup in the main router instead of the current wonky Asus implementation across Mesh router and nodes.

 

[r80xcore]

Thx for doing the heavy lifting
@r80xcore was explaining the difference between AP and router (which I'm well aware of) instead of the much more relevant difference between AP and Mesh node.

In essence I indeed believe we're trying to achieve something similar @jksmurf, the difference might be that I dont have GNP so no native/full VLAN support on my router to start with.

What I thought this does is offer full, proper, VLAN (at least for wireless) across nodes (In this case AP's only so it would seem) for all guest networks setup in the main router.

The addon work the same on AP's as nodes. There really no difference there. But with seperate AP you would need to manually set up SSH but as the node pulls this from the main AP on boot this is automatic.

As said, this needs a managed switch or vlan aware hardware. Getting full VLAN support in router mode would be a really big project. You could probably just add a dhcp on the vlan but you need the firewall for safety and there's a lot of moving parts there.

There's also the issue of hardware acceleration that might stop working and result in bad performance.

Still,when this addon is stable, I might look into that.

 

[Seth Harman]

The addon work the same on AP's as nodes.

Yet another piece of information that hasn't been very clear but should be in giant flashing letters in the README/instructions pertaining to this add-on. AiMesh nodes are not generally referred to as an "AP": in Asus-lingo during initial setup Wireless AP and AiMesh node are both available choices when choosing how you'd like to use the hardware you're setting up and anyone encountering this is going to be led to believe they are two different things (and they are, really, just not in the case of this addon).

 

[r80xcore]

Yet another piece of information that hasn't been very clear but should be in giant flashing letters in the README/instructions pertaining to this add-on. AiMesh nodes are not generally referred to as an "AP": in Asus-lingo during initial setup Wireless AP and AiMesh node are both available choices when choosing how you'd like to use the hardware you're setting up and anyone encountering this is going to be led to believe they are two different things (and they are, really, just not in the case of this addon).

I have updated the OP with much more clear information about this. If you think any information is missing there, please post it here so I can update it.

The main difference for this addon when used with an extra standalone AP or an extra AiMesh node is that the AiMesh node will load the Ssh key automatically and the standalone AP will need manual installation of it. Besides that the VLAN functions are identical.

 

[r80xcore]

Updated mervlan_boot.sh script to version 0.47
Fixed bug causing template injections to duplicate, overwrite or remove
user entries in services-start and service-event scripts during syncs
installation and uninstallation.
1. Centralized all template source into mervlan_templates.sh. *
2. Swapped plain text replacements for marker-bounded template injections.
3. Added variant sniffing: existing markers or shebang detection choose v1/v2
automatically; nodes force service-event-nodes and is detected via .is_node file.
4. Introduced safe locking.
5. Status/report logic switched to the new marker_present helper instead of
brittle grep checks.
6. Node flows now stamp .is_node, run nodeenable --local per sync, and log
remote report output to confirm the marker-based state landed.

Updated sync_nodes.sh script to version 0.47
1. Added template on copy and chmod list.

Update var_settings.sh
Added TEMPLATE library paths for mervlan_boot.sh to source.

*Added new file: templates/mervlan_templates.sh
This contains all template source for mervlan_boot.sh to inject into target files.

Marked for deletion: old .tmp files will be deleted in next commit.

 

[Tech9]

One is in Access Point mode and the other other in AiMesh mode.

You are hurting yourself with this configuration. No different channels, no Tx power control. Both available in AP Mode.

 

[r80xcore]

You are hurting yourself with this configuration. No different channels, no Tx power control. Both available in AP Mode.

It works great. Should I ever need to lower tx or change channels independently that would be a setup. But I am happy with this.

 

[umrico2]

It works great. Should I ever need to lower tx or change channels independently that would be a setup. But I am happy with this.

Just to echo Tech9, It is a night and day experience. AP mode on a different channel opens up the area for more bandwidth. I tried mesh for s could days and switched back to AP mode because there is just no comparison

 

[r80xcore]

Just to echo Tech9, It is a night and day experience. AP mode on a different channel opens up the area for more bandwidth. I tried mesh for s could days and switched back to AP mode because there is just no comparison

Well I'll try. I got some work to do on the ssh and sync anyway that needs that for proper testing!

 

[umrico]

As far as your add on goes, I am trying to understand if it fits my use case. I have (2) AX86U's. One is the primary router which also has internal and IOT networks broadcasting on both the 2.4 and 5.0 channels.

The second AX86U has an uplink to the first AX86U via ethernet. It is in AP mode and also broadcasts both the internal and IOT networks on 2.4 and 5.0 channels. I understand that this AP despite advertising guest networks, is not isolated from my internal network. This is what I would like to change.

I do have access to a managed switch which can handle VLAN segmentation. But I am unsure if this will provide any benefit to the second device in AP mode that is being uplinked via ethernet.

Can you clarify if I am a candidate for this addon?

 

[r80xcore]

As far as your add on goes, I am trying to understand if it fits my use case. I have (2) AX86U's. One is the primary router which also has internal and IOT networks broadcasting on both the 2.4 and 5.0 channels.

The second AX86U has an uplink to the first AX86U via ethernet. It is in AP mode and also broadcasts both the internal and IOT networks on 2.4 and 5.0 channels. I understand that this AP despite advertising guest networks, is not isolated from my internal network. This is what I would like to change.

I do have access to a managed switch which can handle VLAN segmentation. But I am unsure if this will provide any benefit to the second device in AP mode that is being uplinked via ethernet.

Can you clarify if I am a candidate for this addon?

Sorry but you need a vlan aware device to pass the vlan tags to for this to work. This addon tags the traffic for you but in the current state, nothing more.
I am sketching on a way to make this work in router mode with dhcp and firewall rules but this is nothing that would see the light in the near future. It's a lot of work. But really tempting to start on. Need to have the current addon roadmap stable first before adding any major features.

What could try is to use iptables to isolate the traffic. Here one thread about this: Link
On merlin we can do a lot, it just takes time!

 

[r80xcore]

version 0.47 released.

CHANGES:

NEW FILES:
update_mervlan.sh v0.48
Fully automated updating script that will preserve your current settings and pull the newest gitgub main branch.
If any nodes/AP are setup with SSH key they will also be updated to this version.

mervlan_templates.sh v0.47
new template file containing everything needed and easily expandable.

REMOVED FILES:
all .tpl files are obsolete and now deleted.

UPDATED FILES:
heal_event.sh v0.47
heavily reworked to be better at finding and handling events that breaks the VLAN bridges. Will do a 5-stage pass over 10 seconds when detecting a bridge compromising event. Is coupled with a CRU job that does a light 1-pass every 5 minutes silently. Will report every 12h unless bridges are broken. If any pass finds changes inside the VLAN bridges, mervlan_manager.sh will be executed. Both heal_event and mervlan_manager has locks, preventing hammering. Has a 90s cooldown.

service-event-handler.sh v0.47
Changed calls to heal-event to be run outside of the pipeline to prevent that asuswrt-merlin always finishes last and queues heal_event.sh after a VLAN compromising event is done, ensuring fast bridge healing.

mervlan_boot.sh v0.48
added CRU job calls. Moved BOOT_ENABLED to general.json

mervlan_templates.sh v0.48
updated node service-event-handler to match main changes.

 

[r80xcore]

MerVLAN v0.48 released

NEW FILES:
lib_json.sh
Centralized JSON flag management with multi-match parsing to prevent key loss.
Seeded defaults once and updated json_get_flag/json_set_flag to preserve all entries.

lib_ssh.sh
Centralized SSH key checks, node credentials (NODE_SSH_USER / NODE_SSH_PORT), and flag syncing via the shared JSON helper.
Stopped rewriting unrelated flags when refreshing SSH state.

UPDATED FILES:
install.sh / uninstall.sh
Sourced the new helpers, reused ssh_keys_effectively_installed, and adopted the shared node credential getters.
Enabled custom NODE_SSH_USER / NODE_SSH_PORT support during install/uninstall.

update_mervlan.sh / sync_nodes.sh / execute_nodes.sh / collect_clients.sh / mervlan_boot.sh
Dropped unsupported Dropbear options, switched all SSH calls to the shared user/port helpers, and ensured remote operations use the new credentials.

dropbear_sshkey_gen.sh
Replaced the inline JSON writer with the centralized helper to fix the SSH_KEYS_INSTALLED/BOOT_ENABLED overwrite bug. (see above)

 

[r80xcore]

MerVLAN v0.50

UPDATED FILES:

mervlan_boot.sh
* fixed bug preventing proper injection on a system without a services-start
or a service-event file.
* fixed probing of node/ap specific features that was reported as missing,
will now report the current state and also report a cleaner output.

mervlan_manager.sh
* moved json functions to lib_json.sh.
* hardened the dry-run to include all functions that could be
system-alterning, like lock and vlan collection.
* added a dryrun mode in cli.

mervlan_trunk.sh
* hardened version with a lot of work going into the creating of bridges
capable of T/U traffic without destroying previously created bridges.
Still experimental but ready for testing.

settings.json
* structured the json and merged hw_settings into it.
* changed Hardware section to array instead of string.

var_settings.sh
* added missing (previously not needed) sync_nodes.sh reference
* change HW_SETTINGS_FILE to point to settings.json for compatibility.

update_mervlan.sh
* hardened curl and verification of extracted files.
* added the ability to choose branch. Will be used more later on
when addon is getting closer to stable, to enable the use of a
dev branch and also specific branches if needed.
* ensure that public dir gets refreshed after an update.
* force a hw_probe refresh after an update to ensure compatibility.

index.html
* changed hardware reading to settings.json
* fixed bug making load not loading the correct values due to the
updated structure in settings.json.
* added version counter.

hw_probe.sh
* changed the default saving file to settings.json and made the
changed needed for that to work.