config host
option name 'MX4300-NODE-1'
list mac 'xx:xx:xx:xx:xx:xx'
option ip '192.168.192.2'
config host
option name 'MX4300-NODE-2'
list mac 'xx:xx:xx:xx:xx:xx'
option ip '192.168.192.3'
config domain
option name 'NODE-1'
option ip '192.168.192.2'
config domain
option name 'NODE-2'
option ip '192.168.192.3'
Configuring Multiple SSIDs (IoT and Guest) over Mesh with VLAN Tunneling:
I successfully followed Marc's video tutorial on "Guest Wi-Fi over Mesh with VLAN tunneling" (link to video) and got the Guest Wi-Fi working across my mesh nodes.
In the video, Marc briefly touches on setting up an IoT network, but I wasn’t able to get it configured properly. I’m aiming to add multiple SSIDs (Guest, IoT, etc.) and route them through VLAN tunneling over the mesh without needing cables between the mesh nodes.
Has anyone managed to configure multiple SSIDs (Guest + IoT) over mesh with VLAN tunneling?
My mistake. My setup is slightly different. Primary router connects to node1 via cable which means no wifi entries for those nodes are shown.
Try the following:
#!/bin/sh
HOME=/root
USER=root
run_dir=/var/run/scp_leases
mkdir -p $run_dir
exec 201> $run_dir/lock
if ! flock -n 201; then
exit 0
fi
leases_file="/tmp/dhcp.leases"
# Create a temporary file with the node information
cat << EOD > /tmp/nodes
0 XX:XX:XX:XX:XX:XX 192.168.192.2 MX4300-NODE-1 *
0 XX:XX:XX:XX:XX:XX 192.168.192.3 MX4300-NODE-2 *
EOD
# Read the nodes file line by line and append to local dhcp.leases if the line doesn't exist
while IFS= read -r line; do
if ! grep -qF "$line" "$leases_file"; then
echo "$line" >> "$leases_file"
fi
done < /tmp/nodes
# Transfer the updated file to each node.
for i in 2 3; do
if ping -q -A -c 1 -W 1 192.168.192.$i > /dev/null; then
scp $leases_file 192.168.192.$i:/tmp/dhcp.leases
fi
done
This updates the local file first and then scps everything over
P.S. You can remove the domain entries from my previous comment
It works on the parent. Hooray and I see that you added the nodes to /tmp/dhcp.leases for the parent and the two nodes. But, now the nodes are showing "?" for the parent and the other node shows up properly. We are getting close.
I guess I can add the entry for the main like this along with the other 2 nodes? Wouldn't cause any issue to have an entry for the parent router?
0 XX:XX 192.168.192.1 MESH-MAIN *
Btw, thank you so much for fixing the luci deficiency
I have the parent + 2 nodes. That's what I was thinking to add the parent to the /tmp/nodes but wouldn't cause any issue to have the parent's IP on /dhcp.leases?
EDIT: It works on the parent + 2 nodes after this fix.
Deeply appreciate all your help in resolving this and won't bother you again for a while.
Nope, as far as dnsmasq is concerned it believes it handed those leases. Furthermore, since the first column of each entry is 0, it sees the lease as infinite (never expires).
I ended up following his third video with batman_adv. I find it much easier when you have more nodes to set up. Then I just assign bat0.2 to the IoT said and bat0.3 to the guest ssid etc and they all connect onto the correct vlan. I also bridged some lan ports (say lan1) with bat0.x so I can hardwire my TV/console but keep them from my main network.
I managed today to create a 802.11s mesh with three vlans using dd-wrt (with nss-ecm), without using batman-adv. Still testing but working surprisingly well so far. I spent many hours trying to figure this out and eventually did. Still not entirely sure why or how it works (because it shouldn't without a tunnel), but it certainly does.
Presently it is working from mx4300 (main wired node w/trunk lan) to a mr7350 (wireless secondary node). I have not tried a third node yet with this configuration.
I will do a complete how-to soon, for ddwrt but should be adaptable.
Yes. Set up is the same as Marc’s video. Only thing he didn’t touch on was how to untag ports for vlan. I just bridged the ports with bat0.x and created an interface and it works great.
@qosmio I built your repo today and see that the kernel got updated to 6.6.52. Very nice!
Btw, whenever I flash a new version, the files under /root is wiped out and the file, id_dropbear in /root/.ssh folder, is gone and have to copy it over. Is there any way to preserve it when flashing a new version?
I know I can save the id_dropbear file somewhere on the filesystem and copy it over after the reboot process but was wondering why the files are getting removed?
If you find yourself having to copy over files that are relatively static, consider including them as part of your build under the "files" folder.
Things like SSH keys, UCI configs, custom hot plug scripts, let's encrypt SSL certs, etc.
You can also include in your image a custom /etc/sysupgrade.conf that defines what to keep when doing a sysupgrade. But do try to copy back your changes into your custom build files folder so you're always flashing the latest version in case you add new hardware.
I also have mini usb flash drives attached on all my devices that serves as the root for packages installed through opkg and to preserve files that have potential to grow, like shell history.
Take a look at the docs below and through the build system sections for ways to do that.
For the procedure to return to stock firmware, can I simply flash it from the OpenWRT firmware upgrade page, or should I install it from ssh manually
I have the Arix FOSS build installed currently 1 setup as router and 4 setup as dumb APs. Lan speed is excellent 900+ Mbps, but wifi is 350 Mbps or below. Stock firmware got wifi speeds of twice that.
If possible can you update your guide to to include those instructions?
Thank you and that's a very good suggestion. I will look into it. For now, I have ONLY 3 files that need to be saved and for now, I stored them in /etc/config and they are retained as part of the firmware flash.
I created a script to copy them to their respective locations (from /etc/config) at the end of the reboot process and it works!
I didn't say it is a bug. I was curious why they are removed after updating the firmware. It's like when you update your phone to a new version, the data is retained unless you choose to wipe it. FWIW, files under /etc/config are retained (because we specifically check the box) and was hoping that is the case with /root as well. Apparently not!
For now, I have a solution that works by copying from /etc/config and will try to implement what @qosmio suggested in the not so distant future.
