Re: Routing ppp (Was: Getty on USB serial port)

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

Sent the prev email before I was ready. One unexpected behavior I got from 
pppd is that it seems to be able to "swap" the interfaces daemons are bound 
to.

As an example, I have sshd enabled in my /etc/rc.conf, and `ppp.115200` in 
`/etc/ttys`. When my Pi boots, `ifconfig` only shows the loopback interface, 
but when I enable `pppd` on the other end (Beagle), I can `ssh` into the Pi 
without problem, as if ssh was listening on `ppp0` from the beginning before 
it was created. How is this possible?

-----Original Message----- 
From: William D. Jones
Sent: Sunday, September 17, 2017 9:40 AM
To: Michael van Elst
Cc: netbsd-users%netbsd.org@localhost
Subject: Re: Routing ppp (Was: Getty on USB serial port)

Hello again,

Got everything working this morning- can access pi from my home network
through Beagleboard (needing to set ip_forwarding=1 in kernel). Then I
realized something when trying to boost the link speed:

> The initial parameters for the RPI1+2 serial console are hardwired into
the kernel as 115.2kbps and 8N1. You can build a custom kernel to change
this by adding options PLCONSPEED and/or PLCONMODE.

By hardwired, you mean "trying to force a speed change using a gettytab
entry will not work?" Because I've noticed ppp.230400 does not function
correctly. And is this hardwiring unique to the Pi? Maybe I will build a
custom kernel after all.

-----Original Message----- 
From: Michael van Elst
Sent: Saturday, September 16, 2017 7:42 PM
To: William D. Jones
Cc: netbsd-users%netbsd.org@localhost
Subject: Re: Routing ppp (Was: Getty on USB serial port)

On Sat, Sep 16, 2017 at 02:28:00PM -0400, William D. Jones wrote:

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

PPP is layer2 and tunnels layer 3 (IP). The defaultroute option makes it
configure a layer 3 default route.


> 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 only shows layer 3 information, the packet includes the layer 3
source and destination addresses that do not change.

On ethernet, the packet would be sent to the layer 2 address of the
gateway. On ppp, there is no explicit layer 2 address as their is
only a single peer to sent the packet to.


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

Sort of, except for PPP you don't need a "MAC address", any packet
sent through the point-to-point link will reach the one and only peer.


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

Any system using TCP/IP will do that. On layer 3 it decides what interface
to use to send a packet, chosing the most specific route:

> 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

With that table, packets sent to 192.168.1.1 have to use the default
route via ppp0, while e.g. packets sent to 127.1.2.3 or 192.168.1.165
are sent via lo0.



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

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

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