Re: [PATCH] Update default QoS markers for ssh

[Ian McWilliam]

Just for the record the latest OpenBSD snapshot with the changed ssh / sshd 
causes ssh connections to fail

across a VMWare Fusion 10 NAT network.


ssh into the box you get a banner sent before the connection is closed.

ssh out of the like updating a CVS tree gets you...


Obtaining OpenBSD-current src tree.

packet_write_wait: Connection to 130.102.79.219 port 22: Broken pipe

cvs [update aborted]: end of file from server (consult above messages if any)

Finished obtaining OpenBSD-current src tree.


Adding


IPQoS lowdelay


to both the ssh_config / ssh_config make this work as before.


Machines on the Internal network can SSH into and out amongst each other but 
going across the NAT boundary to the real world fails.

With the state of VMWare (the company) I doubt there will be a fix for Fusion 
anytime soon.


Leaving this here for the archives.


Ian McWilliam



From: owner-t...@openbsd.org  on behalf of Stuart 
Henderson 
Sent: Monday, 2 April 2018 12:06 AM
To: Job Snijders
Cc: tech@openbsd.org
Subject: Re: [PATCH] Update default QoS markers for ssh

On 2018/04/01 13:29, Job Snijders wrote:
> On Sun, Apr 01, 2018 at 11:29:55AM +0100, Stuart Henderson wrote:
> > On 2018/03/31 16:10, Job Snijders wrote:
> > > TL;DR: I propose to update the defaults to use DSCP "AF21" (Low
> > > Latency Data) for interactive session traffic, and CS1 ("Lower
> > > Effort") for non-interactive traffic. This applies to both IPv4 and
> > > IPv6.
> >
> > I think this is the right thing to do, but needs handling in
> > conjunction with changes to PF, which has dual queue-setting
> > (IPTOS_LOWDELAY packets go in one queue along with empty TCP ACKs,
> > other packets can go in another lower priority queue).
> >
> > Since firewalls are often updated less often than hosts I think it
> > would be better if the PF side was done first with some time to give
> > people chance to update, though it doesn't need to be too long (they
> > can set qos in sshd_config if they want to retain the old setting).
> >
> > A few other pieces use IPTOS_LOWDELAY (pfsync, carp, vxlan, etherip)
> > which I think would want switching too.
>
> What we're looking at is some kind of "migrate TOS to DSCP" project.
> There is a few tens of files where TOS values need to be examined and an
> appropiate DSCP value choosen.

Yes, that's clearly a much bigger scope. But if we're starting with ssh
those should be on the radar too IMO.

>I'm not sure I'd go as far as blindly
> replacing IPTOS_LOWDELAY with IPTOS_DSCP_AF21, but perhaps as a
> transition that is what is needed in some places.

Indeed. For some of these uses (like carp) something like CS7 seems
more appropriate. ssh seems a great place to start gaining more
experience with this - in particular any breakage can be handled
more easily than things like carp (since ssh already has config
options for this).

> We can start by treating IPTOS_LOWDELAY and IPTOS_DSCP_AF21 similarly in
> pf (see untested patch below), and then accept patches that migrate from
> TOS to DSCP?

That approach generally makes sense to me. It seems that some other
codepoints should probably also be treated as higher priority but
I'm not quite sure which yet...

> As far as I understand, out-of-the-box pf doesn't do anything with TOS
> values, so users wlil have to have explicitly configured something on
> the firewall or clients anyhow?

Yes, the firewall needs to have queues enabled and traffic assigned with
"set queue (foo, bar)" syntax.

> Kind regards,
>
> Job
>
>  share/man/man5/pf.conf.5 | 12 +---
>  sys/net/pf.c |  8 +---
>  2 files changed, 14 insertions(+), 6 deletions(-)
>
> diff --git share/man/man5/pf.conf.5 share/man/man5/pf.conf.5
> index 13e23423daa..f5a65e1b0d4 100644
> --- share/man/man5/pf.conf.5
> +++ share/man/man5/pf.conf.5
> @@ -679,7 +679,9 @@ interface, the queueing priority will also be written as 
> the priority
>  code point in the 802.1Q VLAN header.
>  If two priorities are given, TCP ACKs with no data payload and packets
>  which have a TOS of
> -.Cm lowdelay
> +.Cm lowdelay ,
> +or DSCP value
> +.Cm af21 ,
>  will be assigned to the second one.
>  Packets with a higher priority number are processed first,
>  and packets with the same priority are processed
> @@ -702,7 +704,9 @@ section.
>  Packets matching this rule will be assigned to the specified
>  .Ar queue .
>  If two queues are given, packets which have a TOS of
> -.Cm lowdelay
> +.Cm lowdelay ,
> +or DSCP value
> +.Cm af21 ,
>  and TCP ACKs with no data payload will be assigned to the second one.
>  See
>  .Sx QUEUEING
> @@ -1608,7 +1612,9 @@ Normally only one
>  .Ar queue
>  is specified; when a second one is specified it will instead be used for
>  packets which have a TOS of
> -.Cm lowdelay
> +.Cm lowdelay ,
> +or DSCP value
> +.Cm af21 ,
>  and for TCP ACKs with no data payload.
>  .Pp
>  To continue 

