Re: Help with ssh(1) between OpenBSD and iSH/Alpine on iOS

[Predrag Punosevac]

Erling Westenvik wrote:

> Hi,
> Last year I discovered the iSH app, "The Linux shell for iOS"
> (https:/ish.app), "a project to get a Linux shell environment running
> locally on your iOS device, using a usermode x86 emulator". It's an
> Alpine Linux distribution with the Almquist shell (ash) as default.

Hi Erling, 

I have been using extensively Alpine Linux as a Xen Domain 0 since
BSDCan2016 due to Henning Brauer influence. There are no problems in ssh
communication among OpenBSD and Alpine Linux boxes.

xen1:~# more /etc/alpine-release 
3.13.1
xen1:~# uname -a
Linux xen1.int.autonlab.org 5.10.11-1-lts #2-Alpine SMP Fri, 29 Jan 2021
16:43:14 + x86_64 Linux
xen1:~# echo $SHELL
/bin/ash


xen1:~# ssh au...@lnms.int.autonlab.org
Host key fingerprint is
SHA256:FGVw4gkiFuoDdbDg4+U/ZzyZh/pXaI//4jai+eBHzSE
+---[ECDSA 256]---+
|. *oo . +o+  |
|.= + . o *   |
|oo..+|
|+ +. E . |
| + .S = .|
|  . . . ++ + |
| o Xo.+  |
|  * == = |
| ..==.=o+.   |
+[SHA256]-+
au...@lnms.int.autonlab.org's password: 
Last login: Sat Feb  6 23:31:44 2021 from 192.168.6.4
OpenBSD 6.8 (GENERIC.MP) #4: Mon Jan 11 10:35:56 MST 2021

Welcome to OpenBSD: The proactively secure Unix-like operating system.

Please use the sendbug(1) utility to report bugs in the system.
Before reporting a bug, please try to reproduce it with the latest
version of the code.  With bug reports, please try to ensure that
enough information to reproduce the problem is enclosed, and if a
known fix for it exists, include that as well.

lnms$


lnms$ ssh au...@xen1.int.autonlab.org 
au...@xen1.int.autonlab.org's password: 
Welcome to Alpine!

The Alpine Wiki contains a large amount of how-to guides and general
information about administrating Alpine systems.
See .

You can setup the system with the command: setup-alpine

You may change this message by editing /etc/motd.

Cheers,
Predrag

> Nice, fun -- and useful! -- but one thing puzzles me and prevents me
> from utilizing the full potential of the app:
> 
> I can ssh FROM any OpenBSD box INTO iSH on my iPhone, and once
> authenticated I can ssh back from there to the OpenBSD box or to any
> other OpenBSD or Linux box, but! -- From iSH itself (ie. "directly"
> from my iPhone) I can only successfully ssh to Linux boxes; if I ssh
> from the phone itself to any OpenBSD box I'm getting authenticated and
> receive a full shell prompt but the moment I hit Enter the client
> drops the connection.
> 
> Summarized:
> 
> ssh FAILS from iSH > to OpenBSD
> ssh WORKS from iSH > to Linux
> ssh WORKS from OpenBSD > to iSH (and from iSH (back) to Linux/OpenBSD)
> 
> I guess there must be something obvious I'm missing but for the life
> of me I cannot figure out what. Any help is appreciated.
> 
> Not sure what logs, if any, I should supply. Running ssh -v[vv]
> (verbose) doesnt yield any difference between working and non-working
> connections, and it's the same with /var/log/auth.log as far as I can
> see.
> 
> Cheers,
> Erling

Re: seeing carp interface state change for unknown reason ; cluestick hunting

[Markus Wernig]

On 2/7/21 1:38 AM, Bryan Stenson wrote:


   31 RTM_IFINFO: iface status change: len 168, if# 3, name cnmac2,
link: no carrier, mtu: 1500,



Just grasping for something here...my next steps are to swap this unit
out with the other one (to try and eliminate hardware failure of THIS
unit).  Any other suggestions?


Check the switch interface for any errors and messages.

Re: seeing carp interface state change for unknown reason ; cluestick hunting

[Bryan Stenson]

Thanks for the response.  I've mounted a ramdisk at /mnt and have run
"doas route -n monitor > /mnt/route.monitor" in a tmux session for a
few days.  Here are some details:

