Announcing OpenWrt/MLPPP - multilink firmware for consumer routers - Caneris & Acanac

[Erik L]

> 
> The announcement of LinuxMLPPP said x86-only and nothing as prominent
> says otherwise.
> 
> All code for little routers is cross-compiled as far as I know so the
> limitation could not be based on that issue.
> 
Nope, there wasn't anything special that limited it to x86. Very roughly, it consists of a kernel patch, modified pppd, config db, and shell scripts. Adam provides a great description of it here: http://www.dslreports.com/forum/r23788729-

> - as much code as makes sense should be upstreamed.  This might mean
>   trying to get it into the OpenWRT tree or even getting some of it
>   into Linus' kernel tree.
> 
That's the idea. I believe the Linux/MLPPP guys would have submitted their kernel patch upstream, but you know how it is...we need something now, not in a year when it trickles down.

>   + this takes effort.  The embedded field is full of folks who don't
>     make the effort and it makes for a lot of (badly) duplicated work.
>     Some of the effort is making the code good enough for the
>     gatekeepers but that is often constructive.
> 
>   + it takes time.  But if you don't start, it will never get done.
> 
>   + it means that the code that you add will need maintenance within
>     the upstream tree to adapt to changes in that tree.  Then your
>     code will no longer come with the caveat "only works with 8.09.2".
> 
>     There is a claim that code accepted within an upstream tree gets
>     some maintenance "for free", i.e. done by upstream maintainers.
>     An example is when an internal kernel interface changes, the
>     person making that change usually updates the code that uses that
>     interface.  On the other hand, out-of-tree patches tend to suffer
>     from bitrot.
> 
Agreed with everything - perhaps eventually we'd not have a fork, but just have this built down to 1-2 .ipk. We had to start somewhere and this is just alpha 1.

> - OpenWRT/MLPP could/should then become a nice place to pick up
>   binaries, kind of like x-wrt <http://x-wrt.org/>.  Those binaries
>   could and should be subject to your quality control regime.  That
>   may well mean pegging the OpenWRT tree that you use.
> 
Makes sense.

> 
> | Another major reason was hardware; as I mentioned in the 
> announcement, 
> | we're working on a complementary CPE (hardware). The end 
> goal here is to 
> | sell pre-flashed and pre-configured units to our subscribers.
> 
> A very good idea.  But I don't see why a fork helps.
> 
> | Part of 
> | the hardware effort involves more kernel modification in 
> the form of 
> | driver development for hardware currently not supported by OpenWrt.
> 
> Can you not upstream that too?  That would seem very valuable.
> 
Of course, but again, we need something now! Unless we end up doing a proprietary driver (let me guess, I'll be shot for saying that here), there's no reason not to upstream, except it takes too long for the code to go into the Linux tree, then trickle down to OpenWrt, etc.

> Yeah.  Is anyone actually using MLPP for its original purpose?
> 
> By making it easier, I guess you are inviting Bell to notice this
> trick and swat it.
> 
Our focus here is on multiple lines, not evading the throttling, though of course the latter is useful too (we also have another workaround for throttling, a free SSH tunnel service for all Caneris DSL subscribers). As far as the multiple lines, if we had access to higher speeds on GAS, this would have never taken off for resi. MLPPP is too important for biz and too difficult for Bell to mess with, so it's unlikely to go away anytime soon.

Erik
--
The Toronto Linux Users Group.      Meetings: http://gtalug.org/
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://gtalug.org/wiki/Mailing_lists