tmux fix when renaming session with no client attached

[Ryan Freeman]

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: umsm(4) support for Vodafone k3772

[Jeremie Courreges-Anglas]

On Tue, Apr 10 2018, Björn Ketelaars  wrote:
> I received a Vodafone k3772 USB modem, which is not supported out of the
> box in current. dmesg:
>
> umass0 at uhub3 port 2 configuration 1 interface 0 "Vodafone (Huawei) 
> Vodafone Mobile Broadband (Huawei)" rev 2.00/1.02 addr 6
> umass0: using SCSI over Bulk-Only
> scsibus4 at umass0: 2 targets, initiator 0
> cd0 at scsibus4 targ 1 lun 0:  SCSI2 5/cdrom 
> removable
>
>
> Diff below adds support for this device. dmesg:
>
> umsm0 at uhub0 port 2 configuration 1 interface 0 "Vodafone (Huawei) Vodafone 
> Mobile Broadband (Huawei)" rev 2.00/1.02 addr 2
> umsm0 detached
> umsm0 at uhub0 port 2 configuration 1 interface 0 "Vodafone (Huawei) Vodafone 
> Mobile Broadband (Huawei)" rev 2.00/1.02 addr 2
> ucom0 at umsm0
> umsm1 at uhub0 port 2 configuration 1 interface 1 "Vodafone (Huawei) Vodafone 
> Mobile Broadband (Huawei)" rev 2.00/1.02 addr 2
> ucom1 at umsm1
> umsm2 at uhub0 port 2 configuration 1 interface 2 "Vodafone (Huawei) Vodafone 
> Mobile Broadband (Huawei)" rev 2.00/1.02 addr 2
> ucom2 at umsm2
> umass0 at uhub0 port 2 configuration 1 interface 3 "Vodafone (Huawei) 
> Vodafone Mobile Broadband (Huawei)" rev 2.00/1.02 addr 2
> umass0: using SCSI over Bulk-Only
> scsibus2 at umass0: 2 targets, initiator 0
> cd0 at scsibus2 targ 1 lun 0:  SCSI2 5/cdrom 
> removable
> umass1 at uhub0 port 2 configuration 1 interface 4 "Vodafone (Huawei) 
> Vodafone Mobile Broadband (Huawei)" rev 2.00/1.02 addr 2
> umass1: using SCSI over Bulk-Only
> scsibus3 at umass1: 2 targets, initiator 0
> sd1 at scsibus3 targ 1 lun 0:  SCSI2 
> 0/direct removable
>
>
> I'm able to set up an internet connection using this device in
> combination with a Vodafone subscription on a x230. Actually I've been
> using this device for the last few weeks during my daily commute. There
> seems to be however one issue, which does not interfere with reliability
> or stability. dmesg: 
>
> umsm0: this device is not using CDC notify message in intr pipe.
> Please send your dmesg to , thanks.
> umsm0: intr buffer 0xc1 0x1 0x3 0x0 0x0 0x0 0x0
>
>
> A search on misc@ revealed that this is not an isolated issue, e.g.
> https://marc.info/?l=openbsd-misc=142477847307314=2
>
>
> Comments?

The warning isn't new, I think should go ahead and commit this.  ok jca@

