Routing ppp (Was: Getty on USB serial port)

["William D. Jones" <thor0505%comcast.net@localhost>]

Since yesterday, I've been able to set up a ppp link with my Beagleboard and 
Pi (using getty's special handling for ppp). Unfortunately, I haven't been 
able to get my Pi to be reachable on the rest of my networ. Currently, I'm 
troubleshooting using tcpdump and playing with various options to pppd.

One thing that bothers me (this prob also applies to Linux) is that without 
the `defaultroute` option to `pppd`, any attempt to contact other devices 
fails with `no route to host`:

```
rpi-ptrain# ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1): 56 data bytes
ping: sendto: No route to host
ping: sendto: No route to host
^C
----192.168.1.1 PING Statistics----
2 packets transmitted, 0 packets received, 100.0% packet loss
rpi-ptrain# netstat -rn
Routing tables

Internet:
Destination        Gateway            Flags    Refs      Use    Mtu 
Interface
127/8              127.0.0.1          UGRS        -        -  33180  lo0
127.0.0.1          lo0                UHl         -        -  33180  lo0
192.168.1.164      192.168.1.165      UH          -        -      -  ppp0
192.168.1.165      ppp0               UHl         -        -      -  lo0
```

Okay fair enough, so I enable the `defaultroute` option to `pppd` on my Pi:
```
pppd noauth defaultroute passive 192.168.1.165:192.168.1.164 /dev/ttyU0`)
rpi-ptrain# netstat -rn
Routing tables

Internet:
Destination        Gateway            Flags    Refs      Use    Mtu 
Interface
default            192.168.1.164      UGS         -        -      -  ppp0
127/8              127.0.0.1          UGRS        -        -  33180  lo0
127.0.0.1          lo0                UHl         -        -  33180  lo0
192.168.1.164      192.168.1.165      UH          -        -      -  ppp0
192.168.1.165      ppp0               UHl         -        -      -  lo0
```

However, while researching how Point-to-Point Protocol works (ppp) I 
realized that ppp is a layer 2 protocol, like Ethernet (incompatible). 
Furthermore, ppp has no concept of a gateway or `defaultroute`, b/c the 
protocol itself, well, only connects two devices. There's no way to contact 
the gateway like w/ Ethernet b/c there's no way to encapsulate an alternate 
identifier for the remote device like there is w/ Ethernet (MAC address).

It makes sense to require a `defaultroute`/routing table entry to talk to 
external devices. However, when I run `tcpdump -i ppp0`, in response to 
`ping 192.168.1.1` on my Pi, I get the following output. NetBSD is 
attempting to contact the remote host directly, as it would with Ethernet.

```
01:32:38.602356 IP: IP 192.168.1.165 > 192.168.1.1: ICMP echo request, id 
11861, seq 152, length 64

01:32:39.603053 IP: IP 192.168.1.165 > 192.168.1.1: ICMP echo request, id 
11861, seq 153, length 64
```

This suggests to me that NetBSD is trying to embed information like a MAC 
address to get the gateway (my Beagleboard running pppd) to forward the 
packet to the next location on my local network instead of using the 
gateway's IP address. Is there a rationale for NetBSD trying to access the 
dev this way? If so, why does NetBSD think it can reach the remote device 
(in other words, use the route I provided) using ppp at all?




-----Original Message----- 
From: Michael van Elst
Sent: Friday, September 15, 2017 1:04 PM
To: William D. Jones
Cc: netbsd-users%netbsd.org@localhost
Subject: Re: Getty on USB serial port

On Fri, Sep 15, 2017 at 11:16:31AM -0400, William D. Jones wrote:

> > Intercepting the console with a program is another method. This still
> > causes early messages to be sent to the serial port, but that is seen by
> > ppp as line noise and filtered out.
> Yes, basically this is my concern. I don't know how well ppp will cope 
> with
> random bursts of text. Just out of curiosity, I assume I need to write 
> this
> program myself; how might I go about doing that? I know I need to `dup2` 
> to
> redirect, but the problem is getting the correct fd to redirect so 
> processes
> writing text to the console "see" my altered fd.

You redirect console to some terminal with the TIOCCONS ioctl. I.e.
something like

fd = open("/dev/ttyU0", O_RDONLY);
ioctl(fd, TIOCCONS);
close(fd);

Redirects console output to /dev/ttyU0.

xconsole uses a pseudo-tty instead, so that it can read the output
and render it into a window.

Again, that's the "higher level" console. When the kernel enters DDB
or shuts down, the lowlevel console will be used again.


Greetings,
--
                               Michael van Elst
Internet: mlelstv%serpens.de@localhost
                               "A potential Snark may lurk in every tree."

--
William D. Jones
thor0505%comcast.net@localhost