Sharing Hostnames between Openwrt Routers

Velazquez · March 9, 2024, 2:49am

Hi all,

This is a continuation from the thread: 2nd Openwrt router connected to 1st can't ping ipv4 addresses

We completed making a simple routing configuration between two different openwrt routers with their own subnet. Everything works as expected. Now the last thing I am trying to figure out is how to allow the 2nd router to see the hostnames established by the first.

For example, if I navigate to V-Matrix2.lan on router 2 (it's hostname), I am brought to the luci page. But if I navigate to V-Matrix3 (Hostname for router 1), it is unable to find it. But if I navigate to the ip address of router 1, I am then brought to the luci page of router 1 (V-Matrix3). So the goal is to be able to navigate to hostnames established by router 1, from router 2, strongly preferred to be automated if possible after configurations are complete as I have some ideas in mind on how I would achieve this manually using the Hostnames setting under "DHCP and DNS" in the network section of Openwrt.

As far as I can tell just from that section, Router 1 is passing information on all active connections to router 2, which I thought was pretty cool, as when I select the dropdown, all the active ip addresses tied to a device from router 1 immediately come up, so I see all 3.0 and 4.0 subnet addresses.

A reminder about the configuration of the two routers is as follow:

Google Fiber to Openwrt Router 1[V-Matrix3] (Connected to Wan port)
Openwrt Router 1 to Openwrt Router 2[V-Matrix2] (Connected from Lan1 to Wan Respectively)

V-Matrix3 uses subnet x.x.4.0, has static route for subnet 3.0 to router 2
V-Matrix2 uses subnet x.x.3.0

With the exception of the configurations done from the previous thread, static leases, and simple administrative customizations, these openwrt routers are vanilla installs so no extra packages OR super complex configurations as of now. Here is also some config info commonly requested when trying to get help:

Router 1 [V-Matrix3]

***********************
*ubus call system board*
***********************
root@V-Matrix3:~# ubus call system board
{
        "kernel": "6.1.79",
        "hostname": "V-Matrix3",
        "system": "ARMv8 Processor rev 4",
        "model": "Dynalink DL-WRX36",
        "board_name": "dynalink,dl-wrx36",
        "rootfs_type": "squashfs",
        "release": {
                "distribution": "OpenWrt",
                "version": "SNAPSHOT",
                "revision": "r25389-fe0081eecf",
                "target": "qualcommax/ipq807x",
                "description": "OpenWrt SNAPSHOT r25389-fe0081eecf"
        }
}

*************************
*cat /etc/config/network*
*************************
root@V-Matrix3:~# cat /etc/config/network

config interface 'loopback'
        option device 'lo'
        option proto 'static'
        option ipaddr '127.0.0.1'
        option netmask '255.0.0.0'

config globals 'globals'
        option ula_prefix 'fd1d:47a8:9295::/48'

config device
        option name 'br-lan'
        option type 'bridge'
        list ports 'lan1'
        list ports 'lan2'
        list ports 'lan3'
        list ports 'lan4'

config interface 'lan'
        option device 'br-lan'
        option proto 'static'
        option ipaddr '192.168.4.1'
        option netmask '255.255.255.0'
        option ip6assign '60'

config interface 'wan'
        option device 'wan'
        option proto 'dhcp'

config interface 'wan6'
        option device 'wan'
        option proto 'dhcpv6'

config route
        option interface 'lan'
        option target '192.168.3.0/24'
        option gateway '192.168.4.252'


**************************
*cat /etc/config/firewall*
**************************
root@V-Matrix3:~# cat /etc/config/firewall

config defaults
        option input 'REJECT'
        option output 'ACCEPT'
        option forward 'REJECT'
        option synflood_protect '1'
        option flow_offloading '1'

config zone
        option name 'lan'
        list network 'lan'
        option input 'ACCEPT'
        option output 'ACCEPT'
        option forward 'ACCEPT'

config zone
        option name 'wan'
        list network 'wan'
        list network 'wan6'
        option input 'REJECT'
        option output 'ACCEPT'
        option forward 'REJECT'
        option masq '1'
        option mtu_fix '1'

config forwarding
        option src 'lan'
        option dest 'wan'

config rule
        option name 'Allow-DHCP-Renew'
        option src 'wan'
        option proto 'udp'
        option dest_port '68'
        option target 'ACCEPT'
        option family 'ipv4'

config rule
        option name 'Allow-Ping'
        option src 'wan'
        option proto 'icmp'
        option icmp_type 'echo-request'
        option family 'ipv4'
        option target 'ACCEPT'

config rule
        option name 'Allow-IGMP'
        option src 'wan'
        option proto 'igmp'
        option family 'ipv4'
        option target 'ACCEPT'

config rule
        option name 'Allow-DHCPv6'
        option src 'wan'
        option proto 'udp'
        option dest_port '546'
        option family 'ipv6'
        option target 'ACCEPT'

config rule
        option name 'Allow-MLD'
        option src 'wan'
        option proto 'icmp'
        option src_ip 'fe80::/10'
        list icmp_type '130/0'
        list icmp_type '131/0'
        list icmp_type '132/0'
        list icmp_type '143/0'
        option family 'ipv6'
        option target 'ACCEPT'

config rule
        option name 'Allow-ICMPv6-Input'
        option src 'wan'
        option proto 'icmp'
        list icmp_type 'echo-request'
        list icmp_type 'echo-reply'
        list icmp_type 'destination-unreachable'
        list icmp_type 'packet-too-big'
        list icmp_type 'time-exceeded'
        list icmp_type 'bad-header'
        list icmp_type 'unknown-header-type'
        list icmp_type 'router-solicitation'
        list icmp_type 'neighbour-solicitation'
        list icmp_type 'router-advertisement'
        list icmp_type 'neighbour-advertisement'
        option limit '1000/sec'
        option family 'ipv6'
        option target 'ACCEPT'

config rule
        option name 'Allow-ICMPv6-Forward'
        option src 'wan'
        option dest '*'
        option proto 'icmp'
        list icmp_type 'echo-request'
        list icmp_type 'echo-reply'
        list icmp_type 'destination-unreachable'
        list icmp_type 'packet-too-big'
        list icmp_type 'time-exceeded'
        list icmp_type 'bad-header'
        list icmp_type 'unknown-header-type'
        option limit '1000/sec'
        option family 'ipv6'
        option target 'ACCEPT'

config rule
        option name 'Allow-IPSec-ESP'
        option src 'wan'
        option dest 'lan'
        option proto 'esp'
        option target 'ACCEPT'

config rule
        option name 'Allow-ISAKMP'
        option src 'wan'
        option dest 'lan'
        option dest_port '500'
        option proto 'udp'
        option target 'ACCEPT'

config redirect
        option dest 'lan'
        option target 'DNAT'
        option name 'V-Frame Website (HTTP)'
        list proto 'tcp'
        option src 'wan'
        option src_dport '80'
        option dest_ip '192.168.4.2'
        option dest_port '82'

config redirect
        option dest 'lan'
        option target 'DNAT'
        option name 'V-Frame Website (HTTPs)'
        list proto 'tcp'
        option src 'wan'
        option src_dport '443'
        option dest_ip '192.168.4.2'
        option dest_port '8084'


**********************
*cat /etc/config/dhcp*
**********************
root@V-Matrix3:~# cat /etc/config/dhcp

config dnsmasq
        option domainneeded '1'
        option localise_queries '1'
        option rebind_protection '1'
        option rebind_localhost '1'
        option local '/lan/'
        option domain 'lan'
        option expandhosts '1'
        option cachesize '1000'
        option authoritative '1'
        option readethers '1'
        option leasefile '/tmp/dhcp.leases'
        option resolvfile '/tmp/resolv.conf.d/resolv.conf.auto'
        option localservice '1'
        option ednspacket_max '1232'

config dhcp 'lan'
        option interface 'lan'
        option start '100'
        option limit '150'
        option leasetime '12h'
        option dhcpv4 'server'
        option dhcpv6 'server'
        option ra 'server'
        list ra_flags 'managed-config'
        list ra_flags 'other-config'

config dhcp 'wan'
        option interface 'wan'
        option ignore '1'

config odhcpd 'odhcpd'
        option maindhcp '0'
        option leasefile '/tmp/hosts/odhcpd'
        option leasetrigger '/usr/sbin/odhcpd-update'
        option loglevel '4'

config host
        option name 'V-Frame'
        option ip *Redacted*
        list mac *Redacted*

config host
        option ip *Redacted*
        list mac *Redacted*

config host
        option name *Redacted*
        option ip *Redacted*
        list mac *Redacted*

config host
        option name *Redacted*
        option ip *Redacted*
        list mac *Redacted*

config host
        option name 'V-Matrix2'
        option duid *Redacted*
        list mac *Redacted*
        option ip *Redacted*

Router 2 [V-Matrix2]

***********************
*ubus call system board*
***********************
root@V-Matrix2:~# ubus call system board
{
        "kernel": "6.1.80",
        "hostname": "V-Matrix2",
        "system": "ARMv8 Processor rev 4",
        "model": "Dynalink DL-WRX36",
        "board_name": "dynalink,dl-wrx36",
        "rootfs_type": "squashfs",
        "release": {
                "distribution": "OpenWrt",
                "version": "SNAPSHOT",
                "revision": "r25398-d40d64fc62",
                "target": "qualcommax/ipq807x",
                "description": "OpenWrt SNAPSHOT r25398-d40d64fc62"
        }
}

*************************
*cat /etc/config/network*
*************************
root@V-Matrix2:~# cat /etc/config/network

config interface 'loopback'
        option device 'lo'
        option proto 'static'
        option ipaddr '127.0.0.1'
        option netmask '255.0.0.0'

config globals 'globals'
        option ula_prefix 'fd74:2c31:edd4::/48'

config device
        option name 'br-lan'
        option type 'bridge'
        list ports 'lan1'
        list ports 'lan2'
        list ports 'lan3'
        list ports 'lan4'

config interface 'lan'
        option device 'br-lan'
        option proto 'static'
        option ipaddr '192.168.3.1'
        option netmask '255.255.255.0'
        option ip6assign '60'

config interface 'wan'
        option device 'wan'
        option proto 'dhcp'

config interface 'wan6'
        option device 'wan'
        option proto 'dhcpv6'


**************************
*cat /etc/config/firewall*
**************************
root@V-Matrix2:~# cat /etc/config/firewall

config defaults
        option input 'REJECT'
        option output 'ACCEPT'
        option forward 'REJECT'
        option synflood_protect '1'

config zone
        option name 'lan'
        list network 'lan'
        option input 'ACCEPT'
        option output 'ACCEPT'
        option forward 'ACCEPT'
        option masq '1'

config zone
        option name 'Router'
        option input 'REJECT'
        option output 'ACCEPT'
        option forward 'REJECT'
        list network 'wan'
        list network 'wan6'

config forwarding
        option src 'lan'
        option dest 'Router'

config forwarding
        option src 'Router'
        option dest 'lan'


**********************
*cat /etc/config/dhcp*
**********************
root@V-Matrix2:~# cat /etc/config/dhcp

config dnsmasq
        option domainneeded '1'
        option rebind_protection '1'
        option rebind_localhost '1'
        option domain 'lan'
        option expandhosts '1'
        option cachesize '1000'
        option readethers '1'
        option leasefile '/tmp/dhcp.leases'
        option localservice '1'
        option ednspacket_max '1232'
        option localise_queries '1'
        option authoritative '1'
        option local '/lan/'

config dhcp 'lan'
        option interface 'lan'
        option start '100'
        option limit '150'
        option leasetime '12h'
        option dhcpv4 'server'
        option dhcpv6 'server'
        option ra 'server'
        list ra_flags 'managed-config'
        list ra_flags 'other-config'

config dhcp 'wan'
        option interface 'wan'
        option ignore '1'

config odhcpd 'odhcpd'
        option maindhcp '0'
        option leasefile '/tmp/hosts/odhcpd'
        option leasetrigger '/usr/sbin/odhcpd-update'
        option loglevel '4'

config host
        option name *Redacted*
        option duid *Redacted*
        list mac *Redacted*
        option ip '*Redacted*'

Edit 1: Initial Corrections

psherman · March 9, 2024, 6:20am

Broadly speaking, I could see two ways of approaching this problem...

Router 1 serves as the primary DNS and contains all of the DNS records.
Each router contains the DNS records for it's specific subnet

And there's actually a 3rd option wherein the primary DNS server is a 3rd device (like a pihole) and both routers reference that.

Do you have any opinions (or reasons/constraints) that would suggest one over the others?

Velazquez · March 9, 2024, 7:36am

With my limited understanding of what may be required/at play here, let me go from most preferred down:

Each router contains the DNS records for it's specific subnet

This one sounds like the closest to what I am trying to achieve and potentially the easy. I would love to know how to achieve it where they both are able to contain DNS records and share the hostnames between the two. The biggest desire is automation, so I manually set a hostname on one router, and the second router then knows and can allow navigation to said hostname.

Router 1 serves as the primary DNS and contains all of the DNS records.

I have no issue with this one if the subnets don't have to be changed. And even if it technically doesn't have to be changed and be on the same subnet (Doing things manually via the command lines), I'm curious if there would be any complaints from the luci interface about working with ip's outside the designated subnet for the lan interface. May not apply, especially for this, just know luci can be annoying sometimes and you just better off running some ssh stuff.

The third option sounds cool, but I don't have a third device feasible to achieve it, but I'll look into that in the future as I do intend to add the new pi device that has Wifi 7 capabilities with two 10gb fiber ports. Someday anyway when I have time.

psherman · March 9, 2024, 5:33pm

We should be able to get things working that way, although it may take some creativity and experimentation.

Before going further, though... I want to raise a question I had asked in the previous thread: is there a reason you want to run 1 subnet on each of the two routers? The main router could be used to handle both subnets directly, and this would greatly simplify the routing and DNS considerations. Your second router could be used as a smart switch/dumb AP as needed (or removed if you don't need those features).

Velazquez · March 9, 2024, 10:49pm

Oh yes, my apologies as I did mean to address that and got sidetracked.

This is mostly for lab/home experimenting learning purposes. I know I could disable dhcp on the second router and make the first do all the work and simplify things. I'm interested in this setup because my goal is to have two separate routers able to communicate with each other while also being completely un-reliant on the other to provide basic functionality. A lot of times with the dumb ap setups I've experienced, should the main router die or lose connection, then the second router can't issue ip addresses and will only allow static connections (You needing to configure your device with a static ip before connecting it). Some I've experience then also lose the ability to communicate with other devices on the same router.

I'd be more than willing to give new configurations a try, a lot of what I've experienced have been from many years ago, so I know things could of been established better now. if the following concerns are handled with the proposed setup, then I'll try it:

When router 1 is lost, Router 2 is still able to handle active and new connections to the device, to include things like communication between connected devices and handle the connection of a new device never connected before (so no active lease)
When router 1 is lost, Devices on Router 2 are able to continue to communicate with each other by both i.p addresses and hostnames depending on their configurations (Software communicating with devices via I.P. . . OS systems setup to connect with NAS via hostname.)
While optional, but strongly preferred, it would be nice for both routers to be on different subnets as a visual means to know what device is connected to which router based on the i.p is has assigned (I do have a few roaming experiments I want to document where this would be made easier if I could just see i.p changes and immediately know which router said device is connected to).

psherman · March 10, 2024, 12:35am

So broadly speaking, I'd say that you are not really going to solve many, if any of the reliability issues you've discussed. If anything, you're adding more equipment which means more possible points of failure.

Fundamentally speaking, you're still dealing with single-point-of-failure type situations.

If the main router goes down, that means that all connections upstream of the second router are cut off... meaning that the internet goes down as well as access to the devices that are connected to the first router from the second router. Depending on the situation (discussed in a moment), devices on the first network may not be able to talk to each other, either.
The second router could also go down (instead of, or in addition to the first) which would mean that all of the downstream devices would be unreachable from the first router's network, and obviously the devices behind the second router wouldn't be able to access the internet or the upstream devices. And again, maybe or maybe not each other.
For both routers, the ability for devices on the same network to talk to each other depends on if the path of the connection is physically still up or not. If you're using the router's built-in wifi and/or ethernet switch and the router goes down (i.e. hardware failure or crash of the wifi drivers), the devices will not be able to communicate with each other because the connection path is broken. This is only mitigated if there is a physical connection that is not dependent on the router (i.e. a dumb AP and/or an external switch -- although that could always fail, too).
Assuming that there is an external dumb AP or switch so the path is not broken... if a router goes down, the devices that have active DHCP leases will still be able to talk to each other, but those that don't will still be unable to join the network via DHCP (you can set static IPs instead, but the failure of the router is usually the more critical aspect). This includes when the leases expire or when devices are disconnected/reconnected or rebooted and need to request a lease.

Absent misconfigurations, consumer wifi routers are actually quite reliable these days -- they last many years with very little fuss. Of course, there is always the chance that your particular unit fails for whatever reason ('naturally' due to component failures, external factors including things like power surges or a cup of coffee spilled on it, etc.).

The reality is that unless you go into the "high availability" realm of networking (usually at an enterprise level), adding equipment is actually increasing your chances of a failure, not decreasing it (at a statistical level). And if either one goes out, you'll need to scramble to fix it anyway.

All that said, my personal recommendation is to have a single router doing all the routing, and the secondary device just operates as a dumb AP. That is a good approach unless:

You want to have the 2 independent routers for academic/learning purposes
You want to be able to experiment with the second router's configuration with no impact to the upstream router... obviously misconfiguring your downstream router can cause the downstream network to go offline, but that inherently limits the scope of the 'outage.' (this is particularly important if you have other occupants/users to consider -- best to only mess up your own segment of the network but not interrupt their usage).

Actually, it's not optional insofar as the routers cannot route between networks that are the same or overlapping. They must, by definition, be different subnets.

But roaming between these two routers will not be a good experience if they are handling different subnets. Wifi roaming is supposed to be between two or more APs that have the same SSID+Passphrase+subnet. If you have the SSID+passphrase the same but a different subnet, that will actually cause more headaches than it solves because the devices will constantly be changing networks - this means a longer process for roaming, and some devices may become unhappy in the process.

A set of dumb APs broadcasting the same SSID (with the same passphrase) should be on the same network. It is actually possible to setup your second router as a dumb AP to the first and also for it to perform routing to a separate downstream network -- this could be a good compromise if you want to have roaming and a lab network that you can mess up without consequence to the main network.

slh · March 10, 2024, 4:00am

And for routing to work (rather than double-NAT and no access to devices behind the second router, if this is desired or not is a policy decision, so there is no right- or wrong), you will have to configure static routes on the main router to the LAN subnet of the second one - possible, but usually not great.

psherman · March 10, 2024, 4:03am

@slh is right, but per the other thread, we did get the static routes working as well as the intentionally allowed wan > lan firewall changes (along with disabling masquerading) to allow full symmetric routing.

slh · March 10, 2024, 4:05am

Yes, but the problem is that any changes to the LAN subnet of the second router will have to be replicated/ followed by the static route definitions of the first router. This means the secondary router is not really independent of the primary router - and configurations need to be done (in lockstep) in two places, which is always bad long term.

psherman · March 10, 2024, 4:08am

Exactly right. That's why I really think that the better approach is doing this all on a single router. (unless the purpose is for learning about routing or use as an experimental/lab network router that can be messed up without consequence to the upstream).

Velazquez · March 14, 2024, 5:14am

Hi all,

I'm really sorry about the delay, long story short, my PC was having the strangest overheating issue where it would get hot then shut off, the CPU would get 86+ Celsius and cut off. I ordered, waited in the mail and then applied new thermal paste, but the PC would still cut off with no warning. One day, when it did it, after it would cut off, I'd still here a noise, when I looked further into it, it was PSU fan that would still run a bit after the outage . . . I now had my likely suspect.

I took the PSU out and left it connected to the PC and cut the pc on, didn't have an issue, I cleaned the fan (was already really clean) and made some adjustments to the PC regarding it's airflow as I learned the PSU was sucking air from the mesh vent on the bottom of the case, and made me believe it was not sucking adequate air from under the PC case. Once I addressed that, it hasn't shut off after leaving it on for 3+ days and even running palword and some stress tests on it. Seems to be good now, so let's get back to it!

You want to have the 2 independent routers for academic/learning purposes

Thank you for pointing this out, I should of been more careful about my post with regards to the environment I was trying to establish. Yes, this is all 100% to design a learning environment that I plan to use to educate myself and others. The idea is for me to be able to nuke the router, and still have the upstream router so I don't lose internet and some critical devices like my Nas server. I expect to even soft brick the downstream router a few times.

I am also a budding developer and plan to begin to get my hands dirty in coding and developing solutions, so I'm trying to make the ideal environment.

With that being said, let's take it from the top, I haven't made any changes to the router settings vs some more static I.Ps for devices on the downstream router. One thing to point out that I want to note is that even though the downstream router can communicate with the upstream router and all it's devices, for whatever reason, the upstream router cannot communicate with any of the downstream devices when I attempt to ping them from the diagnostic page in openwrt. No settings have been changed on it (V-Matrix3) since I posted its configuration on earlier in this thread (and from last thread). I would of thought that creating the static route on the upstream router like we did before would of been all that was needed right? since it would have the subnet (X.X.3.0). Any ideas?

psherman · March 14, 2024, 5:28am

Three things are necessary:

static route in the upstream router (which appears to be in place -- 192.168.3.0/24 via 192.168.4.252 -- just verify that .252 is the actual address on the wan of the 2nd router.
Masquerading must be disabled in the wan firewall zone (you've named it Router) for the 2nd router. It is, but for some reason masquerading is enabled on the lan zone... that should also be disabled.
forwarding from lan > router and router > lan -- also in place.

I predict that things will start working when you remove the masquerading from the lan zone.

That said, there is one other 'gottcha' -- some devices and operating systems by default will not communicate across subnets. The Windows firewall, for example, needs to be disabled or otherwise told that this is desired. PiHole, by default, will only respond on the same subnet as well. Some NAS devices do the same, and certain IoT devices also have this default behavior... in some cases, it could even be a limitation and/or a design decision based on certain assumptions.

Velazquez · March 15, 2024, 5:22am

After disabling that Masquerading, the upstream router was still unable to ping the downstream router, and I was having a really difficult time understanding why the downstream router was acting like the world's best shadow router. Right on the front page of openwrt on the Upstream router, where you can see all the active connections, it wasn't there, which was kinda wild as the downstream router still had my static assigned ip ending in .252 and could communicate with no issue to all upstream devices

It took 3 reboots before I saw it come up under the Active DHCP list with the same ip, it was so strange. I reenabled masquerading and changed the Router zone (Router -> Lan) to accept for input. After this change, it worked. For those that may be wondering:

In a zone, if you set input to accept: Upstream router can ping all downstream routers that will respond and the Router

If you set input to reject (Default), and Intra zone forward to accept: Upstream router can ping all devices that will respond on the Downstream router except the downstream router.

Now before we get to the root of the host transfers I was seeking, is there any recommendations between input vs intra zone forwarding being accepted? I am finding surprisingly little information regarding the two in terms of real world applicable use. I am clearly missing something. I understand that the intra zone forwarding really comes into play when there are multiple interfaces. Would I be correct in saying that:

Instead of making multiple zones to cover each interface(int) to be able to forward traffic to each other [int1 -> int2, int 2 -> int3, int3 -> int4, int1 -> int 3, int 1 -> int 4, etc...] You could enable intra zone forward and simply do [int1 -> int2,int3,int4] and all the traffic would be able to communicate between interfaces as if you made each interface explicit like the first example?

After that, we can finally get started with the original intent of the thread =), sorry. I try to leave as much information as possible in hopes to help those that may stumble on this thread something not necessarily directly related to what we are doing!

My initial target is the dhcp lease table on either router, in terms of what I am envisioning. I think the goal regarding hostnames being automatically shared between routers lies under network -> DHCP and DNS -> hostnames

For anybody looking to just make a simple quick fix, you can manually add the hostname and ip address of the device on the other routers here to navigate to it as if you were on the same network it was on (navigating via it's hostname)

Now for me, I am thinking there should be a way where:

Router1 get's all the dhcp names with their ip/mac addresses
Router1 connects to Router2, and either
a. authenticates itself and then writes the hostnames directly to whatever file openwrt uses to store this particular collection of hostnames
b. OSPFv3 somehow is configured to pass hostname information, allegedly possible in a cisco post I was reading (but not too deeply cause its cisco and they be full of proprietary nonsense).

Edit 1: spelling fix

Velazquez · April 27, 2024, 4:42am

Just want to give everyone an update!

First sorry I went dark for a while (Again lol), regular work is hard, bussiness is also ramping up so running it has been more demanding even though it's still in my hobby stages. I'm finally getting around to it, so let me update what is imminent once I'm done making the video (that could be a week from now lol),

I am going to post my proof of concept video as I was able to successfully achieve what I wanted to do, all that is left is to make it automated and improve scenario handling along with bug resolutions. What to expect with this initial video release:

A explaination on how to setup passwordless SSH capabilities between openwrt routers
A demostration of what happens when you run the script, which gets the hostnames of all the devices in the upstream router and add it to the downstream router as domain entires so you can navigate to them via their hostnames vs their ip address.
Then lastly, the initial limitations of the script along with some rambling =)