for out home network, I've been using a NightHawk 6700v2 and an older TP-Link Archer C5 that I have running 18.06.5 on, which I'm liking. However, when everyone is home and online (6 people) 8-12 devices, we are starting to see quite a performance drop. The 6700v2 would shutdown and reboot, the C5 just seems to hang for a few seconds before responding.
I've narrowed the choices down to the
TP-LINK Archer C7 AC1750
Nighthawk R7800
Asus RT-AC68U
Netgear R7000
or going with another 6700 but the V3.
There seems to be some cons with all of these choices, but I'm not sure which would be more suited to our needs. 6 people and 8 to 12 wireless devices. The C7 does pretty good during the weekdays (work from home) and gives me very little problems, but evening performance has everyone going through data withdrawals. lol.
I'm trying to limit my choices to OpenWRT compatible devices so I can initiate forced access rules. And because stock anything sucks.
Thanks. Broadcom is undesirable because of the lack of support or complication of MODs? Some of the forum topics of the R7800 have me re-thinking the router. Even if waiting a while on flashing the R7800, it seems it should be more than adequate in handling the household load.
Any that i haven't included that I should give serious consideration to? I'd like to stay below $200 usd.
Unless you have more than about 350 or 400Mbps both directions, I advise you buy a Raspberry PI 4, a tplink sg108e managed switch, and use your archer C7 as an access point.
Set up the switch so that port 8 is on vlan 2, and connect that port to your ISP equipment... Set up port 1 to be on VLAN 1 and 2 tagged... Plug the RPI to port 1. Set up the RPI to use eth0.1 as LAN and eth0.2 as WAN.
Set up the other ports to be untagged on VLAN 1 for your LAN devices.
Set up SQM on WAN outbound only using layer_cake and your ISP upload speed
set up SQM on LAN outbound only using layer_cake and your ISP download speed
I don't have a link, but at the moment the RPI 4, which has a proper gigE ethernet connection, and gigs of ram and quad core etc and is very widely available, is the best thing short of an x86 for routing at the consumer level, tons of performance. It blows the R7800 out of the water for lower overall cost by far. The thing it doesn't have is good access point level wifi... but your C7 is fine for that.
EDIT: I just realized you have a C5 not a C7... but both your NightHawk and C5 can be connected and act as access points on different channels (same SSID) with the PI acting as router. That's going to give you a lot of improvement in network smoothness.
dang it, dlakelan....the more I mull this over, the more of an interesting idea it sounds.
I have a dumb 4 pt switch now, no problems replacing it with the 8prt managed. With 7 port (well 6), I can remove the wired connections on the C5 and/or 6700 and use strictly for wireless. By not having both wired and wireless traffic, we 'should' see an improvement in wireless connectivity? Or does flipping to AP remove the functions of the router that we might be over-taxing?
Or go with the 7800 and sell it after the rpi4 solution has had time to be developed. LOL
I haven't dug this deep into router solutions since early 2000...it's all new, again.
It's more the routing function that's the issue. Wired traffic between LAN devices goes through the hardware switch... but wired or wireless from LAN to WAN and back requires the router to do:
NAT
Firewall
SQM
Connection tracking...
Maybe PPPoE?
So, that requires a bunch of CPU and RAM. When a device acts as a dumb-AP you don't need any of that, it's just wifi and bridging.
Also by having the two existing devices set up as separate access points on the same SSID, and non-interfering channels, your devices will naturally select between the available stations, reducing the amount of contention for the radios.
If you're not running SQM you should be though, that might by itself reduce the problem. Run SQM on the device directly connected to your ISP equipment.
a wired-only router and separate access points is the modern solution for home networking precisely because of the problems you're experiencing.
then stick it in the PI and boot, and configure... It'll take a couple tens of minutes to flash the latest firmware to the managed switch, and then configure the switch and do a config backup... but not a major issue. It literally shouldn't take longer than setting up an R7800, or not more than an extra half hour or so maybe.
If you're in the US, the CanaKit 4GB kit is $99 comes with a case, a power supply, a power switch, a microSD, some heat sinks, a micro-HDMI cord, etc... The sg108e switch is $28 (it's listed as "unmanaged pro" but it's a web managed switch). The R7800 is $179 by comparison.
You probably want think twice about the RPI4 as it's plagued with issues. You will most likely be more happy with a RK3399 solution but there's little to no support in OpenWrt current although support in mainline is looking promising.
@diizzy, please tell us about the issues. All I've seen on the forum is people saying they have a lot of success:
Edit: note that we're talking entirely about wired routing. All the wifi should be on a different access point, so issues with the built-in wifi don't matter.
Edit2: It looks like some people have issues with the squashfs images: Sysupgrade on squashfs raspberry pi 4 doesn't clear overlay - #7 by Strayer
so it might be better to use an ext4 image, and then when upgrading just use a backup of the config + a brand new fresh install... doesn't seem to be a major problem. I suppose if you have a lot of custom packages it might be irritating, but if you do you probably want to use imagebuilder anyway.
Not all issues may be relevant when used with OpenWrt but they keep piling up and I don't think anyone has tested/evaluated how reliable the STB SoC derived NIC (driver) is long term and "constant" network usage. Not sure if there's any documentation available for it either and that also goes for the new SD card controller.
I understand you can't get everything for the price they're selling the RPI4 but RK3399 seems like a much more solid choice although it does have its own set limitations although the usually exposed PCIe slot might be of interest depending on application including 3rd party NICs instead for example. The downside is that you probably need to run 5.3 or newer to have a somewhat good experience in terms of performance and reliability.
I haven't but apparently it routes a full GigE no problem, and handles 100Mbps OpenVPN without any encryption hardware.
I've actually got an espressobin as my fallback hot-spare router, and it definitely is able to use my custom HFSC based shaper at 400 Mbps, maybe more. The Pi should be faster.
None of the issues that @diizzy linked to are relevant to routing load. It is true that the device is relatively new so there may be some quirks that get ironed out in the next bugfix version, but I don't think any of it is showstopper for routing, particularly considering that people are saying things work well for them so far. I have yet to see anyone post here "Hey I installed OpenWrt on my RPI 4 and I'm having problem xyz" whereas I have seen several people say "hey it works and is fast!"
When the quirks get ironed out in the RPI 4b or whatever, buy one for $35 and swap it in
If after 1.5 years of continuous usage it borks, buy another one for $35. One of the huge advantages of the PI is it's available all over the place. Get a high quality power supply though!
Most of the problems posted here on the forum are associated with trying to get the PI to handle wifi as well... don't do that. Inevitably the antenna is important, and the Pi basically doesn't have what it takes even if there weren't problems with the drivers etc. just disable the wifi on the Pi. It's a lot more powerful than an Edgerouter X at a lower price.
I held off for a while recommending the PI mainly because it had ethernet hanging off a USB 2 interface! but I'm doing it now based on my experience with Espressobin and knowing that the PI4 is more powerful than the espressobin, and there are several reports of satisfied PI4 users here on the forum... But it's not a slam dunk. On the other hand, neither is the R7800 a slam dunk, people had a bunch of latency related issues for example: Packet loss and Latency R7800
And on the Zyxel Z2 (same hardware) weren't there reports of jumbo-frames causing the whole kernel to bork?
Right now it looks like the RPI4 is a solid option. If you want to go more than 500Mbps you should add a USB 3 gigE dongle... or better yet start thinking about an x86. Though I think you can route the GigE with a USB3 ethernet device if you don't care about SQM. I'm just guessing with SQM it'll top out around 500Mbps based on my espressobin experience, but it might go 600 or so... I don't know.
500Mbps is about 42000 packets per second for full size packets. That's 36k cycles per packet at 1.5Ghz.
Perhaps if you bonded a USB 3 dongle and the built-in ethernet, and used a LAG group on the switch you could employ two cores? It's all theory until someone tries it out.
My concern is not physical reliability but rather how well it handles load and stays up working, to my knowledge (which may be wrong) only Broadcom have docs and they're not available to anyone else.
Ah, yes, that's a good question, but again no one complaining about the device on the forum whereas several people saying they've tried it and it works...
In the 7 days since the start of Jan, the RPI 4 image has been downloaded 133 times as ext4 and 104 times as squashfs...
I'm going to assume that means it's been downloaded and installed thousands of times since it was released back in the summer... and yet there aren't people posting to the forum with complains about crashing or reliability... It's not conclusive but it's highly suggestive that the device works well enough for most people.
Other interesting fact... that download stats page shows that essentially EVERYTHING that's popular to download these days is either an x86 or a RPI. There are only 2 exceptions in the top 20.
there is a long tail of devices with 5 or 6 downloads of course, but I think the data suggests that what people are doing is exactly what I'd expect them to do in the face of modern network speeds and requirements: upgrade to either an ARM or an x86 router
