Re: Setup pppd over rs-485 point-to-point

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On 03/17/2017 08:05 PM, James Carlson wrote:
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>]

Thank you James. I think the converter should be fine, without echo, since I remembered before the ppp setup, I tested it with mimicom on both devices and did not recognized any 'echo' behavior. But I like to double check it when I come to office next Monday.


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.

Does this mean I hava to change the pppd source code or even the Linux kernel?



  - 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.

--
To unsubscribe from this list: send the line "unsubscribe linux-ppp" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Audio Users]     [Linux for Hams]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Fedora Users]

  Powered by Linux