ppp entre duas máquinas em série sem um modem

1

Movendo a pergunta de stackoverflow.com Infelizmente não é possível excluir esta pergunta de stackoverflow.com.

Estou tentando configurar uma conexão PPP entre duas máquinas Linux em uma linha serial. Eu segui estas instruções mas não funcionou. As duas máquinas são Fedora 28 Linux em Intel(R) Core(TM) i7-7600U CPU @ 2.80GHz e uma placa personalizada com Linux 4.14.0-xilinx-v2018.2 em ARMv7 A .

Aqui estão os comandos e a saída que obtive em uma Fedora machine:

$ sudo pppd -detach debug passive lock xonxoff 192.168.10.100:192.168.10.1 /dev/ttyUSB0 9600
[sudo] password for user:
using channel 3
Using interface ppp0
Connect: ppp0 <--> /dev/ttyUSB0
sent [LCP ConfReq id=0x1 <asyncmap 0xa0000> <magic 0x888f0bcb> <pcomp> <accomp>]
sent [LCP ConfReq id=0x1 <asyncmap 0xa0000> <magic 0x888f0bcb> <pcomp> <accomp>]
sent [LCP ConfReq id=0x1 <asyncmap 0xa0000> <magic 0x888f0bcb> <pcomp> <accomp>]
sent [LCP ConfReq id=0x1 <asyncmap 0xa0000> <magic 0x888f0bcb> <pcomp> <accomp>]
sent [LCP ConfReq id=0x1 <asyncmap 0xa0000> <magic 0x888f0bcb> <pcomp> <accomp>]
sent [LCP ConfReq id=0x1 <asyncmap 0xa0000> <magic 0x888f0bcb> <pcomp> <accomp>]
sent [LCP ConfReq id=0x1 <asyncmap 0xa0000> <magic 0x888f0bcb> <pcomp> <accomp>]
sent [LCP ConfReq id=0x1 <asyncmap 0xa0000> <magic 0x888f0bcb> <pcomp> <accomp>]
sent [LCP ConfReq id=0x1 <asyncmap 0xa0000> <magic 0x888f0bcb> <pcomp> <accomp>]
sent [LCP ConfReq id=0x1 <asyncmap 0xa0000> <magic 0x888f0bcb> <pcomp> <accomp>]
LCP: timeout sending Config-Requests

E aqui estão os comandos e a saída que recebi Linux 4.14.0-xilinx-v2018.2

root@cpe-08:/data# pppd -detach debug passive lock xonxoff 192.168.10.1:192.168.10.100 /dev/ttyS0 9
600

Sim, você viu corretamente, não houve outra saída Linux4.14.0-xilinx-v2018.2 .

Eu esperava ver ppp0 interface nas duas máquinas, mas não vi nenhuma delas.

Aqui está a saída de ifconfig on Fedora 28 após a execução do comando pppd

$ ifconfig
enp0s20f0u2u2: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 172.24.176.116  netmask 255.255.255.0  broadcast 172.24.176.255
        inet6 fe80::63fd:53b6:8b94:1abf  prefixlen 64  scopeid 0x20<link>
        ether 00:0e:c6:a5:94:88  txqueuelen 1000  (Ethernet)
        RX packets 5016  bytes 457454 (446.7 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1368  bytes 141981 (138.6 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

enp0s31f6: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        ether 54:e1:ad:8c:32:a5  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 16  memory 0xec200000-ec220000

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 184264  bytes 109696260 (104.6 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 184264  bytes 109696260 (104.6 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

virbr0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        inet 192.168.122.1  netmask 255.255.255.0  broadcast 192.168.122.255
        ether 52:54:00:62:c0:6c  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

wlp58s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 100.96.37.134  netmask 255.255.255.192  broadcast 100.96.37.191
        inet6 fe80::3728:7f03:ba95:5757  prefixlen 64  scopeid 0x20<link>
        inet6 2620:10d:c0be:2226:7261:932:1670:38bb  prefixlen 64  scopeid 0x0<global>
        ether f8:34:41:af:1a:0e  txqueuelen 1000  (Ethernet)
        RX packets 13305344  bytes 16391874252 (15.2 GiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 5691206  bytes 1228184162 (1.1 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

E aqui está a saída de ifconfig em Linux 4.14.0-xilinx-v2018.2 após a execução de um comando pppd

# ifconfig
eth0      Link encap:Ethernet  HWaddr 00:04:35:00:01:08
          inet addr:172.24.176.208  Bcast:172.24.176.255  Mask:255.255.255.0
          inet6 addr: fe80::204:35ff:fe00:108/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:2515 errors:0 dropped:0 overruns:0 frame:0
          TX packets:753 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:221227 (216.0 KiB)  TX bytes:93698 (91.5 KiB)
          Interrupt:27 Base address:0xb000

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:36160 errors:0 dropped:0 overruns:0 frame:0
          TX packets:36160 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:1516794 (1.4 MiB)  TX bytes:1516794 (1.4 MiB)

Eu sei que Linux 4.14.0-xilinx-v2018.2 foi compilado para incluir ppp support. Eu teria incluído um trecho de um '.config', mas ele não é fornecido com a compilação. O motivo pelo qual eu sei que o ppp support está no kernel é porque eu perguntei ao nosso cara de construção e ele disse que o incluiu.

    
por flashburn 11.10.2018 / 01:07

1 resposta

1

Depois de mexer por algum tempo eu consegui fazê-lo funcionar. Aqui está o comando para Fedora machine

sudo pppd -detach local debug noauth passive lock 192.168.10.100:192.168.10.1 /dev/ttyUSB0 9600

E aqui está o comando para uma Linux 4.14.0-xilinx-v2018.2 machine

pppd -detach persist debug local noauth passive lock 192.168.10.1:192.168.10.100 /dev/ttyS0 9600

Eu tenho lutado com o problema nos últimos 2 meses. Não sei por que essa pergunta foi inicialmente desclassificada. Eu imagino que há outras pessoas que tiveram o mesmo problema.

    
por 11.10.2018 / 01:07