[USD150] Add multisession PPPoE on the same physical interface to 2.x
Currently pfsense is pretty much unusable beyond a basic internet firewall to the japanese consumer.
The common value-add deployment (internet, voip, optionally iptv) is delivered via fibre/adsl/cable in the following fashion:
- PPPoE session #1 - ipv4 internet, nothing special here
- PPPoE session #2 - ipv4 to a different concentrator (but delivered on the same physical ethernet as session #1) for voip
- (this part is out of the scope of this bounty but I might follow up on it later if this one works out) ipv6 non-PPPoE-encapsulated - for ip-tv set top box. This traffic is typically just bridged to the LAN without filtering on consumer routers for the japanese market.
The following functionality is required.
- Support 2-4 PPPoE client sessions (with seperately configurable authentication) on the same physical interface (the PPPoE protocol has supported this from day one).
- WebGUI support for the session configuration
- Equivalent functionality to current MultiWAN on discrete interfaces
Timeframe: 6 months
If I wanted to take this on, do you have hardware and service from an ISP that you can use to test the functionality?
Where I live such service is not available, but if you can test it, I can try to build it. The first thing I would want to do is to send you a configuration file to put on an existing 2.0 build to test if the software base can handle the functions before we start thinking about building a GUI.
Do you live in Japan?
There is work going on right now for MLPPP in 2.0, not sure how far off this might be from that. You might also be able to "fake" it with multiple VLAN interfaces hooked into the same "dumb" switch that links up to your incoming line.
2.0 already support multiple PPPoE interfaces, so you may want to be wary of what already exists in that branch so work is not duplicated.
As far as I know, I'm the one doing the MLPPP work for 2.0. I responded to this because it's easy to make this work with the same GUI.
Ah, cool. I didn't realize it was you. :)
Sounds like it might be a good feature to have it all work on one interface if mpd can do that. The VLAN trickery seems like an ugly hack, but people seem to make that work for other WAN types that need such treatment.
Yes, I'm in japan, have the proper ISP accounts, link and gear to test with.
As far as implementation goes, if you can massage the mpd.conf into something with multiple sections for each session (i.e. duplicate the same information into a second bundle section, with a different netgraph node (attached to the same ethernet) I think it should work network-wise. I have not delved deep enough into pfsense internals to know how complex generalizing multiple netgraph devices into proper pfsense interfaces will be. That complexity will probably be the make/break of this bounty.
Something along the lines of the following (may not be 100% but something I've cribbed up from bits of various configs that might get you on the right track):
session1: new -i ng0 session1 session1 set iface route default set iface disable on-demand set iface idle 0 set iface up-script /usr/local/sbin/ppp-linkup set bundle disable multilink set bundle authname "email@example.com" set bundle password "my-isp-password" set bundle no noretry set link keep-alive 10 60 set link max-redial 0 set link no acfcomp protocomp set link disable pap chap set link accept chap set link mtu 1492 set ipcp yes vjcomp set ipcp ranges 0.0.0.0/0 0.0.0.0/0 set ipcp enable req-pri-dns set ipcp enable req-sec-dns open iface session2: new -i ng1 session2 session2 set iface disable on-demand set iface idle 0 set bundle disable multilink set bundle authname "guest@flets" set bundle password "guest" set bundle no noretry set link keep-alive 10 60 set link max-redial 0 set link no acfcomp protocomp set link disable pap chap set link accept chap set link mtu 1492 set ipcp yes vjcomp set ipcp ranges 0.0.0.0/0 0.0.0.0/0 set ipcp enable req-pri-dns set ipcp enable req-sec-dns set iface route 22.214.171.124/25 set iface route 126.96.36.199/26 set iface route 188.8.131.52/26 set iface route 184.108.40.206/25 set iface route 220.127.116.11/27 set iface route 18.104.22.168/29 set iface route 22.214.171.124/27 set iface route 126.96.36.199/27 set iface route 188.8.131.52/25 set iface route 184.108.40.206/26 set iface route 220.127.116.11/28 set iface route 18.104.22.168/26 set iface route 22.214.171.124/28 open iface
session1: set link type pppoe set pppoe iface re0 set pppoe service "" set pppoe enable originate set pppoe disable incoming session2: set link type pppoe set pppoe iface re0 set pppoe service "" set pppoe enable originate set pppoe disable incoming
Code is coming along nicely. Should be done soon-ish. :)
So do you differentiate the links by just username, or is the pppoe service name used to differentiate?
I'm just trying to figure out what's best to display in the "interfaces Assign" page. If you define 2 or more PPPoE links, you need something to show up in the drop down menu to enable you to select the right one for WAN or OPTx. Right now the code is displaying the text in the "Description" field from the PPPoE link definition page.
I don't believe PPPoE service name is used at all here.
The way that the majority of FTTH/ADSL is deployed here is kind of interesting. The physical line is logically decoupled from the ISP service in the case of the monopoly telco, and you can change ISP without any line changes just by changing the userid@radius-realm and password on your session (and 2-4 PPPoE sessions are supported depending on line type so you can actually be hooked up with multiple ISPs simultaneously if you can work out the routing).
Phobia last edited by
gnhb - I'm not sure if your question about what to display would apply to this, but just in case I thought I should mention that some ISPs in Canada that provision MLPPP do so with the same username across all the links. Therefore delineating by login/username might not be the best idea.
Again - this may not apply if this project differs from the MLPPP "hack" discussed at :
Thanks for the replies. Further examination of the documentation of the underlying software revealed that MLPPP links MUST use the same username and password. :)
I'm displaying the "Description" field if it is not blank and the "Link Interfaces/Ports" if the Description is left blank.
Almost ready for testing . . .