Windows Bluetooth not connecting? This fix worked for me!

Is your Windows Bluetooth detecting devices, but not connecting to them?

That was a profoundly frustrating problem for me. It turned out to have a simple fix.

Before we get to that, I want to make sure that anyone searching on the same Bluetooth symptoms I saw have a good chance of finding this post. So, if you're running into issues like:

      - Bluetooth not linking;

      - Bluetooth will not connect;

      - Bose QC35 II headset not connecting Bluetooth;

      - Bluetooth mouse not connecting;

      - Bluetooth can see device but will not connect;

      - Bluetooth not working after Windows update.

then this might be the fix that will work for you.

What happened to me?

In my case, Windows Bluetooth just stopped working one day.

For no reason I could determine, Bluetooth devices refused to complete their connection when an attempt was made to link them through Windows.

I updated Bluetooth drivers, uninstalled/reinstalled Bluetooth drivers, removed devices from Windows Device Manager, then performed every last Windows, driver and BIOS update I could find. Alas, none of the 'fixes' I attempted resolved the issue.

Through it all, each Bluetooth device would be seen in Windows when choosing to 'Add Bluetooth or other device', but they would not connect.

So, Bluetooth was working, it was finding devices, but the devices refused to connect.

How did I spot the cause?

A check in Windows Event Viewer showed that each failed connection logged an error with source BTHUSB and Event ID 16.

The Windows Event Viewer error detail text stated:

The mutual authentication between the local Bluetooth adapter and a device with Bluetooth adapter address [device_address_here] failed.

In other words, Windows Bluetooth saw the device, but could not establish an authenticated connection.

What was the solution?

For me, the problem was found in the properties of two Bluetooth Windows Services.

Bluetooth services must "Log on as" Local Service.

Bluetooth services must have the "Log on as" property set to "Local Service". In my case, they had somehow changed to log on as "Local System account".

To correct that setting, follow these steps:

      Open your Windows Services list;

      Scroll to the Windows Services named:

        Bluetooth Audio Gateway Service

        Bluetooth Support Service

      Select a service, open its Properties, then click the 'Log On' tab.

      If you see "Local System account" set for the Log On option of either of those services:

        Select the 'This account:' radio button option;

        Enter in the This account field the text "Local Service" (without the quotes);

        Leave the Password and Confirm Password fields blank;

        Click Apply to apply the change;

        Close the properties dialog;

        Stop the service;

        Restart the service.

Make that change to both the Bluetooth Support Service and (if present) the Bluetooth Audio Gateway Service.

For good measure, fully power off your computer, wait 30 seconds, then power on again.

With your computer restarted, check your Windows Services list and confirm both services are now set to Log On as "Local Service".

Now, try connecting your Bluetooth devices.

If you had the same issue that I did, you should now experience the miraculous return of your Windows Bluetooth connectivity.

Still have issues?

If your Bluetooth devices are still refusing to connect, I recommend opening your Windows Event Viewer.

In Windows Event Viewer, select Custom Views -> Administrative Events in the left-hand menu, then review the Error/Warning entries with Source of type BTHUSB. Under the General tab you will see a description of the error, and an internet search on that text may lead you to a solution.

Special thanks go to the author of this Reddit post:

Of all the myriad Windows / driver doc pages and tech support forums on the internet, that single obscure comment on /r/techsupport was the only resource I found that isolated the cause of and solution to my Bluetooth connectivity issue.

How to Block an IPv6 Address Range

So, your server is receiving unwanted network traffic.

You'd normally add a new iptables rule and block the troublemaker. But this time, the source comes from a network set with an IPv6 address.

Wat do?

Who This Post is For

This post covers the absolute basics of dealing with IPv6 addresses. It delivers the bare-bones summary I had hoped to find when I searched for how to block IPv6 traffic.

If you want detailed information, the IPv6 Wikipedia Page is a good place to start.

But you don't want that, do you.

You want to:

      - understand the syntax of an IPv6 address;

      - learn how to specify an IPv6 address range; and

      - see how to write an iptables rule that blocks an IPv6 address range.

At least I did. And now I know!

And, in a few minutes, you're going to know as well.

The Basics of IPv6

IPv6 syntax is similar to traditional IPv4.

