Announcement

Collapse
No announcement yet.

OpenWRT-Forked LEDE Releases 17.01, Presents At The Embedded Linux Conf

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #11
    Originally posted by anarki2 View Post
    Installed it yesterday, was quite happy until I found out it doesn't (and won't) support BCM4360, the chip responsible for AC WiFi in my router. Too bad. Gotta stick with DD-WRT (KongAC) for now.
    This is the difference between routers supporting alternative firmwares and truly open routers. In most cases it is safe to leave bcm stuff on the shelf.

    Comment


    • #12
      Originally posted by starshipeleven View Post
      fixed.
      If you're nitpicking, at least get it right. It's closed firmware, not closed driver. Not that it'd make ANY difference. End result is, DD-WRT works, LEDE doesn't. I leave the rest up to you.

      Comment


      • #13
        Originally posted by anarki2 View Post
        If you're nitpicking, at least get it right. It's closed firmware, not closed driver.
        If 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/

        Not that it'd make ANY difference. End result is, DD-WRT works, LEDE doesn't. I leave the rest up to you.
        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.
        Last edited by starshipeleven; 25 February 2017, 09:00 AM.

        Comment


        • #14
          Originally posted by starshipeleven View Post
          If 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.
          DD-WRT is basically solving the problem, while OpenWRT is refusing to.

          Comment


          • #15
            Originally posted by anarki2 View Post
            DD-WRT is basically solving the problem, while OpenWRT is refusing to.
            And 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.

            Comment


            • #16
              Originally posted by starshipeleven View Post
              And 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.
              For me, IPv6 is like... sporadic with DD-WRT. I can't figure it out. With LEDE it worked just fine, but if I can't use 5G it's a no-go. Too bad.

              OTOH I can't see why LEDE couldn't release a "blob" version with such closed stuff.

              Comment


              • #17
                Originally posted by anarki2 View Post
                OTOH I can't see why LEDE couldn't release a "blob" version with such closed stuff.
                tl;dr even if we ignore ideological reasons, it's still a pain in the ass to do due to legal and practical reasons.

                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


                • #18
                  aaand a completely non-rude and plain informative post for anarki2 gets blocked by vBulletin automoderation because it sucks. Check above this post in a little while.

                  Comment

                  Working...
                  X