blog.msbit.com.au

Sending non-text emails with stunnel and netcat

2018-08-08T10:19:41+10:00

The initial problem

Today I was putting together an update for my answer on this StackOverflow question, and it occurred to me that (as I’d noted in the edit) it would be possible to create an email that had neither a text/plain part or a text/html part. While I was fairly confident that this would be true, I thought I should quickly confirm this, and the simplest way that I could think of was to send the email through to the SMTP server using netcat.

However, as I’m using Gmail for my email, the SMTP server is only available via secure connection to either port 465 (for SSL connections) or port 587 (for TLS/STARTTLS connections) as shown here. Therefore, I was going to need some kind of SSL tunnel to allow me to connect in plaintext using netcat, but connect to the SMTP server over SSL. From my days using Slackware consistently, I remembered stunnel, which is conveniently available on macOS via brew.

Cheat sheet

$ brew install stunnel
$ cat << EOF > smtps-gmail.conf
> [smtps-gmail]
> accept = localhost:2525
> client = yes 
> connect = smtp.gmail.com:465
> EOF
$ stunnel smtps-gmail.conf
$ nc -c localhost 2525
> EHLO msbit.com.au
> AUTH LOGIN
> <Base64 encoded username>
> <Base64 encoded password>
> MAIL FROM: <tom@msbit.com.au>
> RCPT TO: <tom@msbit.com.au>
> DATA
> Content-Type: application/data; name="data.bin"
> Content-Transfer-Encoding: base64
> <Base64 encoded data>
> .

Making the tunnel

Firstly, we will need to install stunnel, which is as simple as:

$ brew install stunnel

The stunnel configuration file can define multiple services, each with its own local options. In this case, there is only one smtps-gmail, and the configuration defines the endpoint on which to listen:

accept = localhost:2525

the endpoint to connect to:

connect = smtp.gmail.com:465

and the mode in which to operate:

client = yes

which means that the listening connection does not require SSL.

Putting it all together we have:

[smtps-gmail]
accept = localhost:2525
client = yes 
connect = smtp.gmail.com:465

We can now start the tunnel by running:

$ stunnel smtps-gmail.conf

NOTE: The listening port is set to 2525 to ensure it can be bound to as an unprivileged user. If I wanted to use the well-known port for SMTP, port 25, stunnel would need to be run as a privileged user (e.g. via sudo).

Preparing to send

We need to prepare a few items in advance, as the commands are entered interactively:

username
password
message data

All of these involve Base64 encoding to protect the contents during transmission, as SMTP is traditionally not 8-bit clean.

Format username

To prepare the username and password strings:

$ echo -n 'username' | base64

dXNlcm5hbWU=

Format password

$ echo -n 'password' | base64

cGFzc3dvcmQ=

Generate message body

For the purposes of this, I’m going to generate a random file for sending:

$ dd if=/dev/urandom of=data.bin bs=1024 count=1
$ base64 --break 76 data.bin

