We help IT Professionals succeed at work.

How to set up a Dial-In PPP Server

cpak asked
Last Modified: 2013-12-16
I  have Slackware 7 and Zoltrix modem installed.
I'm trying to set up a Dial-In PPP Server starting
 mgetty.  Everytime a client tries to connect to the
PPP server,  I'm getting the following errors in
mgetty log file:

02/20 21:53:52 ##### data dev=ttyS1, pid=139, caller=none, conn='38400/31200 LAP-M', name='', cmd='/usr/sbin/pppd', user='/AutoPPP/'
 02/20 21:53:53 yS1  TIOCMBIS failed: Input/output error
 02/20 21:53:53 yS1  cannot turn off soft carrier:
 Input/output error
 02/20 21:53:53 yS1  tcgetattr failed: Input/output error
 02/20 21:53:53 yS1  cannot get TIO: Input/output error
 02/20 21:53:53 yS1  mg_init_device failed, trying again
 02/20 21:55:24 ##### failed dev=ttyS1, pid=211, got signal 15, exiting

 Here's my login.config

 /AutoPPP/ - a_ppp   /usr/sbin/pppd auth modem refuse-chap require-pap

 Does anyone have the same problems to setup
 a Dial-In PPP Server?

Watch Question

Sounds like you may be using software flow control on the client. Use hardware flow control.

Do you have AT&C1&D2 in you init string for modem


As the estimable Clifford Kite says, "
tcgetattr has always meant that there is another process besides pppd that is contending for the modem IRQ.  Some examples are (1) an ethernet card that used the same IRQ as the modem, (2) a misconfigured ppp script that launched pppd twice, and (3) a mingetty that somehow had been configured for call-in.  "

This means, assuming this modem works for dialout (use minicom and call a BBS or an ISP or something) - if not, check /proc/ioports and /proc/interrupts, make sure you have no irq or port conflicts: then check /etc/inittab to make sure you are not running two gettys
on the same serial port; make sure pppd is not already running on that serial port.  Look at the contents of /var/lock/LCK...ttySx where x is 0 or 1 or whatever the number of the com port you are using for dialin (remember Unix calls com1 ttyS0, etc).  The contents of the LCK.. file shows you the Process ID (PID) of whoever has locked the com port.  then do "ps auxw" and look in the first column for that process ID, and see who's got it, and KILL that process (man kill for details).

cpak: I've just gotten the same log message as this. It happened when the user was disconnected and the pppd on the server side was still trying to communicate. Take a look at the tail of /var/log/messages. For me there's a CHAP authentication failed for user ... right before this log message. If that's the case for you then there's a problem with your pap or chap-secrets file settings(on the server or the client or both)

oops my fault, sounds like you're using pap. Check your /etc/ppp/pap-secrets file on the server side, make sure it's correct. Then make sure that your linux clients have a "noauth" in their /etc/ppp/options file, otherwise they're asking the server to authenticate itself, which by default it shouldn't but can be set up to do so.


tibori:  Actually I setup the client on Window 98 and
PPP dial-up server on linux.  Should the client run on
linux?  I believe the client can run on any platform.
In your previous comments, what are the good examples
of /etc/ppp/pap-secrets and /etc/ppp/options?



The clients can be Windows or Linux, but their setup is a bit different. For Windows machines, you need to set a line like this in pap-secrets(on the server)

login-name server-machine-name password

This is the login name and password that you're using on the Windows client, and the same as you've defined the user and password on the server.

For a Linux client, the client itself sends the machine name and the secret(password) specified in pap-secrets(on the client) so on the server's pap-secrets you need to put in

client-machine-name server-machine-name secret

The secret in this case does not have to be the same as the user's login name, although to avoid confusion that's what I made mine to be.

Now for a linux client to be able to connect you also have to modify pap-secrets on the client side to tell it how to authenticate itself to the server. For that you can just put in

client-machine-name server-machine-name secret

