I still have my WRT54G around somewhere. Loved that thing. What I found interesting was that when the firmware went open demand for that model went through the roof. Wish more companies would realize that there is a demand for that market.
Technology
This is the official technology community of Lemmy.ml for all news related to creation and use of technology, and to facilitate civil, meaningful discussion around it.
Ask in DM before posting product reviews or ads. All such posts otherwise are subject to removal.
Rules:
1: All Lemmy rules apply
2: Do not post low effort posts
3: NEVER post naziped*gore stuff
4: Always post article URLs or their archived version URLs as sources, NOT screenshots. Help the blind users.
5: personal rants of Big Tech CEOs like Elon Musk are unwelcome (does not include posts about their companies affecting wide range of people)
6: no advertisement posts unless verified as legitimate and non-exploitative/non-consumerist
7: crypto related posts, unless essential, are disallowed
I had mine running for probably 10+ years but eventually started acting screwy a few years back. I went ahead and upgraded to a TP-Link and I’ve bee satisfied with it. I haven’t looked into if you can still get these custom firmwares for modern routers - but I’ve also been satisfied with the interface and the performance.
You can. ASUS actually based their official firmware off of one of them, and there is a custom mod of that too.
gl.inet bases all their firmwares on OpenWRT AFAIK
Yeah. I've had a couple of their little travel routers which are a lot of fun. But apparently you can't flash custom builds on one of their more recent models.
I think that model is still being sold for like us$50, or the same price it's been for a decade
The hardware has definitely outlasted any love from the os.
Yea that model was manufactured / sold forever. It really was awesome at the time.
But how are you gonna push your internet security monthly subscription with open firmware silly
I was the lead engineer on an Openwrt router for 2 years at my old job. Their documentation is complete and utter shit, but their design is extremely intuitive. Whenever I said to myself, "hell, let's just try this and see if it works," it had an insanely high success rate.
I didn't know Lua going into this project, but when I left the company, it made me really wonder why more people don't use Lua. It's a really nice language.
I really enjoyed having my own open source router that I could just drop new features into by adding packages and recompiling. I was sad when I had to send all my dev units back.
Yeah, Lua is really nice. It's also fast and small. In fact, "Programming in Lua" is imo one of the best programming language books available, up there with Kernighan and Richie's "The C Programming Language."
Yes, I was shocked at how small it is. I had no experience working with such limited resources going into this project. Our router had 32MB of storage. At one point I was looked into adding a python interpreter, and it was like 11MB. The Lua interpreter is like 250KB. Tiny!
Also, the ternary operator has the best syntax of any language I have ever used.
x = [condition] and [true value] or [false value]
No question marks or colons or anything weird. It's a logical extension of &&
and ||
after commands in bash using keywords since it is a verbose language. I wish every language had this syntax.
For contrast, python is:
x = [true value] if [condition] else [false value]
It just seems weird to me to have the condition in the middle.
Yeah, I've always hated Python's ternary, and I use it every day at work. Though you can do the same in Python if you want:
x = [condition] and [true value] or [false value]
I consider that bad style because the dedicated syntax is preferred. You can also do similar in JS:
x = [condition] && [true value] || [false value]
The caveat in both (and Lua) is that you'll get the false value if the true value is falsey.
My favorite syntax is Rust:
x = if [condition] { [true value] } else { [false value] };
This preserves the flow you get with the ? :
, allows [true value] to be falsey, and is idiomatic without having a lot of extra syntax.
My favorite thing about Lua is that tables separate numeric from string keys, so you can do this:
x = { metadata = ... }
x[1] = 3
x[2] = 4
print(#x) -- prints 2
This is really nice for representing something like an XML/HTML DOM, where numeric indices are child nodes, and string keys are attributes. Or you can store metadata about a list in the list itself (e.g. have a reference to the max value, min value, etc). It's just really nice to work with.
Haskell's if
is pretty nice: if cond then truthy else falsy
Lua is so friendly, I've run in to it in a few instances in different contexts. Currently have a "sound computer" shield for rpi that uses Lua to run community scripts, which turn the thing in to anything from synths to sequencers to loopers and some really esoteric stuff. Lua is so intuitive I'm able to tweak stuff and even add functionality to existing scripts without much effort.
I'm curious what you're really referring to with Lua. (casual hobbyist here) Is that the UCI implementation stuff? I tried to use my intermediate Linux desktop user experience with bash in OpenWRT, but geez that is frustrating without all the bash extras I'm accustomed/detailed help/manual pages. That on top of trying to figure out NFTables is still a bit too much for my little brain to compress. I just started messing with UCI commands so I haven't looked under the hood on that one.
Any ideal device recommendations for fun chipsets to seek out and play with for embedded stuff in this space?
The web UI backend stuff is all done in Lua. So receiving and processing forms was all Lua. My main feature that I implemented was a REST API that was called from another product that my company sold. So I had to do all the REST API processing and data validation and whatnot in Lua.
I don't really have recommendations, because I really only knew our product. If I knew what I get, I probably would have got that instead of the Asus router that I ended up with when I had to return my work materials.
You should try awesome wm
What were your must have packages?
OpenVPN server was my number 1. Being able to VPN back into my home from anywhere in the world was amazing. I can't really remember any other, since it was more than a few years ago.
Nowadays Wireguard is a more performant protocol, but it does the same thing.
Not quite the same thing, you can't do layer 2 VPNs on wireguard (I ended up using tinc for that on a previous project, it worked well). For layer 3 however it's really good. Fast, simple, reliable, client works well on the platforms I've tried so far.
Good to know! What's the practical use for a L2 VPN?
My case for it was dealing with proprietary sensor devices with ethernet ports and garbage firmware. They could work if your server was on a different subnet, but a bunch of stuff broke (including the config tool) if you were not on the same ethernet LAN. The L2 tinc VPN allowed us to fix things without needing to walk around to the dozens of devices in a building with an ethernet cable, laptop and a ladder.
The firmware (& vendors) of the devices that we spent over 100K on were garbage in so many ways. One product's proprietary server software would misbehave (read: open files but never close them, after a time running out of file descriptors) which would then cause its fleet of individual sensors to all start SYN flooding it. Another brand's device model required us to spend lots of time manually updating them through every version of firmware because you were not allowed to jump straight to the latest version. I think it took an hour to complete the process for each unit (during which they'd get really hot and presumably throttle).
A bonus of tunnelling things back to our server over tinc was that everything was now encrypted. I used cheap GL.inet "mango" routers running OpenWRT to backhaul the sensors over the existing shared wifi network (rather than needing dedicated copper or wired VLANs). They worked almost like magic -- a weird wifi stack reliability issue required me to write a watchdog that rebooted them, however, otherwise we were back on ladders every few days :| But once that pain was over things overall worked much better.
Aside: Don't buy ANY off-the-shelf sensor product without first:
- Confirming that you're not tied to their proprietary server software. Them claiming that they speak an open protocol is NOT enough.
- Buying a few to actually test the above AND reliability over the span of at least a week's operation AND that they're not just outright lying about the device's accuracy/reliability/usefulness/etc
I made the mistake of being on holidays when the decisions on what to buy were made :P I ended up designing and building some of our sensor devices (somehow at a cheaper price even including my labour) that worked better for us, but shortly afterwards the funding ran out and I got a job elsewhere.
I pretty successfuly ran a combo of TP-Link with OpenWRT connected with cable to a cheap dumb Edimax, which in turn was connected through wifi to downstairs Zyxel ADSL router from O2 ISP.
Essentially the Edimax bridged the internet (there was only one place where the signal was strong enough) from downstairs, sent it to the TP-Link and that one spread wifi on the upstairs floor (so we could use phones/notebook) and my brother's and mine desktop PCs were connected to it by cable. A bit of an overcomplicating simple problem, but it worked (otherwise we would either have no wifi or would have to buy a different router with 2 separate WiFi chips).
Fucking sick. Make it repairable and user serviceable please.
Countdown until the project ONLY supports its own internal hardware.
It would probably get usurped and replaced by a fork. It is the primary distro used in much of the commercial embedded space at scale.
I wish they could influence the market to return to open source modems. I don't think there has been a single open design in over a decade; since the Atheros chips. Well likely see an Open Risc-V processor in the near term. It would be really nice to see a fully open hardware from bootloader to radios.
Pfsense is that you?! /s
Interesting, though I question why a battery backed RTC is seen as so critically important. Of all the features I can think of wanting in a router, a battery backed RTC doesn't even begin to make the cut. A device that is powered up 24/7 and connected to the Internet can just get NTP time whenever it boots up and keep time using the OS. What is so necessary about an RTC here? I get that time is used for certificate verification and other security stuff, but again NTP and always powered. Are they concerned that NTP could be an attack vector?
I'm interested in a new OpenWRT router as my WRT1900ACS is getting older and the WiFi driver on it never had amazing support. Right now the Banana Pi R4 looks promising as a WiFi 7 OpenWRT supported router as it looks like most off the shelf WiFi 7 routers do not have OpenWRT support.
Have you ever worked with a computer with modern general-purpose OS like Linux and no RTC? It sucks. It is not strictly necessary, you can live without it, but you need workarounds for basic stuff timestamps in log files or in the file system. At least for a minute until NTP connection is established, but may be longer when internet connection is not available. And when routers are rebooted most often? When troubleshooting broken internet connection. This is also the time when properly timestamped logs could be useful.
And battery backed RTC is cheap. It doesn't fit on a Raspberry Pi board, but can easily fit into a router case. No excuse for omitting it.
I've used Raspberry Pis since the first model came out and other SBCs and the lack of RTC has never really been an issue. The Pi syncs time by the time it makes it to the desktop. I can see it being useful for early boot timestamps but the most useful such log (dmesg) is just elapsed time since power on anyways. I can also see it being useful for devices doing data logging without Internet or regular power supply like a remote sensor logging device. I guess I just don't see it as a crucial component of a home router. I agree it's a cheap and useful addition though, just not maybe the most essential of one.
A battery back RTC could make it faster and more reliable reconnect after power loss?
Maybe for private key/cert validation checks when there isn’t a way to NTP to sync time?
Because it's a simple and cheap way to significantly expand a devices capabilities and use cases e.g. cheap offline storage network, or other LAN only services. Or simply to provide your own basic NTP, or backup NTP, as these boards are based off ARM SBCs so perhaps adding 1PPS GPS modules would be possible.
Not all routers are connected to the internet
Network time was an attack vector against windows recently. It’s real easy to just not guess what time it is based on devices around you though and knowing what time it is helps you figure out what’s going on.
The real ask isn’t an rtc chip, it’s the battery socket and battery. Theres rtcs baked into all kinds of chips now, they just need something to keep em ticking.
I've not had that much of a problem with my WRT1900ACv2, although I quite literally have nothing 802.11ax or newer.
HELL YEAH
This looks pretty cool. I haven't used OpenWRT in years. Does it support mesh or adding another access point somehow?
Either way, I'm happy with my current OPNSense/unifi setup.
Interesting idea. I thought they'd have gone for a compute module powered board so that brains are upgradable. It seems they've chosen lower cost and built-in WiFi instead.
OpenWrt is a great piece of software. …As is the hackers that get it running on the proprietary hardware.
I mean OpenWRT runs and actively releases new software for those late 90s hardware.
Even DD-WRT is still doing that as an ex-user who didn't know any better. I moved back to stock firmware after a while since I don't know enough about networking but from what I've read, OpenWRT seems to be the main choice these days.
I just got an onhub router working again thanks to openwrt. Many blessings upon them!
This is the best summary I could come up with:
To keep the project going, lead developers have proposed creating a "fully upstream supported hardware design," one that would prevent the need for handling "binary blobs" in modern router hardware and let DIY router enthusiasts forge their own path.
There are two flash chips on the board to allow for both a main loader and a write-protected recovery.
And there's such an emphasis on a battery-backed RTC because "we believe there are many things a Wi-Fi … device should have on-board by default."
OpenWrt, which has existed in parallel with the DD-WRT project that sprang from the same firmware moment, powers a number of custom-made routers.
It and other open source router firmware faced an uncertain future in the mid-2010s, when Federal Communications Commission rules, or at least manufacturers' interpretation of them, made them seem potentially illegal.
In 2020, OpenWrt patched a code-execution exploit due to unencrypted update channels.
The original article contains 472 words, the summary contains 149 words. Saved 68%. I'm a bot and I'm open source!
Awesome, now upstream everything so I can install Debian on the hardware instead of OpenWRT.