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

[D. Hugh Redelmeier]

| From: Erik L <erik_list-etARiVBfTZtBDgjK7y7TUQ at public.gmane.org>

| > MLPPP support is clearly useful and I'm glad support for it is no
| > longer limited to Tomato (I was previously unaware of Linux/MLPPP but
| > it is (was?) limited to x86).
| > 
| IIRC, Linux/MLPPP is x86 only but I guess you should be able to 
| cross-compile the source code for a different arch, much as we did when 
| porting Linux/MLPPP to OpenWrt for MIPS, etc.

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.

| > Why did you fork?  I can imagine reasons but it would be good to know
| > yours.
|
| We wanted to avoid a fork, but the prevailing factor for OpenWrt/MLPPP 
| became ease of use.

Good goal.  One that raw OpenWRT won't accomplish.

| The product requires
1:
| a non-default (for OpenWrt) kernel config and
2:
| a MLPPP-related kernel patch,
3:
| a non-default web  interface (webif instead of luci) modified by us,
4:
| plus all the userspace MLPPP code and scripts.

| While it's possible to compile the kernel patch 
| into a replacement ppp kernel module and perhaps bring everything else 
| down to a couple of .ipk, installing it like that over a stock OpenWrt 
| would still not be trivial for non-technical end users.

Agreed.

| It would also 
| require them running the correct version of OpenWrt - we based alpha 1 
| on 8.09.2 for various reasons.

| This is why we've chosen to provide 
| pre-compiled binary images - the focus is on anyone being able to 
| download the firmware, flash it, and config from the GUI.

All that makes sense.

| This doesn't 
| preclude the technically-inclined from doing whatever they'd like to do.

What I'd like (without knowing the background) is:

- 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.

  + 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.

- 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.

You would (eventually) use the stock OpenWRT tree but build it with
your options.

| 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.

| Thanks for taking an interest in this. For better or for worse, MLPPP 
| for resi use wouldn't have seen such exposure or development if it 
| weren't for Bell's recent tactics.

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.

I cannot understand how the CRTC let Bell do this.

Thanks again!
--
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