Re: Stop ping telling world its pid

2018-04-11 Thread Job Snijders
When things arrive out of sequence, that usually is of special interest to
network operator people. Not sure  the sequence field can easily be
overloaded to increase “validity”.

I’m not great at math, with a 16 bit random value, wouldn’t we start
running into ID collisions around 256 concurrent ping processes? Perhaps
that already is the case today and this patch does nothing to improve that,
but also doesn’t make it worse.

Kind regards,

Job


Re: Stop ping telling world its pid

2018-04-11 Thread Theo de Raadt
"The standard convention of using the locally-significant PID should be fine."
 Jimmy Hess, 2018

A whole bunch of protocols got holed because of that attitude.



Re: Stop ping telling world its pid

2018-04-11 Thread Theo de Raadt
We never claimed that OpenBSD ping conforms to the
'High Availability ICMP ECHO' RFC.

Jimmy Hess  wrote:

> On Tue, Apr 10, 2018 at 3:11 PM, Vadim Zhukov  wrote:
> 
> > While working on home job for students, I've come across two
> > questionable thingies in ping.c:
> >
> > 1. It sends process PID (well, last 16 bits) to the network.
> >Maybe I'm a bit paranoid, but this looks like bad idea for me.
> 
> Well, you need a UNIQUE  ID,  because all readers of an ICMP socket are
> going to see All the ICMP echo replies,  including ones that belong to other
> programs  (maybe not ping),  and  possibly some unsolicited replies.
> 
> The standard convention of using the locally-significant PID should be fine.
> The only thought would be that if an adversary knows your process id,
> such as by running  a  "ps"  command on the host  -- since the PID is not
> a secret identifier,  well.
> 
> your adversary could then construct and send  Spoofed replies to
> your ping commands's ICMP ECHO request  from somewhere else on
> the internet,  And knowing your PID,  they would be able to put the
> correct Ident value in their spoofed ECHO REPLY packets.
> 
> However,  there's no real-world case where it's really a concern ---
> unless there were some bug where ping  could misbehave on a malformed reply.
> 
> >I understand that this worked good when PIDs were 16-bit limited,
> >because in that case you'll get 100% guarantee two different
> >ping processes won't overlap. But nowadays we have larger PID
> >space, so clashes are possible anyway. I propose to go straight
> >with arc4random().
> 
> Probably using the bottom 16 bits of the PID for most systems is ensuring
> uniqueness,  and  arc4random()  is introducing  unreliability/unpredictability
> in when Ident values may  overlap.
> 
> 
> Perhaps the ideal situation would be to use the whole  combined
> Ident + Sequencefields  for matching.
> 
> In other words:  the ICMP REPLY should be discarded unless both  Ident
>  AND  Sequence bits
> in the reply  are within a certain range of valuesbased on packets sent.
> 
> Then. populate the whole 32-bit  PID with upper 16 bits to Ident and
> Lower  16 bits  into the   Initial Sequence bits.
> 
> And for reply Match Ident,
> Then  test  if the  Sequence Bits  in the response are in the valid reply 
> range
>  based onInitial Sequence  --> Final Sequence,
> 
> Or  Initial Sequence +  The count of sent pings   where ping would increment
>  Sequence for each Ping sent,   with consideration for Sequence
> counter wrap/overflow.
> 
> 
> --
> -Jimmy
> 



Re: Stop ping telling world its pid

2018-04-11 Thread Jimmy Hess
On Tue, Apr 10, 2018 at 3:11 PM, Vadim Zhukov  wrote:

> While working on home job for students, I've come across two
> questionable thingies in ping.c:
>
> 1. It sends process PID (well, last 16 bits) to the network.
>Maybe I'm a bit paranoid, but this looks like bad idea for me.

Well, you need a UNIQUE  ID,  because all readers of an ICMP socket are
going to see All the ICMP echo replies,  including ones that belong to other
programs  (maybe not ping),  and  possibly some unsolicited replies.

The standard convention of using the locally-significant PID should be fine.
The only thought would be that if an adversary knows your process id,
such as by running  a  "ps"  command on the host  -- since the PID is not
a secret identifier,  well.

your adversary could then construct and send  Spoofed replies to
your ping commands's ICMP ECHO request  from somewhere else on
the internet,  And knowing your PID,  they would be able to put the
correct Ident value in their spoofed ECHO REPLY packets.

