Re: ipv6 via ipsec tunnel

2019-03-14 Thread Otto Moerbeek
On Fri, Mar 15, 2019 at 07:48:55AM +0100, Otto Moerbeek wrote:

> On Fri, Mar 15, 2019 at 04:44:52PM +1000, David Gwynne wrote:
> 
> > 
> > 
> > > On 15 Mar 2019, at 16:37, Otto Moerbeek  wrote:
> > > 
> > > On Fri, Mar 15, 2019 at 04:15:55PM +1000, David Gwynne wrote:
> > > 
> > >> 
> > >> 
> > >>> On 14 Mar 2019, at 19:36, Otto Moerbeek  wrote:
> > >>> 
> > >>> Hi,
> > >>> 
> > >>> So i have a little IPv6 problem. 
> > >>> 
> > >>> I have a machine in colocation that has IPv6. I have my home cable
> > >>> modem connection that does not have it.
> > >>> 
> > >>> So I thought: I make my own tunnel. First I tried gif(4), that worked,
> > >>> but only after some fighting with mtu settings on all hosts on my home
> > >>> net via rad.  Performance was kinda bad. So I'm looking for an
> > >>> alternative. I thougt: IPSEC should be able to do this.
> > >>> 
> > >>> I have a flow from my locally created IPv6 net to any and vice versa.
> > >>> THe flow itself works. 
> > >>> 
> > >>> There I ran into the trouble that you cannot specify a default
> > >>> gateway, since my remote gw (the host in colo) it is not reachable
> > >>> according to route(8).
> > >>> 
> > >>> How does one solve the default route problem?  I never really
> > >>> understood how routing works in the presense of IPSEC flows.
> > >> 
> > >> Can you elaborate on what gif and slow meant? Also, you should be able 
> > >> to use gif with whatever MTU you want, even 1500 on the gif interface 
> > >> and fragments over the internet. You could also try gre, but I doubt it 
> > >> would be different to gif in terms of performance and support for 
> > >> MTU/fragmentation.
> > >> 
> > >> If you want ipsec and routes, you would still use tunnel and get IPsec 
> > >> to protect it. Or you could trick someone into making something like 
> > >> Cisco's vti a thing in OpenBSD.
> > >> 
> > >> dlg
> > > 
> > > gif tunnel:
> > > 
> > > ifconfig gif0 inet6 2a02:898:216:3::2 2a02:898:216:3::1 prefixlen 128
> > > 
> > > and viceversa on th eother end.
> > > 
> > > So gif tunnel with default options. With that it showed an an mtu of
> > > 1280 in ifconfig so I assumed that would be the max. I have a
> > > 200 Mb/s cable connection. Downloading IPv4 I reach that. With IPV6
> > > often it would be 10% of that. Plus it would only work reliably if the
> > > hosts in my net use an mtu of 1280 (manually or via rad).
> > 
> > I wonder why PMTUD isn't working in this situation.
> > 
> > > I now have a ipsec tunnel and that does 55 Mb/s (APU2 on both
> > > ends) without any need for config on the hosts in my local net.
> > 
> > Did you have to clamp your internal MTU for that to work too?
> 
> Nope, like I said nothing special. I run rand without any options on

Make that rad(8)

> the gw and just inet6 autoconf on the hosts.
> 
> > 
> > dlg
> 



Re: ipv6 via ipsec tunnel

2019-03-14 Thread Otto Moerbeek
On Fri, Mar 15, 2019 at 04:44:52PM +1000, David Gwynne wrote:

> 
> 
> > On 15 Mar 2019, at 16:37, Otto Moerbeek  wrote:
> > 
> > On Fri, Mar 15, 2019 at 04:15:55PM +1000, David Gwynne wrote:
> > 
> >> 
> >> 
> >>> On 14 Mar 2019, at 19:36, Otto Moerbeek  wrote:
> >>> 
> >>> Hi,
> >>> 
> >>> So i have a little IPv6 problem. 
> >>> 
> >>> I have a machine in colocation that has IPv6. I have my home cable
> >>> modem connection that does not have it.
> >>> 
> >>> So I thought: I make my own tunnel. First I tried gif(4), that worked,
> >>> but only after some fighting with mtu settings on all hosts on my home
> >>> net via rad.  Performance was kinda bad. So I'm looking for an
> >>> alternative. I thougt: IPSEC should be able to do this.
> >>> 
> >>> I have a flow from my locally created IPv6 net to any and vice versa.
> >>> THe flow itself works. 
> >>> 
> >>> There I ran into the trouble that you cannot specify a default
> >>> gateway, since my remote gw (the host in colo) it is not reachable
> >>> according to route(8).
> >>> 
> >>> How does one solve the default route problem?  I never really
> >>> understood how routing works in the presense of IPSEC flows.
> >> 
> >> Can you elaborate on what gif and slow meant? Also, you should be able to 
> >> use gif with whatever MTU you want, even 1500 on the gif interface and 
> >> fragments over the internet. You could also try gre, but I doubt it would 
> >> be different to gif in terms of performance and support for 
> >> MTU/fragmentation.
> >> 
> >> If you want ipsec and routes, you would still use tunnel and get IPsec to 
> >> protect it. Or you could trick someone into making something like Cisco's 
> >> vti a thing in OpenBSD.
> >> 
> >> dlg
> > 
> > gif tunnel:
> > 
> > ifconfig gif0 inet6 2a02:898:216:3::2 2a02:898:216:3::1 prefixlen 128
> > 
> > and viceversa on th eother end.
> > 
> > So gif tunnel with default options. With that it showed an an mtu of
> > 1280 in ifconfig so I assumed that would be the max. I have a
> > 200 Mb/s cable connection. Downloading IPv4 I reach that. With IPV6
> > often it would be 10% of that. Plus it would only work reliably if the
> > hosts in my net use an mtu of 1280 (manually or via rad).
> 
> I wonder why PMTUD isn't working in this situation.
> 
> > I now have a ipsec tunnel and that does 55 Mb/s (APU2 on both
> > ends) without any need for config on the hosts in my local net.
> 
> Did you have to clamp your internal MTU for that to work too?

Nope, like I said nothing special. I run rand without any options on
the gw and just inet6 autoconf on the hosts.

> 
> dlg



Re: ipv6 via ipsec tunnel

2019-03-14 Thread David Gwynne



> On 15 Mar 2019, at 16:37, Otto Moerbeek  wrote:
> 
> On Fri, Mar 15, 2019 at 04:15:55PM +1000, David Gwynne wrote:
> 
>> 
>> 
>>> On 14 Mar 2019, at 19:36, Otto Moerbeek  wrote:
>>> 
>>> Hi,
>>> 
>>> So i have a little IPv6 problem. 
>>> 
>>> I have a machine in colocation that has IPv6. I have my home cable
>>> modem connection that does not have it.
>>> 
>>> So I thought: I make my own tunnel. First I tried gif(4), that worked,
>>> but only after some fighting with mtu settings on all hosts on my home
>>> net via rad.  Performance was kinda bad. So I'm looking for an
>>> alternative. I thougt: IPSEC should be able to do this.
>>> 
>>> I have a flow from my locally created IPv6 net to any and vice versa.
>>> THe flow itself works. 
>>> 
>>> There I ran into the trouble that you cannot specify a default
>>> gateway, since my remote gw (the host in colo) it is not reachable
>>> according to route(8).
>>> 
>>> How does one solve the default route problem?  I never really
>>> understood how routing works in the presense of IPSEC flows.
>> 
>> Can you elaborate on what gif and slow meant? Also, you should be able to 
>> use gif with whatever MTU you want, even 1500 on the gif interface and 
>> fragments over the internet. You could also try gre, but I doubt it would be 
>> different to gif in terms of performance and support for MTU/fragmentation.
>> 
>> If you want ipsec and routes, you would still use tunnel and get IPsec to 
>> protect it. Or you could trick someone into making something like Cisco's 
>> vti a thing in OpenBSD.
>> 
>> dlg
> 
> gif tunnel:
> 
> ifconfig gif0 inet6 2a02:898:216:3::2 2a02:898:216:3::1 prefixlen 128
> 
> and viceversa on th eother end.
> 
> So gif tunnel with default options. With that it showed an an mtu of
> 1280 in ifconfig so I assumed that would be the max. I have a
> 200 Mb/s cable connection. Downloading IPv4 I reach that. With IPV6
> often it would be 10% of that. Plus it would only work reliably if the
> hosts in my net use an mtu of 1280 (manually or via rad).