ypV6owJCIyb+nm5ayZbeeaVp5Wqfxw+VWce+NE2DDAz+LDWCNbFd05LfyyXCVaclsL65Q26ILiHD
RvzMMyRRPyvWvG8q/R3yQcUykFXvTQ4GmOkpMo4hhcqmmfj9blhXT0gTW5UHIMDCSJdvMc8gaS4i
tvEs5ftjCeTMoX1IXOv0N5hDPwue125ZFkG4WCK4LTd44BIRJyVDdMLh+ycVNmCkFq+l3dCTy34r
w2/c9WPpvzo+w1rvA2ryZcd4MXVBbLc7EBA5V0v7IKrCj6af/GmfqulxPWHCwDdhiOc/v1ctO8Q1
jaorupDkRioF3YnN/6SZDJYYxcc5okLRh8DOmYGPlLLx1gthqXeo6BY1wcf5Rh5JiRf6gSgZ2djL
PWBXt0TC96ndK4VT/pxQvShDx/eIG5QSaziNFXQUkVnXfxyazwZdZRgVxdjwrpkM0MZQixVgMPoS
81ucUlhu99SCd+LPfWbsa9Cloyec6GAmfXwvNaYK57g15fTZRm9wftJnzeqavoePIFK9ldgkdgob
Ek2Cm+lEK+2IVmrYg0Y4zWDsuWX01Wf9SKw+QFro4zdMpFrFCB2GAW8ErZrvWE/mjRlXtY4Ja2MN
OQ6KF8pRuzLehNJJhvQJjKGP2RzTqs/OcNnGULOUiy9SIBEnszzhtjqlkMbuZ+cwEKWmRX+/5Wi9
CK28ZxAMSEuAQbCOEEAcKcrqWJKr8bgrOmp0A41IaiZIKzwqkONinCFOEdRSdRvGpJ67oDplvzB6
gLT2Ij+7F5Sc3Yyg00mXK+Zae7bcsMwYVWcH6b3XYRo0LaNUTlCz4oHFWY4/rhhEhVA0zRZpKKYX
H9C7qInKh1+1TJ3hmNW87jrttFft/ggW0LYoTKZEVEAeJHtICJay6GsFaqG6q/KRCdV1ZxfImMgH
gbhgEEzDq2hTpACgBkRu7SUrcKPSzXgBufbUrZwH4EZRcj+x6PRFM0D9EOT+uPQxK3EBNmTjwwLa
uYpP0hDg84o4e7IkCbBHdNNc1PK1YuPXlKjIyNQd5kOQxJJY8+GVgA5IGTrSWUitCh/yW7U8Px7B
Mw7xMKxAdu4nBptvS8mgc1ueikyRGVPTv3NJ44jO6IBCqce3a0yGXLZ3DNc1p0IR1MKe6ta584Fd
bCw5/3/QowqroFMEORxdq/UY7Flea4FufoVCmAhHOVm/W7s4F/ZnF7sUBH0GV8b5cnLmpn1KPsKK
hA4jqT+KrofjiPreu99qGkv01oxPAPLDGNPU7ahCPETK6bznGMO3Fw8dZW9ElonZywP99P8UQU7q
7QP1KMA8EdB0DDdtLpvQeuHWBv3aBgwRnx1HC44fs6yzCVn9H5/SfDUyWh29dWJZWpRBM7If4Q==

The simplest format for the body of the message specifies the Content-Type, the Content-Transfer-Encoding and provides the encoded file. Given that this is for testing sending an email without parts of type text/plain or text/html, the message body will be as follows:

Content-Type: application/data; name="data.bin"
Content-Transfer-Encoding: base64
ypV6owJCIyb+nm5ayZbeeaVp5Wqfxw+VWce+NE2DDAz+LDWCNbFd05LfyyXCVaclsL65Q26ILiHD
RvzMMyRRPyvWvG8q/R3yQcUykFXvTQ4GmOkpMo4hhcqmmfj9blhXT0gTW5UHIMDCSJdvMc8gaS4i
tvEs5ftjCeTMoX1IXOv0N5hDPwue125ZFkG4WCK4LTd44BIRJyVDdMLh+ycVNmCkFq+l3dCTy34r
w2/c9WPpvzo+w1rvA2ryZcd4MXVBbLc7EBA5V0v7IKrCj6af/GmfqulxPWHCwDdhiOc/v1ctO8Q1
jaorupDkRioF3YnN/6SZDJYYxcc5okLRh8DOmYGPlLLx1gthqXeo6BY1wcf5Rh5JiRf6gSgZ2djL
PWBXt0TC96ndK4VT/pxQvShDx/eIG5QSaziNFXQUkVnXfxyazwZdZRgVxdjwrpkM0MZQixVgMPoS
81ucUlhu99SCd+LPfWbsa9Cloyec6GAmfXwvNaYK57g15fTZRm9wftJnzeqavoePIFK9ldgkdgob
Ek2Cm+lEK+2IVmrYg0Y4zWDsuWX01Wf9SKw+QFro4zdMpFrFCB2GAW8ErZrvWE/mjRlXtY4Ja2MN
OQ6KF8pRuzLehNJJhvQJjKGP2RzTqs/OcNnGULOUiy9SIBEnszzhtjqlkMbuZ+cwEKWmRX+/5Wi9
CK28ZxAMSEuAQbCOEEAcKcrqWJKr8bgrOmp0A41IaiZIKzwqkONinCFOEdRSdRvGpJ67oDplvzB6
gLT2Ij+7F5Sc3Yyg00mXK+Zae7bcsMwYVWcH6b3XYRo0LaNUTlCz4oHFWY4/rhhEhVA0zRZpKKYX
H9C7qInKh1+1TJ3hmNW87jrttFft/ggW0LYoTKZEVEAeJHtICJay6GsFaqG6q/KRCdV1ZxfImMgH
gbhgEEzDq2hTpACgBkRu7SUrcKPSzXgBufbUrZwH4EZRcj+x6PRFM0D9EOT+uPQxK3EBNmTjwwLa
uYpP0hDg84o4e7IkCbBHdNNc1PK1YuPXlKjIyNQd5kOQxJJY8+GVgA5IGTrSWUitCh/yW7U8Px7B
Mw7xMKxAdu4nBptvS8mgc1ueikyRGVPTv3NJ44jO6IBCqce3a0yGXLZ3DNc1p0IR1MKe6ta584Fd
bCw5/3/QowqroFMEORxdq/UY7Flea4FufoVCmAhHOVm/W7s4F/ZnF7sUBH0GV8b5cnLmpn1KPsKK
hA4jqT+KrofjiPreu99qGkv01oxPAPLDGNPU7ahCPETK6bznGMO3Fw8dZW9ElonZywP99P8UQU7q
7QP1KMA8EdB0DDdtLpvQeuHWBv3aBgwRnx1HC44fs6yzCVn9H5/SfDUyWh29dWJZWpRBM7If4Q==

