OpenWrt Failover & Repeater with non-WRT router?

I'm trying to figure out the best configuration on an OpenWRT router to act as a backup to a proprietary modem/router I'm stuck with. When the proprietary router is off, the local WiFi needs to remain intact so the clients can still communicate locally.

Constraints (for those who must know why)

I live in an area with no grid power and no regular (cable, DSL, 3/4/5g) internet. My only current option for connectivity is HughesNet Gen5 satellite internet. This requires their HT2000W modem/router unit, which doesn't have a lot of flexibility beyond basic NAT, DHCP, WPA2, etc.

My power consists of a small solar+batteries bank and supplemental gas generator. Solar is cheap when it's sunny, but it's not reliable every day. Running the generator costs about 10x of average US prices per KWh. With those constraints, I only switch on internet when I'm actively using it.

To manage the system, I have a Home Assistant setup which looks at the battery voltage and solar power coming into the system to make control decisions about inverters, generator, panel angle, et cetera. This needs to remain functional when the internet is switched off.

This system only really runs comms and a few LED lights. For a few reasons (mostly that I'm at 65°N, and batteries become a headache in subzero temps), I have decided not to scale the system up.

Endgame

I'd like to achieve the following:

  1. HughesNet router (draws 23W) providing main DNS/DHCP
  2. When power levels are good, OpenWRT router (draws 5W) would act as a repeater. (28W total)
  3. Ability to fall back to OpenWRT when HughesNet router is off (5W)
  4. Ability to switch off the OpenWRT router when power levels are sub-optimal, but I need to use the internet. (23W)

I've been searching around, and it looks like being stuck with the proprietary router significantly limits my options. Relayd looks like it might work, but I'd love some feedback on which packages, protocols, or 802.11x flavors fit this scenario before going much further.

what are your convergence expectations?

The problem in this scenario is that you expect the OpenWrt device to transparently switch roles from a 'dumb wireless extender' to 'router/ DHCPd in charge'. This can't really work without some kind of manual decision, as multiple DHCPds in one network create a havoc for your devices - and because 'the other device doesn't seem to answer over wireless in time' is not really a reliable enough metric for this decision (you'd end up with split, but competing network segments before long). The devices simply can't magically read your mind - and all clean layered approaches I can come up with would require even more power draw.

The easiest approach would probably to kill this problem with hardware... One OpenWrt device configured as router/ DHCPd, one as extender - using a mutually exclusive electrical switch for ISP-router+OpenWrt-extender or just OpenWrt-DHCPd. I'm aware that this is probably not possible (for the distance between them alone), but maybe it jumpstarts some ideas.

1 Like

Agree with the above, but you could rethink parts of the system and save some power on the overall system. Also you might be able to save power on the openwrt system by keeping it running but switching the radios off.

anyway, the basic idea is to merge your HA system and the openwrt AP:

  1. I have run an HA instance on my openwrt router, it's a bit of a pain and largely depends on the capabilities of your router but is doable.
  2. Depending on where your HA system is located, or run a bit of cable for an external antenna, you could use that to run hostapd, (and dnsmasq), for a permanent access point.
1 Like

There are OpenWrt routers in the 1 watt range that you might afford to leave on all the time. Look for Atheros chip, 2.4 GHz only, and 10/100 Ethernet only.

1 Like

Yup. I forgot to add my thinking on that in the OP. When the internet is down, there's no real need for DHCP. The only devices that need the network would be known, and could have static IPs. There's not much need for DNS either. When the internet is on, there are scenarios where new devices need an IP.

If everything is set up static, could the handoff happen more or less transparently?

Let's hope this remains true. But it brings up something I hadn't thought of. Is there a way to tell the OpenWRT router to switch roles, or change its config on the fly? Since I have to tell the internet to switch off, I could send a directive via SNMP, etc.

Yeah, this may end up being the best option.

I've also been thinking about maybe replacing the OpenWRT with something like an ESP-based WiFi NAT router. I've had that working in a mesh of low power esp8266 devices, but I'm still not sure how to transparently remove the proprietary router from the network without disrupting things.

Along those lines, one idea I have briefly entertained is setting the wireless interface on the HA instance (RPiB+, currently) as an AP. I'm skeptical of using the Pi as a router under normal circumstances, but maybe it could handle the small amount of local traffic.

One way for this is to use different configuration files. Just upload the relevant config file and the router should switch modes accordingly. But for this you will have to create your own config files from the current configuration and then save it somewhere else.

Edit: The package TravelMate may be of help to you to some extent because it changes between STA and AP modes automatically. You may check it out.

1 Like

In the event that I did leave the OpenWRT router on all the time, then what would be the best configuration for playing nicely with the proprietary router when it is on?

I'm still hoping to come up with a parsimonious solution with my existing hardware. Can someone recommend an OpenWRT router which is both low-power consumption and has its own battery in case different hardware ends up being the path?

Turn off the wifi in the Hughesnet router and have it connected by Ethernet to the WAN port of the OpenWrt. When the Hughesnet is powered down you simply won't have Internet, but the LAN is all contained in the OpenWrt router.

3 Likes

Having also read comments about power consumption in other threads by @mk24 and @slh, it does seem that spending $20 on a < 1W router would probably pay for itself in a short time due to the high kWh cost of running the generator.

Currently comparing the TP-Link WR703 and 701ND, and open to suggestions.

Who wants my pile of Asus N16s and WRT54Gs? Ha!

While I would be interested in something like this, it's not a requirement. I'm currently using this 3s 18650 charger as a UPS for the RPi, and at $12, I could add them to subsequent low-power routers.

This does sound interesting. Can you clarify which model you're referring to? Searches for that yield a variety of results which don't seem exactly right.

I have used luci-app-travelmate in the past where it was able to connect to a wireless network and provide internet with another SSID as you want to do and once the wireless network is down it still provides you with wireless network SSID as before but without internet and you retain local LAN access.

1 Like

Beware: All of those are 4/32 devices.

https://openwrt.org/toh/hwdata/tp-link/tp-link_tl-wr703n_v1
https://openwrt.org/toh/hwdata/tp-link/tp-link_tl-wa701nd_v1
https://openwrt.org/toh/hwdata/tp-link/tp-link_tl-wa701nd_v2

Battery powered routers which are supported by current OpenWrt AND which have more than 4/32 AND which are commercially available are rare.

You shouldn't restrict your choices unnecessarily with "on-board-battery".

Some inspiration regarding low power devices:

Notes:

  • Please mind the "Availability" column.
  • x VDC, y A means: Rating of the power supply. Real life power consumption will be less (e.g. a TL-MR3020 comes with 5 VDC, 1.0 A power supply, but consumes only approx. 175mA).

Oy, yeah... I have been out of the market for a few years, and had forgotten about this, despite my old Linksys WRTs suffering similar limitations.

Didn't realize the device list allowed such fine-grained filters. Awesome tips. Thanks!

Assuming I'm not against a little soldering, am semi-fluent in Chinglish, and have an FTDI adapter standing by, what might the drawbacks of jumping all the way down the rabbit hole with 3.3 VDC dev boards?

The Carambola 2 advertises .5W power consumption, and on-board u.fl is interesting. The other flavors GL.Inet, WRTNode, and others all look interesting, but availability apparently varies.

As an experiment, I've ordered an ALFA AP121U.

It has the Atheros (h/t @mk24) AR9331 that's in the lowest of the low-power-supply search results @tmomas linked, no ethernet switch, and hits the 8/32 minimum.

I'm calling this an experiment because it has a seemingly wild west passive POE feature, and I couldn't find any reports of its actual power consumption. The barrel jack is 12V nominal, but who knows what the actual range is. The ToH mentions it will run down to 5V. Otoh, POE isn't always the most efficient method of power delivery, and the conversion from 12V to whatever the board/chips actually use is another inefficiency (and why the Carambola 2 remains interesting). My hope is that it will draw ≤ 1W, but < 2W would be okay for now.

I'm still very interested in learning the lowest power consumption OpenWRT options, but since this has changed from a configuration conversation to a hardware conversation, maybe that's better in a subsequent thread in the Hardware Category. The Power Consumption Database was helpful for ideas, but very limited in models reported.

My power monitoring is not sensitive enough to reliably detect a wattage drop in the HughesNet modem/router after disabling all wireless interfaces. It would be nice to know whether I'm actually coming out ahead in terms of my power budget.

Found an eBay seller (Rokland, no affiliation) that sells a bunch of different ALFA branded devices with AR9331 chipsets.

I still don't have testing equipment that I trust to accurately measure power consumption in these ranges. I'll try to provide updates as experimentation progresses.

I have these under testing so far: