The most straightforward way to do this is to run VLANs on the Ethernet cable between the two routers. The first router then operates only as an Ethernet switch, its software doesn't interact with the pppoe packets at all.
That's quite doable. Create a bridge and add the WAN port and the LAN port going to the secondary router. That take cares of the PPPoE relay, on the secondary router you can plug the cable to the WAN port and configure PPPoE as usual.
As for LAN, create a VLAN (802.1q) device, with the Base device being the same port that connects to secondary router. On br-lan, add this new device to the bridge. On the secondary router, similarly create VLAN, but this time of course with WAN port as the Base device and just as in primary, add it to br-lan.
Side note: I trust you know how to manage DHCP as you're bridging LAN between the two routers.
I'd imagine so. What's your setup like? As long as you bridge ports but don't attach it to any interface, you're basically creating a dumb switch all the way to whatever device decides to attach an actual interface to it.
No. The problem is that your primary router will attempt a DHCP transaction because there is no way to disable the automatic creation of a virtual DHCP interface.
Also, the vendor firmware that supports IP passthrough has a trick that has no equivalent in OpenWrt: on reconnection, they temporary drop the carrier on the LAN port, so that the downstream router sees it as a cable replug event.
I like to think there might be a way in OpenWrt or at least some interest in implementing this one day - IP passthrough is a very commonly wanted feature, as for automatic reconnection. Perhaps I should make a feature request post about it.
Ah yes, interesting - my Huawei B818-263 did that, and I wrote a little script for my downstream router running Asus Merlin to handle this:
#!/bin/sh
renew_wan_lease=0
ip monitor link dev eth0 | while read event; do
# logger "maintain-wan-lease detected eth0 event: "$event
case $event in
*'NO-CARRIER'* )
if [ $renew_wan_lease -eq 0 ]; then
logger "maintain-wan-lease detected eth0 state change to: 'NO-CARRIER', so forcing udhcpc to release wan lease."
killall -SIGUSR2 udhcpc
renew_wan_lease=1
fi
;;
*'LOWER_UP'* )
if [ $renew_wan_lease -eq 1 ]; then
logger "maintain-wan-lease detected eth0 state change from: 'NO-CARRIER' to: 'LOWER_UP', so forcing udhcpc to renew wan lease."
killall -SIGUSR1 udhcpc
renew_wan_lease=0
fi
;;
esac
done
What do you mean? If you attach a port to a bridge and don't have it connect to any interface, OpenWrt won't do anything with the interface at all. Only when you attach it to interface, enable DHCP client configuration will it attempt a DHCP transaction. Or you can simply attach it to an interface and leave it in an unconfigured state, it won't do anything with it but you can enable DHCPC if needed in the future.
At most, the bridge will act as an L2 device, effectively a dumb switch, no L3 functionality at all.
If I merely attach the wwan0 port to a bridge, there is nothing that will set the APN and bring the cellular data path up. This is a task for uqmi or ModemManager, but if installed in OpenWrt, they will automatically start the DHCP transaction, because nobody envisioned the use case where the DHCP transaction is supposed to be started by some other host via a bridge.
BTW, this sounds like an USB device. Have you considered USB over IP thing? Is that even relevant/maintained any more?
Document seems very outdated, but I don't know. Also, it doesn't have USB over IP client set up for OWrt, but it's a lead you may find interesting if your device indeed is USB.
Thanks that's very interesting. I really appreciate your input here, especially since I'm aware we're straying a bit. I believe in the NR7101 the modem is connected via USB 3.0 to a switch with a driver that isn't as performant as the OEM one, and this gives a huge speed bottleneck compared to OEM firmware. The NR7101 passes this through to ethernet and to my downstream router. But my understanding of these matters isn't as good as @patrakov's, and I may well be talking through my hat.