Sending the email

Now that we have the tunnel running and our encoded contents prepared, we can connect through it to the SMTP server by running:

$ nc -c localhost 2525

NOTE: On macOS, the netcat command has the -c option, which sends CRLF as the line-ending. This is important when entering the body of the email, as the end of the data is expected to be exactly <CR><LF>.<CR><LF>.

We are greeted with the service ready message:

220 smtp.gmail.com ESMTP v17-v6sm3241947pfn.177 - gsmtp

From here, we interactively enter the SMTP commands effectively in a script as expected by the server:

EHLO msbit.com.au

250-smtp.gmail.com at your service, [xxx.xxx.xxx.xxx]
250-SIZE 35882577
250-8BITMIME
250-AUTH LOGIN PLAIN XOAUTH2 PLAIN-CLIENTTOKEN OAUTHBEARER XOAUTH
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-CHUNKING
250 SMTPUTF8

AUTH LOGIN

334 VXNlcm5hbWU6

dXNlcm5hbWU=

334 UGFzc3dvcmQ6

cGFzc3dvcmQ=

235 2.7.0 Accepted

MAIL FROM: <tom@msbit.com.au>

250 2.1.0 OK v17-v6sm3241947pfn.177 - gsmtp

RCPT TO: <tom@msbit.com.au>

250 2.1.5 OK v17-v6sm3241947pfn.177 - gsmtp

DATA

354  Go ahead v17-v6sm3241947pfn.177 - gsmtp

