Even without the ability to modify the configuration on the router, this is still just a routing problem.
I've simulated your network topology in mininet using this code:
from mininet.cli import CLI
from mininet.net import Mininet
from mininet.node import OVSBridge
from mininet.topo import Topo
from mininet.log import info, error, setLogLevel
class HomeNetwork(Topo):
def build(self):
s0 = self.addSwitch('s0')
router = self.addHost('router', ip='192.168.18.1/24')
hostA = self.addHost('hostA', ip='192.168.18.69/24')
hostB = self.addHost('hostB', ip='192.168.18.70/24')
rpi3b = self.addHost('rpi3b', ip='192.168.11.100/24')
rpi4b = self.addHost('rpi4b', ip='192.168.10.150/24')
self.addLink(router, s0)
self.addLink(hostA, s0)
self.addLink(hostB, s0)
self.addLink(rpi3b, hostA, params2=dict(ip='192.168.11.1/24'))
self.addLink(rpi4b, hostB, params2=dict(ip='192.168.10.1/24'))
topos = {"home": HomeNetwork}
We start up the simulated environment like this:
sudo mn --custom homenetwork.py --topo home
Because we're not actually using DHCP in this example, none of our hosts have appropriate routes, so let's populate the necessary default routes around the network:
mininet> hostA ip route add default via 192.168.18.1
mininet> hostB ip route add default via 192.168.18.1
mininet> rpi3b ip route add default via 192.168.11.1
mininet> rpi4b ip route add default via 192.168.10.1
With this in place, we should to be able to ping hostA from rpi3b:
mininet> rpi3b ping -c1 hostA
PING 192.168.18.69 (192.168.18.69) 56(84) bytes of data.
64 bytes from 192.168.18.69: icmp_seq=1 ttl=64 time=0.032 ms
--- 192.168.18.69 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.032/0.032/0.032/0.000 ms
We want to be able to reach rpi4b (192.168.10.150) from rpi3b. If we try that right now, it won't work:
rpi3b doesn't have a direct route to 192.168.10.0/24, so it sends traffic via its default route (which is hostA)hostA doesn't have a direct route to 192.168.10.0/24, so it sends traffic via its default route (which is the isp router)- The isp router doesn't have a direct route to
192.168.10.0/24, so it effectively drops the traffic.
The easiest solution here is just to take the isp router out of the equation.
We can add a route from hostA to the 192.168.10.0/24 network via hostB:
mininet> hostA ip route add 192.168.10.0/24 via 192.168.18.70
And a route from hostB to the 192.168.11.0/24 network via hostA:
mininet> hostB ip route add 192.168.11.0/24 via 192.168.18.69
With these routes in place, rpi3b can reach rpi4b without a problem:
mininet> rpi3b ping -c2 rpi4b
PING 192.168.10.150 (192.168.10.150) 56(84) bytes of data.
64 bytes from 192.168.10.150: icmp_seq=1 ttl=62 time=0.037 ms
64 bytes from 192.168.10.150: icmp_seq=2 ttl=62 time=0.043 ms
--- 192.168.10.150 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1003ms
rtt min/avg/max/mdev = 0.037/0.040/0.043/0.003 ms
And the reverse is also true:
mininet> rpi4b ping -c2 rpi3b
PING 192.168.11.100 (192.168.11.100) 56(84) bytes of data.
64 bytes from 192.168.11.100: icmp_seq=1 ttl=62 time=0.474 ms
64 bytes from 192.168.11.100: icmp_seq=2 ttl=62 time=0.043 ms
--- 192.168.11.100 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1005ms
rtt min/avg/max/mdev = 0.043/0.258/0.474/0.215 ms
After running the above commands, routes on hostA look like:
mininet> hostA ip route
default via 192.168.18.1 dev hostA-eth0
192.168.10.0/24 via 192.168.18.70 dev hostA-eth0
192.168.11.0/24 dev hostA-eth1 proto kernel scope link src 192.168.11.1
192.168.18.0/24 dev hostA-eth0 proto kernel scope link src 192.168.18.69
And on hostB look like:
mininet> hostB ip route
default via 192.168.18.1 dev hostB-eth0
192.168.10.0/24 dev hostB-eth1 proto kernel scope link src 192.168.10.1
192.168.11.0/24 via 192.168.18.69 dev hostB-eth0
192.168.18.0/24 dev hostB-eth0 proto kernel scope link src 192.168.18.70
