PPP over standard serial port
Elison
I am trying to establish a ppp link over standard serial port. I have
2 computers running Linux. I have connected a standard serial cable
between them.
I have tested the serial connection using cutecom/minicom on both the
machines.
Searching a bit on the internet led me to :
All you need to do now is to start pppd on both systems. So, on both
machines execute the command:-
pppd -detach crtscts lock <local IP>:<remote IP> /dev/ttyS0 38400 &
So on PC 1, I issued:
pppd -detach crtscts lock 192.168.20.2:192.168.20.3 /dev/ttyS0 38400 &
and on PC 2, I issued:
pppd -detach crtscts lock 192.168.20.3:192.168.20.2 /dev/ttyS0 38400 &
But tail /var/log/messages gives me timeout sending lcp-config-
requests.
I also tried creating /etc/ppp/options.ttyS0 on both machines.
Machine 1:
local
lock
38400
192.168.20.2:192.168.20.3
debug
noauth
nodeflate
nobsdcomp
Machine 2:
local
lock
38400
192.168.20.3:192.168.20.2
debug
noauth
nodeflate
nobsdcomp
But still no luck after executing 'pppd file /etc/ppp/options.ttyS0'.
How do I establish a ppp connection between these 2 computers over the
serial port?
OS 1: Fedora 13, 32 bit
OS 2: Fedora 14, 32 bit
Thanks and Regards,
Elison
Moe Trin
<8a93c397-32b4-4aef...@h38g2000pro.googlegroups.com>, Elison
wrote:
NOTE: Posting from groups.google.com (or some web-forums) dramatically
reduces the chance of your post being seen. Find a real news server.
>I am trying to establish a ppp link over standard serial port. I have
>2 computers running Linux. I have connected a standard serial cable
>between them.
"a standard serial cable" meaning what exactly? What is needed here is
called a cross-over or "null modem" cable rather than one wired
pin-to-pin. If you're not familiar with this, see the Serial-HOWTO
278767 Feb 10 15:21 Serial-HOWTO
>I have tested the serial connection using cutecom/minicom on both
>the machines.
And can machine "A" talk to machine "B" using minicom?
>Searching a bit on the internet led me to :
>All you need to do now is to start pppd on both systems. So, on both
>machines execute the command:-
>pppd -detach crtscts lock <local IP>:<remote IP> /dev/ttyS0 38400 &
Kind of old, and less helpful, but
23129 Jul 20 2001 Serial-Laplink-HOWTO
>But tail /var/log/messages gives me timeout sending lcp-config-
>requests.
Do you see anything from the "other" system in the log? This is what
a (dialin) connection start should look like:
===================
Jul 3 09:55:27 gtech pppd[924]: sent [LCP ConfReq id=0x1 <asyncmap
0x0> <magic 0x8bab12d4> <pcomp> <accomp>]
Jul 3 09:55:27 gtech pppd[924]: rcvd [LCP ConfReq id=0x1 < 00 04 00
00> <mru 1524> <asyncmap 0xa0000> <auth pap> <pcomp> <accomp> < 11 04
05 f4> < 13 09 03 00 c0 7b 90 17 04>]
Here, this box said hello before hearing from the peer. The peer
wants to have this system authenticate with PAP ( <auth pap> ), and is
offering three services this box never heard of.
Jul 3 09:55:27 gtech pppd[924]: sent [LCP ConfRej id=0x1 < 00 04 00
00> < 11 04 05 f4> < 13 09 03 00 c0 7b 90 17 04>]
So, this box rejects the unknown stuff.
Jul 3 09:55:27 gtech pppd[924]: rcvd [LCP ConfAck id=0x1 <asyncmap
0x0> <magic 0x8bab12d4> <pcomp> <accomp>]
Jul 3 09:55:27 gtech pppd[924]: rcvd [LCP ConfReq id=0x2 <mru 1524>
<asyncmap 0xa0000> <auth pap> <pcomp> <accomp>]
Jul 3 09:55:27 gtech pppd[924]: sent [LCP ConfAck id=0x2 <mru 1524>
<asyncmap 0xa0000> <auth pap> <pcomp> <accomp>]
The peer comes back and acknowledges the original 'hello', and says hello
itself, but this time without the unknown services. This box acknowledges
the peer.
Jul 3 09:55:27 gtech pppd[924]: sent [PAP AuthReq id=0x1 user=<hidden>
password=<hidden>]
Jul 3 09:55:28 gtech pppd[924]: rcvd [PAP AuthAck id=0x1 ""]
This box sends in the username and password (here edited out), and the peer
comes back and approves the login.
Jul 3 09:55:28 gtech pppd[924]: sent [IPCP ConfReq id=0x1 <addr
0.0.0.0> <compress VJ 0f 01>]
Jul 3 09:55:30 gtech pppd[924]: sent [CCP ConfReq id=0x1 <deflate 15>
<deflate(old#) 15> <bsd v1 15>]
This box now asks to talk TCP/IP, but doesn't know it's address (normal),
and suggests two ways to compress data.
Jul 3 09:55:30 gtech pppd[924]: rcvd [IPCP ConfReq id=0x1 <compress
VJ 0f 01> <addr 201.48.5.2>]
Jul 3 09:55:30 gtech pppd[924]: sent [IPCP ConfAck id=0x1 <compress
VJ 0f 01> <addr 201.48.5.2>]
The peer comes back and asks to talk TCP/IP, and wants to use that address.
This box approves this.
Jul 3 09:55:30 gtech pppd[924]: rcvd [IPCP ConfNak id=0x1 <addr
201.48.5.158>]
Jul 3 09:55:30 gtech pppd[924]: sent [IPCP ConfReq id=0x2 <addr
201.48.5.158> <compress VJ 0f 01>]
The peer comes back and says that you can't use address 0.0.0.0, and
suggests asking to use this address. This peer does so.
Jul 3 09:55:30 gtech pppd[924]: rcvd [IPCP ConfAck id=0x2 <addr
201.48.5.158> <compress VJ 0f 01>]
Jul 3 09:55:30 gtech pppd[924]: local IP address 201.48.5.158
Jul 3 09:55:30 gtech pppd[924]: remote IP address 201.48.5.2
The peer approves our use of this address, and the ppp link is now up
and running.
===================
Now, do you see the boxes talking back and forth - or only one box
sending the same thing over and over:
Jul 3 09:55:24 gtech pppd[924]: sent [LCP ConfReq id=0x1 <asyncmap
0x0> <magic 0x8bab12d4> <pcomp> <accomp>]
with the "id=0x1" value incrementing? That's likely to be a wiring
problem, but check the logs on BOTH systems.
>I also tried creating /etc/ppp/options.ttyS0 on both machines.
Try '/etc/ppp/options'
>local
>lock
>38400
>192.168.20.2:192.168.20.3
>debug
OK - but make sure your syslog daemon is putting 'daemon.debug' level
messages in some file you can read.
>noauth
>nodeflate
>nobsdcomp
Not needed.
Old guy
Elison
Trin) wrote:
> On Tue, 21 Jun 2011, in the Usenet newsgroup comp.protocols.ppp, in article
Hi,
Thanks for the reply.
I am using a standard serial cable, not crossover.
Both machines can talk to each other using minicom so I am "assuming"
ppp should work.
The debug does not show any LCP packets sent or recieved debug.
tail /var/log/messages is same on both the machines.
I guess I have to check with a crossover cable.
Thanks,
Elison
xiebl...@gmail.com
pppd proxyarp mtu 1280 persist nodeflate noauth lcp-echo-interval 10
crtscts lock 10.10.1.2:10.10.1.1 /dev/ttyS4 115200 debug nodetach
in my system，and it sending the same thing over and over：
sent [LCP ConfReq id=0x1 <asyncmap
0x0> <magic 0x8bab12d4> <pcomp> <accomp>]
Thank you！
Moe Trin
<fa1ebc1a-2d3e-451a...@googlegroups.com>,
NOTE: Posting from groups.google.com (or some web-forums) dramatically
reduces the chance of your post being seen. Find a real news server.
>pppd proxyarp mtu 1280 persist nodeflate noauth lcp-echo-interval 10
>crtscts lock 10.10.1.2:10.10.1.1 /dev/ttyS4 115200 debug nodetach
>in my system
link to another computer? What operating system? You show
"/dev/ttyS4" which in Linux would be the fifth (very uncommon) classic
RS-232 serial port. Assuming Linux, what does 'ls' show?
[spica ~]$ ls /dev/ttyS*
/dev/ttyS0 /dev/ttyS1 /dev/ttyS2 /dev/ttyS3
[spica ~]$
During boot, is your kernel loading an appropriate serial driver?
In /var/log/dmesg, I see
[ 0.518034] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
[ 0.538368] serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
Notice the second line - on this computer, there is an actual RS-232
serial port. On two other computers here, the line is missing
because there is no classic serial port (everything is USB, which is
a different device and driver).
>and it sending the same thing over and over
The peer at the other end of the serial link is not responding.
Is your connection to the peer (modem, cross-over cable or similar)
connected? Is there a pppd daemon listening on the appropriate port
on the peer? More details needed.
Old guy