PPP links with MPD5 - Success! (was PPP overhaul?)

sullrich

Nice, we would very much like to dump ppp in favor of mpd. I know that ADSL bonding is a common request from ISPs in Canada which apparently requires MPD.

eri--

Can you test with latest snapshots.
I patched mpd5 to have the NGM_TTY_COOKIE code fixed

gnhb

The modem is the Compass 885 from Sierra Wireless/AT&T. I also have a Novatel Ovation MC950D which works as well.

I'd very much like to dump ppp too. I haven't explored the source, but just experience using it makes me think it's not a great implementation.

gnhb

Hi All,
I'm making some nice progress on the work to use mpd5 for serial PPP connections (3G modems, normal modems).

I've only worked on interfaces.inc so far. I have it generating the mpd.conf file and the mpd.secret file, and the linkup and linkdown scripts for one or more configured PPP links.
Ermal, I copied the style and file placements from the pppoe configuration function since you said awhile back that you wanted it all to be the same.

mpd has a huge default script file that works without modification for my 3G modem, but I don't have to set the APN, so I hope to modify it slightly and then save it statically somewhere and copy it to /var/etc/ when the ppp interface_configure function is called.

I haven't done anything to support modems that require you to set an APN, but I'll work on that tomorrow.

Is there a demand from pfsense users to support multilink PPP with serial based devices?
I'll also work on multilink PPP configs too if that seems to be a demand.

Questions for Ermal, Scott . . .
1. Does /usr/local/sbin/ppp-linkup script work for pppoe users to set their dns servers? It seems like it wouldn't work b/c the script is called with 'dns1 2.3.4.3' as a single field according to the docs and in the script it's assumed that 'dns1' and '2.3.4.3' correlate to two separate fields. And what is the result of sending the interface name to /tmp/rc.newwanip and creating /tmp/<int>up? And what is the facility that caused the desired result?

2. The current PPP code in the snapshots doesn't set the PPP dns servers properly in /var/etc/resolv.conf. How the heck does setting dns servers from dynamic interfaces like PPP and pppoe work? Or, how is it supposed to work? And how is pfsense supposed to un-set them once the interface comes down?

This code from system.inc doesn't work as intended . . . the "ls" call isn't formated correctly. Here's the result when file(s) named nameserver_* do exist in that directory.
[root@pfsense.local]/root(115): ls /var/etc/nameserver_* 2 > /dev/null
ls: 2: No such file or directory


