Tuesday, March 13, 2018

Living in Puget Sound over the last decade, I've noticed tagging and graffiti with LABRAT or LABRAT KNATS across bridges downtown, by Lacey (picture below, the site of the recent train derailment) and down to Olympia, Washington (State).

To be clear, this graffiti is not mine, or is it associated with me. Just in case there was any question... (ha ha, lol)

So...I was running my own SSL cert from a free SSL certificate provider SSLForFree.com but thought I'd try the built in capability of my Synology DS413J to provision one from Let's Encrypt for free.

I walked through the menus to find the Control Panel, Security, and Certificates tab. Once I walked through adding/replacing a cert, I receive this error:

For clarity, this is what it says:
Get a Certificate from Let's Encrypt

Failed to connect to Let's Encrypt. Please make sure your DiskStation and router have port 80
open to Let's Encrypt domain validation from the Internet. All the other communications with
Let's Encrypt go over HTTPS to keep your DiskStation secure.

I originally was thinking my router, an Asus AC68U, wasn't capable of forwarding port 80 because it uses that port for the web interface. Turns out that later software updates fixed this issue and is now able to pass the traffic from outside:80->Synology:80. All good.

I made sure Web Station was running. And it still failed.

Turns out, I think the biggest issue was that even though the screen suggests you should just use your top TLD, you really need to put in your full FQDN in both the domain name and the alternative subject name fields.

Friday, November 25, 2016

I'm a ham radio operator and have been since 1987, when I got my Novice ticket in rural South Dakota (SD) at 14 years old. It's been a fun hobby, even though I took a break from roughly 1993-2013. So...to the point...

I went to the Mike and Key Ham Fest down in Puyallup, WA in the spring of 2015. Before I showed up there, I had been thinking about a GMRS license and radios for the family. I picked up a Kenwood TKR-820 repeater, already programmed to the GMRS repeater frequencies.

Kenwood TK-790/890 control head options, basic and advanced.

I also picked up 4 Kenwood TK-890 radios. I got a "good deal". They didn't come with microphones, but I didn't see that as a big deal...while I was at the ham fest. Once I got home, I found out differently. This particular breed of radio, as a result of the genius of Kenwood, doesn't have a standard microphone plug. As a result, microphones cost $65+ each. And the aftermarket doesn't make them. Stupid. I found a lot of 7 on eBay, for a reasonable price, so now I'm in action.

Anyway, this is a repost of an article I found on a blogspot post about how to tune the TK-890 to the high end of the 70cm ham bands. That article has since disappeared and the blogspot site is no longer in existence...so, I'm reposting the content here. (Thankfully, PDF'ed the article!)

