Return to Answer

1. What would make it apply is if the CIDR used by the DHCP server were sufficient to include both subnets, eg. 192.168.0.0/16.

In case it is confusing about the "wider CIDR" in relation to the "two subnets", my point is that from the perspective of the Pi's routing, there should be two distinct subnets, one on each interface. That's done with the dhcpcd.conf you have using 192.168.4.1/24 and 192.168.5.1/24. I presume you understand how CIDRs work (if not you need to), but these are both 256 addresses wide, with no overlap. Hence if you look at ip route you should see one for each.

But if possible (this depends on whether DCHP allows for this, which it would be a bit silly if it didn't -- you'll have to figure out how to configure dnsmasq to do it), what you want clients on both interfaces to believe in is:

192.168.0.0/16

This CIDR is twice as wide in terms of bits (32 - 16 = 16 vs. 32 - 24 = 8), and 256 times wider in terms of addresses (so, 65536). It includes both 192.168.4.0/24 and 192.168.5.0/24.

This way, the clients will configure their own routing to use the link to the for that entire wider range. Eg., 192.168.4.10 will send packets to the Pi for 192.168.5.42, and because of the forwarding rules, those will passed straight through as is to the other interface.²

The potential problem with this is clients might not be able to correctly connect with others on their own subnet. If that matters, some more complex iptables rules will be needed.

1. What would make it apply is if the CIDR used by the DHCP server were sufficient to include both subnets, eg. 192.168.0.0/16.

2. You don't have to use /16; 15 bits will cover up to 192.168.7.255 so you could use /27.

What you describe in "desired function" is a network bridge, except perhaps it is unidirectional in some sense, which is essentially a router: Instead of an uplink, you have another subnet on the eth interface. You could also consider it technically similar to an access point.

You should stay with the two subnets. Trying to shove them together is not a simpler solution.

You could use the linux virtual bridge, for this, but I think it is more commonplace to use IP forwarding and NAT. This is done with iptables; the standard series of commands would be something like:

sysctl -w net.ipv4.ip_forward=1
iptables -D FORWARD -i wlan1 -o eth0 -j ACCEPT
iptables -D FORWARD -i eth0 -o wlan -j ACCEPT

The difference between this and a router or hotspot is that these would involve network address translation (NAT); you will see lots of examples of this using ip masquerade.

However, sans NAT this then requires that the connected parties have their own routing configured properly -- standard OS software will set up a route to the subnet of the interface they connect to a DHCP server through, but (unless you find a way to do this with dnsmasq, I don't know whether it is possible via the protocol¹) this tells the client system nothing about the other subnet.

Quick fix on a linux client would be to add a route (or make the one to the pi bigger as per the footnote here):

ip route add 192.168.4.0/24 dev wlan0

That's presuming wlan0 is what is connected to the Pi. If you can't configure the clients, you will have to use NAT or the wider CIDR.

1. What would make it apply is if the CIDR used by the DHCP server were sufficient to include both subnets, eg. 192.168.0.0/16.

What you describe in "desired function" is a network bridge, except perhaps it is unidirectional in some sense, which is essentially a router: Instead of an uplink, you have another subnet on the eth interface. You could also consider it technically similar to an access point.

You should stay with the two subnets. Trying to shove them together is not a simpler solution.

You could use the linux virtual bridge, for this, but I think it is more commonplace to use IP forwarding and NAT. This is done with iptables; the standard series of commands would be something like:

sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -i wlan1 -o eth0 -j ACCEPT
iptables -A FORWARD -i eth0 -o wlan -j ACCEPT

The difference between this and a router or hotspot is that these would involve network address translation (NAT); you will see lots of examples of this using ip masquerade.

However, sans NAT this then requires that the connected parties have their own routing configured properly -- standard OS software will set up a route to the subnet of the interface they connect to a DHCP server through, but (unless you find a way to do this with dnsmasq, I don't know whether it is possible via the protocol¹) this tells the client system nothing about the other subnet.

Quick fix on a linux client would be to add a route (or make the one to the pi bigger as per the footnote here):

ip route add 192.168.4.0/24 dev wlan0

That's presuming wlan0 is what is connected to the Pi. If you can't configure the clients, you will have to use NAT or the wider CIDR.

1. What would make it apply is if the CIDR used by the DHCP server were sufficient to include both subnets, eg. 192.168.0.0/16.

What you describe in "desired function" is a network bridge, except perhaps it is unidirectional in some sense, which is essentially a router: Instead of an uplink, you have another subnet on the eth interface. You could also consider it technically similar to an access point.

You should stay with the two subnets. Trying to shove them together is not a simpler solution.

You could use the linux virtual bridge, for this, but I think it is more commonplace to use IP forwarding and NAT. This is done with iptables; the standard series of commands would be something like:

sysctl -w net.ipv4.ip_forward=1
iptables -D FORWARD -i wlan1 -o eth0 -j ACCEPT
iptables -D FORWARD -i eth0 -o wlan -j ACCEPT

The difference between this and a router or hotspot is that these would involve network address translation (NAT); you will see lots of examples of this using ip masquerade.

However, sans NAT this then requires that the connected parties have their own routing configured properly -- standard OS software will set up a route to the subnet of the interface they connect to a DHCP server through, but (unless you find a way to do this with dnsmasq, I don't know whether it is possible via the protocol¹) this tells the client system nothing about the other subnet.

Quick fix on a linux client would be to add a route (or make the one to the pi bigger as per the footnote here):

ip route add 192.168.4.0/24 dev wlan0

That's presuming wlan0 is what is connected to the Pi. If you can't configure the clients, you will have to use NAT or the wider CIDR.

1. What would make it apply is if the CIDR used by the DHCP server were sufficient to include both subnets, eg. 192.168.0.0/16.

What you describe in "desired function" is a network bridge, except perhaps it is unidirectional in some sense, which is essentially a router: Instead of an uplink, you have another subnet on the eth interface. You could also consider it technically similar to an access point.

You should stay with the two subnets. Trying to shove them together is not a simpler solution.

You could use the linux virtual bridge, for this, but I think it is more commonplace to use IP forwarding and NAT. This is done with iptables; the standard series of commands would be something like:

sysctl -w net.ipv4.ip_forward=1
iptables -D FORWARD -i wlan1 -o eth0 -j ACCEPT
iptables -D FORWARD -i eth0 -o wlan -j ACCEPT

The difference between this and a router or hotspot is that these would involve network address translation (NAT); you will see lots of examples of this using ip masquerade.

However, sans NAT this then requires that the connected parties have their own routing configured properly -- standard OS software will set up a route to the subnet of the interface they connect to a DHCP server through, but (unless you find a way to do this with dnsmasq, I don't know whether it is possible via the protocol¹) this tells the client system nothing about the other subnet.

Quick fix on a linux client would be to add a route (or make the one to the pi bigger as per the footnote here):

ip route add 192.168.4.0/24 dev wlan0

That's presuming wlan0 is what is connected to the Pi. If you can't configure the clients, you will have to use NAT or the wider CIDR.

1. What would make it apply is if the CIDR used by the DHCP server were sufficient to include both subnets, eg. 192.168.0.0/16.