However,  there's no real-world case where it's really a concern ---
unless there were some bug where ping  could misbehave on a malformed reply.

>I understand that this worked good when PIDs were 16-bit limited,
>because in that case you'll get 100% guarantee two different
>ping processes won't overlap. But nowadays we have larger PID
>space, so clashes are possible anyway. I propose to go straight
>with arc4random().

Probably using the bottom 16 bits of the PID for most systems is ensuring
uniqueness,  and  arc4random()  is introducing  unreliability/unpredictability
in when Ident values may  overlap.


Perhaps the ideal situation would be to use the whole  combined
Ident + Sequencefields  for matching.

In other words:  the ICMP REPLY should be discarded unless both  Ident
 AND  Sequence bits
in the reply  are within a certain range of valuesbased on packets sent.

Then. populate the whole 32-bit  PID with upper 16 bits to Ident and
Lower  16 bits  into the   Initial Sequence bits.

And for reply Match Ident,
Then  test  if the  Sequence Bits  in the response are in the valid reply range
 based onInitial Sequence  --> Final Sequence,

Or  Initial Sequence +  The count of sent pings   where ping would increment
 Sequence for each Ping sent,   with consideration for Sequence
counter wrap/overflow.


--
-Jimmy



Re: subr_autoconf: allow _attach to fail? w/no void2int churn option

2018-04-11 Thread Artturi Alm
On Tue, Apr 10, 2018 at 02:40:29PM -0600, Theo de Raadt wrote:
> >On Mon, Apr 09, 2018 at 11:11:22AM -0600, Theo de Raadt wrote:
> >> I think this approach is wrong, insane, and fragile.  DVF_ACTIVE
> >> doesn't work precisely that way.
> >
> >Yes, it's a hack, but i don't see it as fragile, nor insane,
> >and i agree something better is great, but it does work exactly
> >as i wanted:
> 
> for 1 driver.

i offered a horse. if it wasn't good enough, why bother with more work;
as i don't see how it would make the horse any better at this point:)

-Artturi



Re: interpolation -> interpretation

2018-04-11 Thread Stuart Henderson
On 2018/04/11 22:55, Jan Stary wrote:
> I am not a native speaker, but printf(3) "interprets" the conversion
> specifiers, it does not "interpolate" them, right?

interpolation is correct.


>   Jan
> 
> Index: printf.3
> ===
> RCS file: /cvs/src/lib/libc/stdio/printf.3,v
> retrieving revision 1.78
> diff -u -p -r1.78 printf.3
> --- printf.3  2 Jan 2018 08:05:03 -   1.78
> +++ printf.3  11 Apr 2018 20:53:05 -
> @@ -870,7 +870,7 @@ This holds true even if the string has b
>  using a function like
>  .Fn snprintf ,
>  as the resulting string may still contain user-supplied conversion specifiers
> -for later interpolation by
> +for later interpretation by
>  .Fn printf .
>  .Pp
>  Be sure to use the proper secure idiom:
> 



Re: ifconfig,route,netstat: s/tableid/rtable/ for consistency

2018-04-11 Thread Klemens Nanni
On Wed, Apr 11, 2018 at 09:28:03AM +0200, Peter Hessler wrote:
> No, all of these uses are correct as-is.
`tableid' surely isn't wrong, but using the argument name across manuals
seems nicer to me.

Or is there any real difference between `tableid' and `rtable' I'm not
aware of?



interpolation -> interpretation

2018-04-11 Thread Jan Stary
I am not a native speaker, but printf(3) "interprets" the conversion
specifiers, it does not "interpolate" them, right?

Jan

Index: printf.3
===
RCS file: /cvs/src/lib/libc/stdio/printf.3,v
retrieving revision 1.78
diff -u -p -r1.78 printf.3
--- printf.32 Jan 2018 08:05:03 -   1.78
+++ printf.311 Apr 2018 20:53:05 -
@@ -870,7 +870,7 @@ This holds true even if the string has b
 using a function like
 .Fn snprintf ,
 as the resulting string may still contain user-supplied conversion specifiers
-for later interpolation by
+for later interpretation by
 .Fn printf .
 .Pp
 Be sure to use the proper secure idiom:



Re: Stop ping telling world its pid

2018-04-11 Thread Florian Obser

