WvDial Frequently Asked Questions

Originally written by Dave Baker

Table of contents [ hide ]

Abstract

This is the FAQ for WvDial, the intelligent internet dialer for Linux. Use this document if you want to learn to use and troubleshoot WvDial.

Preface

This FAQ was written in conjuction with the WvDial MailingList. Normal disclaimers apply. This document should be considered to be in permanent development and subject to change.

Feedback on the FAQ should be sent either directly to the author or to the mailing list at wvdial-list@lists.nit.ca. To subscribe to the mailing list send a mail to wvdial-list-request@lists.nit.ca with subscribe as the only word in the subject line. The list is really low volume (a handful of messages a week) and none of us bite.

It should also be mentioned that since creating this FAQ I switched to using a cable modem. If anyone would like to adopt the FAQ I'll be happy to hand over the reins; if not, I'll be equally happy to keep it updated as I have been doing so far.

Where to get it

WvDial is available in source form and packaged for several distributions. You can get the latest version from DownloadReleases.

Debian

  1. apt-get update && apt-get install wvdial

Package information: http://packages.debian.org/wvdial

Redhat, Mandrake, SuSE, etc

Try rpmfind at http://rpmfind.net/linux/rpm2html/search.php?query=wvdial

Others

Use the Source, Luke.

(If anyone has details on pre-packaged binaries for other distributions, please add them to this FAQ).

Quick Start

Assuming everything works perfectly, the following will get you on-line if you're running as root.

  1. wvdialconf /etc/wvdial.conf
  2. vi /etc/wvdial.conf
    • edit username/password/phone
  3. vi /etc/resolv.conf
    • edit nameservers
  4. wvdial

Questions & Answers

Command not found?

Note that the executables wvdial and wvdialconf are installed in /usr/local/bin by default. Under some distributions (Redhat is one) this is not in root's path, but is in a non-root users path. If you try running wvdial and it reports "command not found" then either:

  • Add /usr/local/bin to your path.

    How to do this depends on what shell you use, but typically you set $PATH to be $PATH:/usr/local/bin by making the appropriate changes to /root/.bashrc or /root/.cshrc.

  • Specify the full path and filename when running the command.

  • Change directory to /usr/local/bin and running the command as ./wvdial (note the leading period - your current directory should not be in your executable search path for security reasons.)

What nameserver should I use?