erl3-01$ grep carp1 route.monitor  | sort | uniq -c
  91 RTM_ADD: Add Route: len 192, priority 146, table 0, if# 6, name
carp1, pid: 0, seq 0, errno 0
 428 RTM_ADD: Add Route: len 192, priority 18, table 0, if# 6, name
carp1, pid: 0, seq 0, errno 0
  43 RTM_DELETE: Delete Route: len 192, priority 146, table 0, if# 6,
name carp1, pid: 0, seq 0, errno 0
 478 RTM_DELETE: Delete Route: len 192, priority 18, table 0, if# 6,
name carp1, pid: 0, seq 0, errno 0
  31 RTM_IFINFO: iface status change: len 168, if# 6, name carp1,
link: backup, mtu: 1500,
flags:
  31 RTM_IFINFO: iface status change: len 168, if# 6, name carp1,
link: invalid, mtu: 1500, flags:
  31 RTM_IFINFO: iface status change: len 168, if# 6, name carp1,
link: master, mtu: 1500,
flags:
   1 RTM_RESOLVE: Route created by cloning: len 192, priority 146,
table 0, if# 6, name carp1, pid: 0, seq 0, errno 0
 385 RTM_RESOLVE: Route created by cloning: len 192, priority 18,
table 0, if# 6, name carp1, pid: 0, seq 0, errno 0

erl3-01$ grep vlan100 route.monitor  | sort | uniq -c
  31 RTM_IFINFO: iface status change: len 168, if# 8, name vlan100,
link: active, mtu: 1500,
flags:
  31 RTM_IFINFO: iface status change: len 168, if# 8, name vlan100,
link: no carrier, mtu: 1500,
flags:

erl3-01$ grep cnmac2 route.monitor  | sort | uniq -c
  57 RTM_ADD: Add Route: len 192, priority 3, table 0, if# 3, name
cnmac2, pid: 0, seq 0, errno 0
  57 RTM_DELETE: Delete Route: len 192, priority 3, table 0, if# 3,
name cnmac2, pid: 0, seq 0, errno 0
  31 RTM_IFINFO: iface status change: len 168, if# 3, name cnmac2,
link: active, mtu: 1500,
flags:
  31 RTM_IFINFO: iface status change: len 168, if# 3, name cnmac2,
link: no carrier, mtu: 1500,
flags:

It looks like the underlying cnmac2 interface is flapping...so, that's a bummer.

As generally underpowered as this machine is, might the kernel be
overwhelmed with other tasks, and have a watchdog timeout mark the
cnmac2 interface as down (due to some expired timeout)?

Just grasping for something here...my next steps are to swap this unit
out with the other one (to try and eliminate hardware failure of THIS
unit).  Any other suggestions?

