Sunday, October 19, 2008

Configuring Persistent PPP under Ubuntu

(This post is the 4th part of my Ubuntu Linux Router Upgrade Project.)

After my last post, Alltel UM175AL USB EVDO under Ubuntu Hardy Heron, I now have a usable serial device to connect to with PPP.

Initial Trials

At this point, Jason Costomiris's instructions at HOWTO: Verizon UM175 USB EVDO Card under Ubuntu Hardy work perfectly. The only difference is that being on Alltel instead of Verizon, the username is "<Modem'sPhoneNumber>@alltel.net", and the password is "alltel".

Disabling NetworkManager

The next improvement is to upgrade the NetworkManager utility that is part of the ubuntu-desktop package, in order for it to recognize and work with the CDMA connection. This is detailed in Jason's next post, Using NetworkManager with Pantech UM175 under Ubuntu Hardy, and allows NetworkManager to respond with the proper connection status when queried by other applications. This also makes it easier to establish the connection automatically.

Unfortunately, NetworkManager does not play well with the goals of a server or router configuration. As listed on its package page at http://packages.ubuntu.com/hardy/base/network-manager:

NetworkManager attempts to keep an active network connection available at all times. It is intended only for the desktop use-case, and is not intended for usage on servers. The point of NetworkManager is to make networking configuration and setup as painless and automatic as possible. If using DHCP, NetworkManager is _intended_ to replace default routes, obtain IP addresses from a DHCP server, and change nameservers whenever it sees fit.

As suggested, I disabled NetworkManager. There are instructions at https://help.ubuntu.com/community/NetworkManager#Disabling%20NetworkManager. However, at least under 8.10 (Intrepid Ibex), placing the "exit" scripts in "/etc/default" didn't have any effect. Instead, I just disabled the startup scripts, by calling "update-rc.d -f NetworkManager remove" (again, using sudo).

The next step is to manually configure the network settings in "/etc/network/interfaces". (See "man interfaces" for details.) Primarily, ensure that the desired interfaces are brought up automatically on startup (using the "auto" stanza), and for the purposes of a router, assigning the internal interface a static IP address:

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
address 192.168.###.1
netmask 255.255.255.0

pppd Configuration

This is fully documented in the pppd man page. You could even use pppconfig to help with the initial setup, but I opted to work with the actual configuration files directly.

Here is what I saved as "/etc/ppp/peers/Alltel":

/dev/ttyACM0
lock

persist
#debug
hide-password

noauth
user ##########@alltel.net

defaultroute
#usepeerdns #Using bind9 instead.

init "/usr/bin/logger -i /etc/ppp/peers/Alltel Calling..."
connect "/usr/sbin/chat -Vf /etc/chatscripts/Alltel 2>/var/log/Alltel.log"

Here is what I saved as "/etc/chatscripts/Alltel":

ABORT 'BUSY'
ABORT 'NO CARRIER'
ABORT 'ERROR'
'' 'AT'
'OK' 'ATQ0V1E0'
'OK' 'ATZ'
'OK' 'AT&F'
'OK' 'AT+CSQ'
'OK' 'ATDT#777'
CONNECT CLIENT

This and other chatscripts are used by and documented in chat.

Finally, the password for the user identified in the peers file needs to be added to "/etc/ppp/pap-secrets":

"##########@alltel.net" Alltel "alltel"

The connection can then manually be initiated using "pppd call <name>", where "<name>" is one of the scripts configured under "/etc/ppp/peers". Note that the "nodetach debug" options are only to diagnose the initial connection, and the "nodetach" option will prevent the call from returning. (Closing the terminal window will disconnect the connection.) Note also that this needs to be run with "sudo" otherwise pppd won't have access to the above configured scripts, which should also be saved with restricted permissions to "root" (or another restricted user account).