If you're migrating from a Windows environment you may find yourself without a nameserver that you're aware of. Certain extensions to the PPP negotiation protocol provided in some Windows dialers allow it to be told what the IP address of the nameserver is - these only work under Linux in fairly recent (how recent?) releases of pppd.

  • Ask someone at your ISP's technical support department.

  • If you can dial up under Windows it may be possible to determine the nameserver being used from the TCP/IP configuration panels. If you can run the winipcfg program and select "More Info" you should see the details you need.

  • Use a well known nameserver to look up the IP of your local nameserver.

    For example, using the IP of a known nameserver (in this case we'll use ns1.sprintlink.net) we type: host -t ns earthlink.net 204.117.214.10

    This will return a series of lines, each one listing the domain, the letters NS (nameserver) and the hostname of the nameserver. We now run a host lookup no those addresses to get the actual IP addresses to use in our /etc/resolv.conf file.

  • Set your linux machine up as it's own nameserver. Redhat has a caching-nameserver package to do exactly this. Older versions of bind used to cause significant delays in timing out lookups when off-line, although this seems to have been fixed.

It dials and then pppd dies for no reason.

  • Check the log file! It will typically be found as /var/log/messages or /var/log/ppp.log depending your distribution. Scan to the end (or use tail) and look for anything marked pppd. Do not send the complete file when asking for help!

  • Check the /etc/ppp/options file. If you set up pppd before and added any lines in here you may well need to take them out due to the way WvDial accesses pppd.

  • Use the script command to capture the exact output when wvdial runs. Often an important error message will scroll off the screen too quickly to read.

  • Check you're using the correct username and password.

What if I don't want to run wvdial as root?

First, WvDial should not be run as root because that means you've logged in as root! There are a few ways to get around this and make WvDial available to the normal user.

  • Make wvdial itself suid root. This is not recommended but is the quickest, easiest fix. It also gives Avery and Dave nightmares. Try not to do it. If you must do this, then at least only allow a limited group execute rights to the executable (Debian has a dialout group for this very purpose).

  • Although more secure than the above, specific details of the best alternative has yet to be discovered that will work with all the various system configurations. Basically the user needs read (and perhaps write) access to the serial device being used, the wvdial.conf file and also to certain portions of the /etc/ppp directory. If you would like to explore this safer alternative, hopefully with a view to correcting the FAQ, check the mailing list archive, join in on the mailing list discussion and let us know what works best for you.

What if I don't want to tie up the terminal session?

You can run wvdial in the background. I use the following scripts, simplified for this example.

/usr/local/bin/netup

#!/bin/sh
wvdial "$*" &

Note the $* is substituted by the entire argument list passed to netup. Thus I can execute netup quiet, and have the script pass the quiet parameter to wvdial in order for it to read from a different configuration block.

/usr/local/bin/netdown

#!/bin/sh
killall wvdial
sleep 2
echo ""

Note the sleep and echo just tidy the screen a little since it takes pppd a second or so to die nicely. This will not work if you run multiple instances of wvdial (two modems, for example) nor will it work if one non-root user tries to terminate a session started by another user.

Interfacing to graphical ppp dialers

Depending on the interface, you may be able to run the scripts above. I don't use a graphical ppp interface except to see data throughput rate (gkrellm has a built-in module to do this) so haven't explored this much. You might want to look into kwvdial if you have the KDE libraries available.

What about WinModems?? Plug and Play? PCI modems? Multiport?

If you have/bought a WinModem? you're pretty much out of luck. Take it back to the store if you can and spend a little more cash for a real modem! These modems used to never work under Linux, but now there is at least a light at the end of the tunnel. Visit http://www.linmodems.org for details of how you might be able to get it to work. Also see the recent (as of Feb 2001) news of IBM releasing GPL drivers for certain, older winmodems.

If it's a plug and play modem try using the isapnptools package to configure it. If you can find it, wvdial can use it. Often a tool such as minicom will be helpful here to reduce the turnaround time for making changes to the serial configuration.

If it's a PCI modem you're probably in for a wild ride trying to get it to work. There is provisional support for these in the newer kernels so you might strike lucky if you happen to have a supported model. Try http://atrey.karlin.mff.cuni.cz/~mj/pciutils.html to help you get started.

I've not used a multiport modem under Linux for several years but if yours is supported there should be no trouble in using it. You will probably need to create /etc/wvdial.conf entirely by hand if you don't want to edit wvdialconf to look at a different range of devices to probe.

I use AOL.

What should I do?

No linux dialer I know of will access AOL. There are reports of using early AOL software under WINE/WABI to access AOL's content pages when already connected to the internet though. My personal opinion is that you should find another service provider, but I'll leave that choice up to you.

How about CompuServe?, Microsoft Network?

Reports are varied. Some people have allegedly reported success, but I have not seen proof.

I couldn't get wvdialconf to work.

At risk of sounding redundant, let's check you have a modem, it's turned on and plugged in. If that doesn't solve your problem then you probably either have a tricky modem (WinModem?, Plug&Play, PCI Modem) or have an IRQ conflict. IRQ conflicts will sometimes manifest with enormously delayed reaction times to modem commands, or by refusing to respond at all. If you're using an internal modem and your motherboard has serial devices on-board you should disable the one you're using in the BIOS setup (refer to the blurry photocopied page that normally comes with all high quality motherboards for details).

Remember that the /dev/ttyS? numbers are off by one from the COM numbers in the DOS/Windows world. COM1 corresponds to /dev/ttyS0. You should be using ttyS? and not cua? unless you have a very VERY good reason to do otherwise.

There is much debate over the merits of using a /dev/modem symlink in place of the real device. (Technically you can even create a device file named /dev/modem with the correct major/minor but this is definitely discouraged!) Some software looks for /dev/modem first; if all software looks for /dev/modem and you change your modem you only need to reconfigure in one place; if you have any mixup of modem vs ttyS? you'll run into the worst device locking problems imaginable. Try whichever you think you prefer but be aware of the differences!

  • Stuff about setserial, UART numbers etc to go in here*

Dialing more than one provider

\layout Standard

WvDial has a very flexible configuration file that allows it to dial different numbers and authenticate as different users depending on how it is run. One exception to this rule is that it will not (yet) alter the /etc/resolv.conf file automagically according to what system you dial. If you dial up to different ISP accounts you may be able to get away with leaving /etc/resolv.conf the same for each, especially if you're running a local caching nameserver. If you have the situation of dialing either an ISP or a private network (such as the office) you will have to get creative with scripts to copy/edit resolv.conf dynamically. One suggestion is to put some checks in /etc/ppp/ip-up to determine the host at the far end of the ppp connection and act accordingly. You may also want some code in /etc/ppp/ip-down to revert to the previous versions (especially if running a caching local nameserver to avoid offline delays as mentioned previously).

Look at the manual page for details of the [Dialer Default] section and how to use [Dialer whatever] to make wvdial act differently.

Common settings for wvdial.conf

Everybody has different needs for their dialer so this section is just for a few examples that myself or others have found useful. If you want to suggest other options then please let me know and I'll include them if they're not too peculiar.

Call Waiting

Change the phone number from (eg) 555-1212 to *70,555-1212 to disable call waiting.

Voice Mail "Stutter-Tone"

If you have a voice mail that generates a stutter-tone to indicate when new messages are waiting your modem will commonly misrecognize this as a "NO DIALTONE". To correct it you can add ATX3 to your Init line(s). (is this still correct?)

Quiet Dialing

Add ATM0 L0 to your Init line(s) to turn off modem noise.

Other Features

Add an empty dialer section such as [Dialer up] to make it easy to integrate with other scripts that examine a single list of command line arguments. For example "up" may be used to instruct the dialer script to leave the network connection established. By passing the whole string to wvdial to parse this empty section prevents the warning that the section named does not exist.

Contributors

In addition to the meagre work done by myself, the following have given me much information that in one way or another I've mangled into something not quite as precise as they originally intended:

  • Avery Pennarun - apenwarr@nit.ca
  • Patrick Patterson - ppatters@nit.ca
  • James Myles - james@thewebdesk.co.uk
  • Phil Dibowitz - webmaster@ipom.com

Misc. Links