> Index: share/man/man4/umsm.4
> ===
> RCS file: /cvs/src/share/man/man4/umsm.4,v
> retrieving revision 1.94
> diff -u -p -r1.94 umsm.4
> --- share/man/man4/umsm.4 20 Mar 2018 07:30:10 -  1.94
> +++ share/man/man4/umsm.4 10 Apr 2018 17:39:52 -
> @@ -113,6 +113,7 @@ driver:
>  .It Li "Toshiba 3G HSDPA MiniCard" Ta "PCI Express Mini Card"
>  .It Li "Vodafone Mobile Connect 3G" Ta "CardBus"
>  .It Li "Vodafone Mobile Broadband K3765" Ta "USB"
> +.It Li "Vodafone Mobile Broadband K3772" Ta "USB"
>  .It Li "ZTE AC2746" Ta "USB"
>  .It Li "ZTE MF112" Ta "USB"
>  .It Li "ZTE MF190" Ta "USB"
> Index: sys/dev/usb/umsm.c
> ===
> RCS file: /cvs/src/sys/dev/usb/umsm.c,v
> retrieving revision 1.111
> diff -u -p -r1.111 umsm.c
> --- sys/dev/usb/umsm.c20 Mar 2018 07:30:10 -  1.111
> +++ sys/dev/usb/umsm.c10 Apr 2018 17:39:52 -
> @@ -142,6 +142,8 @@ static const struct umsm_type umsm_devs[
>   {{ USB_VENDOR_HUAWEI,   USB_PRODUCT_HUAWEI_Mobile }, DEV_HUAWEI},
>   {{ USB_VENDOR_HUAWEI,   USB_PRODUCT_HUAWEI_K3765_INIT }, DEV_UMASS5},
>   {{ USB_VENDOR_HUAWEI,   USB_PRODUCT_HUAWEI_K3765 }, 0},
> + {{ USB_VENDOR_HUAWEI,   USB_PRODUCT_HUAWEI_K3772_INIT }, DEV_UMASS5},
> + {{ USB_VENDOR_HUAWEI,   USB_PRODUCT_HUAWEI_K3772 }, 0},
>   {{ USB_VENDOR_HUAWEI,   USB_PRODUCT_HUAWEI_MU609 }, DEV_TRUINSTALL},
>   {{ USB_VENDOR_HUAWEI,   USB_PRODUCT_HUAWEI_K4510 }, DEV_UMASS5},
>   {{ USB_VENDOR_HUAWEI,   USB_PRODUCT_HUAWEI_K4511 }, DEV_UMASS5},
> Index: sys/dev/usb/usbdevs
> ===
> RCS file: /cvs/src/sys/dev/usb/usbdevs,v
> retrieving revision 1.683
> diff -u -p -r1.683 usbdevs
> --- sys/dev/usb/usbdevs   20 Mar 2018 07:30:10 -  1.683
> +++ sys/dev/usb/usbdevs   10 Apr 2018 17:39:52 -
> @@ -2217,12 +2217,14 @@ product HUAWEI E182   0x1429  HUAWEI Mobil
>  product HUAWEI E3372 0x1442  HUAWEI Mobile Modem
>  product HUAWEI E161  0x1446  HUAWEI Mobile Modem
>  product HUAWEI K3765 0x1465  HUAWEI Mobile K3765
> +product HUAWEI K3772 0x14cf  HUAWEI Mobile K3772
>  product HUAWEI E1820 0x14ac  HUAWEI Mobile Modem
>  product HUAWEI K4510 0x14c5  HUAWEI Mobile Modem
>  product HUAWEI K4511 0x14b7  HUAWEI Mobile Modem K4511
>  product HUAWEI E353_INIT 0x14fe  HUAWEI Mobile E353 Initial
>  

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

[Klemens Nanni]

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.816 Mar 2018 19:45:13 -  1.305
+++ sbin/ifconfig/ifconfig.810 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
===
RCS file: /cvs/src/sbin/route/route.c,v
retrieving revision 1.207
diff -u -p -r1.207 route.c
--- route.c 16 Jan 2018 10:33:55 -  1.207
+++ route.c 10 Apr 2018 21:06:36 -
@@ -131,7 +131,7 @@ usage(char *cp)

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

[Theo de Raadt]

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

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

[Artturi Alm]

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:

# gpioctl gpio2 attach gpioow 2 1
gpioow0 at gpio2: DATA[2]
onewire0 at gpioow0
# gpioctl gpio2 attach gpioow 4 5
gpioow1 at gpio2: invalid pin mask
gpioow1 detached
# gpioctl gpio2 attach gpioow 4 1
gpioow1 at gpio2: DATA[4]
onewire1 at gpioow1
# gpioctl gpio2 attach gpioow 3 2
gpioow2 at gpio2: can't map pins
gpioow2 detached
# gpioctl gpio2 attach gpioow 3 1
gpioow2 at gpio2: DATA[3]
onewire2 at gpioow2
# gpioctl gpio2 attach gpioow 2 1
gpioow3 at gpio2: can't map pins
gpioow3 detached

^ is with the DVF_ACTIVE-hack,
which does work because at that point it is 'local' to the config_attach(),
and if it does fail it(dv_flags) doesn't exist to cause issues later,
as nothing changes for those who don't call config_defer_failure(),
they will get their DVF_ACTIVE just like before.

my v2.diff below, in case you want to reconsider something like this while
waiting for the whole-tree work to appear:)

-Artturi


diff --git share/man/man9/config_defer.9 share/man/man9/config_defer.9
index ef45867188b..280501a538a 100644
--- share/man/man9/config_defer.9
+++ share/man/man9/config_defer.9
@@ -33,6 +33,7 @@
 .Os
 .Sh NAME
 .Nm config_defer ,
+.Nm config_defer_failure ,
 .Nm config_mountroot
 .Nd deferred device configuration
 .Sh SYNOPSIS
@@ -41,6 +42,8 @@
 .Ft "void"
 .Fn config_defer "struct device *dev" "void (*func)(struct device *)"
 .Ft "void"
+.Fn config_defer_failure "struct device *dev"
+.Ft "void"
 .Fn config_mountroot "struct device *dev" "void (*func)(struct device *)"
 .Sh DESCRIPTION
 The
