Hints for when I configure OpenVPN and Tunnelblick the next time

I've gone through the process of configuring OpenVPN and Tunnelblick at least twice before and I never seem to get it right on the first or second try. This time I'll document a few of the paint points that I experienced even while following the excellent Digital Ocean guide to configuring OpenVPN on CentOS 6.

  1. Follow the "Initial OpenVPN Configuration" section from the DO document.
  2. When generating keys and certificates in the next section, the easy-rsa files are in /usr/share/easy-rsa/, not /usr/share/openvpn/easy-rsa/
  3. Be descriptive when running ./build-key client with something like ./build-key jeremy-home so that you don't get annoyed later that you have a config named "client".
  4. The DO docs don't mention configuring a TLS-Auth key, even though the OpenVPN configuration now has it by default. Do this with openvpn --genkey --secret /etc/openvpn/ta.key before attempting to start the openvpn service.
  5. You'll need a few more lines in client.ovpn to match the server config. These worked last time, but look at the OpenVPN logs when you try to connect for other errors.
    • tls-auth ta.key 1 (the server uses this with 0) to enable TLS-Auth.
    • cipher AES-256-CBC to fix 'cipher' is used inconsistently errors.
    • keysize 256 to fix 'keysize' is used inconsistently errors.
    • tun-mtu 1500 to set the MTU, though I'm not sure this is really necessary.
    • Remove comp-lzo from the client if it's configured. This appears to cause an IP packet with unknown IP version=15 seen error.
  6. Be sure to copy the contents of ta.key into a new <tls-auth> section at the end of client.ovpn so that the client has the same static TLS-Auth key as the server.

Throughout all this, remember that after you drag and drop a configuration file into Tunnelblick, it gets put somewhere else and needs to be manually reloaded every time you make a configuration change to the client.ovpn file you might be working with.

Things are now working with OpenVPN 2.4.4, easy-rsa 2.2.2, and Tunnelblick 3.7.4a.

What’s the right USB-C to HDMI adapter for a Dell XPS 13″ 9350 running Ubuntu 16.10

 

When I first got my Dell XPS 13″ 9350 (Developer Edition), I needed an adapter so that I could power an HDMI display via the laptop’s USB-C port.

After poking around for a few minutes, it seemed like the DA200 USB-C to HDMI/VGA/Ethernet/USB 3.0 adapter was the right choice. It works with plenty of Dell XPS laptops and says things like “USB-C to HDMI” in the name of the adapter.

I was wrong!

I have no idea why I was wrong, but thanks to the answer on this Ask Ubuntu post, I learned that the DA200 is not exactly what it claims to be. The only way this adapter actually works with a 55″ TV or similar is at 800×600 resolution. Definitely not what you expect when connecting HDMI.

After reading that post, I purchased the Apple USB-C Digital AV Multiport Adapter. It has only a 2 star rating on the Apple site, but it worked immediately and powered the 55″ TV as expected over HDMI at 1920×1080.

Hopefully this post helps make it more obvious via Google that the DA200 is the wrong adapter and the Apple USB-C Digitial AV Multiport Adapter works great!

Things I learned (or broke) while trying to fix my wireless in Ubuntu 16.10

I’ve had a series of strange issues with my Dell XPS 13 9350 DE under Ubuntu 14.04, 16.04, and now 16.10. Bouncing around between versions has helped some things, but this strange wireless issue seems to have followed me around.

Everything works just fine for X amount of time and then the wireless will just drop.  In my /var/log/kern.log file (or via dmesg), I’ll see something like this:

wlp58s0: disconnect from AP 58:6d:8f:99:8b:f4 for new auth to 58:6d:8f:99:8b:f5

Just in case I missed it, that message will generously repeat every 2 minutes or so. Sometimes nothing noticeable happens, other times my connection will break and I’ll have to restart the network manager service.

I spent some time today digging into the issue. I’m not sure that I actually fixed anything, but I at least learned a few commands and want to save links to a few helpful sites.

FWIW, my laptop has an Intel 8260 rev 3a wireless adapter, but these commands should help in general troubleshooting as well.

sudo lshw -C network

lshw is “a small tool to extract detailed information on the hardware configuration of the machine.”

This gave me some cool information like the product, vendor, and firmware version of the wireless adapter. The firmware version listed when I started was 21.302800.0, which didn’t make any sense when compared to the list of iwlwifi drivers maintained on kernel.org.

sudo iwlist scan

iwlist, combined with “scan”, provides  a list of in range access points. I didn’t really use this much this time, but it does help show what wireless frequencies other nearby APs are using.

uname -r -m

uname prints system information. This isn’t entirely useful for troubleshooting wireless issues, but is an easy way to get your kernel information. I didn’t know this command until recently, so I’m putting it here. See also: uname -a.

dmesg | grep iwl

dmesg displays “all messages from the kernel ring buffer”. There’s a term.

This is probably the most useful command. It showed me what firmware linux was trying to load for the wireless adapter, what failed, and what succeeded.

[ 8.687719] iwlwifi 0000:3a:00.0: Direct firmware load for iwlwifi-8000C-22.ucode failed with error -2
[ 8.690891] iwlwifi 0000:3a:00.0: loaded firmware version 21.302800.0 op_mode iwlmvm

There was a lot more than that, but I was able to see that it was attempting to load 3 wrong versions of the firmware and then successfully loading a very wrong version of the firmware.

modprobe -r iwlwifi; modprobe iwlwifi

I removed the “wrong” versions of the firmware from /lib/firmware/ and ran the modprobe commands to first remove the loaded module and then re-add it again. I confirmed through dmesg that the “correct” firmware version was loaded.

The worst part about all of this is that it’s still happening. So I guess it may not be a firmware issue, but some kind of hardware thing. The list of “platform noise” issue on the kernel.org iwlwifi page is probably where I’m going to focus next. I changed the channel on my router once, but I may be able to dig deeper on that.

Update (an hour later): Things seem to be more stable after finding a more open 2.4Ghz channel. I also found what seems to be a maintained list of core releases for the iwlwifi drivers. That led me to what should be the latest mainline version of the 8260 driver that I need. After making iwlwifi-8000C-22.code available and running modprobe, the correct driver (22) was picked up and installed.

Update (Jan 8, 2017): The problem is definitely back, even with all of the fixes above. I’m starting to wonder if it’s partially the fault of my router as I’m always able to get to the router admin interface, just not over anything that requires DNS. Today I disabled IPv6 on the wireless adapter and set a static IP address with static DNS. We’ll see how that holds up!

Update (Jan 8, 2017): Disabling IPv6 didn’t matter at all. I did find a new piece of the puzzle though. Ubuntu’s Network Manager uses dnsmasq by default. I disabled the configuration for this and now when my wireless drops and reconnects, DNS will at least continue working. Some other network stuff is still having trouble, but I don’t have to completely restart the network services right now.

Here are some links that I found useful for learning how to troubleshoot this all: