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

[mistermoonlight1]

First i have some questions:
Did you get an "unsupported" popup when reloading in 0.52.5?

The new feature affecting you makes easier to track these kind of bugs from now on. The ui bug should be fixed now and this is probably a profile problem.

You can test this easily. (in 0.52.5)

Run

nano /tmp/var/wwwext/mervlan/settings/settings.json

Scroll down to the hardware section.
First check if it says:
"PRODUCTID": "Unsupported"
Then test to change MAX LAN to something else, like 8.
Press ctrl+x, y, then enter to save.

Then reload the UI and see if this changes the amount of ports.

If so, this is only that the model wasnt loaded and an easy fix.

Also, everytime you update the addon a backup is made. You can access and restore these by either running:

These two commands:

cd /jffs/addons/mervlan/functions

./update_mervlan restore

Or this command:

(sh /jffs/addons/mervlan/functions/update_mervlan.sh restore)

Make sure to include the ( ) if you use the oneliner.

Just follow the instructions and choose one of up to three saved backups.

@r80xcore

Hi!

Good guess, effectively, i attempted an update from my franken v0.52.4 from the gui and get back to v0.52.5.

As you guessed, there was someting wrong in the hardware detection:

"Hardware": {
"_description": "Detected hardware profile (auto-generated by hw_probe.sh; do not edit)",
"MODEL": "UNSUPPORTED",
"PRODUCTID": "RT-AC86U",
"MAX_SSIDS": "3",
"RADIOS": ["2.4", "5g-1"],
"GUEST_SLOTS": "3",
"ETH_PORTS": ["eth1", "eth2", "eth3"],
"LAN_PORT_LABELS": ["LAN1", "LAN2", "LAN3"],
"WAN_IF": "eth0",
"MAX_ETH_PORTS": "3"
}

This effectively makes the gui having just 3 ssids and 3 lan ports

Previously with v0.52.4, i had someting like this:

"Hardware": {
"_description": "Detected hardware profile (auto-generated by hw_probe.sh; do not edit)",
"MODEL": "AC86U",
"PRODUCTID": "RT-AC86U",
"MAX_SSIDS": "8",
"RADIOS": ["2.4", "5g-1"],
"GUEST_SLOTS": "3",
"ETH_PORTS": ["eth4", "eth3", "eth2", "eth1"],
"LAN_PORT_LABELS": ["LAN1", "LAN2", "LAN3", "LAN4"],
"WAN_IF": "eth0",
"MAX_ETH_PORTS": "4"
}

It looks like v0.52.5 cannot detect my router correctly anymore, like the previous version can...
I have just manually edited the hardware version with what was detected in previous version and after a reboot, the patched v0.52.5 now displays everything correctly.
It looks basically that it works, but v0.52.5 has some additionnal glitches i didn't get with v0.52.4 (at least maybe i need to "torture" v0.52.4 more). The timing with the save/apply vlan operations is much slowlier now than before (guessing of multiple ap support, but i am only editing in the 1st one single acces point setup). And sometimes there seems to have 2 page refresh after and operation which could be very delayed from each others. I got things like the vlan for a lan port was 222, just changed it to 333, save it. Waits a while for the refresh, apply the vlan. Did not change, and a refresh later, the gui revert to the previous vlan port by itself 222. (and brctl show previous vlan config) So i still think v0.52.4 is more stable. But i will continue testing the previous version to make sure that was not a coincidence...

FYI: i never got any unsupported popup at all (at least i did not see it if it was there)...

 

[r80xcore]

@r80xcore

Hi!

Good guess, effectively, i attempted an update from my franken v0.52.4 from the gui and get back to v0.52.5.

As you guessed, there was someting wrong in the hardware detection:

"Hardware": {
"_description": "Detected hardware profile (auto-generated by hw_probe.sh; do not edit)",
"MODEL": "UNSUPPORTED",
"PRODUCTID": "RT-AC86U",
"MAX_SSIDS": "3",
"RADIOS": ["2.4", "5g-1"],
"GUEST_SLOTS": "3",
"ETH_PORTS": ["eth1", "eth2", "eth3"],
"LAN_PORT_LABELS": ["LAN1", "LAN2", "LAN3"],
"WAN_IF": "eth0",
"MAX_ETH_PORTS": "3"
}

This effectively makes the gui having just 3 ssids and 3 lan ports

Previously with v0.52.4, i had someting like this:

"Hardware": {
"_description": "Detected hardware profile (auto-generated by hw_probe.sh; do not edit)",
"MODEL": "AC86U",
"PRODUCTID": "RT-AC86U",
"MAX_SSIDS": "8",
"RADIOS": ["2.4", "5g-1"],
"GUEST_SLOTS": "3",
"ETH_PORTS": ["eth4", "eth3", "eth2", "eth1"],
"LAN_PORT_LABELS": ["LAN1", "LAN2", "LAN3", "LAN4"],
"WAN_IF": "eth0",
"MAX_ETH_PORTS": "4"
}

It looks like v0.52.5 cannot detect my router correctly anymore, like the previous version can...
I have just manually edited the hardware version with what was detected in previous version and after a reboot, the patched v0.52.5 now displays everything correctly.
It looks basically that it works, but v0.52.5 has some additionnal glitches i didn't get with v0.52.4 (at least maybe i need to "torture" v0.52.4 more). The timing with the save/apply vlan operations is much slowlier now than before (guessing of multiple ap support, but i am only editing in the 1st one single acces point setup). And sometimes there seems to have 2 page refresh after and operation which could be very delayed from each others. I got things like the vlan for a lan port was 222, just changed it to 333, save it. Waits a while for the refresh, apply the vlan. Did not change, and a refresh later, the gui revert to the previous vlan port by itself 222. (and brctl show previous vlan config) So i still think v0.52.4 is more stable. But i will continue testing the previous version to make sure that was not a coincidence...

FYI: i never got any unsupported popup at all (at least i did not see it if it was there)...

I cant thank you enough for testing this and trying to debug it. It really helps me!

I have found one of the problem and its coming from the actual update. When i wrote this (quite long ago) the settings.json was quite barebone. Now when the addon has expanded it contains a lot more sections and keys. The update copies the json and then restores it afterwards. That wasnt a problem before but is now as it essentially removes key needed for the addon to function properly.

Im currently working on making the update function merge the keys instead.
After this i am going to take a look at why your model reports as unsupported. Though this is good in a way, as it meant that we actually detect a unsupported model, i must have missed a character or something in your model, making it miss it.

I'll keep you posted!

 

[mistermoonlight1]

@r80xcore

"It looks basically that it works, but v0.52.5 has some additionnal glitches i didn't get with v0.52.4 (at least maybe i need to "torture" v0.52.4 more)."

After reverting with my v0.52.4 backup using your procedure (much more easier to do this way!) i tortured it a lot more. Yes it has a couple similar glitches than v0.52.5 but maybe not so easy to get them (because of the dynamic changes in the newer version to deal will mult AP)? As v0.52.4 looks more responsive to operations than v0.52.5 (illusion?)

Thanks

 

[mistermoonlight1]

@r80xcore
Once fully uninstalled, is there any way to reinstall offline using a locally backup of a specific version (i assume there is one). I did not inspect all of your scripts, i just ask if i could simply extract a couple of scripts from the backup, and then force a full install from that backup (after completly restarting the router from zero and default configuration, after any problematic situation with the router), reinstalling offline would be usefull.

Thanks

 

[mistermoonlight1]

@r80xcore
Hi!

By testing with v0.52.4 (i guess it could be similar with the newer one). If you create a vlan, apply it on the network manually, reboot etc, nothing looks strange. But once you start to enable the service so it automatically configures on next reboot, this will cause some side effect to the web interface (there seems not to be there when the service is not enable and you play with it manually for the current active session only): after a few minutes (i didn't get a chrono to measure exactly how many), the router web gui interface is forced to logoff of its current active session (even if i set the gui to automatically logoff only after a long period, 30mn for example)! As soon as i disable the service from mervlan, this thing never appears again (so it should be triggered with something related to the service activity)...

I don't understand yet using "Persistent: On" option: what will this change in mervlan operations (except that i understand that this will save some information in the router nvram)?

Thanks

 

[r80xcore]

@r80xcore
Hi!

By testing with v0.52.4 (i guess it could be similar with the newer one). If you create a vlan, apply it on the network manually, reboot etc, nothing looks strange. But once you start to enable the service so it automatically configures on next reboot, this will cause some side effect to the web interface (there seems not to be there when the service is not enable and you play with it manually for the current active session only): after a few minutes (i didn't get a chrono to measure exactly how many), the router web gui interface is forced to logoff of its current active session (even if i set the gui to automatically logoff only after a long period, 30mn for example)! As soon as i disable the service from mervlan, this thing never appears again (so it should be triggered with something related to the service activity)...

I don't understand yet using "Persistent: On" option: what will this change in mervlan operations (except that i understand that this will save some information in the router nvram)?

Thanks

Right now Persistent doesn't do anything. If you set it to "on" the mervlan_manager.sh will translate that off. There is code for using this for AP and some other stuff but after much testing it turned out to pose problems on some users devices. I chose to ditch it (temporarily at least) until I have the time to test it more thoroughly. At the current state, the health-service takes care of any drops anyway. I have not decided yet if i want to venture down the road on that feature or skip it.

@r80xcore
Once fully uninstalled, is there any way to reinstall offline using a locally backup of a specific version (i assume there is one). I did not inspect all of your scripts, i just ask if i could simply extract a couple of scripts from the backup, and then force a full install from that backup (after completly restarting the router from zero and default configuration, after any problematic situation with the router), reinstalling offline would be usefull.

Thanks

No, not right now. A full uninstall will and should nuke mervlan from the router.

@r80xcore

"It looks basically that it works, but v0.52.5 has some additionnal glitches i didn't get with v0.52.4 (at least maybe i need to "torture" v0.52.4 more)."

After reverting with my v0.52.4 backup using your procedure (much more easier to do this way!) i tortured it a lot more. Yes it has a couple similar glitches than v0.52.5 but maybe not so easy to get them (because of the dynamic changes in the newer version to deal will mult AP)? As v0.52.4 looks more responsive to operations than v0.52.5 (illusion?)

Thanks

I tracked down the reason for your LAN and SSIDs disappearing and it turned out that i had accidentally removed the profile for your model. This explain why you have had that "bug" (my bad). It will be back in the next update.

I have also tracked down some other bugs connected to the updater and have patched it to merge the settings.json instead of copy it. This preservers the settings while also allowing the json to gradually grow. For the next update i will provide a transition command that will update the router to 0.52.6 without trashing the json. After that the updates should work as intended. The missing json values is probably the reason for you buggy UI. The UI is heavily json driven.

The next update will focus a lot on the SSH part of the addon. It will centralize all SSH commands and also have a much sturdier build around that to make sure the addon doesn't stall if a node/AP is offline or improperly configured. What this means is that future changes to the SSH functions can be changed on one place instead of in all scripts.
The execute_nodes.sh will also use parallel execution with a local guard on the nodes/AP to tell the main when to continue.