On Mon, Feb 1, 2021 at 3:04 AM David Gwynne  wrote:
>
>
>
> > On 1 Feb 2021, at 6:02 pm, Bryan Stenson  wrote:
> >
> > Hi all -
> >
> > I'm trying to setup a pair of ERL3 octeon routers in master/standby
> > mode via carp/pfsync to route traffic from my internal lan to the
> > internet.  I've seen strange behavior wrt carp on these machines, so
> > in an attempt to reduce the problem, I've removed one completely.
> >
> > Even with only a single box (ERL3-01) on the network configured as a
> > carp member, the carp interface state periodically changes (as seen
> > from ifstated(8)).
> >
> > I'm wondering if disconnecting the other ERL3 device is a valid isolated 
> > test.
> > 1.  Will/might this cause issues with the carp device, as it cannot
> > determine state from any other host?
>
> If carp state flaps around while it is the only device on the network, that 
> would imply the parent device is flapping around.
>
> > 2.  Will/might this cause issues as it cannot send/receive pfsync
> > updates (the other node is disconnected).
>
> pfsync doesn't really care about carp state.
>
> > 3.  Is there something else in my setup causing carp to fail here?
>
> I'd be running "route monitor" and looking for link state changes on the carp 
> parent interface.
>
> > 4.  Could this be hardware/temperature related to this ERL3?  Wouldn't
> > I see an additional error in dmesg if the physical device (cnmac2)
> > failed periodically?
> >
> > I'd appreciate any pointers here...I feel like I'm missing something dumb.
>
> My first ideas are above. If it turns out the carp parent is stable we can 
> try come up with something else.
>
> dlg
>
> >
> > Thanks in advance.
> >
> > Bryan
> >
> > Here are some of my configs.  If I've missed including something
> > critical to help describe my setup, please let me know and I'll add
> > it.
> >
> > ## Help me OBSD-Misc Kenobi.  You're my only hope. ##
> >
> > erl3-01# uname -a
> > OpenBSD erl3-01.siliconvortex.com 6.8 GENERIC#522 octeon
> >
> > erl3-01# dmesg
> > ...
> > carp1: state transition: BACKUP -> MASTER
> > carp1: state transition: BACKUP -> MASTER
> > carp1: state transition: BACKUP -> MASTER
> > carp1: state transition: BACKUP -> MASTER
> > carp1: state transition: BACKUP -> MASTER
> > carp1: state transition: BACKUP -> MASTER
> >
> > erl3-01# tail mbox
> > Mon, 1 Feb 2021 06:49:26 + (UTC)
> > From: Charlie Root 
> > Date: Mon, 1 Feb 2021 06:49:25 + (UTC)
> > To: root@localhost
> > Subject: carp master changed
> > Message-ID: <515eb74cff427...@erl3-01.siliconvortex.com>
> > Status: RO
> >
> > master is now erl3-01.siliconvortex.com
> >
> >
> > erl3-01# sysctl -a | grep carp
> > net.ine

Re: Help with ssh(1) between OpenBSD and iSH/Alpine on iOS

[Christian Weisgerber]

Erling Westenvik:

> I can ssh FROM any OpenBSD box INTO iSH on my iPhone, and once
> authenticated I can ssh back from there to the OpenBSD box or to any
> other OpenBSD or Linux box, but! -- From iSH itself (ie. "directly" from
> my iPhone) I can only successfully ssh to Linux boxes; if I ssh from the
> phone itself to any OpenBSD box I'm getting authenticated and receive a
> full shell prompt

Right here, I'd start ktrace(1)-ing the login shell on the OpenBSD
box to see...

> but the moment I hit Enter the client drops the connection.

... what this looks like at the OpenBSD end.

> ssh FAILS from iSH > to OpenBSD
> ssh WORKS from iSH > to Linux
> ssh WORKS from OpenBSD > to iSH (and from iSH (back) to Linux/OpenBSD)
> 
> I guess there must be something obvious I'm missing but for the life of
> me I cannot figure out what. Any help is appreciated.

I don't think it's anything obvious.  Smells like an interop problem
at a level above SSH to me.

-- 
Christian "naddy" Weisgerber  na...@mips.inka.de

Help with ssh(1) between OpenBSD and iSH/Alpine on iOS

[Erling Westenvik]

Hi,
Last year I discovered the iSH app, "The Linux shell for iOS"
(https:/ish.app), "a project to get a Linux shell environment running
locally on your iOS device, using a usermode x86 emulator". It's an
Alpine Linux distribution with the Almquist shell (ash) as default.
Nice, fun -- and useful! -- but one thing puzzles me and prevents me
from utilizing the full potential of the app:

I can ssh FROM any OpenBSD box INTO iSH on my iPhone, and once
authenticated I can ssh back from there to the OpenBSD box or to any
other OpenBSD or Linux box, but! -- From iSH itself (ie. "directly" from
my iPhone) I can only successfully ssh to Linux boxes; if I ssh from the
phone itself to any OpenBSD box I'm getting authenticated and receive a
full shell prompt but the moment I hit Enter the client drops the
connection.

Summarized:

ssh FAILS from iSH > to OpenBSD
ssh WORKS from iSH > to Linux
ssh WORKS from OpenBSD > to iSH (and from iSH (back) to Linux/OpenBSD)

I guess there must be something obvious I'm missing but for the life of
me I cannot figure out what. Any help is appreciated.

Not sure what logs, if any, I should supply. Running ssh -v[vv]
(verbose) doesnt yield any difference between working and non-working
connections, and it's the same with /var/log/auth.log as far as I can
see.

Cheers,
Erling

Re: Unknown process modifying routing table

[Claudio Jeker]