@@ -53,6 +56,12 @@ is called with the argument
 .Fa dev .
 .Pp
 The
+.Fn config_defer_failure
+function is called by the device to mark its configuration as having
+failed, so it can be detached by
+.Fn config_attach .
+.Pp
+The
 .Fn config_mountroot
 function is called by a device driver to defer the remainder of its
 configuration until after the root file system is mounted.
@@ -60,3 +69,5 @@ At this point, the function
 .Fa func
 is called with the argument
 .Fa dev .
+.Sh SEE ALSO
+.Xr config_attach 9
diff --git sys/dev/gpio/gpioow.c sys/dev/gpio/gpioow.c
index 64d79ab0cb8..912537b7de7 100644
--- sys/dev/gpio/gpioow.c
+++ sys/dev/gpio/gpioow.c
@@ -101,7 +101,7 @@ gpioow_attach(struct device *parent, struct device *self, 
void *aux)
/* Check that we have enough pins */
if (gpio_npins(ga->ga_mask) != GPIOOW_NPINS) {
printf(": invalid pin mask\n");
-   return;
+   goto fail_nomap;
}
 
/* Map pins */
@@ -110,7 +110,7 @@ gpioow_attach(struct device *parent, struct device *self, 
void *aux)
if (gpio_pin_map(sc->sc_gpio, ga->ga_offset, ga->ga_mask,
>sc_map)) {
printf(": can't map pins\n");
-   return;
+   goto fail_nomap;
}
 
/* Configure data pin */
@@ -153,6 +153,8 @@ gpioow_attach(struct device *parent, struct device *self, 
void *aux)
 
 fail:
gpio_pin_unmap(sc->sc_gpio, >sc_map);
+fail_nomap:
+   config_defer_failure(self);
 }
 
 int
diff --git sys/kern/subr_autoconf.c sys/kern/subr_autoconf.c
index 3fff153e8ad..e4ff9ee7536 100644
--- sys/kern/subr_autoconf.c
+++ sys/kern/subr_autoconf.c
@@ -409,6 +409,12 @@ config_attach(struct device *parent, void *match, void 
*aux, cfprint_t print)
if (--autoconf_attdet == 0)
wakeup(_attdet);
mtx_leave(_attdet_mtx);
+
+   /* Process deferred failure here by detaching. */
+   if (dev->dv_flags & DVF_FAILED) {
+   if (config_detach(dev, 0) == 0)
+   dev = NULL;
+   }
return (dev);
 }
 
@@ -678,6 +684,18 @@ config_defer(struct device *dev, void (*func)(struct 
device *))
config_pending_incr();
 }
 
+/*
+ * Defer the detachment of the specified device with failure
+ * until the end of its own configuration, see config_attach().
+ * XXX "void2int ca_attach()"-churn workaround
+ */
+void
+config_defer_failure(struct device *dev)
+{
+
+   dev->dv_flags |= DVF_FAILED;
+}
+
 /*
  * Defer the configuration of the specified device until after
  * root file system is mounted.
diff --git sys/sys/device.h sys/sys/device.h
index 00a1f6ad2a6..c1d133594ff 100644
--- sys/sys/device.h
+++ sys/sys/device.h
@@ -82,6 +82,7 @@ struct device {
 
 /* dv_flags */
 #defineDVF_ACTIVE  0x0001  /* device is activated */
+#defineDVF_FAILED  0x0002  /* device failed to attach */
 
 TAILQ_HEAD(devicelist, device);
 