Hexadecimal values are listed in order of network detail, with each four-byte group delimited by ":".

An address you'll often see is: 2001:db8::

That's not a special value; it's just a standard subnet chosen for IPv6 documentation. Think of it as the of IPv6, or the equivalent of the you might use for an IPv4 document.

We'll be using that 2001:db8:: subnet in the examples outlined here.

"But," you might ask, "isn't that example address a bit short for IPv6?"

Nope! The address is just written in IPv6 short form.

IPv6 Short Form

The IPv6 address 2001:db8:: can be fully written as:


Leading 0s can be omitted. So, we can write a snipped equivalent of the above with:


Snipping further, ranges of 0s can be indicated with a double colon "::", like so:


We can also snip out 0s in the middle of an address. For example, this address:


can be written as:


The IBM documentation page at does an excellent job of describing IPv6 syntax.

I recommend reading that page before continuing (it's very short -- it'll take you two minutes) to make sure you understand IPv6 syntax.

How to Specify an IPv6 Subnet

We now know how to write out one of the 340,282,366,920,938,463,463,374,607,431,768,211,456 possible IPv6 addresses.

Yeah, there are a lot. And we'll have to block many nefarious IPv6 subnets in the years to come.

IPv6 subnets are identified through the address's four-byte groups. So, just as we can write:

to indicate all IPv4 addresses from to, we can write:


to indicate all IPv6 addresses from 2001:0db8:0000:0000:0000:0000:0000:0000 to 2001:0db8:ffff:ffff:ffff:ffff:ffff:ffff

Similarly, the notation:


would indicate all IPv6 addresses from 2001:0db8:4567:0000:0000:0000:0000:0000 to 2001:0db8:4567:ffff:ffff:ffff:ffff:ffff

If you're wondering what /32 and /48 mean, this page about IPv6 subnetting does a fantastic job of explaining values for IPv6 slash "/" notation.

I recommend reading that page before continuing (again, it's very short -- you'll be done in minutes) to make sure you understand how IPv6 subnets are written.

Want to Test What You've Learned?

Of course you do!

This IPv6 Subnet Calculator will accept an entered IPv6 subnet and show the range of addresses it covers.

A few experiments there will confirm you've caught the basics.

How to Block an IPv6 Subnet

Now that we know how to specify an IPv6 subnet, how do we go about blocking it?

Why, using ip6tables, of course!

I'm assuming here that you're familiar with how to use the iptables tool to block unwanted IPv4 network traffic. If iptables is new to you, you'll find Linode's iptables tutorial a helpful guide to get started with the basics.

Using iptables, we could block traffic from the IPv4 address range to with the command:

iptables -A INPUT -s -j DROP

In the same way, we can block all traffic from an IPv6 subnet using ip6tables.

Using our range example above, the IPv6 address range 2001:0db8:0000:0000:0000:0000:0000:0000 to 2001:0db8:ffff:ffff:ffff:ffff:ffff:ffff can be blocked using the ip6tables command:

ip6tables -A INPUT -s 2001:0db8::/32 -j DROP

Similarly, a more precise targeting of the IPv6 address range 2001:0db8:4567:0000:0000:0000:0000:0000 to 2001:0db8:4567:ffff:ffff:ffff:ffff:ffff can be blocked with:

ip6tables -A INPUT -s 2001:0db8:4567::/48 -j DROP

You can specify your subnet of choice using the examples covered above.

And That's It!

You're good to go.

You're armed and ready to block any IPv6 traffic dispatched to hassle your servers.

Good luck!