I wonder why PMTUD isn't working in this situation.

> I now have a ipsec tunnel and that does 55 Mb/s (APU2 on both
> ends) without any need for config on the hosts in my local net.

Did you have to clamp your internal MTU for that to work too?

dlg



Re: ipv6 via ipsec tunnel

2019-03-14 Thread Otto Moerbeek
On Fri, Mar 15, 2019 at 04:15:55PM +1000, David Gwynne wrote:

> 
> 
> > On 14 Mar 2019, at 19:36, Otto Moerbeek  wrote:
> > 
> > Hi,
> > 
> > So i have a little IPv6 problem. 
> > 
> > I have a machine in colocation that has IPv6. I have my home cable
> > modem connection that does not have it.
> > 
> > So I thought: I make my own tunnel. First I tried gif(4), that worked,
> > but only after some fighting with mtu settings on all hosts on my home
> > net via rad.  Performance was kinda bad. So I'm looking for an
> > alternative. I thougt: IPSEC should be able to do this.
> > 
> > I have a flow from my locally created IPv6 net to any and vice versa.
> > THe flow itself works. 
> > 
> > There I ran into the trouble that you cannot specify a default
> > gateway, since my remote gw (the host in colo) it is not reachable
> > according to route(8).
> > 
> > How does one solve the default route problem?  I never really
> > understood how routing works in the presense of IPSEC flows.
> 
> Can you elaborate on what gif and slow meant? Also, you should be able to use 
> gif with whatever MTU you want, even 1500 on the gif interface and fragments 
> over the internet. You could also try gre, but I doubt it would be different 
> to gif in terms of performance and support for MTU/fragmentation.
> 
> If you want ipsec and routes, you would still use tunnel and get IPsec to 
> protect it. Or you could trick someone into making something like Cisco's vti 
> a thing in OpenBSD.
> 
> dlg

gif tunnel:

ifconfig gif0 inet6 2a02:898:216:3::2 2a02:898:216:3::1 prefixlen 128

and viceversa on th eother end.

So gif tunnel with default options. With that it showed an an mtu of
1280 in ifconfig so I assumed that would be the max. I have a
200 Mb/s cable connection. Downloading IPv4 I reach that. With IPV6
often it would be 10% of that. Plus it would only work reliably if the
hosts in my net use an mtu of 1280 (manually or via rad).

I now have a ipsec tunnel and that does 55 Mb/s (APU2 on both
ends) without any need for config on the hosts in my local net.

-Otto



Re: ipv6 via ipsec tunnel

2019-03-14 Thread David Gwynne



> On 14 Mar 2019, at 19:36, Otto Moerbeek  wrote:
> 
> Hi,
> 
> So i have a little IPv6 problem. 
> 
> I have a machine in colocation that has IPv6. I have my home cable
> modem connection that does not have it.
> 
> So I thought: I make my own tunnel. First I tried gif(4), that worked,
> but only after some fighting with mtu settings on all hosts on my home
> net via rad.  Performance was kinda bad. So I'm looking for an
> alternative. I thougt: IPSEC should be able to do this.
> 
> I have a flow from my locally created IPv6 net to any and vice versa.
> THe flow itself works. 
> 
> There I ran into the trouble that you cannot specify a default
> gateway, since my remote gw (the host in colo) it is not reachable
> according to route(8).
> 
> How does one solve the default route problem?  I never really
> understood how routing works in the presense of IPSEC flows.

Can you elaborate on what gif and slow meant? Also, you should be able to use 
gif with whatever MTU you want, even 1500 on the gif interface and fragments 
over the internet. You could also try gre, but I doubt it would be different to 
gif in terms of performance and support for MTU/fragmentation.

If you want ipsec and routes, you would still use tunnel and get IPsec to 
protect it. Or you could trick someone into making something like Cisco's vti a 
thing in OpenBSD.

dlg



Re: cleanup FBSDID

2019-03-14 Thread Kevin Lo
Here's the revised diff that removes $FreeBSD$ IDs from my previous diff.

Index: lib/libc/arch/amd64/sys/tfork_thread.S
===
RCS file: /cvs/src/lib/libc/arch/amd64/sys/tfork_thread.S,v
retrieving revision 1.6
diff -u -p -u -p -r1.6 tfork_thread.S
--- lib/libc/arch/amd64/sys/tfork_thread.S  7 May 2016 19:05:21 -   
1.6
+++ lib/libc/arch/amd64/sys/tfork_thread.S  15 Mar 2019 03:37:05 -
@@ -27,9 +27,6 @@
  */
 
 #include 
