Slashdot Mirror
WRT54G Successor Falls Flat On Promises
New submitter JImbob0i0 writes: "Back in January, Linksys/Belkin made a big deal about their new router, the WRT1900AC, which they claimed was a successor to the venerable WRT54G, and how they were working with OpenWRT. They released it this week, but their promises have fallen far short. You need to apply patches (which don't apply cleanly) and compile yourself in order to get it to work... so long as you don't need wireless support. There has not been much response from Linksys on the mailing list to criticism of the improperly formatted patch dump and poor reviews as a result."
Hey Soulskill -- JImbob0i0 may be a new submitter, but you're not a new editor. How about editing the content of the submission so that it actually makes sense?
What exactly is it they pay you to do? I'm sure I could write a shell script that would randomly select a few stories every day to copy to the front page.
How can we continue to believe in a just universe and freedom to eat crackers if we have no ale?
they clearly missed the ball on there about what made the previous model useful.
I mean, for 400 bucks you could pick up two minnowboards.
or like, 7 raspberry pi's with wifi.
or like, 10 normal home wifi routers.
400 bucks why bother with their gpl dancing around. you can buy a frigging dualcore laptop for that money and enjoy out of the box webcam hosting, ethernet + wifi routing with a built in high resolution display and built in ups!
world was created 5 seconds before this post as it is.
I agree with Andrew Johnson. Almost everyone will want a wireless router. A Linux, open-source, router was the segment that the WRT54GL filled.
It's a bit of a shame. I need a bunch of new routers with wireless support and ideally cellular support too.
So, Linksys' OpenWRT router ships without OpenWRT firmware, apparently because there is no such firmware. You could compile such a firmware yourself, if not for Linksys withholding the wireless drivers.
I can't even begin to imagine a chain of events that resulted in shipping an OpenWRT router without any OpenWRT support.
DATABASE WOW WOW
I'd agree with you... if it actually worked once compiled. Wireless doesn't work.
Holy crap you have to actually compile it yourself! What is the world coming to? You mean hacking isn’t just plugging stuff together?
OK the thing has problems, that’s news. But if compiling is considered hard, well, it’s hard to see you as a nerd.
RTFA. The patches are a mess, don't compile cleanly and the wireless driver is missing. Rendering it an expensive paperweight.
let me sell you this new car that you first need to design yourself, then you print it in a 3D printer and then you can finally build it.
It's 100% hacker friendly.
Because often times compiling things like this, especially what is essentially an entire fucking Linux distribution, and ESPECIALLY AGAIN one that requires cross compiling this, is rather a pain in the ass. Unless somebody has pre-built the toolchain for you, preconfigured it, etc, you're looking at at least 45 minutes of work, not counting the time for the compiler to do its actual work. That's also working under the assumption that you know how to operate the compiler (I'm assuming GCC) fairly well.
I don't know about you, but in spite of using Linux for over 10 years, unless an application I've downloaded in source form already has the build scripts configured, I'll never get the damn thing to compile. (Well, in cases where it's a single .c file with few dependencies it's not a huge deal, but even then cross compiling requires yet more work.)
Configuring make scripts and all of that crap are just not my thing. I've never been into programming anything beyond interpreted languages to be honest. Stuff like writing Bash scripts is easy for me, but I don't like to mess with C mainly because when compilers throw errors I often don't know jack shit about how to solve them, and asking for help on them usually results in me getting trolled or somebody pointing me to one of those god awful man pages.
Careful with names containing L slashdot.org/~AiphaWolf_HK slashdot.org/~AlphaWoif_HK slashdot.org/~AiphaWoif_HK
So basically they are saying since the firmware they are providing will compile (even though it doesn't contain any wireless support) is still a firmware so they are technically holding up on their end of the bargain. This is just really obtuse.
So nerd or not there is no amount of compiling that will actually make this WIFI router actually connect any WIFI devices.
A loop, by its nature, continues. If that didn't make sense, start reading this sentence again.
If the problems can be fixed by the early adopters on the bleeding edge compiling code that has been supplied to them then a more user-friendly patch is probably only a few days away.
Early adopters to something ambitious should expect a hiccup every now and again.
Compiling can be very hard if the patches don't apply cleanly.
You know the man pages are the manual right?
How about you bother to learn something instead of coasting on the work of others for a decade then complaining things don't fulfil your every need after you've contributed exactly bugger all.
As someone who has worked on a Linux-based embedded system, and had to cross-compile to do it... dude, Linux cross-compilation sucks, and there's almost universal pushback from everyone wo deals with Linux build systems, from Debian to Red Hat, and beyond, to any attempts to make it better.
IMO, you should be able to download and install OpenFriggingSolaris on a SPARC system, and cross-compile Linux for ARM, Alpha, and Intel on the damn thing, without having to have some dumb-ass chroot environment because someone is too stupid to deal with include paths, library paths, and source paths correctly, and because the build process somehow thinks it's an OK thing to use build products created during the build process as part of subsequent build steps. I mean, how incredibly, obviously stupid is it to use intermediate build products as part of your build process, unless they are targeted solely at your host environment, and never mirrored into your target build product area (oh yea, a working "DESTDIR=" would be kinda helpful here, too...).
The whole idea that you can have dependencies that reference files in the host environment other than those on a mounted read-only source partition, and that "retry" package builds each time because the build system is too stupid to figure out missing dependencies is terrifically annoying.
Which is an interesting discussion in itself, Ubiquity sme stuff is also a lot cheaper
I work for a company which installs and deploys home / business networks for home automation purposes, and EVERY Linksys device we have tested, has inevitably ended up in the bin, not because they were faulty, but because they turned out to be rubbish.
Linksys has a long history of producing unstable devices, and their original WRT54GL Linux router's only redeeming feature was that it was open source. The interface was terrible, and so was the firmware. In fact, we aren't only talking routers, because we noticed that some of Linksys's cheap gigabit switches had issues with stuttering when playing media (no other switches were affected by this issue, including 10/100 cisco ones). It's particularly pathetic given that Blu-ray requires only 54mbps to stream.
Even assuming that patches are supplied which fixes the issues with this router, unless Linksys seriously has seriously improved their development team, and their hardware, you would be far better off with a cheap TP-Link which acts solely as a router/ADSL modem, a switch which manages the network traffic (NOT A LINKSYS ONE), and Unifi's for your Wifi (those are a dream to roll out in bulk, and the new Unifi software if it comes will even support Seamless wireless WITHOUT an expensive hardware controller).
Further evidence, we didn't even want to risk selling our used Linksys equipment on eBay and damage our seller rating (it was worth the write-off)..
yeah so linksys developed the chips and stuff? yeah right(1).
(2) other manufacturers buy from the same chip manufacturers and get the same cookie cutter drivers under the same cookie cutter nda.
3,4,5 doesn't stop others from doing so.
world was created 5 seconds before this post as it is.
As someone who has worked on a Linux-based embedded system, and had to cross-compile to do it... dude, Linux cross-compilation sucks, and there's almost universal pushback from everyone wo deals with Linux build systems, from Debian to Red Hat, and beyond, to any attempts to make it better.
Did you try OpenEmbedded / the Yocto Project? It takes away pretty much all of the pain of cross-compilation. Most of our users seem pretty happy with it.
See https://lists.openwrt.org/pipe...
I used to be a real fan of WRT54GL and happily ran Tomato on it for a long time, until I realized I needed gigabit ethernet (yes, I do need it) and Wireless N (yes I use it). The new router had to actually work, without crashing, and handle constant data load, and not need hand-holding.
Linksys had the E3000 which worked fine except the CPU was wimpy and the 5GHz never worked for me. Throughput was awful. So I went to closed-source hardware, specifically an Asus router, and it works just great. No problems. Lots of bells and whistles and enough horsepower to cope with actually doing what the buzzwords on the box say it can do, without crapping out. This thing is a beast. Never needs nursing. It just works.
The E3000 is now relegated to a glorified WAP and gigabit backhaul at the other end of the house. Tomato is still useful as I never have to maintain that box at all, not that it's being asked to do a lot.
Open source is great when it's compatible with what I need to do. But bottom line is, I need to do X task. If closed-source can do it, OK. But I am not holding my breath or suffering with some problem waiting for an open fix.
Sig for hire.
As someone who has worked on a Linux-based embedded system, and had to cross-compile to do it... dude, Linux cross-compilation sucks, and there's almost universal pushback from everyone wo deals with Linux build systems, from Debian to Red Hat, and beyond, to any attempts to make it better.
Did you try OpenEmbedded / the Yocto Project? It takes away pretty much all of the pain of cross-compilation. Most of our users seem pretty happy with it.
Yocto has a different goal than cross-building a standard Linux distribution, along with some components. I was specifically involved in ChromeOS, and the cross-build wasn't there fore something as large as a complete Debian distribution.
I think the big problem with Yocto and OpenEmbedded (or ChromeOS) is that it assumes a Linux host environment, and acess through the host environment to package management tools.
I admit that there was a lot of intrinsic bias because of the team's history towards a Debian-based system, but our desktops were a Debian-style environment as well (Ubuntu), and the common implementation was to chroot into a more or less "pure" Debian build environment on the desktop, and then from that, chroot into a cross-build environment basically identical to the first chroot environment, and from that do the cross-build, including installing build products from the second chroot into the build environment for the target, and using them.
Neither Yocto nor OpenEmbedded addresses this issue adequately -- while Yocto did something to eliminate about half the hassle when Richard Purdie did his patch set last October, I don't think it was enough to get to the point where you could base a ChromeOS on it; you could use it for a single embedded device, and, with a lot of work, a number of packages on the device, but clearly nothing like all the software (which I freely admit - it's too much code) needed to do the full product, or do it in a way that was convincing enough that the additional work warranted abandoning a working (non-cross) environment.
yeah so linksys developed the chips and stuff? yeah right(1).
(2) other manufacturers buy from the same chip manufacturers and get the same cookie cutter drivers under the same cookie cutter nda.
3,4,5 doesn't stop others from doing so.
Making the driver proprietary and licensed only for use with the OpenWRT hardware most certainly does prevent 3,4,5 from being leveraged by another vendor. If all I have to do is copy your commodity chip choices and a lot of your interconnect design, you have R&D costs to recover, and I don't = I put you out of business, unless you have brand loyalty above and beyond the price point.
Can you say, with a straight face, that another product that could run the exact same software load and work the exact same way wouldn't render the OpenWRT router fungible, and therefore the only thing that would matter to consumers was the price point? I can pretty much guarantee you can't do that, even if every person who was in the market for an OpenWRT-style device pledged to buy theirs instead of a cheaper one.
You also have failed to address the SDR issue of FCC/CCITT licensing the combination of hardware and firmware as a unit, and revoking licensing for hardware that can be used with a different firmware and/or firmware that can be used with different hardware, because they don't want to have to deal with malicious radio loads screaming over top of military radio bands because the hardware is capable, but it's only the firmware which limits the ability of someone to do the nasty.
what does cisco have to do with it?
They used to own Linksys, but apparently the OP missed the part where they sold them again.
Strictly speaking, under their definition, wouldn't anything that doesn't cause the bootloader to run away crying and fits in the available flash space count as 'a firmware'?
A (?possibly?) decent router with such bad firmware you will be forced to go to extraordinary lengths to fix it.
Troll is not a replacement for I disagree.
Relatively early in their life, they were pretty much at parity or better with anything else you could get for roughly the same money and anything like the same convenience, in terms of specs, and much better supported. The fact that subsequent revisions were stagnant or worse and the state of routers-that-actually-work-with-3rd-party-builds didn't stay still took the shine off them. Then re-releasing (now with new higher price and extra letter!) the WRT54GL was something of an insult.
Wasn't WRT160NL also a successor?
https://www.asus.com/us/Networ...
I bought one of the previous models of these kinds of things from Asus and love the crap out of it. OpenWRT and all!
> But I think ASUS has one too.
Asus RT-N66U ? (I specifically bought this model based on it's TomatoUSB support)
I provided the board support patch for Archer C7v2 in OpenWRT. There have now been nightly builds for it for several days, and the units are pretty much working at 100%.
I had some difficulty in actually *acquiring* a C7v2, but TP-Link is truly a pleasure to deal with. Newegg, on the other hand... I bought a C7v2 from them, they sent me a C7v1. I RMA'd it and they sent me ANOTHER C7v1, and had the audacity to claim that the hardware was identical and I should just install the "v2 update" from tplink's site. TP-Link swapped out the v1 for a v2. TP-Link was under no obligation to do that, since it was newegg lying about what they were sending me.
As far as this WRT1900AC device goes, I just don't see the appeal. Especially at the prices being quotes, and DOUBLE especially given the junk Marvell no-driver-source wifi parts. There are a few features on the WRT1900AC that on the surface seem cool, but that really comes down to the SATA port -- except that the price premium exceeds the cost of a 2-bay NAS.
Although I have to admit, a dual-core ARM would be nice on a router.... but again, not at that price. ARM isn't going to suddenly make it into a freight train of a data processor. If I need serious processing power on a network appliance, I'll find something with an x86.
Go pick up an Asus RT-AC68U or RT-AC66U both support DD-WRT and from what I can tell from mine they work flawless*
New they are a bit pricy but you can pickup refurbished for a reasonable price on newegg
* So far so good...
I went to a multi-band AC router because I have devices in my house that it just doesn't make sense to run a wire to. My basement was finished before I bought the house (new in 09, owner fully finished it) and the ceiling is all drywall.
Yeah, I can poke holes and run cabling just fine. However, it was just easier for me to spend some $$$ and now I can throw files back and forth from anywhere in the house at better than 802.11g speeds; typically half of gigabit wireline speeds. My internet isn't fast enough to really give me a boost - but that wasn't my main goal.
Karnal
I would highly suggest Asus routers as a good alternative. Their native firmware is a customized verison of OpenWRT and they can be setup to run a version of Tomato firmware if you can't be bothered with the complexity. I own an RT-N66U myself and highly recommend it and it's successors. They even have a microSD slot inside for no apparent reason other than for hacking.
OpenWRT developer Felix Fietkau has something different to say:
"Quick update on this subject: Linksys has now posted a GPL source for the WRT1900AC, and it contains the wifi driver sources. It appears to me, that this driver was properly licensed under GPL, with proper license headers in all source files."
Of course, this is Linksys code so...
As I anticipated, the code quality of the driver source code is abysmal. This looks like rewrite (not cleanup) material, ugly enough to cause eye cancer or frighten small children ;)
The issue here isn't that there is no wireless support, just that it's of codethulhu quality.
I've got that on my router. Let me start by saying this is *NOT* the poster child for F/OSS. In fact, if you aren't seriously into hardware, or systems administration, DON'T! Never in my decades of professional work have I ever seen a project where people would talk about their "favorite builds"... in fact, I'd never *ever* thought of putting those two words together.
I wanted one thing besides gigabit routing: the ASUS I have says it can serve as a prntserver for USB printers. Call ASUS, "oh, not that printer". So three? four? debrickings later, and a month of trying, and asking, and finding by googling, not onlist, I found a build that works.
Most of the time. After somewhere between a day and a couple of weeks of not printing, it forgets about the printer, and I have to reset USB on it (and that was what I found after months of fighting).
I want to upgrade, to make sure I don't have heartbleed on it (but I do have no remote admin, so it should be ok)... but WHAT THE HELL DO I UPGRADE TO? Multiple builders, apparently no regression testing, no formal releases....
mark, putting up with it
You know the man pages are the manual right?
How about you bother to learn something instead of coasting on the work of others for a decade then complaining things don't fulfil your every need after you've contributed exactly bugger all.
I assume you synthesise your own medicines, right?
And build your own car.
No, I expect you're just coasting along on the hard work of others. Next time you take any medication remember that you're contributing nothing but reaping all the benefit.
No wonder they suck now. Did they figure out how to fix/avoid that firmware bug that opens up NAS devices attached to most of their routers to the public yet? Or are they still going with "don't set remote admin to on"?
I was recently looking to get a new router to replace my old D-Link DWL-2100AP & DI-604 combo and I saw that WRT1900AC and wished it was available.
I ended up getting a refurbed D-Link DIR-651 for $12.
The WRT1900AC is on $250 on the Linksys store site. And PCWorld gives it a pretty decent review, with caveats, and out of the box firmware.
Well, here's the main thing: I mostly don't have time to trudge through those man pages. The man pages frequently don't show example usage, which in many cases means you have to guess their syntax. Maybe not so bad if you code on a regular basis, but I don't.
I actually would love to be able to code in C, but every time I try to get around to it, one of the common things I'm told is that if you don't know C at this point already, then you really shouldn't bother with it, because there won't ever be any jobs that will ask for it unless you're writing device drivers (which is something I'll probably never do.)
If the learning curve wasn't so steep, I'd probably take a bigger interest in it. Instead though I have to deal with shits like you who talk down to anybody who isn't part of your clique, so I'm just not going to bother.
Careful with names containing L slashdot.org/~AiphaWolf_HK slashdot.org/~AlphaWoif_HK slashdot.org/~AiphaWoif_HK
$400? Woah. I think this is why I have moved to Ubiquiti equipment. The ubnt.com equipment isn't wrt56g compatable, but it is Linux, pretty reliable and solid from what I can tell.
... "When you pry the source from my cold dead hands."
they're all crap, both in hw and sw. Yes, you can install dd-wrt ét al, but it's still generally crap hardware you're installing it on, and the firmware is only valid for certain hardware.
I bought a Fit-PC 1.0 second hand for 500SEK ($76) and installed pfSense on it which is not hardware specific. Best router i've ever had. I have to use another device for wireless, but there I just re-used my old Linksys WRT610nv2 wireless router as a simple access point. You can get wireless-N access points pretty cheap these days, because the market is all for all-in-one router/switch/AP devices which generally cost $150 or more.
"Everyone knows that vi vi vi is the number of the beast" -- Richard Stallman