On Tue, Apr 10, 2018 at 11:11:39PM +0300, Vadim Zhukov wrote:
> Hi all!
> 
> While working on home job for students, I've come across two
> questionable thingies in ping.c:
> 
> 1. It sends process PID (well, last 16 bits) to the network.
>Maybe I'm a bit paranoid, but this looks like bad idea for me.
>I understand that this worked good when PIDs were 16-bit limited,
>because in that case you'll get 100% guarantee two different
>ping processes won't overlap. But nowadays we have larger PID
>space, so clashes are possible anyway. I propose to go straight
>with arc4random().
> 
> 2. There is no point in calling ntohs/htons on the ident value.
>Or we should do this in IPv4 too, then: I'm not opposed, but
>at least consistency should be honored, IMHO.
> 
> Okay? Comments?

OK florian@

> 
> --
> WBR,
>   Vadim Zhukov
> 
> P.S.: I'm not fully back yet, sorry.
> 
> 
> Index: ping.c
> ===
> RCS file: /cvs/src/sbin/ping/ping.c,v
> retrieving revision 1.224
> diff -u -p -r1.224 ping.c
> --- ping.c8 Nov 2017 17:27:39 -   1.224
> +++ ping.c10 Apr 2018 20:03:50 -
> @@ -586,7 +586,7 @@ main(int argc, char *argv[])
>   for (i = ECHOTMLEN; i < datalen; ++i)
>   *datap++ = i;
>  
> - ident = getpid() & 0x;
> + ident = arc4random() & 0x;
>  
>   /*
>* When trying to send large packets, you must increase the
> @@ -1033,7 +1033,7 @@ pinger(int s)
>   icp6->icmp6_cksum = 0;
>   icp6->icmp6_type = ICMP6_ECHO_REQUEST;
>   icp6->icmp6_code = 0;
> - icp6->icmp6_id = htons(ident);
> + icp6->icmp6_id = ident;
>   icp6->icmp6_seq = seq;
>   } else {
>   icp = (struct icmp *)outpack;
> @@ -1151,7 +1151,7 @@ pr_pack(u_char *buf, int cc, struct msgh
>   }
>  
>   if (icp6->icmp6_type == ICMP6_ECHO_REPLY) {
> - if (ntohs(icp6->icmp6_id) != ident)
> + if (icp6->icmp6_id != ident)
>   return; /* 'Twas not our ECHO */
>   seq = icp6->icmp6_seq;
>   echo_reply = 1;
> 

-- 
I'm not entirely sure you are real.



Re: vput(9) for NFS

2018-04-11 Thread Visa Hankala
On Wed, Apr 11, 2018 at 12:34:03PM +0200, Martin Pieuchot wrote:
> On 09/04/18(Mon) 16:10, Martin Pieuchot wrote:
> > Diff below implements most of the missing locking goo for NFS without
> > enabling it.  It does the following:
> > 
> > - Add a missing PDIRUNLOCK in nfs_lookup()
> > 
> > - Change vrele(9) into vput(9) where necessary.  nfs_nget() will in
> >   future return a locked NFSnode.  Just like ffs_vget() returns a
> >   locked vnode.  So every time it is called we need a corresponding
> >   vput(9).
> > 
> > - Make sure VN_KNOTE() is always called with a valid reference, before
> >   vrele(9) or vput(9).
> > 
> > - Substitute an XXX by an assert in nfs_removeit().
> > 
> > However as long as nfs_lock/unlock are noops, this diff should not
> > introduce any change in behavior.  But please do test this diff :)
> 
> New version of the diff after a review from visa@.  It includes:
> 
> - Stop calling vput(9) inside nfs_mknodrpc() to be able to call
>   VN_KNOTE() with a proper reference in nfs_mknod().
> 
> - Do not unconditionally unlock a node in an error case in
>   nfs_lookitup().
> 
> - Fix a dangling reference in the case of 'goto again' in nfs_create().

OK visa@, with one more tweak:

The KASSERT(VOP_ISLOCKED(sp->s_dvp)) in nfs_removeit() should be
commented out until the locking is enabled. Currently, VOP_ISLOCKED()
returns zero with NFS vnodes.



[patch] Chane wfd to static variable in cat.c

2018-04-11 Thread Nan Xiao
Hi tech@,

It seems "wfd" only need get its value when first calling "raw_cat", so
maybe a static variable should be better. Sorry if I am wrong.

Thanks!

