Long story short, I am wanting to try OpenWRT.
I have an Asus ACRH17 to work with. Replacing it is a possibility later, not presently.
The ACRH17 is not on the supported hardware list, but its near-identical sibling, the ACRH13, is.
From what I can find, the only differences seem to be an increase in RAM, the WiFi being either 3x3 or 4x4 (conflicting results on that) instead of 2x2, and possible CPU speed increase.
While I imagine none of you could guarantee compatibility, would the ACRH13 firmware probably function on the ACRH17 or would I need to do a complete firmware build?
If a firmware build would be needed, is there a guide for a person with no experience in building router firmware?
While replacing the ACRH17 is not presently feasible, I am researching what I want to replace it with.
I found there are multiple aspects to this seemingly simple question.
Hadware: While getting a prebuilt router was the standard, now you can also build a router from a PC or RaspberryPi or similar.
Software: You can install OpenWRT, or pfSense, or whatever.
I tend to prefer getting cheaper (but quality) units in favor of replacing more often.
For example, getting a $1000 CPU which smashes all other CPUs presently available, but is beaten by the next-gen $500 CPU because it has improved features & architecture.
As such, I am thinking getting a pre-built router could be a worse choice as its hardware would not be upgradeable to better/faster ethernet/WiFi/etc. WiFi G > N > AC> AX >?
However, I also thought routers were good because their hardware is specifically built to do what it does, while finding appropriate hardware expansions for a PC seems more difficult.
For example, I can't seem to find any PC motherboards with PCIe x4 or x8 slots, while most PCIe NICs seem to be x4 or x8 boards.
I know I can install an x4 or x8 PCIe card in an x16 slot, but motherboards tend to have merely 1 or 2 of them with multiple x1 slots.
Or finding a WiFi card which can be run as master? Only found a vague reference somewhere to that being needed.
Or the possibility of using a RaspberryPi or similar, but they seem too limited.
What I wonder from all that is how do firmware upgrades apply to such devices?
OEMs tend to update their router firmware for very limited durations, but what happens when OpenWRT firmware is updated?
Would OpenWRT firmware for a prebuilt router need to be manually rebuilt each update, or can it be updated easily?
What if it was built on a PC or RaspberryPi?
What if the base kernel is updated?
Ultimately, question 2 is what is the effective lifespan of OpenWRT firmware for any type of device and how easily could upgrades be installed?
If I go the route of finding a good but cheap-ish router which supports OpenWRT, this could be less of an issue as the device would be replaced every few years or so, but this seems wasteful.
If I build a PC or RaspberryPi, I could potentially replace networking components instead of the entire device to add support for new features, but would OpenWRT be indefinitely updateable on a PC?
Considering the size of a network card compared to a router PCB, not sure this is any better...
The same SOC does not imply that the firmware would be compatible, flash type, partitioning (and -size), RAM size, GPIO/ LED assignments, hardware IDs and much more might be different. There are no generic firmware images for embedded devices like routers, every device needs its own bespoke DTS/ image, so you will have to start from scratch and port it over.
Even looking at the very rough wikidevi entries for ACRH13 and ACRH17 suggests very relevant differences in the flash setup (spi-nor+NAND vs NAND only, and different RAM sizes), which inevitably cause differences in the flash setup and partitioning, this alone would be a guaranteed (hard-) bricker when trying to force the wrong firmware image on these devices. While the specs suggests that porting OpenWrt to these might be rather straight, it still needs to be done (with dedicated images for either of these models) - before anyone considers them compatible with OpenWrt.
Thanks for the info. That is unfortunate, and the worst possible answer.
If the ACRH17 could be flashed with the ACRH13 firmware, my other questions would be less important.
Because it cannot, all my other questions become more important, but are also completely untouched.
Any people care to answer my other questions?
It sounds as though building firmware for the device is not a simple task, and would require information I lack.
If I assume I can't flash the ACRH17 with OpenWRT, then again my remaining questions become more important.
you could separate the routing from the WIFI, access points tend to last longer than routers, since there's usually no need for additional flash space on the APs, while a wired only router often have better routing performance.
buy a better/bigger motherboard.
you can find threads about those cards in this subforum
they're actually pretty good, but mostly out of stock.
you upgrade it the same way as any router, or set up the new version in parallell to the
old one, and boot into the new version.
you update it ?
all/most devices booting from build in flash have a sysupgrade images, which are used for updating from one version to another.
then you dd the image to the storage, or use the built in update function.
you update the whole image.
routers with fixed storage will be supported as long as the Linux kernel support the hardware, and there's flash space enough to accommodate the openwrt image, and RAM enough to run the content.
Pretty much, yeah.
For a PC flash space isn't an issue, here it's the CPU that could eventually become a bottle neck, and not provide CPU power enough to route your internet traffic.
Thanks, but you mostly misunderstood me.
You interpreted my questions as "How would I update OpenWRT on my device?"
I was asking how OpenWRT firmware for a device is updated, not how to install updates to a device.
You quoted 1/2 the question but ignored the part on how OEM firmware for any device is updated for merely a few years before they stop updating it.
That is logical for OEM routers as updating indefinitely all devices they ever released would certainly become cost-prohibitive, but that is what I was asking of how OpenWRT is updated.
Think of it less "How do I update OpenWRT on my device?" and more "How is the firmware image for my device updated?"
I think the response from slh is useful here, because as he says the firmware for an ACRH13 would not be compatible with an ACRH17.
If that is the case, and the firmware for any device must be built individually, and this is something which a person must do specifically for each device, then how is the firmware image for any device updated when there are any updates to OpenWRT?
If packages or drivers are updated, I assume they can be individually updated on a device if the updated version is compatible with the kernel on the device, but what of when the kernel is updated for OpenWRT?
I would guess an updated kernel is not inherently compatible with any specific device unless/until it is validated with the hardware.
If the image for any device must be manually built to install OpenWRT on the device, then must a new firmware be manually built to update to a new kernel on a device running OpenWRT?
Which cannot happen if the kernel is not compatible with the drivers, so is this when the life of OpenWRT would end for a device?
I mean, sure you could continue using the device as-is, but there is a reason kernels/drivers/etc are updated at all, which is to fix bugs, improve functionality, and improve security, so an outdated device could quickly become a security risk.
Hence why all my questions referred to how OpenWRT is updated, not how to update it on a device, and why I repeatedly asked of the lifespan of OpenWRT on a device & mentioned OEM firmware not being updated indefinitely, not the simplicity of updating it.
That said, I suppose I should ask the question you repeatedly tried to answer but failed to do so clearly.
"you update it?" was useless as it does not answer the question you thought I was asking, but how is that done?
Similar to OEM firmware where you simply click a simple "Update" button, or would you need to download an updated firmware image?
That said, most of your answers were at best vague.
This is useless.
1st, you answered a statement, not a question. It was not a question because I am comparing general concepts of building a PC-type device for OpenWRT vs getting an actual router-type device, so it was a general statement why building a PC for OpenWRT is much easier said than done.
2nd, were my statement actually a question, your response did nothing to help. I researched dozens of motherboards. Consumer boards, server boards, old boards, new boards. I am trying to find something which would be a relatively compact & power-efficient system, similar to an actual consumer router, so it would be easy to place anywhere as needed, but anything I found less than an SSI-EEB board lacks enough/appropriate PCIe slots to use as a router. As such, a helpful answer would include actual information, not merely a seemingly condescending answer with no useful information. For example, provide links or at least a name to a motherboard you think would be appropriate.
3rd, you can't answer appropriately when you did not bother asking what I am looking for. As I said, I am trying to consider devices which would be more compact & power efficient, so "buy bigger" is useless.
This was a rhetorical question, hence why I followed it with my own statement.
Regardless, a more useful answer would be something like "Yes, you need a WiFi card which can act as master", instead of telling me more information is elsewhere. I already was guessing more information existed elsewhere, but I am not following yet another rabbit hole of research before I even determine if that is a path I want to follow. Should I waste dozens or hundreds of hours researching all the various things I need to know to build a PC into an OpenWRT (or any firmware) router when I am yet to determine if that is the router I want to go?
Again, this answer is at best limited usefulness.
Actually pretty good? For what? Again, you know/asked nothing of my intended use.
A RaspberryPi cannot install multiple WiFi or ethernet NICs, so I cannot use it as an 8-port router with high-end WiFi support, can I?
As I said, they seem rather limited. Perhaps their routing performance is better than a standard router, but how much better?
See how you provided very little useful information here?
Again, I was not asking "How would I update OpenWRT on my device?"
To rephrase the question, how is the OpenWRT firmware for a device updated to then allow me to install those updates to my device?
If the OpenWRT devs update some driver or package or the kernel, what is the process between them updating it and it becoming available for me to install the update to my device?
slh's answer again becomes relevant here, because if OpenWRT cannot be installed to my device unless/until an image is manually built by a person specifically for my exact device (whether it be the ACRH17 or any other device), then how would updates become available to whatever device I install OpenWRT to?
Again, I imagine updates to packages which are not kernel or driver would function similar to mainstream Linux where the package is marked as compatible with various kernels and your device checks for updates which are compatible with the kernel on your device, but what of kernel or driver updates?
This is nearer to what I was asking, but again your answer is vague and you misunderstood me.
As long as the kernel supports the hardware?
1st, does a kernel directly support hardware? Would it not be hardware drivers, and the kernel needs to be compatible with them? This falls back to me mentioning how long an OEM supports a specific device. At some point, they need to move on. Would OpenWRT devs also not need to eventually move on from older hardware? For example, how the minimum requirements for flash/RAM were increased, so older devices cannot install newer versions of OpenWRT, that ended the effective life of older devices. But what if the flash/RAM are sufficient? If I cannot install OpenWRT on (insert specific device) unless some person specifically builds a firmware image for the device, then udpates again become a question of "How is OpenWRT updated for any specific device?"
If the OpenWRT devs update the main kernel generally used, then must a person manually build a firmware image using the new kernel before it can be installed on any device? I mean, there are hundreds of devices on the supported devices list, so are you telling me a new image is manually built by a person for every device on the supported devices list every time the kernel is updated? Or is this somehow done automatically, similar to how packages are updated by checking if the updates are compatible with the installed kernel?
2nd, I was more asking a specific length of time, not a vague reference. "As long as the hardware supports it"? Okay, great, that tells me nothing. 1 year? 10 years? I would guess more general issues like needing to update the minimum flash/RAM requirements to install OpenWRT occur less often, but how often does that occur? And again back to what I repeatedly now asked, how does this apply to any specific device? If the hardware can easily be supported, as slh says my ACRH17 could be, but a firmware image must be built specifically for it before I can install OpenWRT on it, then would that not also be true when OpenWRT is updated? No, not the firmware for my device, but OpenWRT itself to then be updated to any given device. If an update to the firmware for (insert device) is updated, then click the update button to update it. But how is the firmware for a device updated to then be installed by the user on their device?
Sorry for this being much longer, but I hope it is also now more clear what I am asking.
So, no person can answer?
Then using OpenWRT would be a bad idea, because any device I install it on could never receive any updates, so I would be better using OEM firmware which would get at least a couple years of updates.
Wish I could thank you guys, but with the only question actually being answered being the question of whether the ACRH13 firmware would be compatible with the ACRH17, and the answer being no, causing all my other questions to be more important, which all went unanswered....
Whatever. Guess I shall look for better firmware, or at least a firmware with a more helpful community.
Trying to answer some of your questions, to my best understanding:
It's not. The images are built automatically, using the included 'recipe' for the device. Only when the building process fails (or when the build succeeds but users report problems), then a maintainer needs to check on it and apply fixes as necessary. Many devices go from one version to another without any problems.
Your assumptions regarding drivers are way off base.
Most drivers are kernel modules, and maintained along with the kernel. They will generally stay supported as long as there's any meaningful user base.
For drives that are externally maintained, testing is simple - you compile them against the kernel. This can be done automatically, and only in case of failure there's any need for a maintainer to check if anything can be done about it.
Not all drivers are essential for a working firmware. e.g if your WiFi drivers are not supported anymore, you can still use the router without WiFi.
For reference on how long a device could be supported, you could simply check past devices - when support started and when it ended.
Take for example TL-WR1043ND v1. Support added in 2009, First officially supported release in 2010. Last fully supported release was 19.07.10, released this year. So that's 12 full years of support. (the hardware is still supported by the latest kernel BTW, the device would still be supported if not for the shortage of RAM on it.)
The hardest part is actually the initial support - get the layout of the device, create the recipe for it, get any missing drivers and apply necessary patches. Maintenance going forward in most cases is much easier.
There are two main reason someone might want to use OpenWRT: either because the official firmware lacks features you require, or because the support for it had ended and there are no more official firmware updates.
As such, if you're happy with your current firmware capabilities and it still receives updates, there is indeed no reason for you to move to OpenWRT. Nobody's trying to sell anything to you here. There's no gains for the OpenWRT team from you using it. Just do what you want.
If, in the future, your device stops getting updates, and OpenWRT starts supporting it in the meantime, you could always reconsider.
After weeks of limited answers and nearly a month of no answer, I was not expecting an answer, let alone a useful answer. Thank you.
So it is similar to Windows Unattended Installation. You configure a script to automate telling the installer or image builder software how to do so for your specific needs or device, then never need to manually customize or build the software again as the script is used to automate future installations or builds.
That is excellent, and would make OpenWRT a very good option for long-term device support, though I would prefer to test & learn it before committing. Buying new hardware specifically for OpenWRT before testing it to decide if I like it or it meets my needs would be a bad idea.
This then returns to could it be configured for the ACRH17 I already have. As slh said it would probably be easy, just needs to be done, I must re-ask 1 of my unanswered questions in my 1st post: Is there a guide for a person with no experience in building router firmware? Or is initial firmware configuration a task which must be performed by an OpenWRT dev?
I am unfamiliar with the wikidevi slh mentioned he got some specs from but shall research that. However, slh also mentioned the information from it was "very rough", so it could be insufficient for any person to configure the firmware. Even if sufficient, the other issues he mentioned cause me to think initial firmware configuration would need to be performed by a person with knowledge & experience in firmware configuration.
I committed no assumptions at all. All of my statements & questions are either hypotheses based on how computers & software generally function or guesses based on my knowledge of such things.
That is why I am even here asking questions, which is to learn how OpenWRT functions.
Windows & Linux are maintained by their respective "owners", both of which maintain some drivers directly (usually generic or very common drivers), both of which maintain some basic software directly (the UI, some "Notepad" or browser, etc), and both of which have many more drivers & softwares available from 3rd parties.
To clarify your statements further, calling them kernel modules seems like little more than using a different term for the same purpose. The purpose of any driver is to communicate between the OS & hardware. While an OS could be written to directly communicate with specific hardware, it would then be limited to that hardware, hence drivers. Drivers allow any OS to use any hardware with a driver created to communicate between them. OpenWRT also relies on drivers to use any hardware, so is calling them kernel modules merely to indicate they are included with the kernel, or intended to indicate they somehow function different than drivers for any other OS? Either way, searching this forum showed OpenWRT is the same as any other OS in this regard, it needs drivers specifically created for any hardware to use it. Sadly, the best I could do is guess here based on slh's response, which was saying porting it would be straightforward, so I would guess the ACRH17 uses standard drivers, probably included with OpenWRT instead of being external (probably closed-source) drivers.
Regarding your next statement, incomplete functionality would probably not be acceptable. I help several people maintain their home networks because they know nothing of how to do so, are not interested in learning to do so, and several of them would probably not be able to do so well or at all even if they wanted. As such, I need to find an easily supportable device, cheap & small enough they would not mind buying it (which means definitely less than $200 for most/all of them, probably no more than $100 for some), with full functionality of its ports (ethernet & USB) & WiFi, probably also its lights, its hardware to perform special functions like hardware-based NAT, the ability to create guest-networks, and function in a WiFi mesh network or similar user-friendly method of covering a larger area than 1 router can cover. I could consider an alternative to bypass any of those requirements if any can be provided or suggested, but I know nothing which would allow me to ignore those requirements.
Thanks for the information regarding OpenWRT support life. I did not find that information in my initial searching, so a device being supported for 12 years is impressive. I would guess that could vary by several years either way depending on the device, its popularity, and its ease of maintenance, but at least tells me OpenWRT would almost certainly be supported longer than OEM firmware and is therefore a great choice if compatible with a device, and a good reason to buy a device compatible with OpenWRT if possible.
As for your reasons to use OpenWRT, those are exactly the reasons I am here asking questions. I cannot tell you how many times I saw some person using a router many years old, lacking many modern features, and with serious security holes because of flaws discovered since its release or last update. But convincing them to upgrade requires convincing them why they should want to and offering them a choice they can accept. The potential security risks usually help to convince them why, but not always as many think "well, I never noticed any problems with it" so they think it is doing its job of protecting them. As for a choice they can accept, many of them want good internet/WiFi but want to pay as little as possible, so routers above $200 are almost always refused. Most people I dealt with refused routers if they were more than $120-150, and at least 1/3 of people wanted to spend less than $100 to upgrade. The ACRH17 seemed like a great choice when I got it and suggested it to others, but seems Asus discontinued support and it lacks some potentially very useful features which OpenWRT would provide.
Again, thank you for providing useful answers yonizaf.
I am yet to read the links frollic provided but shall soon. Thanks for those.
I suppose this leaves me at: must I buy a new device to test OpenWRT or can I or some person configure an OpenWRT image to install to it?
Your response is mostly inaccurate, and very rude & condescending. Needlessly.
So allow me to respond in kind.
The ACRH17 is not presently supported, you are correct in that being said.That is the end of your accuracy.
I asked in my 1st post if there was a guide to explain to people with no experience how to add build a firmware image for a presently unsupported device. That question was never answered, was it? So what does that say of you who answers so rudely to tell me a question was already answered when it never was? Yeah, it says several things of you, but I need not say them.
I asked if the ACRH13 firmware could install to the ACRH17, but if not, was there a guide to instruct me how to build firmware for it. Did I ask if another person could configure firmware for the ACRH17? Nope. So again, you respond so rudely to tell me a question was already answered when it was never actually asked. What does that say of you?
If that is the kind of person you are, I suggest you not bother responding again, as my next responses shall be much less polite than this if you continue to be rude & insulting, which seems to be who you are.
The term 'easy' here is misleading, it just means it's relatively easy compared to some other devices (e.g if you had to add support for a completely new platform or unique hardware). Even so, it's a very technical work not suited for everybody.
For starters, you'll probably need to open up the router's case and solder a serial port (or connect a JTAG interface if any). this alone will scare away most beginners. Then there's a very real chance you might make your device unusable in the process.
Still, if you're serious and dedicated, and you don't mind the risks, anyone could do it (or try to, anyway). Just don't expect it to be easy. It's not.
For the sake of convenience, let's split the 'drivers' group into 3 categories:
Userspace drivers. These work independent from the kernel, and as such are not very relevant to the current discussion.
Binary / closed source drivers, provided by the hardware manufacturer. These are the most common type on Windows, and (to my understanding) the reason for your worry that hardware might stop being supported.
Open source drivers. This is the most common type for Linux systems, and many of these become part of the kernel at some point, to be maintained by the kernel development team. Even if they don't, there's no real reason to be worried that they stop being supported - even if the manufacturer/previous maintainer dropped it, as long as there's anyone interested in supporting the hardware, they can pick it up (it's open source) and keep maintaining it.
As a general rule, OpenWRT uses only open source drivers. As such, there's no such worry as the driver stops being supported by the kernel, because the OpenWRT devs (or helpful community members) can work to fix it themselves, the same way they maintain any other aspect of OpenWRT. Your only worry is that a device might fall out of favor, and nobody cares to maintain it anymore (in which case you may pick it up yourself).
There are a few cases where no open source drivers exist for a given hardware (mostly WiFi, such as Broadcom wireless), but this does not seem to be the case with your device.
Some people get a wired-only router, knowing they plan to use dedicated APs anyway. It may not be the case for you, but it still means adding and maintaining support for a device even without a working WiFi may still be worthwhile. And as long as the device stays supported, who knows, maybe the missing feature will be [re-]added in the future.