(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:
Would this same method work for using an Alltel phone as a modem?
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.
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?
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.
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.
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.
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".
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?
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.
Post a Comment