function get_nameservers() {
	global $config, $g;
	$master_list = array();

	// Read in dhclient nameservers
	$dns_lists = split("\n", `ls /var/etc/nameserver_* 2>/dev/null`);
	if(is_array($dns_lists)) {
		foreach($dns_lists as $dns) {
			if(!$dns) 
				continue;

I don't know how to fix setting override DNS servers from dynamic interfaces . I tried, alot. I noticed that it was an option to put nameserver IP's in /var/etc/nameservers.conf so I tried that too. Still, the IP's don't ever get into /var/etc/resolv.conf. I tried to make and call an rc script that called system_resolvconf_generate(), and still no success. ???

The only way they ever get into resolv.conf is by clicking the "Save" button on the system.php page, and then they never get erased even when the link goes down, and back up again. So you notice missing nameservers the first time the link comes up, you go check the system.php page and Save it, and viola, they stick until the next reboot. :) Probably not intended behavior. :)

3. Next, how about that "set iface name pppoeX" command in the pppoe mpd.conf file? That's not documented anywhere I can see. Is that a custom patch from pfsense dev team?

4. Where should the mpd.script file for dialing modems live? /usr/local/sbin ? /etc/ppp/ ?

I've included a patch file of my changes to interfaces.inc so far that you guys can review if you like. I don't recommend committing it yet because it will break PPP for users that need to set the APN on their 3G modem.

Thanks,
GB

interfaces.inc.patch.txt</int>

eri--

Answers for the point raised:
4- You do not need a mpd.script just use set auth name/password directives.
3- It is a local patch use it the same way it is used for pppoe, just after the create bundle.
2- It is done with the help of iface-up
1- It works as it should please reread the code.

gnhb

Hi Ermal,

Thanks for the answers. I wrote that when I was stuck, and figured most of it out in the meantime.

I have PPP with mpd5 working really well now, including setting the APN and APN Number. Yes! Your patched mpd5 in recent snapshots works great.
Still no work on multilink PPP with serial port links.

Right now the code creates the mpd.secret file but I'll test and change to your suggestion in a couple days if it works as you say.

And PPP for modems does need the mpd.script file. It's the chat script file for the link establishment, so where do you want it? Right now it has to be in /etc/ppp/mpd.script, and it's copied to /var/etc/. when ppp is first configured.

I also took away the "Dialcmd" field in the PPP setup page (and a couple others) because the script is rather comprehensive and is designed to handle any modem. I just added the APN stuff to it.

The code is currently writing custom ppp-linkup/down files to /var/etc/ for ppp links because it's the only way I know how to associate an interface with a ppp definition later on. I'll test your custom "set iface name XXX". I actually tested it already, but it didn't work, probably because I set the mpd.conf file to use bundle templates instead of static bundles. So, I'll test it out and make more changes and if it works, we can get rid of the custom linkup/down scripts and just use the same one that you're using for pppoe (I think.)

And still no uptime tracking yet. I'm submitting the patches to coreteam@. Please review and commit.

Thanks,
GNB

gnhb

Hi,

Incidentally, I noticed that it takes a long time for this to happen (see log), and I don't know why. I haven't looked at check_reload_status past noting that it's a binary file.

See the first entry is at 14:17:12 and the next is at 14:17:44. Long time.

Mar 23 14:17:12 check_reload_status: rc.newwanip starting
Mar 23 14:17:44 php: : rc.newwanip: Informational is starting ng0.
Mar 23 14:17:45 php: : rc.newwanip: on (IP address: 10.94.5.165) (interface: wan) (real interface: ng0).
Mar 23 14:17:49 dnsmasq[24251]: reading /etc/resolv.conf
Mar 23 14:17:49 dnsmasq[24251]: using nameserver 203.170.228.120#53
Mar 23 14:17:49 dnsmasq[24251]: using nameserver 203.146.237.237#53
Mar 23 14:17:52 check_reload_status: reloading filter
Mar 23 14:18:44 check_reload_status: updating dyndns

eri--

Can you please modify it to take a pin if available?!

It needs 30 secs minimum i never got to modify it to require less.

gnhb

Two more notes . . .

1. I called mpd with the -s flag to tell it to log to syslog as "ppp" so I didn't have to change the syslog configs. Update both if you want it more clean, but it's sort of nice b/c the webgui already splits ppp out to a separate log.

2. It would be nice to display some sort of progress indication in the web gui when users click on the Connect button for PPP. Sometimes it takes more time than people expect, and the webpage reloads immediately, and then of course they go clicking again and again. Yeah or Nay? If yes, I'm not sure I can do it.

G

gnhb

I submitted a new patch set to coreteam@ . . . It seems stable. I tested it for a few hours to work out little issues.

I implemented interface renaming and that simplified the new code a lot, so that's nice. Now ppp interfaces start with ppp0 and go up as you add more.

Also, the ppp-linkdown script is an open issue. This patch refers to the script that Ermal wrote in the /usr/local/sbin/ directory, but I couldn't test it b/c my mpd5 binary doesn't pass the DNS servers the same way the newly(and previously) patched binary does(did).

And the uptime tracking is still an open issue. I've figured out how to do it, but haven't done anything yet. This patch set is getting big and taking time to manage all the parts so I decided to cut it here and do the uptime stuff in the next round.

I'll do the SIM pin thing too in the next set. I just need a break for a day. :)

I'm already experiencing much smother conditions with mpd5 for PPP on 3G than I was with userland ppp. It's very nice.

I also thought there might be a worthy use case for implementing a check box for "dial-on-demand" and text field for "idle timeout."

Thanks,
G

eri--

Can you put the patch here or in a ticket on redmine.pfsense.org.
It is easier to track and can get more review.

Regarding dns i modified mpd5 to restore old behaviour to pass dns1 $ip as different arguments, it should be on updated snapshots.

gnhb

patches
http://redmine.pfsense.org/issues/show/447

gnhb

Hi Ermal,
I'm curious why you modified them mpd5 code to change the behavior of the dns servers being passed as two fields.

The ppp-linkup script is easy enough to modify, and then the mpd5 behavior doesn't conflict with the documented mpd5 behavior. Anyone in the future who touches that code in the future is now going to be confused b/c of the inconsistency with the documentation.
For what it's worth, I vote for keeping the behavior consistent with the docs, and modifying the scripts.

Gabriel

eri--

Patches accpeted.

ryates

As someone who very idly tinkered with a hsdpa modem, my thanks to gnhb for these efforts….

sgray

Hey guys,

I understand there has been some overhaul of the ppp implementation recently. After much work, I was able to get the 2.0 beta (prior to recent changes) to work with my Aircard 881 HSPA modem using both AT&T and T-Mobile providers. I am attempting to test the newest beta build, which includes the changes to PPP, and I cannot get a connection.

Only reason I am testing the new build is because the DynDns service doesn't update as it should when using 3G as WAN (and only gateway to internet) on the old 2.0 beta I am currently running. The only way I can get DynDns to update (without dropping to a command line) is manually via the web interface by opening the Dynamic DNS config page and just simply hitting "save" again. Otherwise, it will just sit and show an old IP address in red. Reboots have no affect. ALSO, if I do update manually and the IP address changes in the future, it still won't update on it's own.

On the prior implementation, I only had to define the "dial command", "phone number", and "line speed" fields. They were defined as follows:

DIAL COMMAND: "TIMEOUT 4 "" AT OK ATDT\T TIMEOUT 20 CONNECT"
PHONE NUMBER: *99#
LINE SPEED: 921600

Given the simple config required to successfully connect on the old implementation of PPP, why am I having so much trouble getting it to work on the new implementation? I wish there were an easy way to see the actual/live config from behind the scenes without having to drop to a command line. (For example, being able to see what is ACTUALLY being sent to the modem for dial string, etc.)

cmb

The DynDNS issues you noted have all been resolved. All the 3G cards we have access to still work. Paste your PPP logs.

gnhb

Hi,
If you only filled in Dial cmd, phone, and line speed on the old config then all you have to fill in on the new config page is phone number. That's it! (well, except to select the correct serial port.)

Check your logs. They will tell you if the chat script doesn't succeed and on what command it fails, otherwise it will look like this (bottom line is first):

May 1 22:00:16 wan: [lnkwan] MODEM: chat script succeeded
May 1 22:00:16 wan: [lnkwan] chat: Connected at 7200000.
May 1 22:00:16 wan: [lnkwan] chat: Dialing server at *99#…
May 1 22:00:16 wan: [lnkwan] chat: Detected Sierra Wireless Compass C885 USB 3G modem.

sgray

The FIX lies in the port config. In the old config, I had to use cuaU0.0. In the new config, I have to use cuaU0.2.

Has the driver changed in the new beta as well? I would not have thought that the data/command ports would have shifted for the same device, unless the driver changed. Does the new ppp program use a different port config than the last one?

gnhb

Those ports only change if you have more than one USB 3G modem plugged into your box simultaneously. If your device presents 2 ports to the OS, then the first one you plug in will get cuaU0.0 and cuaU0.1 and the second will get cuaU0.2 and cuaU0.3.

In rare cases, I've seen the OS fail to remove the cuaX ports when a device is unplugged and the next time you insert it it will get the next higher port numbers. I only saw this in testing during development when netgraph was still hanging onto the cuaU.X ports even when I removed the device (because I was misconfiguring mpd5), so I wouldn't expect to see this in normal operation b/c I'm pretty sure I ironed out most of the bugs. :)

If you reboot, check the port assignments again.