On Sat, Feb 06, 2021 at 02:16:20PM +0100, Otto Moerbeek wrote:
> On Sat, Feb 06, 2021 at 12:18:40PM +, James wrote:
> 
> > I've disabled my VPN on the machine as well as dhclient, connecting via a
> > fixed static IP address and DNS servers. My routing table is still being
> > modifed by PID 0 (which I assume to be the kernel) every 30 minutes or so.
> > Ntpd is also disabled.
> > 
> > I have also caught my machine communicating to one the of the IPs via TCP
> > and have a pcap dump from wireshark. No actual data was sent other than a
> > TCP timestamp.
> > 
> > > If your default route is a VPN,
> > > please show how you establish the VPN to be your default route.
> > > 
> > The default route is established mannually in a script that is run after the
> > VPN starts. Essentially it does the following:
> > 
> >     route add $VPN_HOST $DEFAULT_GW
> > 
> >     route change default $VPN_HOST
> > 
> > 
> > I do not belive the VPN to be the cause of this problem.
> > 
> > 
> > Any tips on debugging the kernel to track the cause of these route changes
> > would be greatly appreciated.
> > 
> > 
> > Thanks,
> > 
> 
> The kernel uses the routing table to store things like PMTU discovery
> data and ARP entries,
> 

Also showing the route -n monitor output will help to identify what is
going on.

-- 
:wq Claudio

Re: Unknown process modifying routing table

[James]

I've disabled my VPN on the machine as well as dhclient, connecting via 
a fixed static IP address and DNS servers. My routing table is still 
being modifed by PID 0 (which I assume to be the kernel) every 30 
minutes or so. Ntpd is also disabled.


I have also caught my machine communicating to one the of the IPs via 
TCP and have a pcap dump from wireshark. No actual data was sent other 
than a TCP timestamp.



If your default route is a VPN,
please show how you establish the VPN to be your default route.

The default route is established mannually in a script that is run after 
the VPN starts. Essentially it does the following:


    route add $VPN_HOST $DEFAULT_GW

    route change default $VPN_HOST


I do not belive the VPN to be the cause of this problem.


Any tips on debugging the kernel to track the cause of these route 
changes would be greatly appreciated.



Thanks,

Re: rdsetroot and gzip'd bsd.rd

[Daniel Jakots]

On Tue, 2 Feb 2021 15:29:12 +0100, Sebastien Marie 
wrote:

