Mlppp hack for pfsense 2.0



  • I posted this thread in my ISP's forum on dslreports: http://www.dslreports.com/forum/r23826167-working-mlppp-in-pfsense-20

    in this case, multi-link ppp is bringing up two adsl connections at the same time and bonding them together. mpd5 splits the packets, my isp joins them. same thing happens in reverse. this seems to be working well for me in pfsense 2.0.

    could anyone with good knowledge of pfsense review this and let me know of any negative impacts i should look out for, or help with the limitations of this?



  • Very cool, nice work. I don't have a need for, or the free time to extensively mess with MLPPP at the moment. I hope it is something we can properly support in the future, it won't happen for 2.0 though and that's our focus at the moment.

    While a hack, it seems it will work properly. That bootup stuff can be done in a shell script, put into the config in <shellcmd>or <earlyshellcmd>tags.</earlyshellcmd></shellcmd>


  • Rebel Alliance Developer Netgate

    @rsingh:

    could anyone with good knowledge of pfsense review this and let me know of any negative impacts i should look out for, or help with the limitations of this?

    It is very cool, I have one customer site that could use this eventually, but unfortunately I don't have any locations I can test with that have two ADSL lines.

    The only thing you'd need to worry about is a method of keeping these changes intact during a firmware update, really.

    MLPPP, when supported on both sides, is very nice. I haven't run it over ADSL but I've used it for T1 bundles for customers and it works very well. You get the combined bandwidth of both pipes without having to worry about load balancing, and no per-connection limits. You can also lose a line and still keep going seamlessly. You just have to be connected up to an ISP which supports it on their end.

    There are some other, unrelated, PPPoE issues on 2.0 now, mainly with automatic connection/reconnection that I'm wondering if mpd5 might solve or improve. Have you seen any issues in your setup with links not reconnecting when they are disconnected?



  • Actually i always wanted to add this to pfSense but never came close to it.
    Probably add a efature request on redmine.pfsense.org and as soon as possible i will implement this, upgrade to mpd5, etc…
    BTW, for your interface name problem you have take a look at this patch for mpd5 http://redmine.pfsense.org/issues/show/252 it would help you overall to comply what is used in present code in pfSense.

    I could do it earlier still if you do a patch to convert current config used for mpd4 to mpd5 in pfSense only the client pppoe/pptp/l2tp ones.
    The server can still leave at mpd4 for now.



  • Jimp:

    There are some other, unrelated, PPPoE issues on 2.0 now, mainly with automatic connection/reconnection that I'm wondering if mpd5 might solve or improve. Have you seen any issues in your setup with links not reconnecting when they are disconnected?

    Due to limitations in pfsense 2.0 (voip problems, ipsec problems), I ran it for a total of 72 hours (some reboots involved). During that time, mpd5 maintained the connection. I don't know if disconnections occurred or not, just that the connection was always working. the status_interfaces.php page's disconnect button doesn't work with my hack.

    ermal:
    i'll look at adding the patch to the 5.3 source for interface naming.

    overall i'm looking at making this work in 1.2.3-RC1 where NAT-T is supported and everything works well except DNS during failover - that is a nice feature in 2.0.



  • i patched and recompiled mpd 5.3 but the iface option doesn't work.

    mpd-5.3 compile on freebsd
    patch < patch (patch is from http://sourceforge.net/tracker/?func=detail&aid=2831674&group_id=14145&atid=314145)

    
    [root@mlppp /usr/ports/net/mpd5/src]# patch < patch
    Hmm...  Looks like a unified diff to me...
    The text leading up to this was:
    --------------------------
    |--- src/bund.c.orig    2009-08-03 21:25:30.000000000 +0200
    |+++ src/bund.c 2009-08-03 21:44:10.000000000 +0200
    --------------------------
    Patching file bund.c using Plan A...
    Hunk #1 succeeded at 1676.
    Hunk #2 succeeded at 1726.
    Hmm...  The next patch looks like a unified diff to me...
    The text leading up to this was:
    --------------------------
    |--- src/iface.c.orig   2009-08-03 20:09:32.000000000 +0200
    |+++ src/iface.c        2009-08-03 21:33:50.000000000 +0200
    --------------------------
    Patching file iface.c using Plan A...
    Hunk #1 succeeded at 84.
    Hunk #2 succeeded at 157.
    Hunk #3 succeeded at 1347.
    Hunk #4 succeeded at 1961.
    Hunk #5 succeeded at 2050.
    Hunk #6 succeeded at 2081.
    Hunk #7 succeeded at 2113.
    Hmm...  The next patch looks like a unified diff to me...
    The text leading up to this was:
    --------------------------
    |--- src/iface.h.orig   2009-08-03 21:23:42.000000000 +0200
    |+++ src/iface.h        2009-08-03 21:24:28.000000000 +0200
    --------------------------
    Patching file iface.h using Plan A...
    Hunk #1 succeeded at 97.
    done
    [root@mlppp /usr/ports/net/mpd5/src]#
    
    make depend all install to rebuild the binary.
    
    

    the compile was good. i'm using the binary it made but no iface option or purhaps the mpd config is wrong:

    new mpd.conf:
    startup:
    default:
            load pppoeclient
    pppoeclient:
          set iface name pppoe0
          new -i pppoe0 pppoeclient pppoeclient
          create bundle static B1
          set iface route default
    ….. the rest is the same.

    mpd5 still works perfectly but i'm still left having to rename the interface. if i run mpd5 in the foreground so it outputs to console, it says set iface name isn't a command.


  • Rebel Alliance Developer Netgate

    There are some patches in mpd4 for that, in the tools repo.

    http://redmine.pfsense.org/repositories/browse/pfsense-tools/pfPorts/mpd4/files



  • Place the set iface name after the bundle create.

    Otherwise it works for me.

    I just added mpd5 to builds with that patch included. It is mpd5.5 the latest and greatest.



  • that worked ermal, the interface comes up named "pppoe0" now without intervention. thanks!



  • I do not think yo uneed this:

    
    new -i pppoe0 pppoeclient pppoeclient
    
    

    To integrate this into pfSense gui it is simple enough to just copy paste the vlan config pages.
    interface_vlan.php and interface_vlan_edit.php from there on is just adding removing pppoe settings.
    After you have those pages ok you just need to add the multilink pppoe type to the interfaces assign page and
    copy the interface_pppoe_configure()  in interfaces.inc to interface_multilink_configure() and add the neccessary settings.
    It is not too much work once you get to it.



  • i removed that line from the config and reconnected. seems fine.

    i'll also work on those config pages you mentioned.



  • rsingh, I'm mlppp-enabled on teksavvy, and getting my second ADSL line Friday. I'm using 1.2.3-Release currently and would like to test what you've got. Does the procedure you posted at the dlsr forum work for you in 1.2.3 or do you have any recommended modifications?

    edit: I tried your 2.0 instructions on 1.2.3 and got a missing library error when trying to run mpd5 in the shell. I'll try it on 2.0 as soon as I can get PFS to boot up.



  • I'm working on getting this functionality into the pfSense code base.
    I need to know, do the two DSL lines have different usernames and passwords, or are they the same?

    Thanks,
    GNB



  • @clarknova:

    rsingh, I'm mlppp-enabled on teksavvy, and getting my second ADSL line Friday. I'm using 1.2.3-Release currently and would like to test what you've got. Does the procedure you posted at the dlsr forum work for you in 1.2.3 or do you have any recommended modifications?

    edit: I tried your 2.0 instructions on 1.2.3 and got a missing library error when trying to run mpd5 in the shell. I'll try it on 2.0 as soon as I can get PFS to boot up.

    these instructions will not work for 1.2.3. You need to recompile mpd5 in freebsd 7.1 (i think 1.2.3 uses this) and then copy all of the libraries from your 7.1 system to 1.2.3. I did this, i found it didn't work well and abandonned it.



  • @gnhb:

    I'm working on getting this functionality into the pfSense code base.
    I need to know, do the two DSL lines have different usernames and passwords, or are they the same?

    Thanks,
    GNB

    in my case, the usernames are the same. people on the ISP i'm on and many other canadian ISPs that run mlppp will have just one account but the provider allows that one account to log in twice for the purposes of mlppp. this may not be true for everyone though.

    if this is to be implemented in the code base, it may be simpler to ask the user to edit the config file manually. the mss, mru, mrru, mtu settings i use in my conf file may not be optimal for everyone.



  • @gnhb:

    I need to know, do the two DSL lines have different usernames and passwords, or are they the same?

    I don't know the answer for sure, but rsingh indicated at the top of this thread that he is on the same ISP as me, so I'm going to go with him and say they are the same.



  • My ISP is looking at implementing mlppp on their network in the near future as well and I would also be grateful for any work done to make this a simple thing to enable from the web interface.
    Thanks for all the work that has gone into this so far.



  • Anything new to report here? Some clarification would be good too: are you still working on mlppp functionality at this point, or is that a wrap and you're just packaging it now?



  • It's ready.

    I'm now just making the existing PPPoE and PPtP code store the config data the same way the new code does it, and writing functions to upgrade existing config to the new data structures.

    GB



  • I've got a 2-link mlppp connection at home right now, running on mlppp-enabled Tomato firmware. I'll be happy to test pfsense on the connection when you get to that point with it.



  • Here's a .tar file with updated files. The brave and skilled can test them out.

    Instructions
    1. Delete existing PPP, PPPoE, and PPtP configurations.
    2. Unpack (tar -xzf mlppp.tgz.txt) the files in the attached archive into the proper directories on pfsense host. If you save the archive in your / directory and then extract it every file should end up in its proper place. If you're running nanobsd image, don't forget to do /etc/rc.conf_mount_rw first to make the file system writeable.
    3. Create new PPP, PPPoE, and PPtP configurations in the GUI. (Use the "PPPs" tab to make advanced configurations for multilink.)

    Good Luck. Let me know how it goes.
    Disclaimer: This is not committed yet. It may change later.

    Gabriel

    mlppp.tgz.txt



  • Very cool. I'll have a look in the next couple days and post my experience here.

    db



  • File I attached doesn't extract properly. PM your email address to me if you want to help test this stuff.

    GB



  • Success here on the nano image. 8)

    Some bugginess in the setup, which may be in the mlppp files, or it could just be the pfsense beta.



  • Can you give me details of bugginess, and post your mpd_wan.conf file (located in /var/etc/ directory)?

    Thanks,
    GB



  • Two or three times while setting things up I was not able to get any IP functionality into or through pfsense, other than dhcp. I could ping LAN and internet hosts from pfsense (on the console) and get a response–with one exception, where I couldn't get any ping response even from the console--but when pinging pfsense from a LAN client I got no response, even though arp resolution was happening. I hadn't touched the firewall rules, so the antilockout rule definitely should have been in effect. I think this happened after changing the IP address of an interface from the webUI, but I'm not sure. The only way I found to correct this situation was to use the console option to restore default settings. I did this 2 or 3 times.

    The other thing I noticed is that sometimes on the interfaces_assign.php page the network port for LAN and OPT1 would show up as "()" instead of vr2 or vr2_vlan1 as the case may be. Despite this, I was still able to interact with pfsense on the webUI.

    And finally, on the interfaces_ppps.php page, before adding any entry, there was already a blank entry, which when I tried to delete it I got some message, like I can't delete it because it's in use. After I created an mlppp entry on this page and assiged it to the WAN I was then able to delete the blank entry. I think deleting the blank entry may have corrected the () issue I described in the previous paragraph, as I'm not seeing it now.

    I've attached the file you requested, although I'm not seeing any of these problems at the moment.

    mpd_wan.conf.txt



  • I'm not sure what was happening with respect to the pinging issues.

    You're guess is correct. The network port showing up as "()" was related to the blank entry on interfaces_ppps.php. That blank entry was an empty tag in your config.xml file that resulted from bugs that should be fixed in that latest file set I just emailed you. You were still able to interact with the box when seeing these because the error was in the GUI, and the actual configuration of the LAN port hadn't changed.

    GB



  • i was all set to try this out tonight but ran into some problems: vmware server no longer gives me console access to any of my VMs (pfsense is running in vmware). i have to carefully fix this first without screwing up anything (otherwise i won't be able to fix it) before the pfsense 2.0 testing.



  • @gnhb:

    I'm not sure what was happening with respect to the pinging issues.

    I think I may have been trying to do setup on the WAN using the standard interfaces.php?if=wan page before creating my multilink pppoe interface on interfaces_ppps.php. I had to play with it a bit and set it up a few times to really grok the new pages. It seems to me the interfaces.php?if=wan page is redundant (except for the RFC1918 and Bogon buttons) and potentially dangerous if settings there could conflict with or overwrite settings made to the ppps page.

    I'll try the updated files and report back. Thanks for the quick response.



  • Ok, I used console option 4 (Reset to factory defaults) then uploaded and untarred the new package. All the old problems are gone, but I experienced a couple new problems.

    1. After assigning my interfaces, including a couple vlans for LAN and OP1, I chose option 2 (Set interface IP address) and gave an IP address to the LAN and enable dhcp. Then the console reloaded and showed no IP address for the LAN, only "NONE" where it should have showed the IP address. So then I chose option 8 (Shell) and used ifconfig to discover that the vlan did not exist, although I had set it up and it was showing in the main console view. A reboot fixed this. My first thought was that it wasn't getting renamed from pppoe0, but ifconfig didn't show any vlan interface at all, so that wouldn't be it I guess.

    2. This is minor, but when connecting to the webUI the first time after getting an IP address on the LAN, I chose pppoe for the WAN. I know this is the wrong choice, as I hadn't been on the ppps page to set up my pppoe bundle yet, but it's what I did the first time trying the new package because I didn't know better, and I wanted to recreate the ignorant user's first attempt. When the wizard finished my dashboard and Status>Interfaces page both showed the WAN was connected, but didn't display any connection information, such as an IP address.

    I then proceeded to Interfaces>Assign and created my pppoe bundle. From this point I had no problems. So the fact that the wizard asks you to configure the WAN before a mlppp bundle is created does not really cause any problem, except that it could confuse the first-time user. If your package could be made to exclude that step from the wizard, or redirect the user to the ppps page I think that would be better.

    All in all the package is quite good.

    I'm using nanoBSD build from May 25.



  • Aw geez. . . .  :-)

    I didn't even touch the code in the wizard that creates pppoe connections. That's the second problem you mentioned. It's still creating the pppoe config in the usual way instead of being compatible with the new code and data storage scheme. I'll have a look at that.

    For your first comment I think that's probably unrelated to the new code since I didn't really touch anything related to vlans or static IP addresses.

    @clarknova:

    @gnhb:

    I'm not sure what was happening with respect to the pinging issues.

    I think I may have been trying to do setup on the WAN using the standard interfaces.php?if=wan page before creating my multilink pppoe interface on interfaces_ppps.php. I had to play with it a bit and set it up a few times to really grok the new pages. It seems to me the interfaces.php?if=wan page is redundant (except for the RFC1918 and Bogon buttons) and potentially dangerous if settings there could conflict with or overwrite settings made to the ppps page.

    I'll try the updated files and report back. Thanks for the quick response.

    As far as this goes, the interfaces.php page shows a subset of the same fields in the ppps page and doesn't conflict or overwrite anything in the config that can be entered only on the ppps page.

    Yes, it's redundant to have the config fields in two places, but the dev team felt it was important to maintain continuity and simplicity for the majority of PPPoE users that just need to enter <username>and <password>for their configuration. So you mlppp guys have to put up with some more complexity for your multi link connectivity. :-)

    GB</password></username>



  • @gnhb:

    Yes, it's redundant to have the config fields in two places, but the dev team felt it was important to maintain continuity and simplicity for the majority of PPPoE users that just need to enter <username>and <password>for their configuration. So you mlppp guys have to put up with some more complexity for your multi link connectivity. :-)</password></username>

    If the settings on interfaces.php aren't going to cause actual conflicts with the overlapping settings on interfaces_ppps.php then it's not such a big deal. Maybe the devs would be amenable to a footnote on interfaces.php that would read something like "if you're using the mlppp package you can safely ignore this page and configure your wan using the PPPs subtab of the Interfaces>Assign page instead".

    As for the wizard, I realized after my last post that if you're going to distribute the mlppp files as a standard package, the wizard will be over and done with by the time users install the package anyway, so my previous point is probably moot.



  • Actually, the plan is to merge the new code into the normal distribution. I'm waiting for review and approval.

    And I'll put that footnote in the interfaces.php page too. Actually, there is already a footnote, with a link that takes you to the correct configuration in the PPPs page, but I'll make it more explicit.

    GB



  • Great news. It's pretty dummy-proof at this point, by my experince. I look forward to having it integrated. If you have any more updates I'll be happy to test them and give feedback.



  • Okay, thanks.



  • Couple more things. The first may not surprise you: I updated to the latest snapshot and the PPPs tab disappeared from the webUI and I had no WAN connection, even though it looked right for a single link pppoe. I put the mlppp.tgz file back into / and untarred it and my bundle was still in the ppps tab when it reappeared. I only had to hit the "Connect" button on the interfaces page to get reconnected. I suppose the implicated php files will not get overwritten on an upgraded once your package is integrated into the base release.

    The other thing I noticed before and after my firmware update is that instead of seeing interface names on the Status>Interfaces page, such as "LAN interface (vr2_vlan1)", I see no name, ie, "LAN interface ()". This is true for all interfaces.



  • @clarknova:

    I suppose the implicated php files will not get overwritten on an upgraded once your package is integrated into the base release.

    Yes, you're right. Once these files are integrated you won't see this behavior.

    @clarknova:

    The other thing I noticed before and after my firmware update is that instead of seeing interface names on the Status>Interfaces page, such as "LAN interface (vr2_vlan1)", I see no name, ie, "LAN interface ()". This is true for all interfaces.

    I'm not sure about the cause of this. The code that displays the interface info was modified recently by other devs. I'm running an image from May 12th on my two test boxes with my new changes and those "()" parentheses are displaying all the proper interface names. I'll check the newer code behind Status -> Interfaces soon.

    GB



  • vmware 2.0 only works well with firefox 2.0… sigh. ah well, i'll test this sunday.



  • I suspect that the WAN traffic graph is reporting approximately double the actual traffic being passed, for outbound traffic only.



  • Hi,

    Is this going to be in the 2.0 release? I can definitely use this with TekSavvy and stop thinking about moving to Tomato because of this shortcoming. However, I don't have the luxury to test this and it should be a 100% stable feature before I can get to it.

    Thanks


Log in to reply