Basically the answer is it's much easier to use something like
dip to establish the connection in the first place. Dip then
takes care of connecting the line on the local system to the
local networking system.
PPP is very much the same way: you run "pppd" on both the local
and remote machines, and they talk to each other and arbitrate
the IP addresses. But you need to run pppd on the local machine
first to establish the connection. Once the connection is
established it then runs pppd on the remote end. Here is
a script that I've used:
# script to login to remote Linux machine through modem
pppd lock connect 'chat -v "" ATD8980834 "Network ID:"
networkname sword: "netpassword" annex: "telnet bip.anatomy" ogin:
username assword: userpasswd "" "exec /usr/bin/pppd passive proxyarp
:22.214.171.124" ' /dev/cua1 38400 crtscts modem noipdefault
# (this of course is all on one command line)
Here "pppd" runs a "connect" script, which runs "chat". Chat
expects a series of pairs of text strings, the first string in
each pair is the text expected and the second is sent out when
the expected text is received. If a string should always be sent
no matter what the "expect" string is "". Chat dials out, sends
my network name and password to get onto the net at work, then
telnets to the remote Linux machine "bip.anatomy", gives another
name and password, and finally runs pppd, giving the IP address
which will be assigned to the local Linux machine. For a better
idea of how to do this, see the documentation in the PPP
It's a little different if you have a direct line: you don't use
a dial out, and you might need several send-receive pairs just to
get connected, and possibly tell pppd about some special chars
that need to be "escaped", but basically it works the same way.
And if you're dialing into an existing modem server that directly
supports PPP you don't need to run "pppd" on the remote end at
all: normally the chat script simply sends "ppp" after you dial
in and give the password. Very often it is similar for a modem
server that runs SLIP: once you're connected to the server you
just send "slip" from dip and it's running. But since PPP is
newer and maybe a little better it might be best to try it
instead of SLIP. Remember that in order for "pppd" to work
correctly you need to compile in PPP support into the Linux
kernel. It works, and is really quite easy!
Hope this helps...
get $local cleopatra
get $remote albion
get $mtu 400
if you dont ask dip to dial, it wont.
so this simply puts the port cua1 in DIP mode with the
correct numbers (speed, mtu, $local and $remote addresses )
the line will be put into (C)SLIP mode immeadiately and will stay
ready to send and recieve SLIP packets until you kill dip.
So its so easy for dip.
For PPP IT IS NOT just a matter of a few ioctl calls.
This is because the ppp service at the other end will have to be
attempting to( or waiting to) negotiate the terms of the
PPP connection before establishing it.
There might be some time limit that specifies how long the remote
end will wait for this negotiation to start before it hangs up.
But anyway, the good news is that pppd need not be used to
dial the modem then establish the ppp link.
if the line is already connected, all you need do is to take out the
bits in the script that refers to dialling.
for example, running pppd like this will try to negotiate
the ppp link, it will work as long there is a pppd at the other end
trying to do the same (before the time limit expires)
/etc/ppp/pppd -detach modem crtscts asyncmap 0 mtu 800 mru 800 \
netmask 255.255.255.0 cleopatra: /dev/cua1 19200
Now, if your wondering about how to specify the time limits, so
Some of these options to ppp (that are put in /etc/ppp/options )
change the number of negotiation attempts before pppd will giveup.
since each attempt is given a time of about one second to succeed,
I figure 1000 attempts will mean a long time limit :)
# these 1000 options gives us a long time to get a pppd on the other end
maybe just the first one would be all that is needed,
or maybe just the second one.
I recently replaced my old HD (Kalok KL-3100)
with a Quantum Fireball 1.08 Gb EIDE.
I re-installed the whole Slackware distribution (3.0, kernel 1.3.20)
and discovered that the performance of all the applications which use
serial ports has significantly dropped down. This sounds very strange,
since the new HD is much faster than the old one and I *never* experienced
such problems in the past.
I get CRC errors during ZMODEM downloads, even at 9600 bps!
They only disappear when I set the port baudrate to 4800 or slower ... :-I
Moreover, all the network applications have become extremely slow :
FTP transfers never exceed 0.7 kb/s on a 14400 serial line.
Flow control is enabled and uses hardware handshake.
Here's a brief description of my system :
Intel 486DX/33 with 8 Mb RAM, ISA bus, AMI BIOS
Trident TVGA 8900C, 1 Mb RAM
2 serial cards: one with 8250 chips and the other with 16450 UARTs
Mediavision Jazz 16 soundcard
RTX03A signal acquisition card
With the old HD all worked great under Linux, and I only experienced
some ZMODEM CRC errors during intense disk activity.
Under DOS/Windows it's all ok even now ...
I tried to replace the Linux kernel, but nothing changed.
... I know I should buy a serial card with 16550 UARTs,
but I'm just wondering *why* serial ports performance
dropped after installing a new HD ...
Thank you for your attention. :-)
I will greatly appreciate any comments & suggestions.
2. S5.5.1 and X