I've got my HomeHub 5a all working with OpenWrt on Sky Broadband nicely. I am however a little underwhelmed by it. After installing unbound (obviously), adblock and DDNS client the amount of free RAM is worryingly small. I have used a USB flash drive to offload the adblock lists from RAM but even then my free RAM often drops below 10MB. I even tried overlaying a physical partition of the flash drive over /tmp to prevent the RAM drive being used, it helped but only gave me about 5MB more free RAM and of course the flash drive is no where near as fast as a RAM drive so even though I didn't notice any difference in internet speed, Luci was very sluggish with the /tmp overlay in place and it'll probably kill the flash drive pretty quickly too, so not ideal. Any kind of heavy multi-connection application used by a client such as BitTorrent quickly exhausts available RAM.
Then I wondered if it could be possible to offload most of the operation to a superior secondary device such as a thin client PC. What I'm thinking is to configure the HH5 as follows
Switch on HH5
Ports 1-5 VLAN 1 (eth0.1)
Port 5 VLAN 101 (eth0.101)
All tagged.
eth0.1 bridged to wireless (lan)
eth0.101 bridged to dsl0.101 (vdsl2 modem bridge)
On Thin Client
lan interface uses eth0.1 device
wan interfaces use eth0.101 device
I'm figuring this will allow me to shunt all WAN traffic for switch ports, wifi and dsl functions over to the thin client with a single cable between it's ethernet port and the HH5 WAN port; but leave internal switched traffic local to the HH5a's switch/bridge. I can then install anything I want on the thin client as it has tonnes of RAM and Storage relatively; leaving the HH5 as just a comms device essentially.
I am going to attempt this but thought I'd ask if there's any insights or advice from folk more experienced with this sort of thing than I currently am. Am still getting to grips with VLANs so I may be completely misunderstanding how they function.
The bthub5 is a great little device for its price, but it's not a performance monster - nor are 128 MB RAM that plenty, and blocklists can be huge (not just under /tmp/, but also in your DNS resolver RAM requirements).
Considering the hardware, I'd first try disabling adblock and probably reverting back to plain dnsmasq instead of unbound (as well), just to familiarize yourself with the abilities of your hardware, then you can slowly add a few blocklists back in.
Depending on your WAN speed and expectations, using a faster device for the routing tasks makes sense - but unless your x86_64 hardware is well selected for its idle power consumption, a more traditional plastic router can save you real money within rather short time. Even if you already run an x86_86 device for other purposes, using a dedicated router might still ease your networking setup considerably.
I've been playing with the HH5 for a while now, started with a plain config and then added the extras. I used to run a thin client separately to my Sky Q Router which did all the DHCP, Adblocking, Recursive DNS, NAS, VPN and other stuff as well. My goal was to replace both devices with the HH5, which I have achieved to be fair and the only issue now is the low RAM which is only a real problem with p2p apps. That can be sidestepped by using a VPN though so it's not setup breaking. I ran the thin client for a year, and it's a reasonably low power device, uses a 3A 12V supply so running it isn't too expensive, but the cost isn't really that important to me. I was just wanting to know if that VLAN bridged setup was even feasible. Even if it fails to perform as I want or is not possible, it'll still be an exercise and learning experience.
This is conceptually similar to running the HH5A as in bridged mode, only you sort of still want to also use it as dumb AP/switch at the same time. Which should work as far as I can tell, leaving essentially only DSL and WiFi as loads on the HH5A, which might not be too much to handle.
I was going to try this, before I realized my HH5A's lantiq modem is a bad match for my broadcom linecard in the dslam and switched to a broadcom bridged modem instead.
Well, it took a little fiddling. On the switch I only needed to tag the WAN and CPU ports on both VLANs and leave the rest untagged for eth0.1 and disabled for eth0.101. Connected the thin client with its single gigabit ethernet port to the HH5's red WAN port and after some time, experimentation and "mild" swearing, managed to get the configs working. It's MUCH better. Internet speed and latency don't seem to have suffered at all, if anything they seem to be slightly better. One HUGE advantage is that since the HH5 is dealing with wifi and dsl and is pretty much in a "set it forget it" mode, restarting the thin client doesn't restart the dsl or wifi meaning I'm back up way faster. I don't get the DSL status readout of course, I have to open the HH5's status page for that, but that's not a huge issue. The one thing I'm currently stuck on is IPv6 assignment. Clients are not autoconfigured with a v6 address, the lan's DHCPv6 settings are configured as router announce in server mode but no go. I do get a v6 address from sky on wan6 and do have v6 connectivity when ping testing from ssh login, and statically configuring a client's v6 address does work, so it's almost there.
To all who are interested, here are my network configs for each device
EDIT: Correction. Clients ARE getting v6 addresses. They just have no connectivity. Not sure what the issue is. The default gateway for a v6 client is a fe80:: address, if I configure a static address using the router's v6 IP for the gateway, it works. But I cannot find anything in the DHCPv6 settings to set the gateway address sent to clients. Kinda frustrating.
EDIT2: Got it working. I updated all packages with opkg and after that everything worked. Spot on!
EDIT3: Seems that IPv6 is a little unreliable. Sometimes clients get assigned addresses and sometimes not. I noticed when this was being a pain, the lan interface on the thin client didn't have an IPv6 address assigned, just marked with "n/a". What eventually solved it was to configure the lan interface as a bridge with eth0.1 as the only device in the bridge. That trick I also use for OpenVPN with IPv6 as it allows unsolicited packets to get routed through the device where they otherwise wouldn't.