> On Mon, Feb 01, 2021 at 08:30:17PM -0500, Daniel Jakots wrote:
> > On Mon, 01 Feb 2021 18:18:43 -0700, "Theo de Raadt"
> >  wrote:
> >   
> > > Should rdsetroot be able to edit gzip'd files?  I am not sure
> > > about that.  
> > 
> > Yeah, I don't think so either. gzip(1) can be easily used to
> > uncompress it beforehand. 
> > 
> > But the result is still that rdsetroot on -current is not able to
> > extract a bsd.rd even when given an uncompressed bsd.rd (i.e. a "ELF
> > 64-bit LSB executable, x86-64, version 1" bsd.rd).
> >   
> 
> I looked at what it is done for amd64/ramdisk_cd
> 
> bsd.rd target is made from bsd (kernel) + mr.fs (rdboot filesystem)
> with rdsetroot(8) bsd.gz target is made from bsd.rd with strip(1) +
> gzip(1).
> 
> with current method, it is bsd.gz which is installed in RELEASEDIR as
> bsd.rd file.
> 
> 
> the problem is rdsetroot(8) doesn't support extracting the mr.fs part
> from image when the image is stripped: it expects to find
> "rd_root_size" and "rd_root_image" symbols to locate the size and the
> offset of the mr.fs part inside the image.
> 
> It is possible to use strip with -K rd_root_size -K rd_root_image
> option to preserve these specifics symbols (and make rdsetroot -x to
> work again). I tested it successfully on i386.
> 
> diff a6394f126ec0ed0606e8aac07a82ab1a4c4f2988
> /home/semarie/repos/openbsd/src blob -
> 77fdc3e10fc525e725a40528b728c06976eefc06 file +
> distrib/i386/ramdisk_cd/Makefile --- distrib/i386/ramdisk_cd/Makefile
> +++ distrib/i386/ramdisk_cd/Makefile
> @@ -56,8 +56,8 @@ MRMAKEFSARGS=   -o
> disklabel=${MRDISKTYPE},minfree=0,den 
>  bsd.gz: bsd.rd
>   cp bsd.rd bsd.strip
> - strip bsd.strip
> - strip -R .comment -R .SUNW_ctf bsd.strip
> + strip -K rd_root_size -K rd_root_image bsd.strip
> + strip -K rd_root_size -K rd_root_image -R .comment -R
> .SUNW_ctf bsd.strip gzip -9cn bsd.strip > bsd.gz
>  
>  bsd.rd: mr.fs bsd
>
> Please note that the second strip call need -K option too, else the
> symtab is removed. I am a bit surprised by this behaviour.
> 
> I am unsure I will be able to provide a patch for all
> architectures. Please comment if the direction is right or not.
> 
> Thanks.

Thanks for looking at it!

I built a release (without the xenocara part) to test a similar diff to
yours for amd64 (I didn't know which bsd.rd was which, so I did both):

Index: ramdiskA/Makefile
===
RCS file: /cvs/src/distrib/amd64/ramdiskA/Makefile,v
retrieving revision 1.10
diff -u -p -r1.10 Makefile
--- ramdiskA/Makefile   18 May 2020 06:20:43 -  1.10
+++ ramdiskA/Makefile   5 Feb 2021 19:01:06 -
@@ -36,8 +36,8 @@ MRMAKEFSARGS= -o disklabel=${MRDISKTYPE}
 
 bsd.gz: bsd.rd
cp bsd.rd bsd.strip
-   strip bsd.strip
-   strip -R .comment -R .SUNW_ctf bsd.strip
+   strip -K rd_root_size -K rd_root_image bsd.strip
+   strip -K rd_root_size -K rd_root_image -R .comment -R .SUNW_ctf 
bsd.strip
gzip -9cn bsd.strip > bsd.gz
 
 bsd.rd: mr.fs bsd
cvs server: Diffing ramdisk_cd
Index: ramdisk_cd/Makefile
===
RCS file: /cvs/src/distrib/amd64/ramdisk_cd/Makefile,v
retrieving revision 1.24
diff -u -p -r1.24 Makefile
--- ramdisk_cd/Makefile 5 Jan 2021 15:10:42 -   1.24
+++ ramdisk_cd/Makefile 5 Feb 2021 19:01:06 -
@@ -59,8 +59,8 @@ MRMAKEFSARGS= -o disklabel=${MRDISKTYPE}
 
 bsd.gz: bsd.rd
cp bsd.rd bsd.strip
-   strip bsd.strip
-   strip -R .comment -R .SUNW_ctf bsd.strip
+   strip -K rd_root_size -K rd_root_image bsd.strip
+   strip -K rd_root_size -K rd_root_image -R .comment -R .SUNW_ctf 
bsd.strip
gzip -9cn bsd.strip > bsd.gz
 
 bsd.rd: mr.fs bsd


And it works:
$ doas cp /home/RELEASEDIR/bsd.rd . 
   
$ mv bsd.rd bsd.rd.gz   
   
$ gunzip bsd.rd.gz  
   
$ doas rdsetroot -x bsd.rd disk.fs  
   
$ file disk.fs  
   
disk.fs: Unix Fast File system [v1] (little-endian), last mounted on , last 
written at Fri Feb  5 18:06:46 2021, clean flag 1, number of blocks 7360, 
number of data blocks 7071, number of cylinder groups 1, block size 4096, 
fragment size 512, minimum percentage of free blocks 0, rotational delay 0ms, 
disk rotational speed 60rps, SPACE optimization


Thanks,
Daniel

Re: Unknown process modifying routing table

[Otto Moerbeek]

On Sat, Feb 06, 2021 at 12:18:40PM +, James wrote:

> I've disabled my VPN on the machine as well as dhclient, connecting via a
> fixed static IP address and DNS servers. My routing table is still being
> modifed by PID 0 (which I assume to be the kernel) every 30 minutes or so.
> Ntpd is also disabled.
> 
> I have also caught my machine communicating to one the of the IPs via TCP
> and have a pcap dump from wireshark. No actual data was sent other than a
> TCP timestamp.
> 
> > If your default route is a VPN,
> > please show how you establish the VPN to be your default route.
> > 
> The default route is established mannually in a script that is run after the
> VPN starts. Essentially it does the following:
> 
>     route add $VPN_HOST $DEFAULT_GW
> 
>     route change default $VPN_HOST
> 
> 
> I do not belive the VPN to be the cause of this problem.
> 
> 
> Any tips on debugging the kernel to track the cause of these route changes
> would be greatly appreciated.
> 
> 
> Thanks,
> 

The kernel uses the routing table to store things like PMTU discovery
data and ARP entries,

-Otto

Re: Unknown process modifying routing table

[Jan Stary]

On Jan 26 15:10:03, ja...@jmp-e.com wrote:
> 
> Hi all,
> 
> My routing table is being modified by an unknown process.
> 
> I have system accounting enabled and I'm monitoring route changes
> but the PID of the process reported by `route monitor` is always 0
> for these unknown changes.
> 
> I've seen my default route (VPN) being deleted and new routes being
> added for specific IPs. I'm out of ideas how to find out what process
> is modifying my routing table.

If your default route is a VPN,
please show how you establish the VPN to be your default route.

> Here are the logs:
> 
> bash-5.0# route -n show
> Routing tables
> 
> Internet:
> DestinationGatewayFlags   Refs  Use   Mtu  Prio Iface
> default10.0.0.1   UGS   15  635 - 8 pair1
> 224/4  127.0.0.1  URS00 32768 8 lo0
> 10.0.0/24  10.0.0.2   UCn10 - 4 pair1
> 10.0.0.1   xx:xx:xx:xx:xx:xx  UHLch 20   76 - 3 pair1
> 10.0.0.2   xx:xx:xx:xx:xx:xx  UHLl   0  251 - 1 pair1
> 10.0.0.255 10.0.0.2   UHb00 - 1 pair1
> 10.2.0.1   10.0.0.1   UGHD   1  599 - L   8 pair1
> 13.35.193.117  10.0.0.1   UGHD   1  616 - L   8 pair1
> 13.224.227.64  10.0.0.1   UGHD   1  611 - L   8 pair1
> 52.48.109.111  10.0.0.1   UGHD   1  614 - L   8 pair1
> 52.84.91.7 10.0.0.1   UGHD   1  574 - L   8 pair1
> 99.84.5.23010.0.0.1   UGHD   1  620 - L   8 pair1
> 104.16.9.251   10.0.0.1   UGHD   0  289  1350 8 pair1
> 104.16.241.18  10.0.0.1   UGHD   1  610 - L   8 pair1
> 104.18.26.20   10.0.0.1   UGHD   1  609 - L   8 pair1
> 104.21.22.28   10.0.0.1   UGHD   1  617 - L   8 pair1
> 108.177.120.13610.0.0.1   UGHD   1  625 - L   8 pair1
> 127/8  127.0.0.1  UGRS   00 32768 8 lo0
> 127.0.0.1  127.0.0.1  UHhl   8 7322 32768 1 lo0
> 140.82.121.3   10.0.0.1   UGHD   1  636 - L   8 pair1
> 142.250.186.12910.0.0.1   UGHD   1  604 - L   8 pair1
> 157.230.120.63 10.0.0.1   UGHD   1  596 - L   8 pair1
> 172.67.203.118 10.0.0.1   UGHD   1  607 - L   8 pair1
> 172.217.169.86 10.0.0.1   UGHD   1  632 - L   8 pair1
> 185.199.111.15410.0.0.1   UGHD   2  633 - L   8 pair1
> 216.58.206.132 10.0.0.1   UGHD   1  624 - L   8 pair1
> 216.58.212.227 10.0.0.1   UGHD   1  629 - L   8 pair1

> The routes for 216.58.212.227, 216.58.206.132, 185.199.111.154,
> 172.217.169.86, 172.67.203.118, 157.230.120.63, 142.250.186.129,
> 140.82.121.3, 108.177.120.136, 104.21.22.28, 104.18.26.20,
> 104.16.241.18, 104.16.9.251, 99.84.5.230, 52.48.109.111, 52.84.5.230,
> 13.224.227.64, 13.35.193.117 are completely unknown and not added by
> myself.

These are probably added by your VPN setup.

Jan