archive mirror
 help / color / mirror / Atom feed
From: James Carlson <>
Subject: Re: Setup pppd over rs-485 point-to-point
Date: Fri, 17 Mar 2017 12:05:12 +0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On 03/16/17 23:18, Woody Wu wrote:
> Hi,
> I want to setup pppd to connect a Linux laptop to an embedded Linux
> device. The Linux box connected to a rs-232 to rs485 converter, then the
> convert connected via a two-wire rs-485 cable to the embedded Linux
> device's rs-485 port.
> On the otherhand, I can make success with similar commands when two
> devices connected with rs-232.  So I guess, this failure was because the
> rs-485 is half-duplex.  But I searched google, people seemed say pppd
> should work over a point-to-point rs-485 connection.  So I want to get
> help from your experts.

I see evidence of other problems in your trace as well.  The PC is
receiving its own transmissions, which is very bad, and is the proximate
cause of the failure.  It means that the converter device you're using
has local echo enabled.  If there's some way to turn off local echo, you
may get a little further.  Check the manufacturer's documentation for
that converter.  This shouldn't happen:

sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0xb3a3da0c> <pcomp> <accomp>]
rcvd [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0xb3a3da0c> <pcomp> <accomp>]

But even though that caused this failure, I don't think it's the root
problem.  As another poster said, it's not going to work like this.

Two-wire TIA-485 is indeed half-duplex.  There are protocols designed
for use on it (MODBUS is one example), but right in the introduction to
RFC 1661 (PPP), it says that you need full-duplex by design.

I think it would be possible to make it work on a half-duplex link, but
it wouldn't be simple or terribly efficient.  The two schemes I can
imagine are:

  - Use a master-slave type of relationship.  This means having one end
    (perhaps the PC in this case) sending some sort of signal (I suggest
    using back-to-back flags; two 0x7E in a row) to let the slave side
    know it should send something if it has it, or to send an empty
    packet.  The master then just periodically polls for data or sends
    what it has.

  - Use something like ALOHA or CSMA.  Both of these require some means
    of knowing that your transmitted message has been garbled by a
    collision so that you can back off and retry.  That might require
    some electrical work on your part.

James Carlson         42.703N 71.076W         <>

  parent reply	other threads:[~2017-03-17 12:05 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-17  3:18 Setup pppd over rs-485 point-to-point Woody Wu
2017-03-17  3:57 ` Mike O'Connor
2017-03-17  4:42 ` Woody Wu
2017-03-17  5:49 ` Mike O'Connor
2017-03-17  5:50 ` Woody Wu
2017-03-17 12:05 ` James Carlson [this message]
2017-03-17 15:13 ` Michael Richardson
2017-03-19 14:40 ` Woody Wu
2017-03-19 14:43 ` Woody Wu
2017-03-20 11:07 ` James Carlson
2017-03-21  3:16 ` Woody Wu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).