@@ -185,6 +186,7 @@ int config_activate_children(struct device *, int);
 struct device *config_make_softc(struct device *parent,
 struct cfdata *cf);
 void config_defer(struct device *, void (*)(struct 

Stop ping telling world its pid

[Vadim Zhukov]

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?

--
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.c  8 Nov 2017 17:27:39 -   1.224
+++ ping.c  10 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;

umsm(4) support for Vodafone k3772

[Björn Ketelaars]

I received a Vodafone k3772 USB modem, which is not supported out of the
box in current. dmesg:

umass0 at uhub3 port 2 configuration 1 interface 0 "Vodafone (Huawei) Vodafone 
Mobile Broadband (Huawei)" rev 2.00/1.02 addr 6
umass0: using SCSI over Bulk-Only
scsibus4 at umass0: 2 targets, initiator 0
cd0 at scsibus4 targ 1 lun 0:  SCSI2 5/cdrom 
removable


Diff below adds support for this device. dmesg:

umsm0 at uhub0 port 2 configuration 1 interface 0 "Vodafone (Huawei) Vodafone 
Mobile Broadband (Huawei)" rev 2.00/1.02 addr 2
umsm0 detached
umsm0 at uhub0 port 2 configuration 1 interface 0 "Vodafone (Huawei) Vodafone 
Mobile Broadband (Huawei)" rev 2.00/1.02 addr 2
ucom0 at umsm0
umsm1 at uhub0 port 2 configuration 1 interface 1 "Vodafone (Huawei) Vodafone 
Mobile Broadband (Huawei)" rev 2.00/1.02 addr 2
ucom1 at umsm1
umsm2 at uhub0 port 2 configuration 1 interface 2 "Vodafone (Huawei) Vodafone 
Mobile Broadband (Huawei)" rev 2.00/1.02 addr 2
ucom2 at umsm2
umass0 at uhub0 port 2 configuration 1 interface 3 "Vodafone (Huawei) Vodafone 
Mobile Broadband (Huawei)" rev 2.00/1.02 addr 2
umass0: using SCSI over Bulk-Only
scsibus2 at umass0: 2 targets, initiator 0
cd0 at scsibus2 targ 1 lun 0:  SCSI2 5/cdrom 
removable
umass1 at uhub0 port 2 configuration 1 interface 4 "Vodafone (Huawei) Vodafone 
Mobile Broadband (Huawei)" rev 2.00/1.02 addr 2
umass1: using SCSI over Bulk-Only
scsibus3 at umass1: 2 targets, initiator 0
sd1 at scsibus3 targ 1 lun 0:  SCSI2 0/direct 
removable


I'm able to set up an internet connection using this device in
combination with a Vodafone subscription on a x230. Actually I've been
using this device for the last few weeks during my daily commute. There
seems to be however one issue, which does not interfere with reliability
or stability. dmesg: 

umsm0: this device is not using CDC notify message in intr pipe.
Please send your dmesg to , thanks.
umsm0: intr buffer 0xc1 0x1 0x3 0x0 0x0 0x0 0x0


A search on misc@ revealed that this is not an isolated issue, e.g.
https://marc.info/?l=openbsd-misc=142477847307314=2


Comments?


Index: share/man/man4/umsm.4
===
RCS file: /cvs/src/share/man/man4/umsm.4,v
retrieving revision 1.94
diff -u -p -r1.94 umsm.4
--- share/man/man4/umsm.4   20 Mar 2018 07:30:10 -  1.94
+++ share/man/man4/umsm.4   10 Apr 2018 17:39:52 -
@@ -113,6 +113,7 @@ driver:
 .It Li "Toshiba 3G HSDPA MiniCard" Ta "PCI Express Mini Card"
 .It Li "Vodafone Mobile Connect 3G" Ta "CardBus"
 .It Li "Vodafone Mobile Broadband K3765" Ta "USB"
+.It Li "Vodafone Mobile Broadband K3772" Ta "USB"
 .It Li "ZTE AC2746" Ta "USB"
 .It Li "ZTE MF112" Ta "USB"
 .It Li "ZTE MF190" Ta "USB"
Index: sys/dev/usb/umsm.c
===
RCS file: /cvs/src/sys/dev/usb/umsm.c,v
retrieving revision 1.111
diff -u -p -r1.111 umsm.c
--- sys/dev/usb/umsm.c  20 Mar 2018 07:30:10 -  1.111
+++ sys/dev/usb/umsm.c  10 Apr 2018 17:39:52 -
@@ -142,6 +142,8 @@ static const struct umsm_type umsm_devs[
{{ USB_VENDOR_HUAWEI,   USB_PRODUCT_HUAWEI_Mobile }, DEV_HUAWEI},
{{ USB_VENDOR_HUAWEI,   USB_PRODUCT_HUAWEI_K3765_INIT }, DEV_UMASS5},
{{ USB_VENDOR_HUAWEI,   USB_PRODUCT_HUAWEI_K3765 }, 0},
+   {{ USB_VENDOR_HUAWEI,   USB_PRODUCT_HUAWEI_K3772_INIT }, DEV_UMASS5},
+   {{ USB_VENDOR_HUAWEI,   USB_PRODUCT_HUAWEI_K3772 }, 0},
{{ USB_VENDOR_HUAWEI,   USB_PRODUCT_HUAWEI_MU609 }, DEV_TRUINSTALL},
{{ USB_VENDOR_HUAWEI,   USB_PRODUCT_HUAWEI_K4510 }, DEV_UMASS5},
{{ USB_VENDOR_HUAWEI,   USB_PRODUCT_HUAWEI_K4511 }, DEV_UMASS5},
Index: sys/dev/usb/usbdevs
===
RCS file: /cvs/src/sys/dev/usb/usbdevs,v
retrieving revision 1.683
diff -u -p -r1.683 usbdevs
--- sys/dev/usb/usbdevs 20 Mar 2018 07:30:10 -  1.683
+++ sys/dev/usb/usbdevs 10 Apr 2018 17:39:52 -
@@ -2217,12 +2217,14 @@ product HUAWEI E182 0x1429  HUAWEI Mobil
 product HUAWEI E3372   0x1442  HUAWEI Mobile Modem
 product HUAWEI E1610x1446  HUAWEI Mobile Modem
 product HUAWEI K3765   0x1465  HUAWEI Mobile K3765
+product HUAWEI K3772   0x14cf  HUAWEI Mobile K3772
 product HUAWEI E1820   0x14ac  HUAWEI Mobile Modem
 product HUAWEI K4510   0x14c5  HUAWEI Mobile Modem
 product HUAWEI K4511   0x14b7  HUAWEI Mobile Modem K4511
 product HUAWEI E353_INIT   0x14fe  HUAWEI Mobile E353 Initial
 product HUAWEI E392_INIT   0x1505  HUAWEI Mobile E392 Initial
 product HUAWEI K3765_INIT  0x1520  HUAWEI Mobile K3765 Initial
+product HUAWEI K3772_INIT  0x1526  HUAWEI Mobile K3772 Initial
 product HUAWEI MU609   0x1573  HUAWEI Mobile ME906 
 product HUAWEI E173S   0x1c05  HUAWEI Mobile E173s
 

diff for usr.bin/mg/fileio.c

[Han Boetes]

I got a problem report from Mark Willson:

"I recently installed mg (via the Debian package) under WSL on Windows
10.
I found that the 'backup-to-home-directory' option didn't work.

The cause of this appears to be that getlogin under WSL returns NULL,
probably due to my use of wsltty to invoke bash.  The patch below fixes
the issue for me:"

[snip]
-   if ((un = getlogin()) != NULL)
+   if ((un = getenv("LOGNAME")) != NULL)
[snip]

Which put me onto the track of what was going on. I found the
following in the Linux manpage:

BUGS
   Unfortunately, it is often rather easy to fool  getlogin().
 Sometimes
   it  does not work at all, because some program messed up the utmp
file.
   Often, it gives only the first 8 characters of  the  login  name.
 The
   user  currently  logged  in  on the controlling terminal of our
program
   need not be the user who started it.  Avoid  getlogin()  for
security-
   related purposes.

   Note  that glibc does not follow the POSIX specification and uses
stdin
   instead of /dev/tty.  A bug.  (Other recent systems, like SunOS 5.8
and
   HP-UX  11.11  and FreeBSD 4.8 all return the login name also when
stdin
   is redirected.)

   Nobody knows precisely what cuserid() does; avoid it in  portable
pro‐
   grams.   Or  avoid  it  altogether: use getpwuid(geteuid()) instead,
if
   that is what you meant.  Do not use cuserid().

So I started looking at the code and rewrote it a bit, which I think
makes it more portable and removes a syscall in the process. I do
suspect this can be written even more elegantly, but didn't want to
rework the code too much.

I also took the liberty to remove some whitespace.


Index: fileio.c
===
RCS file: /cvs/src/usr.bin/mg/fileio.c,v
retrieving revision 1.104
@@ -703,7 +706,7 @@ expandtilde(const char *fn)
struct stat  statbuf;
const char  *cp;
char user[LOGIN_NAME_MAX], path[NFILEN];
-   char*un, *ret;
+   char*ret;
size_t   ulen, plen;

path[0] = '\0';
@@ -722,21 +725,21 @@ expandtilde(const char *fn)
return (NULL);
return(ret);
}
+   pw = getpwuid(geteuid());
if (ulen == 0) { /* ~/ or ~ */
-   if ((un = getlogin()) != NULL)
-   (void)strlcpy(user, un, sizeof(user));
+   if (pw != NULL)
+   (void)strlcpy(user, pw->pw_name, sizeof(user));
else
user[0] = '\0';
} else { /* ~user/ or ~user */
memcpy(user, [1], ulen);
user[ulen] = '\0';
}
-   pw = getpwnam(user);
if (pw != NULL) {
plen = strlcpy(path, pw->pw_dir, sizeof(path));
if (plen == 0 || path[plen - 1] != '/') {
if (strlcat(path, "/", sizeof(path)) >=
sizeof(path)) {
-   dobeep();
+   dobeep();
ewprintf("Path too long");
return (NULL);
}

Re: try to map 64-bit mem space first

[Ted Unangst]

Mark Kettenis wrote:
> We should allways use mmio instead of io if possible.  The cascading
> if statements are a bit ugly, but I can't come up with a better solution.

mapped = 0;
if (pcimap() == 0)
mapped = 1;
if (!mapped && pcimap() == 0)
mapped = 1;
if (!mapped)
printf("no mapping worked");

Not a lot prettier, but avoids neverending indentation, and perhaps clarifies
that we're basically trying the same thing with different arguments instead of
descending into some bizarre error handling rabbit hole.

Re: Earlier FREF() for dupfdopen()

[Alexander Bluhm]

On Tue, Apr 10, 2018 at 01:00:44PM +0200, Martin Pieuchot wrote:
> Instead of incrementing `f_count' directly, we'll use the reference that
> will be returned by fd_getfile(9).  For that call FREF(9) earlier.
> 
> ok?

OK bluhm@

> Index: kern/kern_descrip.c
> ===
> RCS file: /cvs/src/sys/kern/kern_descrip.c,v
> retrieving revision 1.147
> diff -u -p -r1.147 kern_descrip.c
> --- kern/kern_descrip.c   9 Apr 2018 13:59:03 -   1.147
> +++ kern/kern_descrip.c   10 Apr 2018 10:53:33 -
> @@ -1297,22 +1297,26 @@ dupfdopen(struct proc *p, int indx, int 
>*/
>   if ((wfp = fd_getfile(fdp, dupfd)) == NULL)
>   return (EBADF);
> + FREF(wfp);
>  
>   /*
>* Check that the mode the file is being opened for is a
>* subset of the mode of the existing descriptor.
>*/
> - if (((mode & (FREAD|FWRITE)) | wfp->f_flag) != wfp->f_flag)
> + if (((mode & (FREAD|FWRITE)) | wfp->f_flag) != wfp->f_flag) {
> + FRELE(wfp, p);
>   return (EACCES);
> - if (wfp->f_count == LONG_MAX-2)
> + }
> + if (wfp->f_count == LONG_MAX-2) {
> + FRELE(wfp, p);
>   return (EDEADLK);
> + }
>  
>   fdp->fd_ofiles[indx] = wfp;
>   fdp->fd_ofileflags[indx] = (fdp->fd_ofileflags[indx] & UF_EXCLOSE) |
>   (fdp->fd_ofileflags[dupfd] & ~UF_EXCLOSE);
>   if (ISSET(p->p_p->ps_flags, PS_PLEDGE))
>   fdp->fd_ofileflags[indx] |= UF_PLEDGED;
> - wfp->f_count++;
>   fd_used(fdp, indx);
>   return (0);
>  }

Re: Multiple RTCs

[Mark Kettenis]

> Date: Tue, 10 Apr 2018 15:57:30 +0300
> From: Artturi Alm 
> 
> On Sat, Apr 07, 2018 at 08:39:43PM +0200, Mark Kettenis wrote:
> > I have an RK3399 system that has two RTCs.  One of those is the RTC
> > integrated on the RK808 PMIC that is a companion chip to the RK3399.
> > The second one is an ISL1208 I2C chip.  Only the ISL1208 is battery
> > powered, so obviously we want to use that one.  But rkpmic(4) attaches
> > after islrtc(4) on this board and therefore it wins.  The diff below
> > makes sure the RTC of the RK808 PMIC is only enabled if no other RTC
> > installed itself.
> > 
> 
> Off-topic, but related enough i hope.
> instead of fixing up RTCVDD(lack of battery) on all my sunxi boards,
> i'm going to rather add cheap I2C RTCs for each.
> 
> What do you think about kern.timecounter.{choice,hardware}-type solution?

That wouldn't work.  The clock is set early on, before sysctl(8) runs.

If you modify the hardware like this, you should modify the device
tree as well.  Just disable the original RTC when you add yours.  That
only is a problem for multi-function devices like the RK808.  But that
one is covered now.

Re: Multiple RTCs

[Artturi Alm]

On Sat, Apr 07, 2018 at 08:39:43PM +0200, Mark Kettenis wrote:
> I have an RK3399 system that has two RTCs.  One of those is the RTC
> integrated on the RK808 PMIC that is a companion chip to the RK3399.
> The second one is an ISL1208 I2C chip.  Only the ISL1208 is battery
> powered, so obviously we want to use that one.  But rkpmic(4) attaches
> after islrtc(4) on this board and therefore it wins.  The diff below
> makes sure the RTC of the RK808 PMIC is only enabled if no other RTC
> installed itself.
> 

Off-topic, but related enough i hope.
instead of fixing up RTCVDD(lack of battery) on all my sunxi boards,
i'm going to rather add cheap I2C RTCs for each.

What do you think about kern.timecounter.{choice,hardware}-type solution?

i'm kind of covered, either way, as maxrtc(4) does this in maxrtc_attach():
126 /* register our time handlers */
127 if (todr_handle != NULL) {  
128 printf("%s: overwriting existing rtc handler\n",
129 sc->sc_dev.dv_xname);
130 }
131 /* XXX just overwrite existing rtc handler? */
132 todr_handle = >sc_todr;

-Artturi

> ok?
> 
> 
> Index: dev/fdt/rkpmic.c
> ===
> RCS file: /cvs/src/sys/dev/fdt/rkpmic.c,v
> retrieving revision 1.4
> diff -u -p -r1.4 rkpmic.c
> --- dev/fdt/rkpmic.c  25 Feb 2018 20:43:33 -  1.4
> +++ dev/fdt/rkpmic.c  7 Apr 2018 18:31:41 -
> @@ -127,7 +127,8 @@ rkpmic_attach(struct device *parent, str
>   sc->sc_todr.cookie = sc;
>   sc->sc_todr.todr_gettime = rkpmic_gettime;
>   sc->sc_todr.todr_settime = rkpmic_settime;
> - todr_handle = >sc_todr;
> + if (todr_handle == NULL)
> + todr_handle = >sc_todr;
>  
>   if (OF_is_compatible(node, "rockchip,rk805")) {
>   chip = "RK805";
> 

No FRELE() in finishdup

[Martin Pieuchot]

Document that we're using the current reference instead of incrementing 
then decrementing the refcount in finishdup().

Ok?

Index: kern/kern_descrip.c
===
RCS file: /cvs/src/sys/kern/kern_descrip.c,v
retrieving revision 1.147
diff -u -p -r1.147 kern_descrip.c
--- kern/kern_descrip.c 9 Apr 2018 13:59:03 -   1.147
+++ kern/kern_descrip.c 10 Apr 2018 11:01:45 -
@@ -241,6 +241,7 @@ restart:
}
goto out;
}
+   /* No need for FRELE(), finishdup() uses current ref. */
error = finishdup(p, fp, old, new, retval, 0);
 
 out:
@@ -320,7 +321,7 @@ restart:
panic("dup2: fdalloc");
fd_unused(fdp, new);
}
-   /* finishdup() does FRELE */
+   /* No need for FRELE(), finishdup() uses current ref. */
error = finishdup(p, fp, old, new, retval, 1);
if (!error && flags & O_CLOEXEC)
fdp->fd_ofileflags[new] |= UF_EXCLOSE;
@@ -376,7 +377,7 @@ restart:
goto restart;
}
} else {
-   /* finishdup will FRELE for us. */
+   /* No need for FRELE(), finishdup() uses current ref. */
error = finishdup(p, fp, fd, i, retval, 0);
 
if (!error && SCARG(uap, cmd) == F_DUPFD_CLOEXEC)
@@ -616,8 +617,6 @@ finishdup(struct proc *p, struct file *f
 
fdp->fd_ofiles[new] = fp;
fdp->fd_ofileflags[new] = fdp->fd_ofileflags[old] & ~UF_EXCLOSE;
-   fp->f_count++;
-   FRELE(fp, p);
if (dup2 && oldfp == NULL)
fd_used(fdp, new);
*retval = new;

Earlier FREF() for dupfdopen()

[Martin Pieuchot]

Instead of incrementing `f_count' directly, we'll use the reference that
will be returned by fd_getfile(9).  For that call FREF(9) earlier.

ok?

Index: kern/kern_descrip.c
===
RCS file: /cvs/src/sys/kern/kern_descrip.c,v
retrieving revision 1.147
diff -u -p -r1.147 kern_descrip.c
--- kern/kern_descrip.c 9 Apr 2018 13:59:03 -   1.147
+++ kern/kern_descrip.c 10 Apr 2018 10:53:33 -
@@ -1297,22 +1297,26 @@ dupfdopen(struct proc *p, int indx, int 
 */
if ((wfp = fd_getfile(fdp, dupfd)) == NULL)
return (EBADF);
+   FREF(wfp);
 
/*
 * Check that the mode the file is being opened for is a
 * subset of the mode of the existing descriptor.
 */
-   if (((mode & (FREAD|FWRITE)) | wfp->f_flag) != wfp->f_flag)
+   if (((mode & (FREAD|FWRITE)) | wfp->f_flag) != wfp->f_flag) {
+   FRELE(wfp, p);
return (EACCES);
-   if (wfp->f_count == LONG_MAX-2)
+   }
+   if (wfp->f_count == LONG_MAX-2) {
+   FRELE(wfp, p);
return (EDEADLK);
+   }
 
fdp->fd_ofiles[indx] = wfp;
fdp->fd_ofileflags[indx] = (fdp->fd_ofileflags[indx] & UF_EXCLOSE) |
(fdp->fd_ofileflags[dupfd] & ~UF_EXCLOSE);
if (ISSET(p->p_p->ps_flags, PS_PLEDGE))
fdp->fd_ofileflags[indx] |= UF_PLEDGED;
-   wfp->f_count++;
fd_used(fdp, indx);
return (0);
 }

Re: Adding current bandwidth to ftp(1)

[Stuart Henderson]

On 2018/04/09 09:27, Matthias Schmidt wrote:
> Hi Christian,
> 
> On 08.04.2018 22:42, Christian Barthel wrote:
> > Hello,
> > 
> > i am often sitting behind a very slow internet link and thought, it
> > might be useful to show the current bandwidth while downloading
> > something with ftp(1).
> 
> Since I sometimes work with crappy WLANs/connections I very much appreciate
> your patch!

Do you know you can just send SIGINFO (often bound to ^T) to get the same
information?