For testing reasons, I have Openwrt #2's WAN port connected into one of the LAN ports of Openwrt #1, but the former (#2) is unable to get a DHCP lease from the latter (#1), even though it (#2) could from the ISP CPE modem if directly connected to that. What could be the cause of this, from a config standpoint, on either or both of Openwrt #1 and #2? I've configured them as identically as possible.
OpenWRT #2 has to have the LAN interface set to DHCP Client, and the ethernet would need to be plugged into on the LAN ports. Getting an IP from your ISP is WAN side. You want to receive it from the LAN side. Make sure you disable DHCP on OpenWRT #2.
You could also assign OpenWRT #2 a static IP outside OpenWRT #1's DHCP lease settings and connect it to a LAN port and it should work.
I assume that based on the config explanation, you want the #2 to act as a router, so that its WAN is in router1's LAN. In that case, you need to remember to change the #2's LAN subnet from 192.168.1.x to something else, so that it can use the 192.168.1.x addresses for WAN (from #1).
One explanation might be identical hostname? Both are named "OpenWrt"?
The advice from jc1685 is more related to "dumb AP" advice, but I am not sure what your intention actually is...
They do have different hostnames, so I get differently-named backup-archive.tar.gz so I don't get confused, haha. But why would Openwrt (software-wise) care, if the upstream sees another "Openwrt" downstream requesting DHCP?
Both are configured for router mode, as I'm undecided and want to keep both on wire synchronizing the configs as much as possible. One supports hardware flow offloading, so that's more likely.
IP addressing wise, the CPE has DHCP server enabled too, and is handing out 192.168.x.x. Both Openwrt devices have a "CPE" interface along with WAN/WAN6 statically IPed to 192.168.x.x so I could access the CPE's management GUI from my LAN. On the Openwrt themselves, the WAN/WAN6 interfaces are in DHCP client mode, but one Openwrt (#1) has a static 10.1.x.1 for the "lan", and the other Openwrt (#2) has static 10.2.x.1 for "lan". Both Openwrt serve a range of 10.x.x.x as "authoritative" on their respective LAN DHCP, but I assume #1 serves the 10.1.x.x range while #2 does 10.2.x.x, based on their respective static "lan" interface IP addr.
Wait, it just occurred to me: Is it because of "Discard upstream RFC1918 responses" rebind protection? But why could #2 get DHCP lease in the 192.168.x.x range from the CPE then?
opkg update; opkg install tcpdump; tcpdump -i br-lan -evn udp port 67
Let tcpdump capture a few packets, stop with
Ctrl-c and paste here the output.
Shortly I ran this on #1, I saw that #2 was able to get a lease from #1. Obviously it's not due to tcpdump itself. I don't recall making many changes, other than making a change /etc/config/network on #2:
config interface 'iptv' option proto 'none' option type 'bridge' option stp '1' option ifname 'eth0.55'
config interface 'iptv' option proto 'none' option type 'bridge' option stp '1' option ifname 'eth0.55 eth1.55'
because #2's eth1 ("wan") does not get exposed to its RTL8366S switch0, but I need to keep the WAN and LAN ports in VLAN55 for IPTV.
Wait, #1 (the upstream Openwrt) seems to lose internet on its WAN port (connected to the CPE), when #2's WAN port is connected and getting a DHCP(v4) lease from one of #1's LAN ports. So I couldn't even post this reply until I unplug #2 WAN from #1's LAN. Merely restarting the "wan" interface in Luci, or "/etc/init.d/network restart" still couldn't recover; have to reboot #1 to get it to reconnect (get DHCP lease) from the CPE. Is it due to a bridge loop from the IPTV VLAN stuff, or a routing loop?
Even when #2 WAN was connected to #1 with a DHCP lease, I couldn't ping #2 from #1 (Openwrt's firewall blocking incoming WAN ping by default?)
Hard to say, there isn't enough information. We don't know the topology nor the configurations.
There is a rule to allow the ping if I remember correctly. But still, you can verify that yourself.