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

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.

sgray

There were no hardware changes between changing from the previous 2.0 beta to the current one. And I have changed it back and forth twice, each time wiping the drive and installing fresh. Although I backed up the config, I did not restore it. I configured everything from scratch.

There is only one 3G device (also no other modems or usb devices) installed in the entire system and it is that Aircard 881. It is cardbus, but my understanding is that the card has an internal usb controller and the modem connects to that.

With the old beta on this box, the following ports were listed in the PPP webgui:
/dev/cuaU0.0
/dev/cuaU0.1
/dev/cuaU0.2
/dev/cuaU0.3
/dev/cuau0
/dev/cuau1

With the new beta on this box, the following ports are listed in the PPP webgui:
/dev/cuaU0.0
/dev/cuaU0.1
/dev/cuaU0.2
/dev/cuaU0.3

After reboots, everything is the same as it should be.

cmb

@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?

Depends on what version you started with. In January we moved from FreeBSD 8.0 to RELENG_8 (8.1).

sgray

@cmb:

Depends on what version you started with. In January we moved from FreeBSD 8.0 to RELENG_8 (8.1).

I have been running build 20100322. Before that, I was running 20091212. I had no issues in the switch to 20100322 and the same ports were still present and cuaU0.0 was still the port that worked. The switch from 20100322 to one from a few days ago required me to use cuaU0.2.

cmb

There have been several date bumps on RELENG_8 between March and now, something must have changed there in FreeBSD for your card.