(Special thanks to's post about IPv6 range blocking at That gave me a good starting point for figuring out the basics.)

Past Space Resource Papers

These old papers and abstracts came up in conversation, and I thought I'd surface them here from Google Scholar for easy blog reference.

The contents are decades old, but lunar matters are much the same. The major difference these days is that the ‘non-renewable resource' of scientific ignorance has diminished a bit.

So we've got that going for us, which is nice.

This list is in chronological order, and nowhere near complete. Three full lunar/asteroidal development papers for the Journal of the British Interplanetary Society seem to be tucked elsewhere, and there is a ridiculously extensive collection of presentations made through the years that are very slightly bending a shelf to my right.

If you'd like copies, just ask over a coffee or pint.

Commercial activities resulting from a lunar base - Charles D. O'Dale (1994)
British Interplanetary Society, Journal (ISSN 0007-094X)
vol. 47, no. 12, p. 549-554

Policy Considerations for Lunar Development - Charles D. O'Dale (1995)
Thirty Second Space Congress, Paper Session II-C (1995)

The International Lunar Base as a Foundation for Commercial Industry - Charles D. O'Dale (2000)
Proceedings of the Fourth International Conference on Exploration and Utilisation of the Moon: ICEUM 4

Public and Private Sector Coordination for Effective Lunar Resource Use - Charles D. O'Dale (2005)
Proceedings of the International Lunar Conference, 2005

Lessons from Earth: Experiences Which can Guide Lunar and Asteroidal Development - Charles D. O'Dale (2004)
Space Resources Roundtable VI

Using Secondary Objectives to Guide the Development of Lunar Industry - Charles D. O'Dale (2005)
Lunar Exploration Analysis Group (LEAG) (2005)

How To Stop Windows 10 Notepad From Saving Find Settings

Windows Notepad is a simple workhorse text editor. It's nothing fancy. It just gives the bare basics, with a clean session each time it's opened.

At least it did.

Get Windows 10 Notepad to start with a clean session each time it is opened.

In 2019, Microsoft decided to have Windows 10 Notepad remember its last used settings. That change isn't a big deal for most people, but when I open Notepad I'm not looking to tweak settings before getting to work. I just want to open Notepad, enter a snippet to find with 'ctrl-f', hit 'enter', and confirm the text is present (or not) before moving on. But now, I have to step out of my workflow to first confirm text search is clear, set its direction, and then perform my search.

Again, not a big deal for most people. But if you are as annoyed by that change as I am, you understand why it's a pain.

It would be fantastic if Microsoft provided a 'do not remember last settings' option in Windows 10 Notepad along with that extra functionality to remember find settings, but they didn't. So, now we have to work a little magic with the registry editor to fix that and get Windows 10 Notepad to start with a clean session each time it is opened.

Like it used to.

Quick Side-Note:

The changes made here use the Windows registry edit tool.

If you are already familiar with the registry editor, you know how to tweak registry settings and are aware of how dangerous those changes can be.

If you are not familiar with the Windows registry editor, please familiarize yourself with the ins-and-outs of that tool and back up your full windows registry before proceeding.

These instructions have been left deliberately vague and may be confusing to anyone not familiar with the Windows 10 registry editor. If these instructions are not perfectly clear to you, please take a bit of time to familiarize yourself with your Windows registry editor.

Disclaimer and Warning:

Changes made in your Windows registry editor can destroy your computer. That is not an exaggeration. Be certain you have a full registry backup and know what you are doing before proceeding with any windows registry edits.

To Prevent Windows 10 Notepad From Saving Its Find Settings:

First, perform a search in Windows 10 Notepad to place your settings in your preferred default search direction ("Direction (*) Down", right?) then close Notepad.

Next, open your editor to the branch:

Select the key:

and clear its contents.

At this point, you have Windows 10 Notepad set to its traditional defaults. Now, we are going to lock those defaults in place:

Click the registry branch:

then right-click on that item and choose the "Permissions..." pop-up menu item. The "Permissions for Notepad" dialog box will be opened, with its "Security" tab displayed.

In the displayed list of "Group or user names:", select the user account you would like to fix Notepad for (that will almost always be the user account you have signed in with). With that user account selected, toggle on the "Deny" checkboxes for the "Full Control" and "Read" permissions (the "Allow" checkbox items are read-only and cannot be changed; setting those items to "Deny" will serve to disable them).

With "Deny" toggled on, click "Apply".

A security dialog will appear, warning that you are going to deny a permissions entry (yes, that is exactly what we are wanting to do). Click the "Yes" button on that warning dialog to apply your change, then click "Ok" on the "Permissions for Notepad" dialog to close that box.

You're done. You can now close your registry editor and go about your business, with Notepad now clearing its find preferences after every session.

What a pain.

Microsoft, please don't mess with Notepad. If I want a text editor with text editor functionality, I'll use one. Windows 10 Notepad is a notepad for quick scratch notes and text reference, please keep it that way.

To Main Page
Back To Top
To Blog Archive