RH7 - ppp error
dugan at passwall.com
Sat Apr 21 12:21:28 PDT 2001
Last few times I have worked with people to try to resolve
networking/connectivity issues over e-mail, they ended up being these long
and massive threads. (I was told some people left the list shortly after
them.) I can take a stab at this, and if it starts to get too detailed, we
can take this off-list so as to not cause problems with other people's
mailboxes becoming filled.
These kinds of problems are best solved in person IMHO, because the next
course of action often depends on the results of the previous results
*and* many different tests are often conducted leading to lots of traffic.
I don't know your level of sophistication, so I am targetting a general
course instead of a condensed, or specialized one.
General diagnosis for connections often starts with examining the physical
connections. (You know the whole tech support routine... "Is it plugged
in?", "Have you installed any new hardware since the time that your system
stopped doing the ppp-connection thing with your modem?" etc.) I'll assume
you checked all of the physical connections, but would still like to hear
the answer to the second question above.
Next, if you have a dual boot system, see if the other OS can talk to the
hardware (In this case the modem.) Also note what COM port/IRQ and if
possible what IO address the modem is using. (example: COM1 uses IRQ4, IO
0x03f8. You can check to see that linux thinks you have the same settings
as windows with:
# setserial /dev/ttyS0
# setserial /dev/ttyS1
etc for each of your serial ports installed.)
Be careful to not add settings to the setserial command unless you know
what you are doing. Just asking for the settings as above should be safe.
If another OS can talk to the modem, then check in linux to see if you can
also talk to the modem. (I like to use "minicom" but nearly any terminal
software in linux should work. Simple commands like "ath" to hang up the
phone should be followed by "OK" on most modems by default. (Exceptions do
exist however but are uncommon so YMMV.)
If you can enter "ath" and see an "OK" then it is very likley your serial
ports, IO addresses and IRQs used by your modem(s)/serial port(s) were
detected by Linux and have been configured to be addressed. If you do not
see this, then there are steps for checking your serial ports and if
necessary configuring them. (IE if you have 4 serial ports with IRQs
2,3,4,5 and "normal" IO ports then you may need to modify the serial port
setup to use IRQ 2 and 5 for ttyS2 (COM3) and ttyS3 (COM4) etc.)
If minicom works in talking to your modem, then check the settings for
your ppp dialup to make sure it is talking to the right serial port. (As a
guess, newer bits of dialup software may look at /dev/modem and see what
it points to. (symbolic link often pointing to /dev/ttyS? where "?" is
often a number from 0-3 for COM1-COM4.) If your /dev/modem points to the
same COM port found while in windows or other OS that is able to talk to
your modem, that is a good sign.
My primary experience is with Debian installations, and I don't know as
much about RedHat installs. I would assume there is a bit of software
included with RedHat like "pon/poff" and "pppsetup" or "pppconfig". They
allow you to answer a few questions like "where is my modem? ttyS0,1,2,3?"
, "Do you use "PAP, CHAP, or ? authentication" etc. You may want to check
to see what settings you presently have configured for your dialup
settings. Is the ppp config software talking to your modem?
shows ppp is loaded, then that is a good sign. However, the error message
on the "slhc" suggests that slhc (Serial Line Header Compression) may not
be a compiled module from the same kernel version/mark you are using right
now. Have you upgraded kernels recently? Did you compile it on your own?
Did you remember to
# make modules
# make modules_install
# depmod -a
after you made your new kenrel and installed it? (Only need to do these
if you actually compiled and configured your own kernel. If you did not do
this, then the above would have been done by the package maintainer.)
(It appears as though slhc.o deals with the whole von Jacobson PPP header
compression. Sometimes this is referred to "PPP Compression" or "PPP
Software compression" as an option in other OSes. Lack of this may be a
problem if your pppconfig file is set to use von Jacobson header
compression. This can be disabled in the ppp options file. The options
file is found in /etc/ppp/ on debian as "/etc/ppp/options" scroll down
this file to a point where you can find something like:
# Disable negotiation of Van Jacobson style IP header compression (use
# default, i.e. no compression).
If you wish to disable von Jacobson header compression take out the
"#" and make it read:
The above however, would be a kludge to be used in just testing and
diagnosing. If it seems to work without vj compression, then I would look
to try to get a new kernel and modules with a new slhc module.)
Also, you may want to check out /var/log/messages or /var/log/daemon.log
with tail when you try to dialup. Many bits of dialup software log their
connection messages through a logging daemon or to a debug file. If a ppp
dialup script is used, /etc/ppp/options also includes a "debug" option and
"kdebug" option with debug levels. (Higher numbers create more garbage -
ahem... information in your log files and smaller numbers, less. Try
numbers like 1 through 3 at first and then progress higher. Usually, a
"1" answers most general questions.)
One good way to do this log checking in "real time" ;-) is to "tail" the
log file. Open up a second "extra" xterm or screen, or console and try:
# tail -f /var/log/messages
(or whatever file you want to "watch")
To stop watching the log file for changes press control-c (^c)
The above periodically watches the end of the log file and prints to that
console/screen/xterm "new" messages that have been added to the end. It is
very useful in cases like these. Often it will tell you useful information
like: "bad username", "bad password", or if debug levels are set in the
chat scripts, places where your chatscript had to bail out on you.
Try some of the items above and let us know where you get stuck, or if you
get stuck. Inclusion of log files is nice BUT *please* edit parts of the
log file included down to only include the messages posted during the time
of your test connection with PPP to your ISP. (No need to have a multi
megabyte file passwed into everyone's mailbox.)
One last thing - if you are trying to use channel bonding /
modem-load-balancing with eql or slirp or ? most do not support vj header
compression with PPP and you need to manually disable it. If you do not
know what these are, then you probably dont use them and can ignore this
On Fri, 20 Apr 2001 cdlcruz at sonic.net wrote:
> I keep getting e-mail in windoze that I have to upgrade something on my RH
> machine, but cannot get online with it anymore. It worked until about a week
> ago; I made no changes, but I can no longer dial anywhere.
> Reinstalling the number for sonic.net and running debug sends me
> to /var/log/messages where I find: this system lacks kernel support for ppp
> and instructions to run "/sbin/modprobe -v ppp"
> That gets me the following : /sbin/insmod lib/modules/2.2.16-22/net/slhc.o
> Symbol version prefix ''
> /sbin/insmod /lib/modules/2/2/16-22/net/ppp.o
> using /lib/modules/2.2.16-22/net/ppp.o
> Huh?? Can someone explain to me in plain english what I need to do to get
> back online?
> Catherine de la Cruz
More information about the talk