Index: cat.c
===
RCS file: /cvs/src/bin/cat/cat.c,v
retrieving revision 1.26
diff -u -p -r1.26 cat.c
--- cat.c   19 Oct 2016 18:20:25 -  1.26
+++ cat.c   11 Apr 2018 10:05:05 -
@@ -223,14 +223,14 @@ raw_args(char **argv)
 void
 raw_cat(int rfd)
 {
-   int wfd;
+   static int wfd;
ssize_t nr, nw, off;
static size_t bsize;
static char *buf = NULL;
struct stat sbuf;

-   wfd = fileno(stdout);
if (buf == NULL) {
+   wfd = fileno(stdout);
if (fstat(wfd, ))
err(1, "stdout");
bsize = MAXIMUM(sbuf.st_blksize, BUFSIZ);
-- 
Best Regards
Nan Xiao(肖楠)



Re: vput(9) for NFS

2018-04-11 Thread Martin Pieuchot
On 09/04/18(Mon) 16:10, Martin Pieuchot wrote:
> Diff below implements most of the missing locking goo for NFS without
> enabling it.  It does the following:
> 
> - Add a missing PDIRUNLOCK in nfs_lookup()
> 
> - Change vrele(9) into vput(9) where necessary.  nfs_nget() will in
>   future return a locked NFSnode.  Just like ffs_vget() returns a
>   locked vnode.  So every time it is called we need a corresponding
>   vput(9).
> 
> - Make sure VN_KNOTE() is always called with a valid reference, before
>   vrele(9) or vput(9).
> 
> - Substitute an XXX by an assert in nfs_removeit().
> 
> However as long as nfs_lock/unlock are noops, this diff should not
> introduce any change in behavior.  But please do test this diff :)

New version of the diff after a review from visa@.  It includes:

- Stop calling vput(9) inside nfs_mknodrpc() to be able to call
  VN_KNOTE() with a proper reference in nfs_mknod().

- Do not unconditionally unlock a node in an error case in
  nfs_lookitup().

- Fix a dangling reference in the case of 'goto again' in nfs_create().

Index: nfs/nfs_vnops.c
===
RCS file: /cvs/src/sys/nfs/nfs_vnops.c,v
retrieving revision 1.171
diff -u -p -r1.171 nfs_vnops.c
--- nfs/nfs_vnops.c 22 Feb 2017 11:42:46 -  1.171
+++ nfs/nfs_vnops.c 11 Apr 2018 10:21:11 -
@@ -769,6 +769,7 @@ nfs_lookup(void *v)
flags = cnp->cn_flags;
 
*vpp = NULLVP;
+   newvp = NULLVP;
if ((flags & ISLASTCN) && (dvp->v_mount->mnt_flag & MNT_RDONLY) &&
(cnp->cn_nameiop == DELETE || cnp->cn_nameiop == RENAME))
return (EROFS);
@@ -836,8 +837,10 @@ nfs_lookup(void *v)
if (cnp->cn_nameiop != LOOKUP && (flags & ISLASTCN))
cnp->cn_flags |= SAVENAME;
if ((!lockparent || !(flags & ISLASTCN)) &&
-newvp != dvp)
+newvp != dvp) {
VOP_UNLOCK(dvp, p);
+   cnp->cn_flags |= PDIRUNLOCK;
+   }
return (0);
}
cache_purge(newvp);
@@ -1282,7 +1285,6 @@ nfs_mknodrpc(struct vnode *dvp, struct v
rdev = nfs_xdrneg1;
else {
VOP_ABORTOP(dvp, cnp);
-   vput(dvp);
return (EOPNOTSUPP);
}
nfsstats.rpccnt[NFSPROC_MKNOD]++;
@@ -1318,10 +1320,6 @@ nfs_mknodrpc(struct vnode *dvp, struct v
if (!error) {
nfsm_mtofh(dvp, newvp, info.nmi_v3, gotvp);
if (!gotvp) {
-   if (newvp) {
-   vrele(newvp);
-   newvp = NULL;
-   }
error = nfs_lookitup(dvp, cnp->cn_nameptr,
cnp->cn_namelen, cnp->cn_cred, cnp->cn_proc, );
if (!error)
@@ -1335,7 +1333,7 @@ nfs_mknodrpc(struct vnode *dvp, struct v
 nfsmout: 
if (error) {
if (newvp)
-   vrele(newvp);
+   vput(newvp);
} else {
if (cnp->cn_flags & MAKEENTRY)
nfs_cache_enter(dvp, newvp, cnp);
@@ -1345,7 +1343,6 @@ nfsmout: 
VTONFS(dvp)->n_flag |= NMODIFIED;
if (!wccflag)
NFS_INVALIDATE_ATTRCACHE(VTONFS(dvp));
-   vrele(dvp);
return (error);
 }
 
@@ -1362,9 +1359,10 @@ nfs_mknod(void *v)
 
error = nfs_mknodrpc(ap->a_dvp, , ap->a_cnp, ap->a_vap);
if (!error)
-   vrele(newvp);
+   vput(newvp);
 
VN_KNOTE(ap->a_dvp, NOTE_WRITE);
+   vput(ap->a_dvp);
 
return (error);
 }
@@ -1390,8 +1388,11 @@ nfs_create(void *v)
/*
 * Oops, not for me..
 */
-   if (vap->va_type == VSOCK)
-   return (nfs_mknodrpc(dvp, ap->a_vpp, cnp, vap));
+   if (vap->va_type == VSOCK) {
+   error = nfs_mknodrpc(dvp, ap->a_vpp, cnp, vap);
+   vput(dvp);
+   return (error);
+   }
 
if (vap->va_vaflags & VA_EXCLUSIVE)
fmode |= O_EXCL;
@@ -1430,10 +1431,6 @@ again:
if (!error) {
nfsm_mtofh(dvp, newvp, info.nmi_v3, gotvp);
if (!gotvp) {
-   if (newvp) {
-   vrele(newvp);
-   newvp = NULL;
-   }
error = nfs_lookitup(dvp, cnp->cn_nameptr,
cnp->cn_namelen, cnp->cn_cred, cnp->cn_proc, );
if (!error)
@@ -1446,12 +1443,14 @@ again:
 
 nfsmout: 
if (error) {
+   if (newvp) {
+   vput(newvp);
+   newvp = NULL;
+   }
if (info.nmi_v3 && (fmode & O_EXCL) && error == NFSERR_NOTSUPP) 

Re: tmux fix when renaming session with no client attached

2018-04-11 Thread Nicholas Marriott

Fixed, thanks!




On Tue, Apr 10, 2018 at 04:31:38PM -0700, Ryan Freeman wrote:
> Hey,
> 
> After upgrading OpenBSD 6.2 -> 6.3, a program I am building for $DAYJOB
> started malfunctioning.
> 
> Basically, we use tmux to manage running sessions of this program, which
> does automated work on things with console ports.
> 
> The session is started in a detached state with temp session name derived
> from a date(1) stamp (date +%s) plus a few random digits:
> 
> $ tmux -S /var/someprog/default new-session -s tmp1234456789
> 
> After the program is running, a command is executed by the running
> program to give it a proper session id, fetched from a database:
> 
> exec /usr/bin/tmux -S /var/someprog/default rename-session $SESSIONID
> 
> Tmux in OpenBSD 6.2 worked a-okay, tmux in 6.3 would return an error
> indicating no current client.  This seems similar to here:
> 
> https://marc.info/?l=openbsd-cvs=152183263526828=2
> 
> I took a stab at fixing this in cmd-rename-session.c like was done
> for cmd-rename-window.c, and the rebuilt tmux seems happy renaming
> sessions from a program running within it again.
> 
> OK?  Flames? :-)
> 
> -ryan
> 
> Index: cmd-rename-session.c
> ===
> RCS file: /cvs/src/usr.bin/tmux/cmd-rename-session.c,v
> retrieving revision 1.27
> diff -u -p -r1.27 cmd-rename-session.c
> --- cmd-rename-session.c1 Mar 2018 12:53:08 -   1.27
> +++ cmd-rename-session.c10 Apr 2018 23:21:52 -
> @@ -47,7 +47,7 @@ static enum cmd_retval
>  cmd_rename_session_exec(struct cmd *self, struct cmdq_item *item)
>  {
> struct args *args = self->args;
> -   struct client   *c = cmd_find_client(item, NULL, 0);
> +   struct client   *c = cmd_find_client(item, NULL, 1);
> struct session  *s = item->target.s;
> char*newname;
> 



Re: Stop telling patch runs ed

2018-04-11 Thread Sebastian Benoit
Vadim Zhukov(persg...@gmail.com) on 2018.04.11 12:10:39 +0300:
> Hi all.
> 
> Lets stop lying that patch(1) runs ed(1). Okay? 

ok

> Or should we tell
> explicitly mention that we don't do bad things?

No, otherwise we would have to document lots of bad things that we do not do
in manpages ;)


> 
> --
> WBR,
>   Vadim Zhukov
> 
> 
> Index: patch.1
> ===
> RCS file: /cvs/src/usr.bin/patch/patch.1,v
> retrieving revision 1.30
> diff -u -p -r1.30 patch.1
> --- patch.1   26 Jul 2015 14:32:19 -  1.30
> +++ patch.1   11 Apr 2018 09:05:37 -
> @@ -64,12 +64,6 @@ will attempt to determine the type of th
>  or
>  .Fl u
>  option.
> -Context diffs (old-style, new-style, and unified) and
> -normal diffs are applied directly by the
> -.Nm
> -program itself, whereas ed diffs are simply fed to the
> -.Xr ed 1
> -editor via a pipe.
>  .Pp
>  If the
>  .Ar patchfile
> Wed Apr 11 12:05:38 MSK 2018: Updating sources ended: diff patch.1
> 



Stop telling patch runs ed

2018-04-11 Thread Vadim Zhukov
Hi all.

Lets stop lying that patch(1) runs ed(1). Okay? Or should we tell
explicitly mention that we don't do bad things?

--
WBR,
  Vadim Zhukov


Index: patch.1
===
RCS file: /cvs/src/usr.bin/patch/patch.1,v
retrieving revision 1.30
diff -u -p -r1.30 patch.1
--- patch.1 26 Jul 2015 14:32:19 -  1.30
+++ patch.1 11 Apr 2018 09:05:37 -
@@ -64,12 +64,6 @@ will attempt to determine the type of th
 or
 .Fl u
 option.
-Context diffs (old-style, new-style, and unified) and
-normal diffs are applied directly by the
-.Nm
-program itself, whereas ed diffs are simply fed to the
-.Xr ed 1
-editor via a pipe.
 .Pp
 If the
 .Ar patchfile
Wed Apr 11 12:05:38 MSK 2018: Updating sources ended: diff patch.1



Re: ifconfig,route,netstat: s/tableid/rtable/ for consistency

2018-04-11 Thread Peter Hessler
No, all of these uses are correct as-is.


On 2018 Apr 10 (Tue) at 23:23:24 +0200 (+0200), Klemens Nanni wrote:
:Several tools may operate on specific routing tables (or routing domains
:in special cases).
:
:With the exception of `tableid' in ifconfig(8), route(8) and netstat(1),
:all other manuals denote the respective argument as `rtable'.
:
:Looking for use cases of rdomain(4), `man -k ar~rtable' does not list
:those tools, so I'd like to rename arguments from `tableid' to`rtable'.
:Looking for `table' obviously shows all of them, but also includes other
:(false) positives.
:
:The following diff changes the wording in besaid manuals as well as
:route's usage for consistency and to ease searching.
:
:Variable names in code have not been touched.
:
:Feedback?
:
:Index: sbin/ifconfig/ifconfig.8
:===
:RCS file: /cvs/src/sbin/ifconfig/ifconfig.8,v
:retrieving revision 1.305
:diff -u -p -r1.305 ifconfig.8
:--- sbin/ifconfig/ifconfig.8   16 Mar 2018 19:45:13 -  1.305
:+++ sbin/ifconfig/ifconfig.8   10 Apr 2018 20:42:02 -
:@@ -1613,7 +1613,7 @@ for a complete list of the available pro
: .Ar tunnel-interface
: .Op Oo Fl Oc Ns Cm keepalive Ar period count
: .Op Oo Fl Oc Ns Cm tunnel Ar src_address dest_address
:-.Op Cm tunneldomain Ar tableid
:+.Op Cm tunneldomain Ar rtable
: .Op Oo Fl Oc Ns Cm tunneldf
: .Op Cm tunnelttl Ar ttl
: .Op Oo Fl Oc Ns Cm vnetflowid
:@@ -1658,13 +1658,13 @@ The optional destination port can be spe
: which further encapsulate the packets in UDP datagrams.
: .It Cm -tunnel
: Remove the source and destination tunnel addresses.
:-.It Cm tunneldomain Ar tableid
:+.It Cm tunneldomain Ar rtable
: Use routing table
:-.Ar tableid
:+.Ar rtable
: instead of the default table.
: The tunnel does not need to terminate in the same routing domain as the
: interface itself.
:-.Ar tableid
:+.Ar rtable
: can be set to any valid routing table ID;
: the corresponding routing domain is derived from this table.
: .It Cm tunneldf
:Index: sbin/route/route.8
:===
:RCS file: /cvs/src/sbin/route/route.8,v
:retrieving revision 1.83
:diff -u -p -r1.83 route.8
:--- sbin/route/route.8 6 Sep 2017 20:21:22 -   1.83
:+++ sbin/route/route.8 10 Apr 2018 20:42:02 -
:@@ -39,7 +39,7 @@
: .Sh SYNOPSIS
: .Nm route
: .Op Fl dnqtv
:-.Op Fl T Ar tableid
:+.Op Fl T Ar rtable
: .Ar command
: .Oo
: .Op Ar modifiers
:@@ -84,7 +84,7 @@ may require correct operation of the net
: to forgo this, especially when attempting to repair networking operations.)
: .It Fl q
: Suppress all output.
:-.It Fl T Ar tableid
:+.It Fl T Ar rtable
: Select an alternate routing table to modify or query.
: The default is to use the current routing table.
: .It Fl t
:@@ -101,18 +101,18 @@ utility provides the following simple co
: .Bl -tag -width Fl
: .It Xo
: .Nm route
:-.Op Fl T Ar tableid
:+.Op Fl T Ar rtable
: .Cm exec
: .Op Ar command ...
: .Xc
: Execute a command forcing the process and its children to use the
: routing table and appropriate routing domain as specified with the
:-.Fl T Ar tableid
:+.Fl T Ar rtable
: option.
: .It Xo
: .Nm route
: .Op Fl nqv
:-.Op Fl T Ar tableid
:+.Op Fl T Ar rtable
: .Cm flush
: .Op Ar modifiers
: .Xc
:@@ -130,7 +130,7 @@ modifiers.
: .It Xo
: .Nm route
: .Op Fl nv
:-.Op Fl T Ar tableid
:+.Op Fl T Ar rtable
: .Cm get
: .Op Ar modifiers
: .Ar address
:@@ -160,7 +160,7 @@ are shown.
: .It Xo
: .Nm route
: .Op Fl nv
:-.Op Fl T Ar tableid
:+.Op Fl T Ar rtable
: .Cm show
: .Op Ar family
: .Op Fl gateway
:@@ -194,7 +194,7 @@ have the syntax:
: .It Xo
: .Nm route
: .Op Fl dnqtv
:-.Op Fl T Ar tableid
:+.Op Fl T Ar rtable
: .Cm add
: .Op Ar modifiers
: .Ar destination gateway
:@@ -202,7 +202,7 @@ have the syntax:
: .It Xo
: .Nm route
: .Op Fl dnqtv
:-.Op Fl T Ar tableid
:+.Op Fl T Ar rtable
: .Cm change
: .Op Ar modifiers
: .Ar destination gateway
:@@ -210,7 +210,7 @@ have the syntax:
: .It Xo
: .Nm route
: .Op Fl dnqtv
:-.Op Fl T Ar tableid
:+.Op Fl T Ar rtable
: .Cm del Ns Op Cm ete
: .Op Ar modifiers
: .Ar destination gateway
:Index: usr.bin/netstat/netstat.1
:===
:RCS file: /cvs/src/usr.bin/netstat/netstat.1,v
:retrieving revision 1.81
:diff -u -p -r1.81 netstat.1
:--- usr.bin/netstat/netstat.1  12 Aug 2017 03:21:02 -  1.81
:+++ usr.bin/netstat/netstat.1  10 Apr 2018 20:42:02 -
:@@ -50,7 +50,7 @@
: .Op Fl p Ar protocol
: .Op Fl M Ar core
: .Op Fl N Ar system
:-.Op Fl T Ar tableid
:+.Op Fl T Ar rtable
: .Ek
: .Nm netstat
: .Op Fl bdhn
:@@ -272,7 +272,7 @@ option, also print routing labels.
: .It Fl s
: Show per-protocol statistics.
: If this option is repeated, counters with a value of zero are suppressed.
:-.It Fl T Ar tableid
:+.It Fl T Ar rtable
: Select an alternate routing table to query.
: The default is to use the current routing table.
: .It Fl t
:Index: route.c