1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Interesting thread on modding Tomato to use MLPPP

Discussion in 'Tomato Firmware' started by Sunspark, May 14, 2008.

  1. Sunspark

    Sunspark LI Guru Member

  2. webstar

    webstar LI Guru Member

  3. Guspaz

    Guspaz Addicted to LI Member

    Hi, I'm Guspaz, one of the authors of Tomato/MLPPP.

    DSL_Ricer actually did almost all of the implementation, but I thought I'd give an idea about what changes we made. They may not necessarily be in the order that they were implemented.

    First, we backported the PPP code from the 2.4.35 kernel to Tomato's 2.4.20 kernel. This was necessary as some bug fixes were made that were required for MLPPP to work.

    Next, we merged Debian's version of PPPd 2.4.4 into Tomato, replacing the existing PPPd (and removing pppoecd). We were having some issues with the generic PPPd, and one of Debian's patches evidently fixed that.

    We then modified PPPd further to add support for connecting to the correct ERX on the second link. TekSavvy is the only DSL ISP that I know of that supports MLPPP on PPPoE sessions (none of the other Bell wholesalers do, to my knowledge), so they'll be my test case here. They have four ERXes, and both links need to be on the same endpoint. In effect, this is actually just adding an option to PPPd to require a certain endpoint; after the primary link is established, we pass that endpoint to the secondary PPPd, and it treats connecting to the wrong endpoint as a connection failure.

    From there, we redesigned how Tomato handles PPP connections by rewriting parts of rc and redial. rc now correctly manages PPPd, and the redial processes themselves spawn pppd to be able to more quickly detect a failure (rather than polling). This is useful, what with endpoint-mismatches being treated as connection failure; the secondary link (and tertiary if there is one, and so on) will re-try until they get the correct endpoint, and then it moves on to the next. Obviously there are now n redial and pppd processes, due to the requirement of having one per modem.

    Lastly, we added UI support. This was achieved by adding a few new options, and modifying the MTU option. First, there is a new "MultiLink PPP" dropdown to the Network page. The options are:

    "Off": Just use an ordinary PPPoE link, although we're obviously now using PPPd instead of pppoecd)

    "Single Link": Use MLPPP on a single DSL modem/line. This actually doesn't do anything like round-robin or splitting packets, all it does is pad the PPP packets with 6 bytes of the multilink header. This is useful as it can confuse some Deep Packet Inspection hardware, circumventing throttling as performed by Bell Canada (yes, they throttle their wholesalers even though they just provide an L2TP tunnel and DSLAM). Many people are using this firmware for this reason, even though they don't have multiple DSL lines.

    "Multiple Link": Establish (by default) two links. One is expected to be on vlan1 (pppd segfaults connecting to vlans, so we make a new bridge, br1, as an abstraction layer), and the other is on br0 (any switch port, although this is also technically wireless).

    Next, we modified the MTU setting, by replacing the current "Default" option with "Automatic". Wheras before it simply always defaulted to 1492, it now chooses the optimal MTU based on the multilink mode. When you're using multilink, the optimal MTU is 1440+2n (so, 1442 for single-link, 1444 for dual-link, and so on). When you disable multilink, the new default is 1448, which saves an ATM cell. This was somewhat required, as there can be a rather large performance hit using an MTU of 1492 with a multilink setup.

    Lastly, on the Advanced/Miscellaneous page, we added a "MLPPP Interfaces" text box. This is normally auto-populated by the firmware (blank for off/single, br0 for dual), but lets you add additional devices if you want to try multilink with three or more modems (comma separated). Obviously, to do that, you'll need to modify the VLANs to be able to partition off another port for the third modem, and that requires the user to stick a script on the scripts page.

    After all this, it makes setting up multilink with two modems almost trivial. Essentially, the procedure is:

    1) Set up Tomato just like you normally would for PPPoE
    2) Plug the second modem into a switch port
    3) Select "Multiple Links" in the dropdown

    And you're done. That's about as easy as multilink can get.

    All the PPP stuff is still done in-kernel, as it was with pppoecd, so there shouldn't really be any major performance differences there. Multilink itself doesn't seem to require any additional CPU time, it's still primarily throughput-based.

    For a ballpark estimate, roughly 5% CPU time is required per megabit of throughput. DSL wholesalers in Ontario and Quebec currently offer 5mbit down 800kbit up DSL service, meaning you can easily bond two DSL lines on a WRT54GL (~58% CPU load for PPP, compared to ~29% normally), and three lines is possible (87%), but doesn't leave much headroom for other stuff (wireless, QoS, etc).

    Bell's own service is 7/1 (upstream actually a bit higher in practice), so bonding two of those lines (TekSavvy logins can be used on Bell lines, and eventually wholesalers should get access to the ADSL2+ profiles like 7/1 and 16/1) is possible (~80%), but again doesn't leave a huge amount of headroom.

    And, of course, bonding two 16/1 lines is impossible on a Tomato-supported router, but at that point you're probably paying enough for the line that you're not terribly interested in bonding anyhow.

    For an idea of why so many TekSavvy customers are so interested in MLPPP, they currently sell the 5/0.8 lines for $29.95/mth (200GB included each), which make MLPPP somewhat affordable. $26.95 with group rates (4+ customers) Estimated cost breakdown, recurring per month, in a group:

    Line 1 (presumed wet): $26.95
    Line 2 (presumed dry): $26.95
    Dry-loop fee for line 2: $7.25+

    Cost per month for 10mbit down 1.6mbit up DSL with 400GB per month cap (ISP charges $10 per additional 100GB on your cap), before tax:


    I'd especially like to thank Webstar for lending us a box on his network to VNC to; neither myself nor DSL_Ricer actually have multiple DSL lines, and so we would have had quite a tough time testing MLPPP without his assistance. Another user, Vinch, also donated an WRT54GL, as DSL_Ricer didn't have one (only myself). And, of course, DSL_Ricer, who did the majority of the work on this.

    EDIT: There are still some bugs left in the preliminary release (mostly related to handling line disconnections), and a second release is planned. Also, we broke L2TP along the way, and removed it from the dropdown in the UI; obviously this needs to be fixed if our changes have any chance of ever being merged into Tomato, but neither of us knows terribly much about L2TP. It's hard to debug something when you don't know what it's supposed to be done :p
  4. jnappert

    jnappert LI Guru Member

    Sounds very interesting.

    Would it be possible to link two WRTs which are connected via WDS as a Multilink, when one DSL-Line is connected to the first WRT and an additional second Satellite-Modem is connected to the second?

    Or can this be done with the "normal" firmware?
  5. Guspaz

    Guspaz Addicted to LI Member

    Yes and no. You'd have to have both instances of pppd on a single router, but you might be able to get one instance talking to a modem that's on the wireless network. We've never seen anybody succeed at getting that working, although nobody has tried terribly hard.

    And multilink can't be done with the mainline Tomato firmware in general; neither pppoecd, nor the bundled version of pppd, nor the kernel support it. It might be possible to do it with a user-land PPP client, but that would probably incur undesirable performance penalties.
  6. mstombs

    mstombs Network Guru Member

    It doesn't seem right to me to use br0, this is the lanbridge combining the lan switch ports and the wireless, shouldn't you split off a second ethernet port as another WAN port, say vlan2?
  7. Guspaz

    Guspaz Addicted to LI Member

    Isolating a switch port would require monkeying about that is strictly required. We'd need to redefine vlan0, and enable/disable that based on the multilink mode. We'd also then need to create a br2 to avoid exposing pppd to a vlan device. We also presumably can't use eth0, since that seems to include both the WAN and LAN ports.

    Unless there is some performance or security concern from using the wired/wireless bridge, what's the problem with that? I suppose your initial PPPoE discovery broadcast would go out over the wireless, but that's not necessarily a concern.
  8. mstombs

    mstombs Network Guru Member

    Both, but I don't use pppoe so am probably out of my depth, but it seems to me you are mixing WAN with LAN so I don't understand how the routing/firewall/switch works.

    Also it is easy to create a vlan2 WAN port - I have one under Tomato as per this thread


    You'd also have symmetry in creating br1 for vlan1, br2 for vlan2 ...

    I never finished simultaneous use of both WANs, but Tomato's graphs etc worked fine just by creating the interface, and I can easily switch between my 2 'half-bridge' Ethernet modems.
  9. RobiGo

    RobiGo Guest

    i need some help

    I have ASUS WL-500gP
    an i have 2 modems for 2 different internet service providers. (2 PPPoE)
    I can use this MLPPP firmware?
    It is possible to set the bandwith? (one is 6Mb download bandwith, 0,5Mb up, another 40Mb down, 6Mb up (the first i want to use only for backup line...)) and a sort of load balance?
  10. Toastman

    Toastman Super Moderator Staff Member Member

    Try a search for "tomato dual-wan china" ... our hope is that the guy will release an English version one day ...
  11. itanium

    itanium Addicted to LI Member

    1.23.0061 is the only English version I know
    I am running on it now..
    It has a 2 WAN features.
    My Asus WL520GU LAN1 becoming a WAN2 port

Share This Page