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

2017-09-17 Thread William D. Jones 


Excellent, I have everything set up properly, and I can now call this a 
success. I'll post my instructions on how to accomplish this (which should 
be adaptable to other boards running NetBSD in the near future). I think ppp 
is still relevant b/c it provides a mechanism to put small Ethernet-less 
boards on the Internet.


For those still following along:

For one, the interrupt rate at that speed can be very high and the
hardware FIFO buffer built into the serial port can be too small.
So you may drop characters which causes PPP retries so that the net
speed will be much lower.


460800 baud is a safer bet than 921600 baud. I don't know whether this is 
due to NetBSD or my cable (I suspect the former b/c a serial login works 
fine; it's only when the system is under heavy load that it occurs). In 
fact, my top speed (about 43kB/s) is fastest at 460800 baud. Not impressive, 
but certainly tolerable.



-Original Message- 
From: Michael van Elst

Sent: Sunday, September 17, 2017 11:28 AM
To: William D. Jones
Cc: netbsd-users@netbsd.org
Subject: Re: Routing ppp (Was: Getty on USB serial port)

On Sun, Sep 17, 2017 at 09:40:43AM -0400, William D. Jones wrote:

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.


Hardwired just means that the initial speed is defined as that. Getty
can of course change it. Getty uses standard ioctl calls which can
set a fixed set of standard speeds up to B921600 when supported by
the hardware. The codes are defined in 

This has nothing to do with the speeds supported by the hardware. For
the RPI1+2 console, the speeds are based on a 3MHz clock which is
divided by 16. So the max speed using this setup is 3Mbps/16 = 187500 bps.

The 3MHz clock is however not the maximum supported by the hardware,
just the default configuration set by the firmware. You can change
this by setting the parameter init_uart_clock in /boot/config.txt
and rebooting. A value of 14745600 allows standard speeds up to
B921600 and most important, the driver will automatically adjust
to the changed clock.

There are still two obstacles :)

For one, the interrupt rate at that speed can be very high and the
hardware FIFO buffer built into the serial port can be too small.
So you may drop characters which causes PPP retries so that the net
speed will be much lower.

For the RPI3 console this is worse as it uses a "mini"-UART without
FIFO as the "full" UART is used for the bluetooth adapter. If you
give up bluetooth, you could reconfigure the console to use the
good UART.

For two, the GPIO signal drivers aren't meant to drive such a
high frequency signal. Depending on cable type and length, the
low signal quality will prevent error free reception.


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

--
William D. Jones
thor0...@comcast.net

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

2017-09-17 Thread Michael van Elst 
On Sun, Sep 17, 2017 at 09:50:10AM -0400, William D. Jones wrote:
> 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?

sshd isn't listening on a particular interface but on an IP address.
By default this is the 0.0.0.0 wildcard address. Then a connection made
to any address configured on any interface will work, even when the
interface didn't exist when sshd started.

That's the normal behaviour for most network services and is good
for normal computers that have a single network connection.

Things are more complicated for so-called 'multi-homed' setups,
i.e. computers that have multiple network interfaces connected
to multiple networks. There you often want to provide services
only to specific networks. Combining that with interfaces that
are created on the fly (like your ppp setup) can be, well,
complicated.


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

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

2017-09-17 Thread William D. Jones 
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
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
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:
DestinationGatewayFlagsRefs  UseMtu
Interface
default192.168.1.164  UGS --  -  ppp0
127/8  127.0.0.1  UGRS--  33180  lo0
127.0.0.1  lo0UHl --  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: mlel...@serpens.de
   "A potential Snark may lurk in every tree."

--
William D. Jones
thor0...@comcast.net

--
William D. Jones
thor0...@comcast.net

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

2017-09-17 Thread Michael van Elst 
On Sun, Sep 17, 2017 at 09:40:43AM -0400, William D. Jones wrote:
> 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.

Hardwired just means that the initial speed is defined as that. Getty
can of course change it. Getty uses standard ioctl calls which can
set a fixed set of standard speeds up to B921600 when supported by
the hardware. The codes are defined in 

This has nothing to do with the speeds supported by the hardware. For
the RPI1+2 console, the speeds are based on a 3MHz clock which is
divided by 16. So the max speed using this setup is 3Mbps/16 = 187500 bps.