The secrets on the client and the server of course have to match. Also on a Linux client you want to put "noauth" in /etc/ppp/options otherwise you'll have to add an extra line to both client and server's pap-secrets to allow the server to authenticate itself to the client(which is not really necessary, but to be absolutely safe, it's a good idea)
If you want to set that up just have a pair of lines on both the client and the server, one as mentioned above and the second line with the client and server machine names reversed, then you can change the noauth to auth on the client side.
I hope that all made sense, let me know if it didn't. Also take a look at the tail end of your /var/log/messages file on both server and client to know what's going on..why the conecction wasn't successful. If you're having problems let me know what those have in them.

there needs to be a white space between the three fields for the pap-secrets file.

I really don't think this is an authentication problem.  You are not getting a ppp connection at all.  You have (1) a bad serial cable, if your modem is external (2) a misconfigured modem (3) a misconfigured mgetty.   In /etc/inittab, next to the S1 entry, you should NOT have an -r option on mgetty.  You might want to add an initialization string here, such as AT&C1&D2 to make sure the carrier detect signals are correct.  add the following:
/sbin/mgetty -m '"" AT&C1&D2 OK' -x9
to the command line, or change the /etc/mgetty/mgetty.config
and add a

port ttyS1
  init-chat "" AT&C1&D2 OK

to it.

Have you used this port for anything yet - can you dial OUT using this port, say to a BBS, successfully? can you dial IN using minicom and get a login?  Are you sure you don't have something besides mgetty also watching this port - say, a mingetty - look in /etc/inittab and make sure there is only ONE Line that starts with S1 and that that line calls mgetty.  Check the contents of the LCK... files in /var/lock/ and check the PIDs you see.  Check the contents of /proc/interrupts and make sure that
interrupt 3 says 'serial' next to it.  

If this still doesn't work post the contents of your /var/log/messages file also, and the contents of /etc/inittab.  


The remote client on Windows98 tried to
dial-in to my PPP server on linux twice.
I believe that PPP-connection's OK, but
the remote connection's terminated as
soon as it connected to the server.
Here's the /var/log/message file:

Mar  2 22:34:04 sushi kernel: PPP line discipline registered.
Mar  2 22:34:04 sushi kernel: PPP BSD Compression module registered
                                         Mar  2 22:34:04 sushi kernel:   kernel build: 2.2.13 #22 Wed Oct 20 17:32:52 CDT
Mar  2 22:34:04 sushi kernel:   options:  [pci] [cardbus]
Mar  2 22:34:04 sushi kernel: Intel PCIC probe: not found.
Mar  2 22:34:04 sushi kernel: Databook TCIC-2 PCMCIA probe: not found.
Mar  2 22:34:04 sushi kernel: ds: no socket drivers loaded!
Mar  2 22:34:09 sushi sendmail[115]: starting daemon (8.9.3): SMTP+queueing@00:1
Mar  2 22:34:10 sushi kernel: iBCS: socksys registered on character major 30
Mar  2 22:40:29 sushi kernel: registered device ppp0
Mar  2 22:40:30 sushi pppd[219]: pppd 2.3.10 started by LOGIN, uid 0
Mar  2 22:40:30 sushi pppd[219]: Using interface ppp0
Mar  2 22:40:30 sushi pppd[219]: Connect: ppp0 <--> /dev/ttyS1
Mar  2 22:40:36 sushi pppd[219]: Connection terminated.
Mar  2 22:40:36 sushi pppd[219]: Exit.
Mar  2 22:41:19 sushi pppd[236]: pppd 2.3.10 started by LOGIN, uid 0
Mar  2 22:41:19 sushi pppd[236]: Using interface ppp0
Mar  2 22:41:19 sushi pppd[236]: Connect: ppp0 <--> /dev/ttyS1
Mar  2 22:41:26 sushi pppd[236]: Connection terminated.
Mar  2 22:41:26 sushi pppd[236]: Exit.

Here's my /etc/ppp/pap-secrets:

# PAP authentication file: /etc/ppp/pap-secrets
# This file should have a permission of
# 600.
# ~# chmod 600 /etc/ppp/pap-secrets
# Username      Server      Password
# IP addresses
# Dial-in clients
cpak    myhostname   mypassword

In my /etc/inittab, there's only one S1
entry for that device.  
Here's the /etc/inittab:

# inittab       This file describes how the INIT process should set up
#               the system in a certain run-level.
# Version:      @(#)inittab             2.04    17/05/93        MvS
#                                       2.10    02/10/95        PV
#                                       3.00    02/06/1999      PV
# Author:       Miquel van Smoorenburg, <miquels@drinkel.nl.mugnet.org>
# Modified by:  Patrick J. Volkerding, <volkerdi@ftp.cdrom.com>

# These are the default runlevels in Slackware:
#   0 = halt
#   1 = single user mode
#   2 = unused (but configured the same as runlevel 3)
#   3 = multiuser mode (default Slackware runlevel)
#   4 = X11 with KDM/GDM/XDM (session managers)
#   5 = unused (but configured the same as runlevel 3)
#   6 = reboot

# Default runlevel. (Do not set to 0 or 6)

# System initialization (runs when system boots).

# Script to run when going single user (runlevel 1).

# Script to run when going multi user.

# What to do at the "Three Finger Salute".
ca::ctrlaltdel:/sbin/shutdown -t5 -rf now

# Runlevel 0 halts the system.

# Runlevel 6 reboots the system.

# What to do when power fails (shutdown to single user).
pf::powerfail:/sbin/shutdown -f +5 "THE POWER IS FAILING"

# If power is back before shutdown, cancel the running shutdown.
pg:0123456:powerokwait:/sbin/shutdown -c "THE POWER IS BACK"

# If power comes back in single user mode, return to multi user mode.
ps:S:powerokwait:/sbin/init 3

# The getties in multi user mode on consoles an serial lines.
# NOTE NOTE NOTE adjust this to your getty or you will not be
#                able to login !!
# Note: for 'agetty' you use linespeed, line.
# mgetty -------------
s1:45:respawn:/usr/local/sbin/mgetty -m '"" AT&C1&D2 OK' -D -x9 /dev/ttyS1

Is there any reason the client's
terminated immediately?




Here's my /etc/ppp/options:

# General configuration options for PPPD:
# Uncomment the line below for more verbose error reporting:
# If you have a default route already, pppd may require the other side
# to authenticate itself, which most ISPs will not do.  To work around this,
# uncomment the line below.  Note that this may have negative side effects
# on system security if you allow PPP dialins.  See the docs in /usr/doc/ppp*
# for more information.
asyncmap 0
name "cpak"

To make one more time, the remote
client tried to login using
corrent username and


by specifing "name" in /etc/ppp/options, you're setting or changing the name of the host. If the /etc/ppp/pap-secrets file you posted is the server one, you need to change it around to be
remote-client's-loginname cpak remote-client's password.

I think tibori is onto it.  Your earlier log messages indicated communication failure.  But this log shows pppd starting.  Try removing the
name "cpak"
lines, perhaps adding
kdebug 1
to the pppd options file, and retrying.

You don't need passive if mgetty is starting pppd, and passive will allow multiple copies of pppd to start, causing you more lock and contention problems on your port.


Thank  you so much for all of the comments.
So, what's the bottom line here?
Do I need to remove the lines "name cpak" or
to replace the line  into "cpak   password" in
/etc/ppp/options ?


if you remove "name cpak" pppd will report the actual name of your server, so then that's what you'd have to put into pap secrets:

clients-name actual-server-name clients-password

If you leave it there then you can put what I specified above. Either way should work.
This one is on us!
(Get your first solution completely free - no credit card required)
Unlock the solution to this question.
Join our community and discover your potential

Experts Exchange is the only place where you can interact directly with leading experts in the technology field. Become a member today and access the collective knowledge of thousands of technology experts.

*This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.


Please enter a first name

Please enter a last name

8+ characters (letters, numbers, and a symbol)

By clicking, you agree to the Terms of Use and Privacy Policy.