-#if 0
-__FBSDID("$FreeBSD: /repoman/r/ncvs/src/lib/libc/amd64/gen/rfork_thread.S,v 
1.1 2003/10/13 20:32:33 alc Exp $");
-#endif
 
 /*
  * With thanks to John Dyson for the original version of this.
Index: lib/libc/arch/i386/sys/tfork_thread.S
===
RCS file: /cvs/src/lib/libc/arch/i386/sys/tfork_thread.S,v
retrieving revision 1.8
diff -u -p -u -p -r1.8 tfork_thread.S
--- lib/libc/arch/i386/sys/tfork_thread.S   7 May 2016 19:05:21 -   
1.8
+++ lib/libc/arch/i386/sys/tfork_thread.S   15 Mar 2019 03:37:05 -
@@ -26,9 +26,6 @@
  */
 
 #include 
-#if 0
-__FBSDID("$FreeBSD: /repoman/r/ncvs/src/lib/libc/i386/gen/rfork_thread.S,v 1.5 
2003/05/07 17:23:25 jhb Exp $");
-#endif
 
 /*
  * With thanks to John Dyson for the original version of this.
Index: lib/libc/arch/sparc64/fpu/fpu_add.c
===
RCS file: /cvs/src/lib/libc/arch/sparc64/fpu/fpu_add.c,v
retrieving revision 1.2
diff -u -p -u -p -r1.2 fpu_add.c
--- lib/libc/arch/sparc64/fpu/fpu_add.c 5 Dec 2012 23:19:59 -   1.2
+++ lib/libc/arch/sparc64/fpu/fpu_add.c 15 Mar 2019 03:37:05 -
@@ -45,10 +45,6 @@
  * $NetBSD: fpu_add.c,v 1.3 1996/03/14 19:41:52 christos Exp $
  */
 
-#if 0
-__FBSDID("$FreeBSD: src/lib/libc/sparc64/fpu/fpu_add.c,v 1.4 2002/04/27 
21:56:28 jake Exp $");
-#endif
-
 /*
  * Perform an FPU add (return x + y).
  *
Index: lib/libc/arch/sparc64/fpu/fpu_compare.c
===
RCS file: /cvs/src/lib/libc/arch/sparc64/fpu/fpu_compare.c,v
retrieving revision 1.2
diff -u -p -u -p -r1.2 fpu_compare.c
--- lib/libc/arch/sparc64/fpu/fpu_compare.c 5 Dec 2012 23:19:59 -   
1.2
+++ lib/libc/arch/sparc64/fpu/fpu_compare.c 15 Mar 2019 03:37:05 -
@@ -45,10 +45,6 @@
  * $NetBSD: fpu_compare.c,v 1.3 2001/08/26 05:46:31 eeh Exp $
  */
 
-#if 0
-__FBSDID("$FreeBSD: src/lib/libc/sparc64/fpu/fpu_compare.c,v 1.4 2002/03/22 
21:52:58 obrien Exp $");
-#endif
-
 /*
  * CMP and CMPE instructions.
  *
Index: lib/libc/arch/sparc64/fpu/fpu_div.c
===
RCS file: /cvs/src/lib/libc/arch/sparc64/fpu/fpu_div.c,v
retrieving revision 1.3
diff -u -p -u -p -r1.3 fpu_div.c
--- lib/libc/arch/sparc64/fpu/fpu_div.c 26 Nov 2013 20:33:07 -  1.3
+++ lib/libc/arch/sparc64/fpu/fpu_div.c 15 Mar 2019 03:37:05 -
@@ -45,10 +45,6 @@
  * $NetBSD: fpu_div.c,v 1.2 1994/11/20 20:52:38 deraadt Exp $
  */
 
-#if 0
-__FBSDID("$FreeBSD: src/lib/libc/sparc64/fpu/fpu_div.c,v 1.3 2002/03/22 
21:52:58 obrien Exp $");
-#endif
-
 /*
  * Perform an FPU divide (return x / y).
  */
Index: lib/libc/arch/sparc64/fpu/fpu_explode.c
===
RCS file: /cvs/src/lib/libc/arch/sparc64/fpu/fpu_explode.c,v
retrieving revision 1.8
diff -u -p -u -p -r1.8 fpu_explode.c
--- lib/libc/arch/sparc64/fpu/fpu_explode.c 8 May 2016 18:41:17 -   
1.8
+++ lib/libc/arch/sparc64/fpu/fpu_explode.c 15 Mar 2019 03:37:05 -
@@ -45,10 +45,6 @@
  * $NetBSD: fpu_explode.c,v 1.5 2000/08/03 18:32:08 eeh Exp $
  */
 
-#if 0
-__FBSDID("$FreeBSD: src/lib/libc/sparc64/fpu/fpu_explode.c,v 1.5 2002/05/11 
21:20:04 jake Exp $");
-#endif
-
 /*
  * FPU subroutines: `explode' the machine's `packed binary' format numbers
  * into our internal format.
Index: lib/libc/arch/sparc64/fpu/fpu_implode.c
===
RCS file: /cvs/src/lib/libc/arch/sparc64/fpu/fpu_implode.c,v
retrieving revision 1.5
diff -u -p -u -p -r1.5 fpu_implode.c
--- lib/libc/arch/sparc64/fpu/fpu_implode.c 15 Nov 2015 22:41:43 -  
1.5
+++ lib/libc/arch/sparc64/fpu/fpu_implode.c 15 Mar 2019 03:37:05 -
@@ -45,10 +45,6 @@
  * $NetBSD: fpu_implode.c,v 1.8 2001/08/26 05:44:46 eeh Exp $
  */
 
-#if 0
-__FBSDID("$FreeBSD: src/lib/libc/sparc64/fpu/fpu_implode.c,v 1.5 2002/04/27 
21:56:28 jake Exp $");
-#endif
-
 /*
  * FPU subroutines: `implode' internal format numbers into the machine's
  * `packed binary' format.
Index: lib/libc/arch/sparc64/fpu/fpu_mul.c
===
RCS file: /cvs/src/lib/libc/arch/sparc64/fpu/fpu_mul.c,v
retrieving revision 1.2
diff -u -p -u -p -r1.2 fpu_mul.c
--- lib/libc/arch/sparc64/fpu/fpu_mul.c 5 Dec 2012 23:19:59 -   1.2
+++ lib/libc/arch/sparc64/fpu/

Re: ipv6 via ipsec tunnel

2019-03-14 Thread Claudio Jeker
On Thu, Mar 14, 2019 at 09:06:12PM +0100, Sebastian Benoit wrote:
> Claudio Jeker(cje...@diehard.n-r-g.com) on 2019.03.14 11:53:29 +0100:
> > On Thu, Mar 14, 2019 at 11:46:10AM +0100, Otto Moerbeek wrote:
> > > On Thu, Mar 14, 2019 at 10:43:03AM +0100, Claudio Jeker wrote:
> > > 
> > > > On Thu, Mar 14, 2019 at 10:36:58AM +0100, Otto Moerbeek wrote:
> > > > > Hi,
> > > > > 
> > > > > So i have a little IPv6 problem. 
> > > > > 
> > > > > I have a machine in colocation that has IPv6. I have my home cable
> > > > > modem connection that does not have it.
> > > > > 
> > > > > So I thought: I make my own tunnel. First I tried gif(4), that worked,
> > > > > but only after some fighting with mtu settings on all hosts on my home
> > > > > net via rad.  Performance was kinda bad. So I'm looking for an
> > > > > alternative. I thougt: IPSEC should be able to do this.
> > > > > 
> > > > > I have a flow from my locally created IPv6 net to any and vice versa.
> > > > > THe flow itself works. 
> > > > > 
> > > > > There I ran into the trouble that you cannot specify a default
> > > > > gateway, since my remote gw (the host in colo) it is not reachable
> > > > > according to route(8).
> > > > > 
> > > > > How does one solve the default route problem?  I never really
> > > > > understood how routing works in the presense of IPSEC flows.
> > > > > 
> > > > 
> > > > IPSec flows steal the traffic away before it is being sent out. You 
> > > > still
> > > > need routes in place to get to this point though. In your case adding a
> > > > dummy default route should work. Never tried but I think you should be
> > > > able to use the loopback for this and add a route like 'route add -inet6
> > > > default ::1' also don't forget to enable net.inet6.ip6.forwarding
> > > > 
> > > > -- 
> > > > :wq Claudio
> > > > 
> > > 
> > > Indeed, that seems to work. Thanks,
> > > 
> > 
> > You may need to use pf to block the routed IPv6 traffic on the loopback
> > or you may end up with a routing loop when the IPsec flow is not present.
> > You can use a 2nd loopback or maybe even a vether(4) and use the link
> > local address as the default gateway then dropping this traffic should be
> > trivial.
> 
> Why not "route add -inet6 default ::1 -blackhole" ?
> 

Because that would drop the packets in the forwarding path before hitting
the ipsec code. At least I thought this was the case. If that works even
better :)

-- 
:wq Claudio



xenocara: unlink libFS from the build

2019-03-14 Thread Matthieu Herrb
Hi,

all tools dealing with X font server have been already removed, and
don't seem to be missed since no one asked to re-add them in ports.

Now, libFS, the font server client library can be removed.
I've checked in sqlports and with a bulk build on amd64 that nothing
in ports in depending on it either.

ok ?

Index: lib/Makefile
===
RCS file: /cvs/OpenBSD/xenocara/lib/Makefile,v
retrieving revision 1.41
diff -u -p -u -r1.41 Makefile
--- lib/Makefile11 Sep 2018 19:34:56 -  1.41
+++ lib/Makefile14 Mar 2019 20:25:08 -
@@ -37,7 +37,7 @@ XCB_LIBS= \
 
 SUBDIR= freetype fontconfig libxtrans libXau libXdmcp ${XCB_LIBS}\
libX11  libXext  libXrender libXft libdmx libfontenc \
-   libFS libICE libSM libXt \
+   libICE libSM libXt \
libXmu libXpm libXaw libXfixes libXcomposite \
libXdamage libXcursor libXfont2  \
libXi libXinerama libxkbfile libxkbui \
Index: distrib/sets/lists/xbase/mi
===
RCS file: /cvs/OpenBSD/xenocara/distrib/sets/lists/xbase/mi,v
retrieving revision 1.118
diff -u -p -u -r1.118 mi
--- distrib/sets/lists/xbase/mi 19 Jan 2019 13:38:38 -  1.118
+++ distrib/sets/lists/xbase/mi 14 Mar 2019 20:25:09 -
@@ -206,9 +206,6 @@
 ./usr/X11R6/lib/X11/fvwm/system.fvwm2rc-sample-1
 ./usr/X11R6/lib/X11/fvwm/system.fvwm2rc-sample-2
 ./usr/X11R6/lib/X11/xman.help
-./usr/X11R6/lib/libFS.a
-./usr/X11R6/lib/libFS.la
-./usr/X11R6/lib/libFS.so.10.0
 ./usr/X11R6/lib/libICE.a
 ./usr/X11R6/lib/libICE.la
 ./usr/X11R6/lib/libICE.so.10.0
Index: distrib/sets/lists/xshare/mi
===
RCS file: /cvs/OpenBSD/xenocara/distrib/sets/lists/xshare/mi,v
retrieving revision 1.154
diff -u -p -u -r1.154 mi
--- distrib/sets/lists/xshare/mi10 Feb 2019 23:08:36 -  1.154
+++ distrib/sets/lists/xshare/mi14 Mar 2019 20:25:09 -
@@ -423,7 +423,6 @@
 ./usr/X11R6/include/X11/extensions/xtestproto.h
 ./usr/X11R6/include/X11/fonts
 ./usr/X11R6/include/X11/fonts/FS.h
-./usr/X11R6/include/X11/fonts/FSlib.h
 ./usr/X11R6/include/X11/fonts/FSproto.h
 ./usr/X11R6/include/X11/fonts/font.h
 ./usr/X11R6/include/X11/fonts/fontenc.h
@@ -713,7 +712,6 @@
 ./usr/X11R6/lib/pkgconfig/ice.pc
 ./usr/X11R6/lib/pkgconfig/inputproto.pc
 ./usr/X11R6/lib/pkgconfig/kbproto.pc
-./usr/X11R6/lib/pkgconfig/libfs.pc
 ./usr/X11R6/lib/pkgconfig/pciaccess.pc
 ./usr/X11R6/lib/pkgconfig/randrproto.pc
 ./usr/X11R6/lib/pkgconfig/recordproto.pc
@@ -3798,8 +3796,6 @@
 ./usr/X11R6/share/doc/kbproto/ch15.xml
 ./usr/X11R6/share/doc/kbproto/ch16.xml
 ./usr/X11R6/share/doc/kbproto/xkbproto.xml
-./usr/X11R6/share/doc/libFS
-./usr/X11R6/share/doc/libFS/FSlib.txt
 ./usr/X11R6/share/doc/libICE
 ./usr/X11R6/share/doc/libICE/ICElib.xml
 ./usr/X11R6/share/doc/libICE/ice.xml

-- 
Matthieu Herrb



Re: ipv6 via ipsec tunnel

2019-03-14 Thread Sebastian Benoit
Claudio Jeker(cje...@diehard.n-r-g.com) on 2019.03.14 11:53:29 +0100:
> On Thu, Mar 14, 2019 at 11:46:10AM +0100, Otto Moerbeek wrote:
> > On Thu, Mar 14, 2019 at 10:43:03AM +0100, Claudio Jeker wrote:
> > 
> > > On Thu, Mar 14, 2019 at 10:36:58AM +0100, Otto Moerbeek wrote:
> > > > Hi,
> > > > 
> > > > So i have a little IPv6 problem. 
> > > > 
> > > > I have a machine in colocation that has IPv6. I have my home cable
> > > > modem connection that does not have it.
> > > > 
> > > > So I thought: I make my own tunnel. First I tried gif(4), that worked,
> > > > but only after some fighting with mtu settings on all hosts on my home
> > > > net via rad.  Performance was kinda bad. So I'm looking for an
> > > > alternative. I thougt: IPSEC should be able to do this.
> > > > 
> > > > I have a flow from my locally created IPv6 net to any and vice versa.
> > > > THe flow itself works. 
> > > > 
> > > > There I ran into the trouble that you cannot specify a default
> > > > gateway, since my remote gw (the host in colo) it is not reachable
> > > > according to route(8).
> > > > 
> > > > How does one solve the default route problem?  I never really
> > > > understood how routing works in the presense of IPSEC flows.
> > > > 
> > > 
> > > IPSec flows steal the traffic away before it is being sent out. You still
> > > need routes in place to get to this point though. In your case adding a
> > > dummy default route should work. Never tried but I think you should be
> > > able to use the loopback for this and add a route like 'route add -inet6
> > > default ::1' also don't forget to enable net.inet6.ip6.forwarding
> > > 
> > > -- 
> > > :wq Claudio
> > > 
> > 
> > Indeed, that seems to work. Thanks,
> > 
> 
> You may need to use pf to block the routed IPv6 traffic on the loopback
> or you may end up with a routing loop when the IPsec flow is not present.
> You can use a 2nd loopback or maybe even a vether(4) and use the link
> local address as the default gateway then dropping this traffic should be
> trivial.

Why not "route add -inet6 default ::1 -blackhole" ?

> 
> -- 
> :wq Claudio
> 



Re: less(1) UTF-8 bugfix and cleanup: search.c

2019-03-14 Thread Ingo Schwarze
Hi Stefan,

Stefan Sperling wrote on Thu, Mar 14, 2019 at 04:11:00PM +0100:

> Yes, OK.

Thanks for checking.

Here is the next step outside line.c, completely cleaning up the file
less/filename.c with respect to UTF-8 handling.  The loop needed is very
similar to the one in search.c except that the case data[i] == '\0' can
occur here, resulting in a 0 return value from mbtowc(3), which has to
be counted as a binary character.

Note that the patch does change behaviour even for LC_CTYPE=C.
Currently, arcane ASCII (C0) control characters like 0x01 SOH,
0x02 STX, and so on are not counted as binary, but i think they should.
Currently, with LC_CTYPE=C, only bytes with the high bit set are
counted as binary.  The following patch counts everything as binary
except:
 * printable characters
 * whitespace characters
 * the 0x08 backspace character
 * and (with -R only) the 0x1b escape character

There is no need to handle the ASCII and UTF-8 cases separately.
With LC_CTYPE=C, the new code will advance byte by byte and count
non-ASCII bytes as binary as it should.

The third (n - i) argument to mbtowc(3) prevents buffer overruns;
no harm is done when n - i exceeds MB_CUR_MAX.

The additional, inner loop on escape sequences has no effect and
can be deleted.  The function is_ansi_middle() only returns true
for printable ASCII characters, and for those, the outer loop is
already good enough.  Neither the old nor the new code tries to
check whether the escape sequence ends in a valid or invalid manner.
One could count the ESC as binary for invalid sequences - but it
is not quite clear which sequences should be considered valid and
i don't think this minor detail is worth adding any complexity.
The function only provides crude heuristics in the first place.

This patch cleans up the only caller of the bad function binary_char(),
which can consequently be deleted.

While here, use ssize_t for the return value of read(2) rather than
int, even though it isn't a bug since the nbytes argument is always
the constant 256.  And avoid an idiom that relies on undefined
behaviour by moving p out of the buffer on read(2) failure; the
latter change does the job more portably with one variable less
on the stack.

OK?
  Ingo


Index: filename.c
===
RCS file: /cvs/src/usr.bin/less/filename.c,v
retrieving revision 1.27
diff -u -p -r1.27 filename.c
--- filename.c  26 Feb 2019 11:01:54 -  1.27
+++ filename.c  14 Mar 2019 18:15:54 -
@@ -334,25 +334,25 @@ fcomplete(char *s)
 int
 bin_file(int f)
 {
-   int n;
-   int bin_count = 0;
char data[256];
-   char *p;
-   char *pend;
+   ssize_t i, n;
+   wchar_t ch;
+   int bin_count, len;
 
if (!seekable(f))
return (0);
if (lseek(f, (off_t)0, SEEK_SET) == (off_t)-1)
return (0);
n = read(f, data, sizeof (data));
-   pend = &data[n];
-   for (p = data; p < pend; ) {
-   LWCHAR c = step_char(&p, +1, pend);
-   if (ctldisp == OPT_ONPLUS && c == ESC) {
-   do {
-   c = step_char(&p, +1, pend);
-   } while (p < pend && is_ansi_middle(c));
-   } else if (binary_char(c))
+   bin_count = 0;
+   for (i = 0; i < n; i += len) {
+   len = mbtowc(&ch, data + i, n - i);
+   if (len <= 0) {
+   bin_count++;
+   len = 1;
+   } else if (iswprint(ch) == 0 && iswspace(ch) == 0 &&
+   data[i] != '\b' &&
+   (ctldisp != OPT_ONPLUS || data[i] != ESC))
bin_count++;
}
/*
Index: charset.c
===
RCS file: /cvs/src/usr.bin/less/charset.c,v
retrieving revision 1.21
diff -u -p -r1.21 charset.c
--- charset.c   20 Apr 2017 21:23:16 -  1.21
+++ charset.c   14 Mar 2019 18:15:54 -
@@ -146,18 +146,6 @@ init_charset(void)
 }
 
 /*
- * Is a given character a "binary" character?
- */
-int
-binary_char(LWCHAR c)
-{
-   if (utf_mode)
-   return (is_ubin_char(c));
-   c &= 0377;
-   return (!isprint((unsigned char)c) && !iscntrl((unsigned char)c));
-}
-
-/*
  * Is a given character a "control" character?
  */
 int
Index: funcs.h
===
RCS file: /cvs/src/usr.bin/less/funcs.h,v
retrieving revision 1.20
diff -u -p -r1.20 funcs.h
--- funcs.h 1 Mar 2019 14:31:34 -   1.20
+++ funcs.h 14 Mar 2019 18:15:54 -
@@ -56,7 +56,6 @@ void ch_init(int, int);
 void ch_close(void);
 int ch_getflags(void);
 void init_charset(void);
-int binary_char(LWCHAR);
 int control_char(LWCHAR);
 char *prchar(LWCHAR);
 char *prutfchar(LWCHAR);



Re: less(1) UTF-8 bugfix and cleanup: search.c

2019-03-14 Thread Stefan Sperling
On Thu, Mar 14, 2019 at 04:04:20PM +0100, Ingo Schwarze wrote:
> Hi,
> 
> the following is a very simple patch to completely clean up the
> file less/search.c with respect to UTF-8 handling.  It also fixes
> an outright bug: Searching for uppercase UTF-8 characters currently
> doesn't work because passing a Unicode codepoint (in this case, the
> "ch" retrieved with step_char()) to isupper(3) is just totally
> wrong.
> 
> The new loop is fairly standard.  Invalid bytes are simply skipped.
> 
> OK?
>   Ingo
> 

Yes, OK.

> Index: search.c
> ===
> RCS file: /cvs/src/usr.bin/less/search.c,v
> retrieving revision 1.19
> diff -u -p -r1.19 search.c
> --- search.c  2 Aug 2017 19:35:57 -   1.19
> +++ search.c  14 Mar 2019 13:48:59 -
> @@ -75,12 +75,14 @@ static struct pattern_info filter_info;
>  static int
>  is_ucase(char *str)
>  {
> - char *str_end = str + strlen(str);
> - LWCHAR ch;
> + wchar_t ch;
> + int len;
>  
> - while (str < str_end) {
> - ch = step_char(&str, +1, str_end);
> - if (isupper(ch))
> + for (; *str != '\0"; str += len) {
> + if ((len = mbtowc(&ch, str, MB_CUR_MAX)) == -1) {
> + mbtowc(NULL, NULL, MB_CUR_MAX);
> + len = 1;
> + } else if (iswupper(ch))
>   return (1);
>   }
>   return (0);



less(1) UTF-8 bugfix and cleanup: search.c

2019-03-14 Thread Ingo Schwarze
Hi,

the following is a very simple patch to completely clean up the
file less/search.c with respect to UTF-8 handling.  It also fixes
an outright bug: Searching for uppercase UTF-8 characters currently
doesn't work because passing a Unicode codepoint (in this case, the
"ch" retrieved with step_char()) to isupper(3) is just totally
wrong.

The new loop is fairly standard.  Invalid bytes are simply skipped.

OK?
  Ingo


P.S.
I'm sending this even though my pappend() patch
  https://marc.info/?l=openbsd-tech&m=155249735725712
is still looking for review.

Both are touching different files and are independent of each other.
The cleanup is now maybe about half done with only one or two
functions remaining in the most affected file line.c, but the files
cmdbuf.c, cvt.c, and filename.c still remain, so i might have to
speed up a bit to get it done before release comes too close.


Index: search.c
===
RCS file: /cvs/src/usr.bin/less/search.c,v
retrieving revision 1.19
diff -u -p -r1.19 search.c
--- search.c2 Aug 2017 19:35:57 -   1.19
+++ search.c14 Mar 2019 13:48:59 -
@@ -75,12 +75,14 @@ static struct pattern_info filter_info;
 static int
 is_ucase(char *str)
 {
-   char *str_end = str + strlen(str);
-   LWCHAR ch;
+   wchar_t ch;
+   int len;
 
-   while (str < str_end) {
-   ch = step_char(&str, +1, str_end);
-   if (isupper(ch))
+   for (; *str != '\0"; str += len) {
+   if ((len = mbtowc(&ch, str, MB_CUR_MAX)) == -1) {
+   mbtowc(NULL, NULL, MB_CUR_MAX);
+   len = 1;
+   } else if (iswupper(ch))
return (1);
}
return (0);



Re: ipv6 via ipsec tunnel

2019-03-14 Thread Claudio Jeker
On Thu, Mar 14, 2019 at 11:46:10AM +0100, Otto Moerbeek wrote:
> On Thu, Mar 14, 2019 at 10:43:03AM +0100, Claudio Jeker wrote:
> 
> > On Thu, Mar 14, 2019 at 10:36:58AM +0100, Otto Moerbeek wrote:
> > > Hi,
> > > 
> > > So i have a little IPv6 problem. 
> > > 
> > > I have a machine in colocation that has IPv6. I have my home cable
> > > modem connection that does not have it.
> > > 
> > > So I thought: I make my own tunnel. First I tried gif(4), that worked,
> > > but only after some fighting with mtu settings on all hosts on my home
> > > net via rad.  Performance was kinda bad. So I'm looking for an
> > > alternative. I thougt: IPSEC should be able to do this.
> > > 
> > > I have a flow from my locally created IPv6 net to any and vice versa.
> > > THe flow itself works. 
> > > 
> > > There I ran into the trouble that you cannot specify a default
> > > gateway, since my remote gw (the host in colo) it is not reachable
> > > according to route(8).
> > > 
> > > How does one solve the default route problem?  I never really
> > > understood how routing works in the presense of IPSEC flows.
> > > 
> > 
> > IPSec flows steal the traffic away before it is being sent out. You still
> > need routes in place to get to this point though. In your case adding a
> > dummy default route should work. Never tried but I think you should be
> > able to use the loopback for this and add a route like 'route add -inet6
> > default ::1' also don't forget to enable net.inet6.ip6.forwarding
> > 
> > -- 
> > :wq Claudio
> > 
> 
> Indeed, that seems to work. Thanks,
> 

You may need to use pf to block the routed IPv6 traffic on the loopback
or you may end up with a routing loop when the IPsec flow is not present.
You can use a 2nd loopback or maybe even a vether(4) and use the link
local address as the default gateway then dropping this traffic should be
trivial.

-- 
:wq Claudio



Re: fallback to pio serial in efiboot

2019-03-14 Thread Mark Kettenis
> Date: Thu, 14 Mar 2019 19:17:42 +1100
> From: Jonathan Gray 
> 
> A large number of machines ship uefi firmware which does not have
> the serial io protcol.  When using shell.efi 'dh -p serialio' and
> 'sermode' indicate it is not present.
> 
> To handle this fallback to pio access with code derived from
> amd64/stand/libsa/bioscons.c minus the init code which resulted in
> nothing showing up on serial.
> 
> I've not found any hardware which implements the serial io protocol,
> but it is present with edk2 ovmf with qemu and still seems fine with
> these changes.

ok kettenis@

> Index: efiboot/conf.c
> ===
> RCS file: /cvs/src/sys/arch/amd64/stand/efiboot/conf.c,v
> retrieving revision 1.16
> diff -u -p -r1.16 conf.c
> --- efiboot/conf.c10 Aug 2018 16:43:54 -  1.16
> +++ efiboot/conf.c14 Mar 2019 07:51:51 -
> @@ -39,7 +39,7 @@
>  #include "efidev.h"
>  #include "efipxe.h"
>  
> -const char version[] = "3.40";
> +const char version[] = "3.41";
>  
>  #ifdef EFI_DEBUG
>  int  debug = 0;
> Index: efiboot/efiboot.c
> ===
> RCS file: /cvs/src/sys/arch/amd64/stand/efiboot/efiboot.c,v
> retrieving revision 1.32
> diff -u -p -r1.32 efiboot.c
> --- efiboot/efiboot.c 20 Nov 2018 03:10:47 -  1.32
> +++ efiboot/efiboot.c 14 Mar 2019 08:11:17 -
> @@ -20,9 +20,11 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include "libsa.h"
>  #include "disk.h"
> @@ -533,6 +535,87 @@ int com_addr = -1;
>  int com_speed = -1;
>  
>  static SERIAL_IO_INTERFACE   *serios[4];
> +const int comports[4] = { 0x3f8, 0x2f8, 0x3e8, 0x2e8 };
> +
> +/* call with sp == 0 to query the current speed */
> +int
> +pio_comspeed(dev_t dev, int sp)
> +{
> + int port = (com_addr == -1) ? comports[minor(dev)] : com_addr;
> + int i, newsp;
> + int err;
> +
> + if (sp <= 0)
> + return com_speed;
> + /* valid baud rate? */
> + if (115200 < sp || sp < 75)
> + return -1;
> +
> + /*
> +  * Accepted speeds:
> +  *   75 150 300 600 1200 2400 4800 9600 19200 38400 76800 and
> +  *   14400 28800 57600 115200
> +  */
> + for (i = sp; i != 75 && i != 14400; i >>= 1)
> + if (i & 1)
> + return -1;
> +
> +/* ripped screaming from dev/ic/com.c */
> +#define divrnd(n, q)(((n)*2/(q)+1)/2)   /* divide and round off */
> + newsp = divrnd((COM_FREQ / 16), sp);
> + if (newsp <= 0)
> + return -1;
> + err = divrnd((COM_FREQ / 16) * 1000, sp * newsp) - 1000;
> + if (err < 0)
> + err = -err;
> + if (err > COM_TOLERANCE)
> + return -1;
> +#undef  divrnd
> +
> + if (com_speed != -1 && cn_tab && cn_tab->cn_dev == dev &&
> + com_speed != sp) {
> + printf("com%d: changing speed to %d baud in 5 seconds, "
> + "change your terminal to match!\n\a",
> + minor(dev), sp);
> + sleep(5);
> + }
> +
> + outb(port + com_cfcr, LCR_DLAB);
> + outb(port + com_dlbl, newsp);
> + outb(port + com_dlbh, newsp>>8);
> + outb(port + com_cfcr, LCR_8BITS);
> + if (com_speed != -1)
> + printf("\ncom%d: %d baud\n", minor(dev), sp);
> +
> + newsp = com_speed;
> + com_speed = sp;
> + return newsp;
> +}
> +
> +int
> +pio_com_getc(dev_t dev)
> +{
> + int port = (com_addr == -1) ? comports[minor(dev & 0x7f)] : com_addr;
> +
> + if (dev & 0x80)
> + return (inb(port + com_lsr) & LSR_RXRDY);
> +
> + while ((inb(port + com_lsr) & LSR_RXRDY) == 0)
> + ;
> +
> + return (inb(port + com_data) & 0xff);
> +}
> +
> +void
> +pio_com_putc(dev_t dev, int c)
> +{
> + int port = (com_addr == -1) ? comports[minor(dev)] : com_addr;
> +
> + while ((inb(port + com_lsr) & LSR_TXRDY) == 0)
> + ;
> +
> + outb(port + com_data, c);
> +}
>  
>  void
>  efi_com_probe(struct consdev *cn)
> @@ -545,6 +628,9 @@ efi_com_probe(struct consdev *cn)
>   UINTNsz;
>   int  i, uid = -1;
>  
> + cn->cn_pri = CN_LOWPRI;
> + cn->cn_dev = makedev(8, 0);
> +
>   sz = 0;
>   status = EFI_CALL(BS->LocateHandle, ByProtocol, &serio_guid, 0, &sz, 0);
>   if (status == EFI_BUFFER_TOO_SMALL) {
> @@ -594,8 +680,6 @@ efi_com_probe(struct consdev *cn)
>   if (serios[i] != NULL)
>   printf(" com%d", i);
>   }
> - cn->cn_pri = CN_LOWPRI;
> - cn->cn_dev = makedev(8, 0);
>  }
>  
>  int
> @@ -615,7 +699,7 @@ comspeed(dev_t dev, int sp)
>   return com_speed;
>  
>   if (!efi_valid_com(dev))
> - return (-1);
> + return pio_comspeed(dev, sp);
>  
>   if (serio->Mode->BaudRate != sp) {
>   status = EFI_CALL(serio->SetAttributes, serio,
> @@ -659

Re: ipv6 via ipsec tunnel

2019-03-14 Thread Otto Moerbeek
On Thu, Mar 14, 2019 at 10:43:03AM +0100, Claudio Jeker wrote:

> On Thu, Mar 14, 2019 at 10:36:58AM +0100, Otto Moerbeek wrote:
> > Hi,
> > 
> > So i have a little IPv6 problem. 
> > 
> > I have a machine in colocation that has IPv6. I have my home cable
> > modem connection that does not have it.
> > 
> > So I thought: I make my own tunnel. First I tried gif(4), that worked,
> > but only after some fighting with mtu settings on all hosts on my home
> > net via rad.  Performance was kinda bad. So I'm looking for an
> > alternative. I thougt: IPSEC should be able to do this.
> > 
> > I have a flow from my locally created IPv6 net to any and vice versa.
> > THe flow itself works. 
> > 
> > There I ran into the trouble that you cannot specify a default
> > gateway, since my remote gw (the host in colo) it is not reachable
> > according to route(8).
> > 
> > How does one solve the default route problem?  I never really
> > understood how routing works in the presense of IPSEC flows.
> > 
> 
> IPSec flows steal the traffic away before it is being sent out. You still
> need routes in place to get to this point though. In your case adding a
> dummy default route should work. Never tried but I think you should be
> able to use the loopback for this and add a route like 'route add -inet6
> default ::1' also don't forget to enable net.inet6.ip6.forwarding
> 
> -- 
> :wq Claudio
> 

Indeed, that seems to work. Thanks,

-Otto



Re: Option for alternative escape character with cu(1)

2019-03-14 Thread Nicholas Marriott
Thanks, comments inline.

> diff --git a/usr.bin/cu/command.c b/usr.bin/cu/command.c
> index c07fe73aeca..e225fb544be 100644
> --- a/usr.bin/cu/command.c
> +++ b/usr.bin/cu/command.c
> @@ -30,6 +30,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include "cu.h"
>  
> @@ -223,6 +224,8 @@ start_record(void)
>  void
>  do_command(char c)
>  {
> + char esc[4 + 1];
> +
>   if (restricted && strchr("CRX$>", c) != NULL) {
>   cu_warnx("~%c command is not allowed in restricted mode", c);
>   return;
> @@ -266,20 +269,26 @@ do_command(char c)
>   sleep(1);
>   ioctl(line_fd, TIOCCBRK, NULL);
>   break;
> - case '~':
> - bufferevent_write(line_ev, "~", 1);
> + default:
> + if (c != escape_char)
> + break;
> + esc[0] = escape_char;
> + esc[1] = '\0';

No need for \0 since you are only writing one byte, but...

> + bufferevent_write(line_ev, esc, 1);

...why not do this instead:

bufferevent_write(line_ev, &c, 1);

>   break;
>   case '?':
> + vis(esc, escape_char, VIS_WHITE | VIS_NOSLASH, 0);
>   printf("\r\n"
> - "~#  send break\r\n"
> - "~$  pipe local command to remote host\r\n"
> - "~>  send file to remote host\r\n"
> - "~C  connect program to remote host\r\n"
> - "~D  de-assert DTR line briefly\r\n"
> - "~R  start recording to file\r\n"
> - "~S  set speed\r\n"
> - "~X  send file with XMODEM\r\n"
> - "~?  get this summary\r\n"
> + "%s#  send break\r\n"
> + "%s$  pipe local command to remote host\r\n"
> + "%s>  send file to remote host\r\n"
> + "%sC  connect program to remote host\r\n"
> + "%sD  de-assert DTR line briefly\r\n"
> + "%sR  start recording to file\r\n"
> + "%sS  set speed\r\n"
> + "%sX  send file with XMODEM\r\n"
> + "%s?  get this summary\r\n",
> + esc, esc, esc, esc, esc, esc, esc, esc, esc
>   );
>   break;
>   }
> diff --git a/usr.bin/cu/cu.1 b/usr.bin/cu/cu.1
> index 104a6ea7893..d52e0b94e5f 100644
> --- a/usr.bin/cu/cu.1
> +++ b/usr.bin/cu/cu.1
> @@ -38,6 +38,7 @@
>  .Op Fl dr
>  .Op Fl l Ar line
>  .Op Fl s Ar speed | Fl Ar speed
> +.Op Fl E Ar escape_char

E comes before l and s.

>  .Nm
>  .Op Ar host
>  .Sh DESCRIPTION
> @@ -92,6 +93,8 @@ and
>  .It Fl s Ar speed | Fl Ar speed
>  Set the speed of the connection.
>  The default is 9600.
> +.It Fl E Ar escape_char
> +Specify a escape character to use instead of the default tilde.

"an escape character".

>  .El
>  .Pp
>  If
> diff --git a/usr.bin/cu/cu.c b/usr.bin/cu/cu.c
> index 03a2df4181f..f269f4a74f3 100644
> --- a/usr.bin/cu/cu.c
> +++ b/usr.bin/cu/cu.c
> @@ -41,6 +41,7 @@ FILE*record_file;
>  struct termiossaved_tio;
>  struct bufferevent   *input_ev;
>  struct bufferevent   *output_ev;
> +int   escape_char = -1;

Why not just initialize it to '~'?

>  int   is_direct = -1;
>  int   restricted = 0;
>  const char   *line_path = NULL;
> @@ -53,7 +54,7 @@ struct event sighup_ev;
>  enum {
>   STATE_NONE,
>   STATE_NEWLINE,
> - STATE_TILDE
> + STATE_ESCAPE
>  } last_state = STATE_NEWLINE;
>  
>  __dead void  usage(void);
> @@ -67,8 +68,8 @@ voidtry_remote(const char *, const char *, 
> const char *);
>  __dead void
>  usage(void)
>  {
> - fprintf(stderr, "usage: %s [-dr] [-l line] [-s speed | -speed]\n",
> - __progname);
> + fprintf(stderr, "usage: %s [-dr] [-l line] [-s speed | -speed]"
> + " [-E escape_char]\n", __progname);

-E comes before -l and -s.

>   fprintf(stderr, "   %s [host]\n", __progname);
>   exit(1);
>  }
> @@ -101,7 +102,7 @@ main(int argc, char **argv)
>   errx(1, "speed asprintf");
>   }
>  
> - while ((opt = getopt(argc, argv, "drl:s:")) != -1) {
> + while ((opt = getopt(argc, argv, "drl:s:E:")) != -1) {
>   switch (opt) {
>   case 'd':
>   is_direct = 1;
> @@ -119,6 +120,17 @@ main(int argc, char **argv)
>   if (errstr != NULL)
>   errx(1, "speed is %s: %s", errstr, optarg);
>   break;
> + case 'E':
> + if (optarg[0] == '^' && optarg[2] == 0 &&
> + (unsigned char)optarg[1] >= 64 &&
> + (unsigned char)optarg[1] < 128)
> + escape_char = (unsigned char)optarg[1] & 31;
> +   

Re: ipv6 via ipsec tunnel

2019-03-14 Thread Janne Johansson
Den tors 14 mars 2019 kl 10:48 skrev Claudio Jeker :
> On Thu, Mar 14, 2019 at 10:36:58AM +0100, Otto Moerbeek wrote:
> > How does one solve the default route problem?  I never really
> > understood how routing works in the presense of IPSEC flows.
>
> IPSec flows steal the traffic away before it is being sent out. You still
> need routes in place to get to this point though. In your case adding a
> dummy default route should work. Never tried but I think you should be
> able to use the loopback for this and add a route like 'route add -inet6
> default ::1' also don't forget to enable net.inet6.ip6.forwarding

I remember having to do exactly this for a similar scenario long time
ago to bring
ipv6 home over a v4-only setup.

-- 
May the most significant bit of your life be positive.



Re: ipv6 via ipsec tunnel

2019-03-14 Thread Claudio Jeker
On Thu, Mar 14, 2019 at 10:36:58AM +0100, Otto Moerbeek wrote:
> Hi,
> 
> So i have a little IPv6 problem. 
> 
> I have a machine in colocation that has IPv6. I have my home cable
> modem connection that does not have it.
> 
> So I thought: I make my own tunnel. First I tried gif(4), that worked,
> but only after some fighting with mtu settings on all hosts on my home
> net via rad.  Performance was kinda bad. So I'm looking for an
> alternative. I thougt: IPSEC should be able to do this.
> 
> I have a flow from my locally created IPv6 net to any and vice versa.
> THe flow itself works. 
> 
> There I ran into the trouble that you cannot specify a default
> gateway, since my remote gw (the host in colo) it is not reachable
> according to route(8).
> 
> How does one solve the default route problem?  I never really
> understood how routing works in the presense of IPSEC flows.
> 

IPSec flows steal the traffic away before it is being sent out. You still
need routes in place to get to this point though. In your case adding a
dummy default route should work. Never tried but I think you should be
able to use the loopback for this and add a route like 'route add -inet6
default ::1' also don't forget to enable net.inet6.ip6.forwarding

-- 
:wq Claudio



ipv6 via ipsec tunnel

2019-03-14 Thread Otto Moerbeek
Hi,

So i have a little IPv6 problem. 

I have a machine in colocation that has IPv6. I have my home cable
modem connection that does not have it.

So I thought: I make my own tunnel. First I tried gif(4), that worked,
but only after some fighting with mtu settings on all hosts on my home
net via rad.  Performance was kinda bad. So I'm looking for an
alternative. I thougt: IPSEC should be able to do this.

I have a flow from my locally created IPv6 net to any and vice versa.
THe flow itself works. 

There I ran into the trouble that you cannot specify a default
gateway, since my remote gw (the host in colo) it is not reachable
according to route(8).

How does one solve the default route problem?  I never really
understood how routing works in the presense of IPSEC flows.

-Otto



fallback to pio serial in efiboot

2019-03-14 Thread Jonathan Gray
A large number of machines ship uefi firmware which does not have
the serial io protcol.  When using shell.efi 'dh -p serialio' and
'sermode' indicate it is not present.

To handle this fallback to pio access with code derived from
amd64/stand/libsa/bioscons.c minus the init code which resulted in
nothing showing up on serial.

I've not found any hardware which implements the serial io protocol,
but it is present with edk2 ovmf with qemu and still seems fine with
these changes.

Index: efiboot/conf.c
===
RCS file: /cvs/src/sys/arch/amd64/stand/efiboot/conf.c,v
retrieving revision 1.16
diff -u -p -r1.16 conf.c
--- efiboot/conf.c  10 Aug 2018 16:43:54 -  1.16
+++ efiboot/conf.c  14 Mar 2019 07:51:51 -
@@ -39,7 +39,7 @@
 #include "efidev.h"
 #include "efipxe.h"
 
-const char version[] = "3.40";
+const char version[] = "3.41";
 
 #ifdef EFI_DEBUG
 intdebug = 0;
Index: efiboot/efiboot.c
===
RCS file: /cvs/src/sys/arch/amd64/stand/efiboot/efiboot.c,v
retrieving revision 1.32
diff -u -p -r1.32 efiboot.c
--- efiboot/efiboot.c   20 Nov 2018 03:10:47 -  1.32
+++ efiboot/efiboot.c   14 Mar 2019 08:11:17 -
@@ -20,9 +20,11 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
+#include 
 
 #include "libsa.h"
 #include "disk.h"
@@ -533,6 +535,87 @@ int com_addr = -1;
 int com_speed = -1;
 
 static SERIAL_IO_INTERFACE *serios[4];
+const int comports[4] = { 0x3f8, 0x2f8, 0x3e8, 0x2e8 };
+
+/* call with sp == 0 to query the current speed */
+int
+pio_comspeed(dev_t dev, int sp)
+{
+   int port = (com_addr == -1) ? comports[minor(dev)] : com_addr;
+   int i, newsp;
+   int err;
+
+   if (sp <= 0)
+   return com_speed;
+   /* valid baud rate? */
+   if (115200 < sp || sp < 75)
+   return -1;
+
+   /*
+* Accepted speeds:
+*   75 150 300 600 1200 2400 4800 9600 19200 38400 76800 and
+*   14400 28800 57600 115200
+*/
+   for (i = sp; i != 75 && i != 14400; i >>= 1)
+   if (i & 1)
+   return -1;
+
+/* ripped screaming from dev/ic/com.c */
+#define divrnd(n, q)(((n)*2/(q)+1)/2)   /* divide and round off */
+   newsp = divrnd((COM_FREQ / 16), sp);
+   if (newsp <= 0)
+   return -1;
+   err = divrnd((COM_FREQ / 16) * 1000, sp * newsp) - 1000;
+   if (err < 0)
+   err = -err;
+   if (err > COM_TOLERANCE)
+   return -1;
+#undef  divrnd
+
+   if (com_speed != -1 && cn_tab && cn_tab->cn_dev == dev &&
+   com_speed != sp) {
+   printf("com%d: changing speed to %d baud in 5 seconds, "
+   "change your terminal to match!\n\a",
+   minor(dev), sp);
+   sleep(5);
+   }
+
+   outb(port + com_cfcr, LCR_DLAB);
+   outb(port + com_dlbl, newsp);
+   outb(port + com_dlbh, newsp>>8);
+   outb(port + com_cfcr, LCR_8BITS);
+   if (com_speed != -1)
+   printf("\ncom%d: %d baud\n", minor(dev), sp);
+
+   newsp = com_speed;
+   com_speed = sp;
+   return newsp;
+}
+
+int
+pio_com_getc(dev_t dev)
+{
+   int port = (com_addr == -1) ? comports[minor(dev & 0x7f)] : com_addr;
+
+   if (dev & 0x80)
+   return (inb(port + com_lsr) & LSR_RXRDY);
+
+   while ((inb(port + com_lsr) & LSR_RXRDY) == 0)
+   ;
+
+   return (inb(port + com_data) & 0xff);
+}
+
+void
+pio_com_putc(dev_t dev, int c)
+{
+   int port = (com_addr == -1) ? comports[minor(dev)] : com_addr;
+
+   while ((inb(port + com_lsr) & LSR_TXRDY) == 0)
+   ;
+
+   outb(port + com_data, c);
+}
 
 void
 efi_com_probe(struct consdev *cn)
@@ -545,6 +628,9 @@ efi_com_probe(struct consdev *cn)
UINTNsz;
int  i, uid = -1;
 
+   cn->cn_pri = CN_LOWPRI;
+   cn->cn_dev = makedev(8, 0);
+
sz = 0;
status = EFI_CALL(BS->LocateHandle, ByProtocol, &serio_guid, 0, &sz, 0);
if (status == EFI_BUFFER_TOO_SMALL) {
@@ -594,8 +680,6 @@ efi_com_probe(struct consdev *cn)
if (serios[i] != NULL)
printf(" com%d", i);
}
-   cn->cn_pri = CN_LOWPRI;
-   cn->cn_dev = makedev(8, 0);
 }
 
 int
@@ -615,7 +699,7 @@ comspeed(dev_t dev, int sp)
return com_speed;
 
if (!efi_valid_com(dev))
-   return (-1);
+   return pio_comspeed(dev, sp);
 
if (serio->Mode->BaudRate != sp) {
status = EFI_CALL(serio->SetAttributes, serio,
@@ -659,7 +743,7 @@ efi_com_getc(dev_t dev)
static u_charlastchar = 0;
 
if (!efi_valid_com(dev & 0x7f))
-   return (0) ;
+   return pio_com_getc(dev);
serio = serios[minor(dev & 0x7f)];
 
if (last