The 3MHz clock is however not the maximum supported by the hardware,
just the default configuration set by the firmware. You can change
this by setting the parameter init_uart_clock in /boot/config.txt
and rebooting. A value of 14745600 allows standard speeds up to
B921600 and most important, the driver will automatically adjust
to the changed clock.

There are still two obstacles :)

For one, the interrupt rate at that speed can be very high and the
hardware FIFO buffer built into the serial port can be too small.
So you may drop characters which causes PPP retries so that the net
speed will be much lower.

For the RPI3 console this is worse as it uses a "mini"-UART without
FIFO as the "full" UART is used for the bluetooth adapter. If you
give up bluetooth, you could reconfigure the console to use the
good UART.

For two, the GPIO signal drivers aren't meant to drive such a
high frequency signal. Depending on cable type and length, the
low signal quality will prevent error free reception.


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

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

2017-09-17 Thread William D. Jones 

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
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:
DestinationGatewayFlagsRefs  UseMtu
Interface
default192.168.1.164  UGS --  -  ppp0
127/8  127.0.0.1  UGRS--  33180  lo0
127.0.0.1  lo0UHl --  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: mlel...@serpens.de
   "A potential Snark may lurk in every tree."

--
William D. Jones
thor0...@comcast.net

Re: Getty on USB serial port

2017-09-17 Thread Rhialto 
On Fri 15 Sep 2017 at 16:29:32 +0200, Michael van Elst wrote:
> On Fri, Sep 15, 2017 at 05:52:10AM -0400, William D. Jones wrote:
> > * I wanted to use the serial port that defaults to the console on my rpi as
> > the ppp connection for various logistical reasons. Can I redirect kernel
> > messages (and init messages) to another tty without recompiling? I don't see
> > a kernel option in `man boot`.
> 
> The kernel messages always go to the "console", which is a low-level
> interface. The kernel only knows two such devices (or three since a few
> days), which are the serial port, the framebuffer/keyboard and the
> second serial port (for RPI3 support).

Look at tty(4), TIOCCONS:

 TIOCCONS int *on
 If on points to a non-zero integer, redirect kernel console
 output (kernel printf's) to this terminal.  If on points to a
 zero integer, redirect kernel console output back to the
 normal console.  This is usually used on workstations to
 redirect kernel messages to a particular window.

> Once the kernel is running, the console can be intercepted by a program.
> In standard X11 there is a xconsole doing this, which displays the
> messages in a window.

I suspect that xconsole does this by opening a pty and issuing TIOCCONS
on it.

Screen can also issue TIOCCONS:

   console [on|off]

   Grabs or un-grabs the machines console output to a window.  Note: Only
   the owner of /dev/console can grab the console output.  This command is
   only available if the machine supports the ioctl TIOCCONS.

Apart from that, a simple program to issue the ioctl on stdout is easily
written.

-Olaf.
-- 
___ Olaf 'Rhialto' Seibert  -- Wayland: Those who don't understand X
\X/ rhialto/at/falu.nl  -- are condemned to reinvent it. Poorly.


signature.asc
Description: PGP signature

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

2017-09-16 Thread Michael van Elst 
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:
> DestinationGatewayFlagsRefs  UseMtu
> Interface
> default192.168.1.164  UGS --  -  ppp0
> 127/8  127.0.0.1  UGRS--  33180  lo0
> 127.0.0.1  lo0UHl --  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: mlel...@serpens.de
"A potential Snark may lurk in every tree."

Routing ppp (Was: Getty on USB serial port)

2017-09-16 Thread William D. Jones 
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:
DestinationGatewayFlagsRefs  UseMtu 
Interface

127/8  127.0.0.1  UGRS--  33180  lo0
127.0.0.1  lo0UHl --  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:
DestinationGatewayFlagsRefs  UseMtu 
Interface

default192.168.1.164  UGS --  -  ppp0
127/8  127.0.0.1  UGRS--  33180  lo0
127.0.0.1  lo0UHl --  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
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: mlel...@serpens.de
   "A potential Snark may lurk in every tree."

--
William D. Jones
thor0...@comcast.net

Re: Getty on USB serial port

2017-09-15 Thread Michael van Elst 
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: mlel...@serpens.de
"A potential Snark may lurk in every tree."

Re: Getty on USB serial port

2017-09-15 Thread Valery Ushakov 
Michael van Elst  wrote:

> On Fri, Sep 15, 2017 at 05:52:10AM -0400, William D. Jones wrote:
> 
>> ```
>> rpi-ptrain$ ls -l /dev/plcom0
>> crw---  1 uucp  wheel  93, 0 Jun 25 12:49 /dev/plcom0
>> rpi-ptrain$ ls -l /dev/ttyU0
>> crw---  1 wjones  tty  74, 0 Jun 25 17:42 /dev/ttyU0
> 
>> Why are they different, and why do I own `ttyU0` (I don't think NetBSD
>> dynamically creates/alters device nodes)?
> 
> plcom0 still has the default ownership, which is the uucp account for
> the original communication protocol ("Unix-to-Unix-CoPy").
> 
> ttyU0 was running getty, you logged in and the login process passes
> ownership of the tty to you. Ownership is reset when you log out.
> 
> The command 'write' is a very traditional way to send messages to
> other users on the system by just writing text to their tty. The
> command 'mesg' is used to grant and revoke write access for others.
> 
> You also need ownership to change tty settings, without this you
> couldn't run e.g. a screen editor like vi.

BTW, shouldn't dial-out devices be owned by "dialer" and
group-writable?  ISTR this was broken when uucp was removed from the
base.  I thought we had a PR for this, but I can't seem to find it.

-uwe

Re: Getty on USB serial port

2017-09-15 Thread William D. Jones 

Thank you for your answers.


echo hello >/dev/ttyU0
Indeed that's what I did. I'll see if I can duplicate later. But reading 
tmux backlog, I had commented out the gettytab entry for ttyU0 when I tried 
that.


it also has an automatic PPP detection. In the latter case, it will not 
exec login but pppd.
Indeed, this is my intent for /dev/plcom0. The only reason I have a USB 
serial port attached is because I know I'll inevitably screw it up and lock 
myself out of my Pi if I don't :). Also, just plain good for debugging.


So, using the framebuffer is the most simple method. The serial port isn't 
used then.
For those reading along, this means putting "console=fb" into your 
`/boot/cmdline.txt`, even for a headless system.


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.



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.
Although ultimately what I'm going to do is just add a custom entry to 
`/etc/gettytab` with basically "run as fast as possible", this is useful to 
know. getty manual says that it will set the speed for me.



-Original Message- 
From: Michael van Elst

Sent: Friday, September 15, 2017 10:29 AM
To: William D. Jones
Cc: netbsd-users@netbsd.org
Subject: Re: Getty on USB serial port

On Fri, Sep 15, 2017 at 05:52:10AM -0400, William D. Jones wrote:


Now the questions:
* While debugging, I disabled ttyU0 (FTDI cable connected) from the
gettytab, rebooted, and attempted to echo characters down the serial line 
to

be received by minicom on the other end; I got a `-sh: cannot create
/dev/ttyU0: interrupted` each time. What could possibly cause this?


Looks like you do something like:

echo hello >/dev/ttyU0

and the shell receives an EINTR error which happens when it receives
a signal during that operation. If that's the only thing you do, the
only signal could be a SIGHUP, which means that you lost the carrier
signal and I don't see how that could happen.



* `getty` is in fact spawning the `NetBSD (hostname) (tty?) login:` 
message
and prompt, correct? Then `getty` will execve `login [user]` to ask for 
the

password? One thing that confuses me is that the "user" prompt from both
login and getty are identical. So I thought `getty` somehow execve's 
`login`

to immediately show a prompt once certain conditions (RTS/CTS control?) of
the serial line are met.


The initial prompt is done by getty. It knows some magic that lets you
reconfigure the tty (e.g. the autobaud and portselect features) and it
also has an automatic PPP detection. In the latter case, it will not
exec login but pppd.


* I wanted to use the serial port that defaults to the console on my rpi 
as

the ppp connection for various logistical reasons. Can I redirect kernel
messages (and init messages) to another tty without recompiling? I don't 
see

a kernel option in `man boot`.


The kernel messages always go to the "console", which is a low-level
interface. The kernel only knows two such devices (or three since a few
days), which are the serial port, the framebuffer/keyboard and the
second serial port (for RPI3 support).

Once the kernel is running, the console can be intercepted by a program.
In standard X11 there is a xconsole doing this, which displays the
messages in a window.

So, using the framebuffer is the most simple method. The serial port
isn't used then.

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.


* Possibly related, I'm trying to test an ekermit xfer over /dev/plcom0, 
but

to no avail. When I execute `ekermit -r < /dev/plcom0` as root, nothing
happens; there's no output on remote end. When I execute `ekermit -r <
/dev/plcom0` as a normal user, I get "Permission denied". Here are the
permissions of each:

```
rpi-ptrain$ ls -l /dev/plcom0
crw---  1 uucp  wheel  93, 0 Jun 25 12:49 /dev/plcom0
rpi-ptrain$ ls -l /dev/ttyU0
crw---  1 wjones  tty  74, 0 Jun 25 17:42 /dev/ttyU0



Why are they different, and why do I own `ttyU0` (I don't think NetBSD
dynamically creates/alters device nodes)?


plcom0 still has the default ownership, which is the uucp account for
the original communication protocol ("Unix-to-Unix-CoPy").

ttyU0 was running getty,

Re: Getty on USB serial port

2017-09-15 Thread Michael van Elst 
On Fri, Sep 15, 2017 at 05:52:10AM -0400, William D. Jones wrote:

> Now the questions:
> * While debugging, I disabled ttyU0 (FTDI cable connected) from the
> gettytab, rebooted, and attempted to echo characters down the serial line to
> be received by minicom on the other end; I got a `-sh: cannot create
> /dev/ttyU0: interrupted` each time. What could possibly cause this?

Looks like you do something like:

echo hello >/dev/ttyU0

and the shell receives an EINTR error which happens when it receives
a signal during that operation. If that's the only thing you do, the
only signal could be a SIGHUP, which means that you lost the carrier
signal and I don't see how that could happen.



> * `getty` is in fact spawning the `NetBSD (hostname) (tty?) login:` message
> and prompt, correct? Then `getty` will execve `login [user]` to ask for the
> password? One thing that confuses me is that the "user" prompt from both
> login and getty are identical. So I thought `getty` somehow execve's `login`
> to immediately show a prompt once certain conditions (RTS/CTS control?) of
> the serial line are met.

The initial prompt is done by getty. It knows some magic that lets you
reconfigure the tty (e.g. the autobaud and portselect features) and it
also has an automatic PPP detection. In the latter case, it will not
exec login but pppd.


> * I wanted to use the serial port that defaults to the console on my rpi as
> the ppp connection for various logistical reasons. Can I redirect kernel
> messages (and init messages) to another tty without recompiling? I don't see
> a kernel option in `man boot`.

The kernel messages always go to the "console", which is a low-level
interface. The kernel only knows two such devices (or three since a few
days), which are the serial port, the framebuffer/keyboard and the
second serial port (for RPI3 support).

Once the kernel is running, the console can be intercepted by a program.
In standard X11 there is a xconsole doing this, which displays the
messages in a window.

So, using the framebuffer is the most simple method. The serial port
isn't used then.

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.


> * Possibly related, I'm trying to test an ekermit xfer over /dev/plcom0, but
> to no avail. When I execute `ekermit -r < /dev/plcom0` as root, nothing
> happens; there's no output on remote end. When I execute `ekermit -r <
> /dev/plcom0` as a normal user, I get "Permission denied". Here are the
> permissions of each:
> 
> ```
> rpi-ptrain$ ls -l /dev/plcom0
> crw---  1 uucp  wheel  93, 0 Jun 25 12:49 /dev/plcom0
> rpi-ptrain$ ls -l /dev/ttyU0
> crw---  1 wjones  tty  74, 0 Jun 25 17:42 /dev/ttyU0

> Why are they different, and why do I own `ttyU0` (I don't think NetBSD
> dynamically creates/alters device nodes)?

plcom0 still has the default ownership, which is the uucp account for
the original communication protocol ("Unix-to-Unix-CoPy").

ttyU0 was running getty, you logged in and the login process passes
ownership of the tty to you. Ownership is reset when you log out.

The command 'write' is a very traditional way to send messages to
other users on the system by just writing text to their tty. The
command 'mesg' is used to grant and revoke write access for others.

You also need ownership to change tty settings, without this you
couldn't run e.g. a screen editor like vi.


> * While I don't think I'll need this, is `/etc/rc.local` a good place for
> serial parameters I need to change with `stty`?

Most drivers will reset parameters after use, so anything you set
in /etc/rc.local will probably get lost. It's better to set parameters
when you start using a tty.

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.


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

Re: Getty on USB serial port

2017-09-15 Thread Valery Ushakov 
William D. Jones  wrote:

> * `getty` is in fact spawning the `NetBSD (hostname) (tty?) login:`
> message and prompt, correct?  Then `getty` will execve `login
> [user]` to ask for the password?  One thing that confuses me is that
> the "user" prompt from both login and getty are identical.  So I
> thought `getty` somehow execve's `login` to immediately show a
> prompt once certain conditions (RTS/CTS control?) of the serial line
> are met.

getty(8) prints the first login: prompt and reads the username to be
able to look at the input and try to infer additional tty modes, iirc.
E.g. when upper-case only terminals were still a thing it would check
the login name for upper case letters and turn on case mapping.  Then
"login user" it executes asks for the password, and if you make a
mistake, the next "login:" prompt is from login(1)..


-uwe

Re: Getty on USB serial port

2017-09-15 Thread William D. Jones 
Finally got a chance to go back to this and... excellent! Some progress and 
some more questions.


First the progress:
* I was able to get a getty by swapping out my USB-to-serial device with 
another Prolific device: https://www.adafruit.com/product/70. Notice no flow 
control signals. I'll investigate the other device later.


* I was able to switch the speed to std.115200 (and use the "vt100") entry 
successfully.


Now the questions:
* While debugging, I disabled ttyU0 (FTDI cable connected) from the 
gettytab, rebooted, and attempted to echo characters down the serial line to 
be received by minicom on the other end; I got a `-sh: cannot create 
/dev/ttyU0: interrupted` each time. What could possibly cause this?


* `getty` is in fact spawning the `NetBSD (hostname) (tty?) login:` message 
and prompt, correct? Then `getty` will execve `login [user]` to ask for the 
password? One thing that confuses me is that the "user" prompt from both 
login and getty are identical. So I thought `getty` somehow execve's `login` 
to immediately show a prompt once certain conditions (RTS/CTS control?) of 
the serial line are met.


* I wanted to use the serial port that defaults to the console on my rpi as 
the ppp connection for various logistical reasons. Can I redirect kernel 
messages (and init messages) to another tty without recompiling? I don't see 
a kernel option in `man boot`.


* Possibly related, I'm trying to test an ekermit xfer over /dev/plcom0, but 
to no avail. When I execute `ekermit -r < /dev/plcom0` as root, nothing 
happens; there's no output on remote end. When I execute `ekermit -r < 
/dev/plcom0` as a normal user, I get "Permission denied". Here are the 
permissions of each:


```
rpi-ptrain$ ls -l /dev/plcom0
crw---  1 uucp  wheel  93, 0 Jun 25 12:49 /dev/plcom0
rpi-ptrain$ ls -l /dev/ttyU0
crw---  1 wjones  tty  74, 0 Jun 25 17:42 /dev/ttyU0
```

Why are they different, and why do I own `ttyU0` (I don't think NetBSD 
dynamically creates/alters device nodes)?


* While I don't think I'll need this, is `/etc/rc.local` a good place for 
serial parameters I need to change with `stty`?


I'm on the right track now, so thank you for your help :)!

-Original Message- 
From: Michael van Elst

Sent: Thursday, September 07, 2017 5:34 PM Newsgroups: lists.netbsd.users
To: netbsd-users@netbsd.org
Subject: Re: Getty on USB serial port

thor0...@comcast.net ("William D. Jones") writes:


There's no getty process! What happened? Is getty supposed to disappear
after invoking login?


Yes. getty initializes the tty, waits for input and then executes login.
It doesn't fork a subprocess, it just calles execve().

login will also just execute your login shell (after you successfully
entered user+password). When your login shell exits, the whole session
is gone and init spawns another getty process.

When you fail to login several times, the login process will exit itself.
And again the session ends and init spawns another getty process.


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

--
William D. Jones
thor0...@comcast.net

Re: Getty on USB serial port

2017-09-07 Thread Michael van Elst 
thor0...@comcast.net ("William D. Jones") writes:

>There's no getty process! What happened? Is getty supposed to disappear 
>after invoking login?

Yes. getty initializes the tty, waits for input and then executes login.
It doesn't fork a subprocess, it just calles execve().

login will also just execute your login shell (after you successfully
entered user+password). When your login shell exits, the whole session
is gone and init spawns another getty process.

When you fail to login several times, the login process will exit itself.
And again the session ends and init spawns another getty process.


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

Re: Getty on USB serial port

2017-09-07 Thread William D. Jones 
Okay, something's completely not right here. Before rebooting, I ran `ps ax` 
just to see what interfaces getty was
running on, and saw a getty for ttyU0 as expected, but no getty for the 
console.


Curious, I edited `/etc/ttys` and commented out the ttyU0 line, disconnected 
my USB serial port and rebooted.
When I logged in, my `ps ax` looked like the following (plcom0 is indeed the 
console, according to dmesg):


```
PID TTYSTATTIME COMMAND
 0 ?  DKl  0:01.22 [system]
 1 ?  Is   0:00.05 init
181 ?  Is   0:00.09 /usr/sbin/syslogd -s
368 ?  Is   0:00.00 /sbin/devpubd
468 ?  I0:00.12 qmgr -l -t unix -u
506 ?  Is   0:00.10 /usr/libexec/postfix/master -w
554 ?  I0:00.11 pickup -l -t unix -u
568 ?  Ss   0:00.02 /usr/sbin/cron
72 plcom0 O+   0:00.01 ps -ax
594 plcom0 S0:00.16 -sh
606 plcom0 Is   0:00.85 login
```

There's no getty process! What happened? Is getty supposed to disappear 
after invoking login? If so, why in your example,

I see the following?:

After a reboot, there are two getty processes. One for console and one
for ttyU0.

| root821  0.0  0.2  4920 1464 ttyE0 Is+   7:09AM 0:00.01 
/usr/libexec/getty default console
| root493  0.0  0.2  4976 1520 ttyU0 Is+   7:09AM 0:00.01 
/usr/libexec/getty default ttyU0


-Original Message- 
From: Michael van Elst

Sent: Thursday, September 07, 2017 3:24 AM Newsgroups: lists.netbsd.users
To: netbsd-users@netbsd.org
Subject: Re: Getty on USB serial port

thor0...@comcast.net ("William D. Jones") writes:


ttyU0   "/usr/libexec/getty default"vt100   on secure
However, this change had no effect and I didn't see any output on the 
system

attached at the other end of the USB serial port upon rebooting.


Here this just works. Setup:

RPI3 running NetBSD with a dual USB/Serial adapter:

| uplcom0 at uhub2 port 1
| uplcom0: Prolific Technology Inc. (0x67b) USB-Serial Controller D 
(0x2303), rev 1.10/4.00, addr 5

| ucom0 at uplcom0
| uplcom1 at uhub2 port 2
| uplcom1: Prolific Technology Inc. (0x67b) USB-Serial Controller D 
(0x2303), rev 1.10/4.00, addr 6

| ucom1 at uplcom1

In /etc/ttys:
ttyU0   "/usr/libexec/getty default"unknown on secure
ttyU1   "/usr/libexec/getty default"unknown off secure

After a reboot, there are two getty processes. One for console and one
for ttyU0.

| root821  0.0  0.2  4920 1464 ttyE0 Is+   7:09AM 0:00.01 
/usr/libexec/getty default console
| root493  0.0  0.2  4976 1520 ttyU0 Is+   7:09AM 0:00.01 
/usr/libexec/getty default ttyU0



A laptop running NetBSD with a single USB/Serial adapter. The default
baudrate for both sides is 9600. Both are connected through a null-modem
cable. Running 'cu -l /dev/ttyU3' shows the getty login:

| NetBSD/evbarm (egghed) (ttyU0)
|
| login: root
| Password:
| Last login: Thu Sep  7 07:10:34 2017 from 10.28.5.17 on pts/0
| Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,
| 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017
| The NetBSD Foundation, Inc.  All rights reserved.
| Copyright (c) 1982, 1986, 1989, 1991, 1993
| The Regents of the University of California.  All rights reserved.
|
| NetBSD 8.99.2 (EGGHED) #62: Mon Sep 4 23:11:25 CEST 2017
...


A critical part is the null-modem cable, as it also has to connect
the handshake and flow control signals. If those signals are not
used correctly, you can try to disable the functionality in /etc/ttys
with the 'softcar' and/or 'local' flags. You may also tell cu (or
whatever terminal program you use) to ignore modem handshake and
flow control.


--
--
   Michael van Elst
Internet: mlel...@serpens.de
   "A potential Snark may lurk in every tree."

--
William D. Jones
thor0...@comcast.net

Re: Getty on USB serial port

2017-09-07 Thread Michael van Elst 
thor0...@comcast.net ("William D. Jones") writes:

>ttyU0   "/usr/libexec/getty default"vt100   on secure
>However, this change had no effect and I didn't see any output on the system 
>attached at the other end of the USB serial port upon rebooting.

Here this just works. Setup:

RPI3 running NetBSD with a dual USB/Serial adapter:

| uplcom0 at uhub2 port 1
| uplcom0: Prolific Technology Inc. (0x67b) USB-Serial Controller D (0x2303), 
rev 1.10/4.00, addr 5
| ucom0 at uplcom0
| uplcom1 at uhub2 port 2
| uplcom1: Prolific Technology Inc. (0x67b) USB-Serial Controller D (0x2303), 
rev 1.10/4.00, addr 6
| ucom1 at uplcom1

In /etc/ttys:
ttyU0   "/usr/libexec/getty default"unknown on secure
ttyU1   "/usr/libexec/getty default"unknown off secure

After a reboot, there are two getty processes. One for console and one
for ttyU0.

| root821  0.0  0.2  4920 1464 ttyE0 Is+   7:09AM 0:00.01 
/usr/libexec/getty default console 
| root493  0.0  0.2  4976 1520 ttyU0 Is+   7:09AM 0:00.01 
/usr/libexec/getty default ttyU0 


A laptop running NetBSD with a single USB/Serial adapter. The default
baudrate for both sides is 9600. Both are connected through a null-modem
cable. Running 'cu -l /dev/ttyU3' shows the getty login:

| NetBSD/evbarm (egghed) (ttyU0)
| 
| login: root
| Password:
| Last login: Thu Sep  7 07:10:34 2017 from 10.28.5.17 on pts/0
| Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,
| 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017
| The NetBSD Foundation, Inc.  All rights reserved.
| Copyright (c) 1982, 1986, 1989, 1991, 1993
| The Regents of the University of California.  All rights reserved.
| 
| NetBSD 8.99.2 (EGGHED) #62: Mon Sep 4 23:11:25 CEST 2017
...


A critical part is the null-modem cable, as it also has to connect
the handshake and flow control signals. If those signals are not
used correctly, you can try to disable the functionality in /etc/ttys
with the 'softcar' and/or 'local' flags. You may also tell cu (or
whatever terminal program you use) to ignore modem handshake and
flow control.


-- 
-- 
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."

Getty on USB serial port

2017-09-05 Thread William D. Jones 

Hello all,

I'm trying to add a secondary serial port to my Raspberry Pi 1 Model A for 
debugging reasons (I want to repurpose the main UART for `pppd` as an 
experiment). Right now, I'm stuck on trying to spawn a getty on the USB 
serial port.


According to dmseg, my USB-to-serial device is a Prolific device:

```
ucom0 at uplcom0
uplcom0 at uhub0 port 1
uplcom0: Prolific Technology Inc. (0x67b) USB 2.0 To COM Device (0x2303), 
rev 1.10/3.00, addr 2

```

According to `man uplcom` and `man ucom`, `ucom` devices are treated as 
`ttys` and are available under `/dev/ttyU?`, where I presume `?` matches the 
number assigned to `ucom?`. So, using the above `dmesg` output, I add  an 
entry to `/etc/ttys`, expecting it to be picked up on reboot:

```
ttyU0   "/usr/libexec/getty default"vt100   on secure
```

However, this change had no effect and I didn't see any output on the system 
attached at the other end of the USB serial port upon rebooting. At this 
point I figured it's possible that the baud rate is incorrect, but I figured 
I should debug from a root shell first.


However, no matter which arguments I invoke the getty program_, getty 
_insists_ on using the main console, to dump input and output. This leads to 
fun things that I had no idea were possible like, for example (when invoking 
using `/usr/libexec/getty default ttyU0`):


* Getting a login prompt printed over the UART associated with `console` 
that says "(`ttyU0`)", when `ttyU0` should be associated with the USB serial 
port.
* Logging into said login prompt, invoking `tty` command, and the output 
saying my current tty is a psuedoterminal: `/dev/pts/0`


At this point I'm stumped. What would cause me to have the above conditions? 
And what is the proper command I should use from a root shell (after logging 
in over `console` UART) to spawn a login prompt over the USB serial port?


As always, thanks all for any help.

Sincerely,

--
William D. Jones
thor0...@comcast.net