$ sudo pppd call Alltel nodetach debug
Serial port initialized.
Serial connection established.
using channel 34
Using interface ppp0
Connect: ppp0 <--> /dev/ttyACM0
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x63dc86e0> <pcomp> <accomp>]
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x63dc86e0> <pcomp> <accomp>]
rcvd [LCP ConfReq id=0x1 <asyncmap 0x0> <auth chap MD5> <magic 0xfd80aab9> <pcomp> <accomp>]
sent [LCP ConfNak id=0x1 <auth pap>]
rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0x63dc86e0> <pcomp> <accomp>]
rcvd [LCP ConfReq id=0x2 <asyncmap 0x0> <auth pap> <magic 0xfd80aab9> <pcomp> <accomp>]
sent [LCP ConfAck id=0x2 <asyncmap 0x0> <auth pap> <magic 0xfd80aab9> <pcomp> <accomp>]
sent [LCP EchoReq id=0x0 magic=0x63dc86e0]
sent [PAP AuthReq id=0x1 user="##########@alltel.net" password=<hidden>]
rcvd [LCP EchoRep id=0x0 magic=0xfd80aab9]
rcvd [PAP AuthAck id=0x1 ""]
PAP authentication succeeded
sent [CCP ConfReq id=0x1 <deflate 15> <deflate(old#) 15> <bsd v1 15>]
sent [IPCP ConfReq id=0x1 <compress VJ 0f 01> <addr 0.0.0.0>]
rcvd [IPCP ConfReq id=0x1 <addr ###.###.###.###>]
sent [IPCP ConfAck id=0x1 <addr ###.###.###.###>]
rcvd [LCP ProtRej id=0x4 80 fd 01 01 00 0f 1a 04 78 00 18 04 78 00 15 03 2f]
Protocol-Reject for 'Compression Control Protocol' (0x80fd) received
rcvd [IPCP ConfRej id=0x1 <compress VJ 0f 01>]
sent [IPCP ConfReq id=0x2 <addr 0.0.0.0>]
rcvd [IPCP ConfNak id=0x2 <addr ###.###.###.###>]
sent [IPCP ConfReq id=0x3 <addr ###.###.###.###>]
rcvd [IPCP ConfAck id=0x3 <addr ###.###.###.###>]
Cannot determine ethernet address for proxy ARP
local  IP address ###.###.###.###
remote IP address ###.###.###.###
Script /etc/ppp/ip-up started (pid 12340)
Script /etc/ppp/ip-up finished (pid 12340), status = 0x0

Once the connection is successfully established without "nodetach", there doesn't appear to be a "hangup" option to pair with "call". It seems that using "kill" to kill the associated pppd process is the most common approach. The "pon" and "poff" scripts may also be used, but internally, "poff" just calls "kill" as well.

Integrating with /etc/network/interfaces

By adding a reference to the above pppd configuration in "/etc/network/interfaces", the connection can be easily managed like any of the other interfaces with commands like "ifup" and "ifdown" (both of which are actually the same program, but called with different names).

auto ppp0
iface ppp0 inet ppp
 provider Alltel

Bringing up the connection then yields an error:

$ sudo ifup ppp0
ppp0: ERROR while getting interface flags: No such device

While this doesn't look good, the connection is actually successfully established. This can be verified by seeing a connection for "ppp0" using "ifconfig". Calling ifup with the "-v" flag for verbose mode shows some detail as to where the error is occurring:

$ sudo ifup -v ppp0
Configuring interface ppp0=ppp0 (inet)
run-parts --verbose /etc/network/if-pre-up.d
run-parts: executing /etc/network/if-pre-up.d/vlan
run-parts: executing /etc/network/if-pre-up.d/wireless-tools
ppp0: ERROR while getting interface flags: No such device
run-parts: executing /etc/network/if-pre-up.d/wpasupplicant
pon Alltel
run-parts --verbose /etc/network/if-up.d
run-parts: executing /etc/network/if-up.d/avahi-autoipd
run-parts: executing /etc/network/if-up.d/avahi-daemon
run-parts: executing /etc/network/if-up.d/ip
run-parts: executing /etc/network/if-up.d/mountnfs
run-parts: executing /etc/network/if-up.d/wpasupplicant

It is actually due to the "wireless-tools" script, apparently on line #11 where it calls "$IFCONFIG "$IFACE"" up". It seems that "$IFACE" resolves to "" at this point, as the "/etc/network/if-*up.d/" scripts are called before pppd actually brings up the connection's interface. The entire script could probably be selectively disabled, but it isn't hurting anything for now.

At another point, I added a link to an iptables script in "/etc/network/if-up.d/". Similar to the above situation, "ppp0" isn't yet available at this point. The script called ifconfig to determine ppp0's IP address, which resulted in the following error:

ppp0: error fetching interface information: Device not found

That's it. At this point, I have a functional, persistent Internet connection over PPP for the local computer.

To be continued...

Next up: Enabling routing and NAT with iptables.

9 comments:

Lee said...

Would this same method work for using an Alltel phone as a modem?

Mark A. Ziesemer said...

Lee - The notes in this post should work with any modem-type device that can be used with PPP. The challenge may be getting your phone recognized as a valid TTY device that can be used by pppd. See the previous post for an example of what this might involve.

brian said...

I am trying to use my alltel usb plug and play modem um175 on my mini9 with ubuntu could somone tell me how to make it work?

Mark A. Ziesemer said...

Brian - it sounds like you're using the same hardware as I am, and I can only guess at what version of Ubuntu you're using. I and probably others are more than willing to help, but we'll need specifics as to what you need. What are the details of any issues you're having? What have you already tried?

Have you read through not only this post, but the ones leading up to it, specifically the previous one - Alltel UM175AL USB EVDO under Ubuntu Hardy Heron?

I'd recommend making a new post - including details - at the Networking & Wireless thread on ubuntuforms.org. Optionally include a link to this page. Add another comment here with a link to the thread you started to get my attention. Then we and others can work to solve your issue there.

Shyam Jude said...

Hi Mark,

I wanted an advice from you to solve this issue of mine. I am a newbie to Linux. My first task was to set up Internet connection with the GSM Modem i have and i made it by using ppconfig. The issue is when the connection is established if i try to send a message using AT commands from the modem i see no response for the reason that both are accesing the same tty device(ttyUSB0) in my case(I mean GPRS as well as the GSM Message). So is there any ways where i can send SMS as well as GPRS enabled at the same time.


Many thanks,
Jude.

Alan Murray said...

The current behaviour with udev is that interfaces marked auto in /etc/network/interfaces are told to ifdown when udev detects that the connection has terminated. With pppd this causes it to be sent a TERM signal causing pppd to end and breaking the persistent properties of the connection.

Due to this it is best not to mark ppp interfaces auto.

Mark A. Ziesemer said...

Thanks, Alan. I had actually ran across your blog post (http://rants.atmurray.net/2007/01/pppd-persist-not-so-persist-with-udev.html) while looking into the issue you mentioned, but not before starting my own thread on the Ubuntu forums: http://ubuntuforums.org/showthread.php?t=1177021.

I still wanted the PPP interface marked with auto so it can participate in other automatic operations. I had used the work-around proposed by user woltion in the forum thread: Editing the 85-ifupdown.rules script to use "--allow hotplug" instead of "--allow auto".

Bearcat M. Sandor said...

Thank you so much for these great blogs! This has really helped me in the continuing set up of my um175 with alltel. I note that the unit shuts down and reconnects once every 12 hours or so, i presume to refresh the ip. I believe there is a string you can send it via AT commands to make it stay up indefinitely. Do you happen to know what that string is?

Mark A. Ziesemer said...

Bearcat - sorry, but I don't think there is anything you can do about the disconnections. As it appears that you're using Alltel as I had been, you're being forcefully disconnected by them after a hard 12-hour timeout.

See also: http://blogger.ziesemer.com/2009/07/alltel-wireless-internet-update.html.