Next Previous Table of Contents
Did you read the this manual carefully? Here are once more the most common pitfalls.
/etc/ppp/options
file exists and that it doesnīt contain any conflicting entries. If in doubt: Leave this file empty.
/dev/modem
may cause some conflicts.
Eliminate this source of trouble by using the real device, i.e. /dev/cuaX
or /dev/ttySX
.
NOTE: COM1 equals ttyS0, COM2 is ttyS1 and so on. If nothing helps, you might obtain some debugging info from your systems log by issuing:
# tail /var/log/messages
This means that kppp doesn't have permissions to open the modem
device or that you selected a modem device on the Modem Tab Dialog that is
not valid. First make sure you selected the right modem device. Once you are
sure you have selected the right modem device, you must
give kppp the right permission to access the modem
device and to be able to modify /etc/resolv.conf
in case you want kppp to
configure DNS correctly for you. If you can afford to run kppp setuid root
this would solve all access problems for you, if not you will have to figure
out what the right permissions are for your purposes. In order to give
kppp setuid root permissions do the following:
% su root
# chown root:root ${KDEDIR}/bin/kppp
# chmod +s ${KDEDIR}/bin/kppp
# exit
This in most instances means that you have installed kppp
without SETUID bit on while you, the person executing kppp,
doesn't have write access to the lock file directory which
by default is /var/lock
. This for example is the case on
Red Hat systems. Check the modem dialog for the
precise location you have chosen. The solution is easy --
either run kppp SETUID if you can afford to, or give regular
users write access to /var/lock
or create a modem group
that will have access to the /var/lock
file.
There is no need for the SETUID bit, if you know a bit of Unix systems
administration. Simply create a modem group, add all users that you
want to give access to the modem to that group and make the modem
device read/writable for that group. Also if you want DNS configuration
to work with kppp, then /etc/resolv.conf
must be read/writable by the
members of that group. The same counts for
/etc/ppp/pap-secrets
and /etc/ppp/chap-secrets
if
you want to use the built-in PAP or CHAP support, respectively.
Please do not criticise me for installing kppp with setuid bit on, I simply can no longer handle the amount of mail I used to get from desperate users who had problems getting kppp to work because they didn't understand enough about Unix and device permissions.
The kppp team has lately done a lot of work to make kppp setuid-safe. But it's up to you to decide if you install and how you install it.
You might also want to read the Security section.
You probably have activated the Auto-configure hostname option and the X Server has problems connecting to your newly named host. If you really need this option (chances are that you donīt) you are on your own to setup the appropriate authorisations. Issuing xhost + before starting the connection would do the job, but be warned of any security risks that involves since everyone else is granted access to your X Server.
Another source of trouble (note to Red Hat users): one of the pre-installed
network scripts might be playing tricks on you. Rename /etc/ppp/ip-up
to stop pppd from executing it automatically on every connection.
Try pinging another server by its IP number, e.g. ping 195.0.254.76
. If that
works you should
/etc/host.conf
. There should be a line
saying something similar to order hosts, bind
. The bind
keyword advises the resolver library to include a name server query when
performing an address lookup.
Just send an empty string such as in the following script:
Send # send an empty string
Expect ID:
Send itsme
Expect word:
Send forgot
Expect granted
Send ppp
This means that you don't have permissions to create a lock file. If you chose to use a lock file you must have write permissions to the directory (typically /var/lock). This is of course no problem if you have given kppp setuid permissions. Please read the section on lock files .
Click on "Setup", "Modem". You can control the modem volume here in three steps: off, medium and high. For most modems "medium" and "high" result in the same volume. If that doesn't work, make sure that the correct settings for your modem are specified in "Setup"/"Modem"/"Modem commands"!
The volume initialisation string can get lost if your modem can't cope with the speed it revives its command from kppp. Increase the value of "Post-Init Delay" in "Setup"/"Modem"/"Modem commands"!
Click on "Setup", "Modem". You can control the modem volume here in three steps: off, medium and high. For most modems "medium" and "high" result in the same volume. If that doesn't work, make sure that the correct settings for your modem are specified in "Setup"/"Modem"/"Modem commands"!
Many modems only report the speed of the serial line and not the speed over the telephone line as default. You must configure these modems to report the true line speed (add to modem init or dial string). For many modems this command is "ATW2". If you want to add it to the dial-string (typical "ATD"), the new dial string would be "ATW2D".
New modems often have very complex connection messages like "CONNECT LAP.M/V42.bis/115000:RX/31200:TX", and kppp cannot parse this message correctly. Turn on "Show Log" and you'll see the connection speed. I'm currently working on a solution for this, and the parser is now much better, but still not perfect.
If you are not satisfied with the modem speed, make sure you've set the connection speed ("Setup" / "Device" / "Speed") to 57600 or higher. Make sure that your serial ports support higher speeds. Many systems based on i486 do not work correctly when you set the speed to 115200. If you have a 8250 UART chip, it won't work. If you have a 16550 or 16550A it should work flawlessly.
Additionally, consult your modem manual to look for init strings that enable a high speed mode.
If data drips in at a rate of just a few bytes per second you should check your hardware setup. If moving your mouse speeds up the transmission this is definitely a hardware issue.
Obtain some information about your serial port with
setserial -a /dev/ttySx
and check for interrupt conflicts with other
components of your system.
You must modify you modem dial string. Nearly all modems support the following AT-commands:
Did you compile it or the libraries with gcc-2.8? This version of gcc is somewhat broken, and it will not work as expected.
Just follow the TEMPLATE rules files supplied with kppp. You should be
able to find a copy in the ${KDEDIR}/share/apps/kppp/Rules
.
Use the -r
kppp command line options to check the syntax of your proposed
rules file.
I would love to receive any rule files written. I will make them available on my kppp web page. Before you send me a new rules file make sure it is not already available on the kppp web page. Then email the new rules file one of the current maintainers.
Yes this is possible. But you should not use unusual small time units (below tenth of a second), because this would result in higher CPU load (though I doubt you'll notice with a modern CPU :-)
In that case you need to write new code that allows for the computation of that holiday. Please have a look at ruleset.cpp and emulate the ``easter'' example. Then send us the patches.
Uncheck the "Modem Asserts CD Line" option you will find on the Modem tab. Your hardware seems to be missing support for sensing the "Carrier Detect" line.
The PPP daemon didn't get into contact with the remote server in time. Listed below are a few hints that helped several users:
Put X3 into your dial string, e.g. ATX3DT.
Short answer: You haven't started the PPP software on the peer system.
See a posting from Al Longyear on http://www.dejanews.com/getdoc.xp?AN=184945314 for a more detailed explanation.
If you see the following lines you've probably just received a timeout error from kppp, too. kppp has been waiting for the PPP interface to come up and gave up after the specified timeout. pppd was signaled to shut down with signal number 15, i.e. SIGTERM.
pppd[26921]: pppd 2.3.5 started by me, uid 500
pppd[26921]: Using interface ppp0
pppd[26921]: Connect: ppp0 <--> /dev/ttyS0
pppd[26921]: Terminating on signal 15.
pppd[26921]: Connection terminated.
pppd[26921]: Exit.
The PPP daemon is alarmed by the fact that all data it receives has bit 8 set to zero. In most cases this simply indicates that the remote PPP server isn't running yet. You might be still confronted with a login prompt that echoes back all data sent by your pppd.
Do you get the following messages ?
modprobe: can't locate module ppp-compress-21
modprobe: can't locate module ppp-compress-26
modprobe: can't locate module ppp-compress-24
Just add the lines
alias ppp-compress-21 bsd_comp
alias ppp-compress-24 ppp_deflate
alias ppp-compress-26 ppp_deflate
to your /etc/conf.modules file.
Next Previous Table of Contents