Announcement

Collapse
No announcement yet.

OpenWRT 14.07 RC1 Brings Native IPv6 Support, New Init System

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

  • OpenWRT 14.07 RC1 Brings Native IPv6 Support, New Init System

    Phoronix: OpenWRT 14.07 RC1 Brings Native IPv6 Support, New Init System

    The first release candidate to OpenWRT "Barrier Breaker" 14.07 is now available with a large number of changes to this popular embedded Linux distribution primarily for routers and other network devices...

    http://www.phoronix.com/vr.php?view=MTc0MTc

  • #2
    Yes! I've been waiting for a new OpenWRT release. I'll make sure to check it next weekend

    Comment


    • #3
      IPv6 now?

      Native IPv6 support now?

      Shouldn't this have been made years ago? Really?

      Comment


      • #4
        Originally posted by uid313 View Post
        Native IPv6 support now?

        Shouldn't this have been made years ago? Really?
        OpenWrt 12.09 user here. IPv6 was already available (I've been using it for awhile now), but you had to manually install and configure the whole stack. Not hard, if you know your way around OpenWrt and IPv6. I think the difference now is that IPv6 comes enabled by default.

        Comment


        • #5
          Originally posted by Pseus View Post
          OpenWrt 12.09 user here. IPv6 was already available (I've been using it for awhile now), but you had to manually install and configure the whole stack. Not hard, if you know your way around OpenWrt and IPv6. I think the difference now is that IPv6 comes enabled by default.
          You shouldn't have to manually install it and manually configure it.

          It is a shame they only got IPv6 now.
          They should have gotten full automatic IPv6 by default enabled year ago.

          No wonder IPv6 adoption is so low.
          I know some vendors do as little as they can to get by, and rather postpone it later so they can sell more units later.
          But OpenWRT ought to be a pioneer here.

          Comment


          • #6
            Originally posted by uid313 View Post
            You shouldn't have to manually install it and manually configure it.

            It is a shame they only got IPv6 now.
            They should have gotten full automatic IPv6 by default enabled year ago.
            How did you help us? Did you provide any patches? Did you donate anyone working on IPv6?

            Comment


            • #7
              Originally posted by uid313 View Post
              You shouldn't have to manually install it and manually configure it.

              It is a shame they only got IPv6 now.
              They should have gotten full automatic IPv6 by default enabled year ago.

              No wonder IPv6 adoption is so low.
              I know some vendors do as little as they can to get by, and rather postpone it later so they can sell more units later.
              But OpenWRT ought to be a pioneer here.
              This would be a nice speech, if OpenWRT sold routers. In actuallity, you buy a router (which may or may not support IPv6), and install OpenWRT on it if you want. Then, if you want IPv6 support (until now) you would install and enable it. Now you don't need to do that, but it doesn't change the fact that you still need to install OpenWRT to your router.

              (except in the case that some vendor preinstalls OpenWRT on their routers, but that's a definite exception, I'm sure)

              Comment


              • #8
                native IPv6 support
                It's about time!

                Comment


                • #9
                  Couldn't it run systemd, too?

                  Comment


                  • #10
                    Originally posted by phoronix View Post
                    Phoronix: OpenWRT 14.07 RC1 Brings Native IPv6 Support, New Init System

                    The first release candidate to OpenWRT "Barrier Breaker" 14.07 is now available with a large number of changes to this popular embedded Linux distribution primarily for routers and other network devices...

                    http://www.phoronix.com/vr.php?view=MTc0MTc
                    sweet, time to move away from attitude adjustment on my buffalo router! congrats!

                    Comment


                    • #11
                      Originally posted by caligula View Post
                      Couldn't it run systemd, too?
                      I believe systemd is a bit too heavy on the storage side of the equation for old and not so old routers. Every byte of flash memory counts.

                      Comment


                      • #12
                        Originally posted by Pseus View Post
                        I believe systemd is a bit too heavy on the storage side of the equation for old and not so old routers. Every byte of flash memory counts.
                        But systemd is modular? You could statically link with uclibc and use gcc's -Os.

                        Comment


                        • #13
                          Hi,

                          systemd seems to run on openwrt, see here: https://forum.openwrt.org/viewtopic.php?id=49599, but the integration is not very good AFAIK.
                          Would be awesome, though. Just imagine having all your logs from all your tiny devices on your sever so you always see then there is a problem,
                          not having to remember if the device is a router or a real server and finally, having easy port activated services on openwrt.


                          I also find it funny, that the openwrt guys do not list any reason why we need a new init system (procd) on their own wiki: http://wiki.openwrt.org/doc/techref/procd

                          Let me quote this as they might change this in the future:
                          "Why do we want procd?

                          One thing that procd does much better then

                          It boils down to the fact that the current are rather constrained and inflexible:





                          procd will be able to - and of course all that without adding unnecessary bloat. AFAIK there are no alternatives to procd. "

                          Well, we will see if procd is a good solution or not.

                          Comment


                          • #14
                            There you go:
                            [11 of July 2014] [11:18:49] <txomon|fon> have you thought about including systemd in openwrt?
                            [11 of July 2014] [11:19:05] <txomon|fon> or is it too heavy?
                            [11 of July 2014] [11:19:18] <jow_laptop> its too heavy
                            [11 of July 2014] [11:19:30] <jow_laptop> and too tightly integrated with other subsystems we do not want
                            [11 of July 2014] [11:19:48] <txomon|fon> replacing the init by a binary loader?
                            [11 of July 2014] [11:19:56] <jow_laptop> hm?
                            [11 of July 2014] [11:20:03] <txomon|fon> it would be really impressive the result, wouldn't it?
                            [11 of July 2014] [11:20:09] <jow_laptop> the init is already replaced by a binary loader in trunk
                            [11 of July 2014] [11:20:25] <jow_laptop> unless you mean init scripts
                            [11 of July 2014] [11:20:30] <txomon|fon> yeah, sorry
                            [11 of July 2014] [11:20:35] <txomon|fon> the init scripts and so
                            [11 of July 2014] [11:20:45] <jow_laptop> those are mostly stubs that send service descriptions to procd already
                            [11 of July 2014] [11:21:00] <jow_laptop> procd then handles reload, process tracking etc.
                            [11 of July 2014] [11:21:15] <txomon|fon> yes, but I was speaking about suppressing those scripts
                            [11 of July 2014] [11:21:24] <txomon|fon> I suppose it's on the roadmap
                            [11 of July 2014] [11:22:03] <jow_laptop> well many init scripts still perform config transformation
                            [11 of July 2014] [11:23:42] <jow_laptop> and this requires still scripting
                            [11 of July 2014] [11:23:49] <jow_laptop> which in turn still requires spawning a shell
                            [11 of July 2014] [11:23:58] <jow_laptop> unless we come up with a custom script language to do so
                            [11 of July 2014] [11:24:02] <jow_laptop> which in turn will likely upset people
                            [11 of July 2014] [11:24:07] <txomon|fon> yeah
                            [11 of July 2014] [11:24:50] <txomon|fon> or maybe if the config setup is really simple, they don't miind
                            [11 of July 2014] [11:24:54] <jow_laptop> however services that have fixed args can be probably described by fixed service description files
                            [11 of July 2014] [11:25:27] <txomon|fon> well, they can also be patched to have those defaults, can't they?
                            [11 of July 2014] [11:27:24] <jow_laptop> probably, but patching any possible software package to accomodate for an init mechanism is a dead-end
                            [11 of July 2014] [11:27:42] <jow_laptop> too much maintenance work and a too small niche
                            [11 of July 2014] [11:28:55] <txomon|fon> well, if you trim functionalities in the binaries... Anyway, the truth is that the workflow of openwrt is to adecuate incoming sources
                            [11 of July 2014] [11:29:20] <plntyk> btw - does the dbus -> kdbus kernel integration have any effect on openwrt ?
                            [11 of July 2014] [11:30:00] <jow_laptop> plntyk: yes, the kernel becomes bigger and multiple targets will fail
                            [11 of July 2014] [11:30:47] <txomon|fon> do you have any stats on how big usually images are, or package usage statistics?
                            [11 of July 2014] [11:31:31] <jow_laptop> not really
                            [11 of July 2014] [11:32:01] <txomon|fon> maybe that could be interesting to prioritize packages, updates, designs
                            [11 of July 2014] [11:36:02] <nbd> txomon|fon: in my opinion, systemd would be completely useless to us, because it solves boring problems in a slightly different way, while leaving the interesting problems completely unsolved
                            [11 of July 2014] [11:36:17] <builder> build #5 of x86.kvm_guest is complete: Failure [failed shell] Build details are at http://buildbot.openwrt.org:8010/bui...guest/builds/5
                            [11 of July 2014] [11:36:49] <txomon|fon> nbd, example?
                            [11 of July 2014] [11:36:52] <nbd> starting a service and keeping track of it is boring, it has been done in so many different variations with so many different implementations
                            [11 of July 2014] [11:37:29] <txomon|fon> and the interesting problems part?
                            [11 of July 2014] [11:37:37] <nbd> having a unified config storage where the part that's changing the config does not need to keep track of what needs to be done to apply it
                            [11 of July 2014] [11:38:08] <nbd> and our own init system plays an important role in that
                            [11 of July 2014] [11:45:39] <ifdm_> the companies use to make a mess when they try to make their own process tracking system
                            [11 of July 2014] [11:46:45] <txomon|fon> nbd, so you mean that not having to restart apps if config hasn't changed is that interesting?
                            [11 of July 2014] [11:47:48] <jow_laptop> it is if restarting the ap has side effects
                            [11 of July 2014] [11:47:51] <jow_laptop> *app
                            [11 of July 2014] [11:52:22] <nbd> the restart-everything-after-changing-something model is quite stupid
                            [11 of July 2014] [12:01:01] <txomon|fon> usually apps have reload mechanisms, don't they?
                            [11 of July 2014] [12:03:30] <nbd> some do, some don't
                            [11 of July 2014] [12:03:44] <nbd> but for many apps, configuration isn't stored in their native format
                            [11 of July 2014] [12:03:47] <nbd> it's converted from uci
                            [11 of July 2014] [12:05:28] <txomon|fon> sure

                            Comment


                            • #15
                              What about a solution to enable channel 13 and 13 in Europe?

                              https://dev.openwrt.org/ticket/9678

                              Comment

                              Working...
                              X