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.
Netgear has an R7000 model which works fine with OpenWRT. I'm not sure of the accuracy of the following: But I think ASUS has one too.
Seems like a major failure on Lynksys/Belkin's part. But neither of those companies really impress me.Sure I used WRT54Gs in multiple applications and have a few laying around. But it's not like those things were actually *great*. They were good enough and hung around far too long for my taste.
Another consultant who stuck it out.
"We are the Priests, of the Temples of Syrinx..."
It's not that it's hard to compile, it's that 1: They sold this as a router to run with OpenWRT, yet it doesn't come with OpenWRT or even an installer for it. and 2: when you DO build it from source, you can't actually use the wireless router as a wireless router.
Here's a link to the full patch at the mailing list who want to take a look at the code.
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.
Or One Apple AirPort Extreme 2TB and 3 faux black turtle necks.
RTFA. The patches are a mess,
Yeah, not seeing this one as a problem; Open Source projects have no problem supporting hardware that the manufacturer would rather they didn't support, often over the manufacturers objections, but when it comes to hardware specifically built on behalf of the Open Source project, all of the sudden it's now the companies job, rather than the Open Source project's job, to pee on the patches until they smell like the projects leaders peed on them, so that there are no changes required to be able to use them.
This seems really similar to Samsung releasing code with "board" support for some hardware, and then some maintainer getting all pissy that they didn't write the code the same the maintainer would have, had the maintainer had the time, but the maintainer doesn't have the time, but won't integrate the patches anyway because they aren't done the same way they would have been done, had the maintainer done them, but the maintainer won't do them.
Either bitch when they don't obey the GPL and provide their code, or take their code when it's provided and say "thank you", but don't bitch when they hand you code, and you don't want to do the work to integrate it into your moving target of a project. Thanks.
don't compile cleanly and the wireless driver is missing. Rendering it an expensive paperweight.
It's not entirely a paperweight, but they've acknowledged that the code, as supplied, lacks wireless driver support, and that they need to sanitize the code and break it along interface boundaries so that it can be a binary driver module.
Again, I think the "problem" isn't so much that the module wasn't supplied immediately, instead of just being promised, but that it means they aren't going to get the source code for the module itself. A lot of Open Source projects like to try to force hardware vendors to give up what the hardware vendors consider their "keys to the kingdom", and will go so far as to design system interfaces which aren't usable unless you have GPL'ed code in your driver, making your driver GPL'ed, meaning that they can demand source code.
As far as SDR - Software Defined Radio - such as that used in WiFi and cellular radio parts firmware is concerned, those guys can piss up a rope. Specifically, if the source were made available in a way that could be utilized the way the Open Source people want it to be able to be utilized, which would mean:
(1) Other vendors could just copy the register interfaces and use the same driver, without having to do hardware design work
(2) Other vendors could thus undercut the prices by the amortized R&D costs (i.e. the hardware would be commoditized)
(3) The driver work would effectively not be a recoverable cost at the commodity price point
(4) They lose their FCC certification for the part
(5) They can't sell in the U.S., France, the U.K., Japan, and other countries that license hardware/firmware as a single lump
So... piss up a rope; be happy with the forthcoming binary-only driver blob, and be happy it's been promised at all so that you can dick around with the way the rest of the system works to your hearts content. That's all you're going to get for economic reasons, unless you get together as a group and buy out their R&D costs, and buy out their first mover advantage.
Otherwise, if you can live with the limitations, hold your damn horses, and wait to buy the router, which is generally not hardware available anyway.
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.
Commercial products get released all the time with no open source support. Belkin/Linksys is actually working with the WRT team, and whether or not they keep a proprietary interface, they are at least making good on their promise of supporting OpenWRT. Shipping just started this past week. They're getting the hardware out in the market, and making money, and when the OpenWRT support is ready, that will be there, too. Calling it "fatal" at this point implies immediate success requirements on an open source project. Yeah, right....
I have a very old WRT55G, and I ordered one of the new WRT1900ACs last week. The old 54 lacks range for the home we purchased more recently, and I wanted 5GHz support. The 1900 arrived Friday, and in an hour it was up and operational.
The web interface is far simpler than the older models for administration. Side-by-side comparisons with both routers show a 12db signal gain using Wifi Analyzer on my Android tablet, and similar results from a friend's Fluke testing device. I still have a -50 db signal at the far end of our pool, more than sufficient for general use lounging around the pool, and nearly 20db higher than what I got from the 54. That's 3 walls and 80 feet distance. It also gives me better signal and speed in my woodworking shop. I tested speeds while running equipment, and even my table saw and planer don't interfere with it. Not a realistic test, because I'd never use power tools like those while actually watching something else. But it made for an interesting test. :) Note: these tests were done with devices that only test 2.4GHz. I have no mobile device yet to test the 5GHz band in those spaces. We do have a couple of desktop computers that work fine with the 5GHz band in the house.
All I have to do now is wait for the WRT team to work their magic.
Now if you'll excuse me, I'm going to set up the old '54 out in my garage, which will extend coverage across my side yard and front yard. I have no need in those spaces yet, but one never knows.
After buying a couple expensive routers and having them fail or become totally unusable. I have gone back to basics. Buying a simple single band 20Mhz bandwidth 2.4Ghz router. For so many reasons, such as more stability, much simpler firmware, more compatibility with hardware, multi channel 40Mhz bandwidth does not work anyway because of so many other close 2.4Ghz routers. I can still multi stream, run multiple devices and see no speed compromise with internet or local network. It does what I need it to. I think many people buy these expensive routers because they think or have been told incorrectly that their router is their main cause of speed related issues. This most likely is not the problem, because most speed related problems come from poor ISP speed, hardware in devices that is of poor quality or is incorrectly setup. Yet router makers with the advent of each new 802.11 improvement saw a opportunity to increase margins and jack the prices up on their routers. Even though, much of the changes in routers were simply on the Wireless chip which was a minimal increase in manufacturing costs.
As I tell many people I set up wireless networks for. Your perception of speed is mainly about internet speed which generally does not trump whatever network speed you have. Even with cheaper routers. Unless you use local networking to transfer large amounts of data for example a local network storage solution.
You probably are wasting money on any kind of multiple band A/C router at this point in time. The future of WiFi is with the 5Ghz band and yes it holds promise for very good speed, low potential for interference and less chance for crowding due to multiple stations nearby. Firmware seems to suck worse as you go up in costs and features and the open source projects are not as good as some claim. Some of that firmware is old, poorly setup by the user, and can brick a router if someone does not know what they are doing. You better off just returning a router if it does not work properly. That way, maybe these router manufactures will begin to address the problems.
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.
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!
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.
Yeah, you're starting to get how Linux looks to most folks.
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 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.
http://www.ubnt.com
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.
...because you sound like you work for Ubiquiti.
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.
Linksys & Qualcom Atheros developers have screwed us. Ever since two key free software developers left Atheros there hasn't been anybody left willing to cooperate on the release of code under free software licensing. Management/legal/marketing/etc at Atheros is OK with it, but the key developers left don't want to put in the time and effort to release it. The reason being it would require them to change there development habits. As a result they're refusing to release the source code to their 802.11ac firmware despite prior developers having setup the conditions to do so from a bureaucratic stand point.
Somebody important needs to call Linksys & Qualcom Atheros out on it and demand the source.
Personally I'm sticking with companies that care about free software and respect my freedom. 802.11ac isn't worth it if it's at the expense of my privacy & freedom. If we don't want government and corporate spyware we need to demand the complete set of code. Binary blobs are NOT acceptable. You can't even begin to audit code you don't have and personally I don't want to see another OpenSSL catastrophe, and even with the code, it's just the beginning, as OpenSSL proved.
Except...they have now posted a GPL driver
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