Original article:
(from Wirelessness blog from W6DTW, originally at http://sparqi.blogspot.com/2013/05/tk-890-amateur-radio-mod.html)

Over the past weekend a friend of mine asked if I would help him convert his Kenwood TK-890 mobile to work on the ham bands. I wasn't sure how successful we'd be, since most every online search came up with at best little information or at worst flat out statement saying "Nope, can't be done." As it turns out, it can't be done. Kudos to Time K for his notes posted to Radio Reference [cg, I also placed the relevant content at the end] which gave enough hints to make this happen.

In general this is how it went. My friend wanted his radio to work on the Bay-Net repeater system, which operates 443.225 with a +5 MHz TX split. TX was fine, but RX was giving a steady "beep-beep-beep..." which indicates PLL unlock.

In the PLL section, under the copper foil, [cg, for the record, mine weren't) are three adjustment pots: A = TC302, B = TC303, and C = TC301. (Don't ask why they're out of order.) According to the Service Manual, Pot A sets the PLL for the low end of the receiver range, Pot B set the high end of the receiver range, and Pot C sets the TX PLL. The goal is to monitor testpoint CV with a voltmeter and adjust for minimum voltage during RX and TX. This requires reprogramming the radio's test frequencies to match the band of interest, so you'll need the [KPG-44] software and [KPG-4] cable.

Once we had the PLL voltages minimized for RX and TX, I found that the radio's TX frequency was way off, so a frequency alignment was needed. This again required the [KPG-44] software - for some reason we couldn't get the radio in to Panel Test/Tune via the control head. It was easy enough with the KPG, once we realized you need to press "Enter" to lock the modified value.

Other things like adjusting the BPF and checking deviations should be done. In the end, the conversation was very easy and the radio is working well on the UHF amateur band.

[cg Adding this here, to make it more complete, and have information all in one place.]From Radio Reference:
From ramal121:
"The VCO can be adjusted fairly easy with a volt meter. You just program your highest and lowest frequencies, monitor the VCO steering line voltage, check high and low (both TX and RX) and see if the voltage stays within specs. There are tweekers for both TX and RX to achieve this. And yes, if you lower your VCO's range, you will lose the top freqs, the VCO can only swing so far."

Thursday, November 3, 2016

HP, in their wisdom, decided that a standard laptop BIOS update should sound like you're bricking your device. So, I'm posting this here so it will get picked up by Google and people don't need to freak out as much as I did. My experience was I ran the BIOS update, the machine started beeping with the screen blank and then I panicked, trying to figure out what I should do. After a bit of work, I found out that this is completely normal for these laptops, for this BIOS update. It is not normal in the world of systems BIOS updates, by any means.

Tuesday, June 14, 2016

I have a Shuttle XPC Glamor Series SN68SG2 that I've had for years. I originally built it in 2008 as a Windows Home Server box.

As time has gone on, I turned into a workstation for mundane tasks, such as running the weather station interface software, or USB-to-Serial cables for programming the scanner, ham and GMRS radios.This went from Windows Home Server to Windows 7 to Windows 10 with the free upgrade. Since the upgrade to Windows 10, I've had issues with the Start Menu and Cortana. I tried a number of fixes, but nothing really worked. I even went so far as reloading the system with a fresh copy of Windows 10.I had just been resigned to getting the weather station software fired up and running and then not interacting with it until I needed to restart the software and computer.
Turns out I think it's been a video driver related problem all along. I installed an older, alternative video card and the start menu is magically working again. I used an ATI Radeon X1300/X1550 PCIe video card that had two SVGA cables when it was on Windows 7 and it worked well. This video card doesn't have any valid or supported Windows 10 drivers...but since Windows 10 knows that, it kicked the video driver back to the generic, lower resolution driver.

Start menu works like a champ so far and its been a couple days, which is a couple days longer than it had been working before.

Given all that, I'll be on the hunt for a cheap and/or free low profile PCIe video card for this machine.

Monday, March 7, 2016

Grant's Rants:

My initial reaction to the original story of how a reporter was hacked mid-flight through an airline's GoGo wireless network was that reporters, by nature, tend to use less secure, consumer-focused systems. With this update, we understand with clarity that he is operating as an independent reporter. This wasn't a reporter for security issues, so this was just a reporter, even if he has a description like: USA TODAY columnist Steven Petrow offers advice about living in the Digital Age."

In the end, we can interpret this story as being one that was ripe for happening, and was trumpeted by an opportunistic reporter. We now know that he wasn’t focused on maintaining his own equipment or being concerned about information security issues until he was compromised, and then he made some money off of it by writing articles about his experience that are being shared widely.

Let's look at the situation:

He was using an older, deprecated email connection method (POP3). He set it up in 2002 and apparently hasn’t touched it since. Therefore, his email traffic could be picked up “in the air” and was entirely unencrypted.

He wasn’t using a VPN for his insecure email protocol. Again, his email traffic could be seen.

He was using unencrypted (public) WiFi. Frankly, any Public WiFi is as secure as any unencrypted WiFi network, home or otherwise. If the network connections aren’t encrypted, then others who are within listening range can see any app traffic that isn’t encrypted…like unencrypted POP3 to pull email.

He wasn't under the corporate umbrella of systems management and secure configurations, so he was left to his own devices (no pun intended). Petrow asked the security expert “'What else do I need to do?' He explained [the reporter] needed to regularly download software updates…” was shocking to read. Frankly, I was surprised it took this long for this reporter to be compromised.

After writing this, there is blame to be spread around, though:

ISPs and email providers should only provide encrypted methods for accessing email. Why was unencrypted POP3 still allowed? I know the answer, because they didn't want to have additional support requests from their users.

OS vendors should do more to educate and encourage automatic updating for OSes. Microsoft does a good job, on the initial install, and through occasional reminders.

App vendors should be encrypting network connections by default, not by exception or an opt-in process.

App vendors should be building in automatic updates and/or warnings about lack of upgrades. This is a win-win driving more business and securing the consumer. Apple App Store, Chrome and Firefox Automatic Updates were designed for the consumer with no ability to engage in this overhead. Turn it on and forget it. Never look back. Kudos to them. It is for self preservation, and other selfish reasons, typically, but it is moving the needle for consumers and consumer protection.

At this point, consumer VPN services are used widely for a) the paranoid, b) high school students trying to get around school content filters. Maybe it's time for Consumer VPN services to take off.

This type of article in USA Today gives continued exposure and awareness to these basic issues to those people in hotels across the country, so that's good, but updating systems should be table stakes for anyone under 50, especially if you offer "advice about living in the Digital Age." He wasn't paying attention, was compromised and suffered embarrassment. Fortunately, this guy got a second chance to improve his security posture and get paid for his work instead of more serious consequences for his inaction.

Wednesday, September 24, 2014

As I mentioned previously, I had switched my Synology box to have a real, live SSL cert from a trusted CA, StartSSL. That worked great for connecting via SSL to either the web console, or Chrome extension for Download Station. All worked swimmingly, until I discovered my OpenVPN connection wasn't functioning any longer. PPTP worked fine, but OpenVPN had issues. Turns out the Synology box, the OpenVPN server, and therefore, the OpenVPN client connection package, don't understand the StartSSL CA. Here was my process of discovery and resolution for this issue.

I tried re-exporting the config, changing the hostname to the new Internet-facing hostname. That didn't work. I re-exported the .crt files from the server and included them in the .tblk file to import into TunnelBlick. That didn't work.

Then I decided to go look at the client connection logs, which is where I should have started. Here's what they said:

Researching this error, I found the following reference on the Synology forums:

Here's how I fixed this problem:

Get the StartSSL root CA cert (ca.pem) and the StartSSL Class1 cert (sub.class1.server.ca.pem) from StartSSL's web site

Concatenate the StartSSL root CA with the StartSSL Class1 cert and save it as a new file. You can use cat in *nix to do this or notepad in Windows, or TextEdit in OS X. Order doesn't matter. It will look something like this, except much longer:

In Control Panel > Security > Certificate, you may see that your StartSSL cert is already installed, which was the case in my situation. If this is true, export your certificates, so you have a known good copy of your server.crt and server.key. This will be needed on the next step.

Import your server.key, server.crt and the new ca.crt (or whatever you called it) file generated above as the intermediate certificate.