Originally posted by anarki2
View Post
Announcement
Collapse
No announcement yet.
OpenWRT-Forked LEDE Releases 17.01, Presents At The Embedded Linux Conf
Collapse
X
-
-
Originally posted by anarki2 View PostIf you're nitpicking, at least get it right. It's closed firmware, not closed driver.
It's not a firmware, it's a blob driver with some opensourced linkers that allow it to work on any kernel version. The blob used for their cards on linux is shipped already compiled for x86 (either 32 or 64bits) so it can't work in a router that is MIPS or ARM or whatever (it also lacks critical functions for a router like say "AP mode"). Only way to get the driver for routers is to sign a NDA and use their SDK.
See AUR for links about the two binaries https://aur.archlinux.org/packages/broadcom-wl-dkms/
Not that it'd make ANY difference. End result is, DD-WRT works, LEDE doesn't. I leave the rest up to you.Last edited by starshipeleven; 25 February 2017, 09:00 AM.
Comment
-
Originally posted by starshipeleven View PostIf you are reacting, please don't post bullshit.
It's not a firmware, it's a blob driver with some opensourced linkers that allow it to work on any kernel version. The blob used for their cards on linux is shipped already compiled for x86 (either 32 or 64bits) so it can't work in a router that is MIPS or ARM or whatever (it also lacks critical functions for a router like say "AP mode"). Only way to get the driver for routers is to sign a NDA and use their SDK.
See AUR for links about the two binaries https://aur.archlinux.org/packages/broadcom-wl-dkms/
I was just pointing out that it's not their fault if Broadcom does not release a proper linux driver for routers, and that dd-wrt is basically sugarcoating the same stuff that is used in stock firmware.
Comment
-
Originally posted by anarki2 View PostDD-WRT is basically solving the problem, while OpenWRT is refusing to.
The reason OpenWRT/LEDE wants to use opensourced stuff and not sign NDAs is that they make a distro for embedded devices, all their devices have the same underlying firmware made by the same stuff at the same version, so it's easier to have a consistent and stable experience across them.
In dd-wrt the wifi works great, just like stock firmware (no duh). The problem everything else. The firmware on my router (yes I have a netgear 6300v2, also broadcom-based and wifi-ac router) is pretty decent and offers most features you will really need (it even has a tftp server), so dd-wrt needs to beat that, and... it does not.
VLANs don't work from the webinterface, I had to use SSH same as with stock firmware (on stock I actually used serial console, but anyway), and this is a common and well-known issue since forever, when expanding functionality the device requires silly hacks like adding scripts that rebuild custom config of built-in services on reboot (ftp is what I tried, I wanted it to use passive mode so I could host stuff for people outside my own LAN without triggering firewalls), when setting up entware (aka clone of OpenWRT package feeds) some packages break and you need to symlink stuff or bind-mount things around to make them happy (just see the tutorial in their wiki).
So yeah, they "solve" the wifi issue, but lose in most other areas. Sorry but nope, there is no point.
Disappointed, very disappointed by dd-wrt.
- Likes 1
Comment
-
Originally posted by starshipeleven View PostAnd for good reasons, if I might add.
The reason OpenWRT/LEDE wants to use opensourced stuff and not sign NDAs is that they make a distro for embedded devices, all their devices have the same underlying firmware made by the same stuff at the same version, so it's easier to have a consistent and stable experience across them.
In dd-wrt the wifi works great, just like stock firmware (no duh). The problem everything else. The firmware on my router (yes I have a netgear 6300v2, also broadcom-based and wifi-ac router) is pretty decent and offers most features you will really need (it even has a tftp server), so dd-wrt needs to beat that, and... it does not.
VLANs don't work from the webinterface, I had to use SSH same as with stock firmware (on stock I actually used serial console, but anyway), and this is a common and well-known issue since forever, when expanding functionality the device requires silly hacks like adding scripts that rebuild custom config of built-in services on reboot (ftp is what I tried, I wanted it to use passive mode so I could host stuff for people outside my own LAN without triggering firewalls), when setting up entware (aka clone of OpenWRT package feeds) some packages break and you need to symlink stuff or bind-mount things around to make them happy (just see the tutorial in their wiki).
So yeah, they "solve" the wifi issue, but lose in most other areas. Sorry but nope, there is no point.
Disappointed, very disappointed by dd-wrt.
OTOH I can't see why LEDE couldn't release a "blob" version with such closed stuff.
Comment
-
Originally posted by anarki2 View PostOTOH I can't see why LEDE couldn't release a "blob" version with such closed stuff.
There are multiple issues:
-the usual ideological reasons we all know and love,
-Broadcom does not grant free access to the SDK (and blobs) but you must pay significant sums of money for the privilege, usually tens of thousands of $ (I don't know about this case specifically, but in embedded world it's common to see these prices for SDK + devboard as it's aimed to companies).
-you must also sign NDAs that will likely limit your ability to write other similar stuff (as you had access to some of their source/information, so you could be stealing their stuff and they could sue you for that even if it's not true, just for trolling), see the case of David Airlie that had signed an NDA for some ATI/AMD/Radeon GPUs and had to stay clear of opensource development for those cards and a few years after too. Quite a bit of LEDE core devs also contribute to mainline linux or u-boot or wherever else, they won't like being tied up like this.
-the blobs require a specific linux kernel version from the SDK, and that is not usually a vanilla kernel either so you need to devote time to adapt stuff from LEDE to work in the SDK's build system (and fix all fun new bugs that appear) or manage to port the blobs to work in the modern kernel used in LEDE.
DD-WRT guys offer a premium version with advanced features and they have some companies that ship dd-wrt (Buffalo, there may be others), so I assume they get enough money for buying the SDK or they have some other kind of deal, they are only working on dd-wrt so NDAs are not an issue, while having a ton of different device firmwares to deal with seems to still take its toll, secondary features can be left half-baked or not fleshed out, there are some ugly hacks and so on.
LEDE/OpenWRT builds the same kernel and packages for whole classes of devices of the same arch, then packages stuff+ right configs into a device-specific firmware.
This means that while LEDE is supporting around 650 devices and random people keep sending new device support PRs, the load on core developers to debug actual issues and whatnot is only for 10 or so classes of devices.
Then it has its sore points (like webinterface), but stuff that is supported by mainline works fine.
Comment
Comment