Content-Type: application/data; name="data.bin"
Content-Transfer-Encoding: base64
ypV6owJCIyb+nm5ayZbeeaVp5Wqfxw+VWce+NE2DDAz+LDWCNbFd05LfyyXCVaclsL65Q26ILiHD
RvzMMyRRPyvWvG8q/R3yQcUykFXvTQ4GmOkpMo4hhcqmmfj9blhXT0gTW5UHIMDCSJdvMc8gaS4i
tvEs5ftjCeTMoX1IXOv0N5hDPwue125ZFkG4WCK4LTd44BIRJyVDdMLh+ycVNmCkFq+l3dCTy34r
w2/c9WPpvzo+w1rvA2ryZcd4MXVBbLc7EBA5V0v7IKrCj6af/GmfqulxPWHCwDdhiOc/v1ctO8Q1
jaorupDkRioF3YnN/6SZDJYYxcc5okLRh8DOmYGPlLLx1gthqXeo6BY1wcf5Rh5JiRf6gSgZ2djL
PWBXt0TC96ndK4VT/pxQvShDx/eIG5QSaziNFXQUkVnXfxyazwZdZRgVxdjwrpkM0MZQixVgMPoS
81ucUlhu99SCd+LPfWbsa9Cloyec6GAmfXwvNaYK57g15fTZRm9wftJnzeqavoePIFK9ldgkdgob
Ek2Cm+lEK+2IVmrYg0Y4zWDsuWX01Wf9SKw+QFro4zdMpFrFCB2GAW8ErZrvWE/mjRlXtY4Ja2MN
OQ6KF8pRuzLehNJJhvQJjKGP2RzTqs/OcNnGULOUiy9SIBEnszzhtjqlkMbuZ+cwEKWmRX+/5Wi9
CK28ZxAMSEuAQbCOEEAcKcrqWJKr8bgrOmp0A41IaiZIKzwqkONinCFOEdRSdRvGpJ67oDplvzB6
gLT2Ij+7F5Sc3Yyg00mXK+Zae7bcsMwYVWcH6b3XYRo0LaNUTlCz4oHFWY4/rhhEhVA0zRZpKKYX
H9C7qInKh1+1TJ3hmNW87jrttFft/ggW0LYoTKZEVEAeJHtICJay6GsFaqG6q/KRCdV1ZxfImMgH
gbhgEEzDq2hTpACgBkRu7SUrcKPSzXgBufbUrZwH4EZRcj+x6PRFM0D9EOT+uPQxK3EBNmTjwwLa
uYpP0hDg84o4e7IkCbBHdNNc1PK1YuPXlKjIyNQd5kOQxJJY8+GVgA5IGTrSWUitCh/yW7U8Px7B
Mw7xMKxAdu4nBptvS8mgc1ueikyRGVPTv3NJ44jO6IBCqce3a0yGXLZ3DNc1p0IR1MKe6ta584Fd
bCw5/3/QowqroFMEORxdq/UY7Flea4FufoVCmAhHOVm/W7s4F/ZnF7sUBH0GV8b5cnLmpn1KPsKK
hA4jqT+KrofjiPreu99qGkv01oxPAPLDGNPU7ahCPETK6bznGMO3Fw8dZW9ElonZywP99P8UQU7q
7QP1KMA8EdB0DDdtLpvQeuHWBv3aBgwRnx1HC44fs6yzCVn9H5/SfDUyWh29dWJZWpRBM7If4Q==
.

250 2.0.0 OK 1533692605 v17-v6sm3241947pfn.177 - gsmtp

QUIT

221 2.0.0 closing connection v17-v6sm3241947pfn.177 - gsmtp

Note the final . line to end the DATA portion.

The email should now have been sent!

Confirming the output

When checking my inbox, there is a new email from me, with no subject, or body, but an attachment. The full email message is as shown below:

Bcc: tom@msbit.com.au
Return-Path: <tom@msbit.com.au>
Received: from msbit.com.au (xxx.xxx.xxx.xxx.xxx. [xxx.xxx.xxx.xxx])
        by smtp.gmail.com with ESMTPSA id v17-v6sm3241947pfn.177.2018.08.07.18.43.09
        for <tom@msbit.com.au>
        (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
        Tue, 07 Aug 2018 18:43:25 -0700 (PDT)
Message-ID: <5b6a4abd.1c69fb81.319ec.8e62@mx.google.com>
Date: Tue, 07 Aug 2018 18:43:25 -0700 (PDT)
From: tom@msbit.com.au
Content-Type: application/data; name="data.bin"
Content-Transfer-Encoding: base64

ypV6owJCIyb+nm5ayZbeeaVp5Wqfxw+VWce+NE2DDAz+LDWCNbFd05LfyyXCVaclsL65Q26ILiHD
RvzMMyRRPyvWvG8q/R3yQcUykFXvTQ4GmOkpMo4hhcqmmfj9blhXT0gTW5UHIMDCSJdvMc8gaS4i
tvEs5ftjCeTMoX1IXOv0N5hDPwue125ZFkG4WCK4LTd44BIRJyVDdMLh+ycVNmCkFq+l3dCTy34r
w2/c9WPpvzo+w1rvA2ryZcd4MXVBbLc7EBA5V0v7IKrCj6af/GmfqulxPWHCwDdhiOc/v1ctO8Q1
jaorupDkRioF3YnN/6SZDJYYxcc5okLRh8DOmYGPlLLx1gthqXeo6BY1wcf5Rh5JiRf6gSgZ2djL
PWBXt0TC96ndK4VT/pxQvShDx/eIG5QSaziNFXQUkVnXfxyazwZdZRgVxdjwrpkM0MZQixVgMPoS
81ucUlhu99SCd+LPfWbsa9Cloyec6GAmfXwvNaYK57g15fTZRm9wftJnzeqavoePIFK9ldgkdgob
Ek2Cm+lEK+2IVmrYg0Y4zWDsuWX01Wf9SKw+QFro4zdMpFrFCB2GAW8ErZrvWE/mjRlXtY4Ja2MN
OQ6KF8pRuzLehNJJhvQJjKGP2RzTqs/OcNnGULOUiy9SIBEnszzhtjqlkMbuZ+cwEKWmRX+/5Wi9
CK28ZxAMSEuAQbCOEEAcKcrqWJKr8bgrOmp0A41IaiZIKzwqkONinCFOEdRSdRvGpJ67oDplvzB6
gLT2Ij+7F5Sc3Yyg00mXK+Zae7bcsMwYVWcH6b3XYRo0LaNUTlCz4oHFWY4/rhhEhVA0zRZpKKYX
H9C7qInKh1+1TJ3hmNW87jrttFft/ggW0LYoTKZEVEAeJHtICJay6GsFaqG6q/KRCdV1ZxfImMgH
gbhgEEzDq2hTpACgBkRu7SUrcKPSzXgBufbUrZwH4EZRcj+x6PRFM0D9EOT+uPQxK3EBNmTjwwLa
uYpP0hDg84o4e7IkCbBHdNNc1PK1YuPXlKjIyNQd5kOQxJJY8+GVgA5IGTrSWUitCh/yW7U8Px7B
Mw7xMKxAdu4nBptvS8mgc1ueikyRGVPTv3NJ44jO6IBCqce3a0yGXLZ3DNc1p0IR1MKe6ta584Fd
bCw5/3/QowqroFMEORxdq/UY7Flea4FufoVCmAhHOVm/W7s4F/ZnF7sUBH0GV8b5cnLmpn1KPsKK
hA4jqT+KrofjiPreu99qGkv01oxPAPLDGNPU7ahCPETK6bznGMO3Fw8dZW9ElonZywP99P8UQU7q
7QP1KMA8EdB0DDdtLpvQeuHWBv3aBgwRnx1HC44fs6yzCVn9H5/SfDUyWh29dWJZWpRBM7If4Q==

As we can see, the email has been delivered, the content is exactly the same as what was sent, and there is no mention of a text/plain or text/html component. As a final test, we can download the data.bin attachment and compare the SHA hashes:

$ shasum data.bin
e54b3d70b1368829d5db4c9ea77f2f667adf5b59  data.bin
$ shasum ~/Downloads/data.bin
e54b3d70b1368829d5db4c9ea77f2f667adf5b59  /Users/tom/Downloads/data.bin

which also confirm that the file has been successfully sent.

OpenBSD Kernels

2018-04-23T14:07:34+10:00

The initial problem

This weekend I’ve installed OpenBSD 6.3 on my old Macbook (Early 2008), and immediately I remember why I love this operating system. However, not everything is completely rosy.

After boot, the inteldrm driver appears to get confused and changes the console resolution to 848x480 (480i), but restricts this to the top left of the Macbook’s 1280x800 panel. Taking a look online, I found the following suggestion here: build a new kernel with DRMDEBUG enabled and consult the output.

Cheat sheet

# export KERNEL_CONFIGURATION_NAME=GENERIC_CUSTOM_NAME.MP
# cat << EOF > /sys/arch/$(machine)/conf/${KERNEL_CONFIGURATION_NAME}
> include "arch/i386/conf/GENERIC.MP"
>
> #option OPTION1
> #option OPTION2
>
> EOF
# mkdir /sys/arch/$(machine)/compile/${KERNEL_CONFIGURATION_NAME}
# cat << EOF > /sys/arch/$(machine)/compile/${KERNEL_CONFIGURATION_NAME}/Makefile
> .include "../Makefile.inc"
> EOF
# cd /sys/arch/$(machine)/compile/${KERNEL_CONFIGURATION_NAME}
# make obj
# make config
# make && make install
# reboot

The process

The first steps are as listed here:

$ cd /usr
$ cvs -qd anoncvs@anoncvs.ca.openbsd.org:/cvs checkout -rOPENBSD_6_3 -P src

This will take a while, and afterwards you’ll have all the source for the kernel and the core userland nicely in place.

Given that it’s been a long time since I’ve compiled an OpenBSD kernel, I thought I’d follow the instructions here pretty much verbatim to start with:

# cd /sys/arch/$(machine)/compile/GENERIC.MP
# make obj
# make config
# make && make install
# reboot

Fingers crossed, breath held and my Macbook comes back up. Success; I know I can build a kernel properly.

Configuration modification

Now, as I’d noted in the introduction, I needed to enable DRMDEBUG to enable the drm debug logging, and the way to do this is via options. Each of the option entries are provided as defines to the kernel build process, so in my case:

option DRMDEBUG

would result in:

-DDRMDEBUG

being added to the compiler flags.

Where to add this?

In the compilation steps, the only obviously variable item (besides the call to machine which will be the i386 for any invocations on this installation) is GENERIC.MP. If we take a look at this directory (ignoring source control files and the generated obj link) we find a single Makefile which is the tail end of the following include hierarchy:

/sys/arch/i386/compile/GENERIC.MP/Makefile
/sys/arch/i386/compile/Makefile.inc
/usr/src/share/mk/bsd.obj.mk
/usr/src/share/mk/bsd.own.mk
$MAKECONF or /etc/mk.conf if they exist

The target we are interested in, config, is defined in /sys/arch/i386/compile/Makefile.inc as:

config:
        config ${.CURDIR:M*.PROF:C/.*/-p/} -b ${.OBJDIR} \
                -s ${SYSDIR} ${CONFDIR}/${.CURDIR:T:S/.PROF$//}

This command makes use of config command to create a kernel build directory for a specified top-level source kernel source directory based on the configuration file. This configuration file (${CONFDIR}/${.CURDIR:T:S/.PROF$//}) is the next thing to look at.

Variable interpretation

To work out what this expands to, we need to know a few things from here, namely:

The built in .CURDIR variable, which is the path from which make is called
The :S modifier, which performs string replacement on a variable
The :T modifier, which replaces the variable with its last path component

Due to where we called make from, .CURDIR is now:

/sys/arch/i386/compile/GENERIC.MP

Based on this, CONFDIR (defined at the top of /sys/arch/i386/compile/Makefile.inc as the absolute path to ${.CURDIR}/../../conf), becomes:

/sys/arch/i386/conf

so we have:

/sys/arch/i386/conf/${.CURDIR:T:S/.PROF$//}

.CURDIR:T:S/.PROF$// is getting the last path component of /sys/arch/i386/compile/GENERIC.MP and removing the first (and only, based on the regex anchoring) occurence of .PROF.

NOTE: The removal of .PROF in this case isn’t relevant, but works in concert with ${.CURDIR:M*.PROF:C/.*/-p/} in the call to config to automatically include profiling code for appropriately named configurations.

Expanding this out, we now have:

/sys/arch/i386/conf/GENERIC.MP

Voila.

The contents of this configuration file (comments removed) are:

include "arch/i386/conf/GENERIC"

option          MULTIPROCESSOR

cpu*            at mainbus?

which is where we could set our options.

Custom configuration

I say could because it’s not a great idea to modify a configuration file that’s checked into source control, and from the use of include "arch/i386/conf/GENERIC" at the top of the file it’s clear that we can easily extend the configuration, creating our own custom configuration. All we need to do is:

create the configuration file
add a correspondingly named directory and Makefile under /sys/arch/$(machine)/compile

Given that I’m adding the DRMDEBUG flag, I’m going to name the configuration GENERIC_DRMDEBUG.MP, so the commands look like this:

# cat << EOF > /sys/arch/$(machine)/conf/GENERIC_DRMDEBUG.MP
> include "arch/i386/conf/GENERIC.MP"
>
> option  DRMDEBUG
> EOF
# mkdir /sys/arch/$(machine)/compile/GENERIC_DRMDEBUG.MP
# cat << EOF > /sys/arch/$(machine)/compile/GENERIC_DRMDEBUG.MP/Makefile
> .include "../Makefile.inc"
> EOF

Now, the compilation is almost exactly the same as the default:

# cd /sys/arch/$(machine)/compile/GENERIC_DRMDEBUG.MP
# make obj
# make config
# make && make install
# reboot

Once that’s done and the computer restarts, I can check the (voluminous) contents of /var/log/messages for the additional logging information, and hopefully this puts me on the path to working out my initial console resolution issue.

Windows 10 Update Issues

2018-04-12T13:08:18+10:00

An issue with an update

After waking my Windows 10 PC up and running updates, I was told that the latest update (2018-04 Cumulative Update for Windows 10 Version 1709 for x64-based Systems (KB4093112)) could not be installed. Looking over the update history, it appeared that this was the second update that couldn’t be installed, the first being 2018-02 Cumulative Update for Windows 10 Version 1709 for x64-based Systems (KB4074588).

Restarting the PC, either manually or through the button in Windows Update, wasn’t causing the update to be installed; in my experience the update would be queued up immediately prior to restart, or immediately after restart.

Some information could be gleaned in Event Viewer, under Windows Logs > System, filtering by:

Event sources restricted to WindowsUpdateClient
Event level restricted to Error

or using the following XML filter:

<QueryList>
  <Query Id="0" Path="System">
    <Select Path="System">*[System[Provider[@Name='Microsoft-Windows-WindowsUpdateClient'] and (Level=2)]]</Select>
  </Query>
</QueryList>

From this I had the following distinct events:

Installation Failure: Windows failed to install the following update with error 0x80010108: 2018-02 Cumulative Update for Windows 10 Version 1709 for x64-based Systems (KB4074588).
Installation Failure: Windows failed to install the following update with error 0x80070BC2: 2018-02 Cumulative Update for Windows 10 Version 1709 for x64-based Systems (KB4074588).
Installation Failure: Windows failed to install the following update with error 0x80070020: 2018-02 Cumulative Update for Windows 10 Version 1709 for x64-based Systems (KB4074588).
Installation Failure: Windows failed to install the following update with error 0x80246007: 2018-02 Cumulative Update for Windows 10 Version 1709 for x64-based Systems (KB4074588).
Installation Failure: Windows failed to install the following update with error 0x80070BC2: 2018-04 Cumulative Update for Windows 10 Version 1709 for x64-based Systems (KB4093112).
Installation Failure: Windows failed to install the following update with error 0x8007045B: 2018-04 Cumulative Update for Windows 10 Version 1709 for x64-based Systems (KB4093112).

resolving down to the following error codes:

A solution is found

Looking for these error codes online, I luckily found a very helpful comment on Reddit here which indicated that ensuring particular services were configured to run automatically would solve the issue.

The services in question were:

BITS (Background Intelligent Transfer Service)
CryptSvc (Cryptographic Services)
TrustedInstaller (Windows Modules Installer)
wuauserv (Windows Update)

As opposed to simply configuring the services to run automatically, I thought I’d take a look at the current configuration of each.

Before attempting the fix, the service configuration for each (obtained via sc qc <service-name>) was:

SERVICE_NAME: BITS
        TYPE               : 20  WIN32_SHARE_PROCESS
        START_TYPE         : 2   AUTO_START  (DELAYED)
        ERROR_CONTROL      : 1   NORMAL
        BINARY_PATH_NAME   : C:\WINDOWS\System32\svchost.exe -k netsvcs -p
        LOAD_ORDER_GROUP   :
        TAG                : 0
        DISPLAY_NAME       : Background Intelligent Transfer Service
        DEPENDENCIES       : RpcSs
        SERVICE_START_NAME : LocalSystem

SERVICE_NAME: CryptSvc
        TYPE               : 20  WIN32_SHARE_PROCESS
        START_TYPE         : 2   AUTO_START
        ERROR_CONTROL      : 1   NORMAL
        BINARY_PATH_NAME   : C:\WINDOWS\system32\svchost.exe -k NetworkService -p
        LOAD_ORDER_GROUP   :
        TAG                : 0
        DISPLAY_NAME       : Cryptographic Services
        DEPENDENCIES       : RpcSs
        SERVICE_START_NAME : NT Authority\NetworkService

SERVICE_NAME: TrustedInstaller
        TYPE               : 10  WIN32_OWN_PROCESS
        START_TYPE         : 3   DEMAND_START
        ERROR_CONTROL      : 1   NORMAL
        BINARY_PATH_NAME   : C:\WINDOWS\servicing\TrustedInstaller.exe
        LOAD_ORDER_GROUP   : ProfSvc_Group
        TAG                : 0
        DISPLAY_NAME       : Windows Modules Installer
        DEPENDENCIES       :
        SERVICE_START_NAME : localSystem

SERVICE_NAME: wuauserv
        TYPE               : 20  WIN32_SHARE_PROCESS
        START_TYPE         : 2   AUTO_START
        ERROR_CONTROL      : 1   NORMAL
        BINARY_PATH_NAME   : C:\WINDOWS\system32\svchost.exe -k netsvcs
        LOAD_ORDER_GROUP   :
        TAG                : 0
        DISPLAY_NAME       : Windows Update
        DEPENDENCIES       : rpcss
        SERVICE_START_NAME : LocalSystem

The odd one out in this listing is TrustedInstaller, with a START_TYPE of DEMAND_START, all others have some variant of AUTO_START. More importantly, the current status of TrustedInstaller (obtained via sc query TrustedInstaller) was:

SERVICE_NAME: TrustedInstaller
        TYPE               : 10  WIN32_OWN_PROCESS
        STATE              : 1  STOPPED
        WIN32_EXIT_CODE    : 0  (0x0)
        SERVICE_EXIT_CODE  : 0  (0x0)
        CHECKPOINT         : 0x0
        WAIT_HINT          : 0x0

so the service was not running.

My understanding of DEMAND_START is that it should be, well, started on demand, so Windows Update should have been able to start it as part of the update installation process. However, this seemed a very likely issue, so I reconfigured the start type via the command mentioned in the Reddit comment, sc config TrustedInstaller start= auto and restarted my PC.

After this, initialising a restart via Windows Update proceeded smoothly, and the update has been installed.

Further investigation

Now I felt it was worth looking into how the TrustedInstaller service had been configured for on-demand start, so I took a look at Event Viewer once again. This time, filtering by:

Event sources restricted to Service Control Manager and WindowsUpdateClient

or using the following XML filter:

<QueryList>
  <Query Id="0" Path="System">
    <Select Path="System">*[System[Provider[@Name='Service Control Manager' or @Name='Microsoft-Windows-WindowsUpdateClient']]]</Select>
  </Query>
</QueryList>

Around the time of a failed update installation were the following events:

The start type of the Windows Update service was changed from demand start to auto start.
Windows Update started downloading an update.
The start type of the Windows Modules Installer service was changed from demand start to auto start.
Installation Started: Windows has started installing the following update: 2018-04 Cumulative Update for Windows 10 Version 1709 for x64-based Systems (KB4093112)
The start type of the Windows Modules Installer service was changed from auto start to demand start.
The start type of the Update Orchestrator Service service was changed from demand start to auto start.
The start type of the Background Intelligent Transfer Service service was changed from auto start to demand start.
The Update Orchestrator Service service terminated with the following error:
    This operation returned because the timeout period expired.
The start type of the Update Orchestrator Service service was changed from auto start to demand start.
Installation Failure: Windows failed to install the following update with error 0x80070BC2: 2018-04 Cumulative Update for Windows 10 Version 1709 for x64-based Systems (KB4093112).

From this listing, it appears that:

wuauserv initiates an update download and starts TrustedInstaller
TrustedInstaller starts an install, but stops due to the installation requiring a restart
UsoSvc (Update Orchestrator Service) is started but is terminated due to an error
Installation of the update fails

So how does changing the start type of TrustedInstaller do to fix this issue? My guess is that UsoSvc is tasked with re-enabling TrustedInstaller (among other things), and so if it fails it also doesn’t re-enable TrustedInstaller to finalise the installation during the restart process.

Conclusion

That’s about as far as I can go now, without attempting to rollback the update and reinstall to trigger the issue. Going forward, I’m going to return the TrustedInstaller service to start on demand, and see whether this issue rears its head again for the next update.