Republicans Don’t Understand Democrats—And Democrats Don’t Understand Republicans

should this surprise anyone? No, but maybe it will help us realize our own weaknesses. Neither conservatives or liberals are trying to destroy this country. It’s all a ruse to keep us apart.

A new study shows Americans have little understanding of their political adversaries—and education doesn’t help.

Source: Republicans Don’t Understand Democrats—And Democrats Don’t Understand Republicans

Choosing the Wrong Lane in the Race to 5G

The US seems to be making all the wrong choices when it comes to 5G networking, for all the wrong reasons. Also, I’m one of those who thinks it will be YEARS before you and I have useful 5G phones or anything else.

All you have to do is look at AT&T, who did the exact same thing with 5G as they did with 4G – lie to their customers and try to fool them into thinking they already have the new technology, when they don’t. It’s cheaper to lie than it is to roll out all that new technology all across this great nation. MUCH cheaper.

I worked in the Cell Phone industry for 10 years, and one thing I learned, is the companies are dependent upon the radio frequencies they are assigned. The first generation cell phones use relatively low frequencies, which carry less data, but travel further, and penetrate walls and buildings much better.

Your ancient analog cell phone, or even the 2G digital phones, would work fine inside shopping malls, or high rise buildings, whereas your 4G or 5G phone most likely would not, without assistance. Now the US wants to use extremely HIGH frequencies, which other nations around the globe aren’t. The higher the freqency, the shorter the maximum distance it can travel (at the same wattage signal), and the worse it can penetrate walls and buildings. 60 GHz signals won’t even pass through a glass door, much less work in your living room. Unless you install 60 GHz 5G transceivers in every room in your house, that is. This is not the promise the carriers are making to us, is it?

Opinion: The US should be focusing on building 5G networks with mid-band spectrum, because it will support faster, cheaper, and more ubiquitous deployment.

Source: Choosing the Wrong Lane in the Race to 5G | WIRED


Tonight I started delving into something I’ve long wanted to – Asterisk, and other Voice-over-IP SIP protocol services. I never did learn any actual telephony protocol knowledge in my 10 years at a phone company, mostly because I was busy enough dealing with IP WAN, GPRS/EDGE, and application protocols needed to do my job. I was on the WAN team, not the telephony side of the business.

VOIP servers like Asterisk are powerful, loaded with tons of features, to the point where you almost don’t know where to start. There are quite a few online guides to getting started, but I haven’t located the one I need yet. I installed FreePBX in a VM to play with it, but there are so many features and options to setup correctly to lock down my server so others can’t abuse it.

My goal is to setup a text/voice/video communications service that my friends and family can use to talk to each other in a more secure environment than the regular telephony network, Facebook Messager, WhatsApp, or anything else. Asterisk can let your SIP clients setup peer-to-peer communications connections, so there is no intermediary system between the two clients. The metadata of who called whom, is still visible to the SIP server, but none of the content passes through any third system capable of monitoring it.

I did setup a Matrix homeserver of my own already, and it wasn’t too hard to do. There are free Windows, Android, IOS, Mac, and Linux clients for Matrix, and it works quite well. The only real problem is the user unfriendly process of verifying encryption keys. The Riot client forces each user to manually verify the keys from every single device you talk to. If I have an iPhone, Mac, and Linux laptop, you need to verify my keys three times. Of course, this is much more secure than something easy to use, like WhatsApp. WhatsApp automatically accepts peer encryption keys without question, which simply enables man-in-the-middle attacks. It does have an option to notify the user when someone else’s keys change, but it defaults to off. Even turning it on only produces a slightly red notification as soon as the chat starts. Most uneducated users would probably just ignore it, and chat away, revealing all their communications to whatever man-in-the-middle may intercept your communications.

I agree, whatsapp never would have become as popular as it has, had they not made thie tradeoff, preferring easy-of-use over strict security rules. Riot has made the exact opposite choice, preferring security over easy of use. I would think the whole thing would be adopted much more widely if they made that choice configurable, on a user-by-user basis. When you install the client, or maybe when you setup your account, ask the user which option they prefer – maximum security, or maximum easy to use. The paranoid of us will not be able to chat with our peers when they get a new phone, until we verify their encryption keys, and my Grandma can chat with her grandkids without even thinking about Encryption.

Tonight, I found the GNU Jami project, which is a free, open-source SIP client available for Windows, MacOS, Linux, Android, and IOS. You can chat with other Jami clients in a peer-to-peer, end-to-end encrypted session, but by default, the call setup depends on some public servers to setup those calls, so all of your communications metadata will still be given away to somebody else. Jami is a full SIP client, so i decided to try setting up a SIP server on my home server. If I can get Jami to use my own systems, instead of the shared Jami servers, to let my clients talk to each other, that will fit my bill.

SIP servers are quite powerful, and software like Asterisk supports all the options I desire. The downside is SIP and Asterisk are full of features and options, and not easy for a newbie to lock down. It’s about time I learned more about SIP. It could provide additional skills I could use to extend my IT career, since I don’t want to retire anytime in the near term.

When to choose an LXD Container vs native Linux server install

There is a general trend in IT technology these days to solve every problems using docker containers running under Kubernetes. I am using a different kind of container technology called LXD. It was created by Canonical, the Ubuntu people. LXD is really just LXC version 2.

LXC Version 1 is the original Linux Containers technology, and it works, and is great and all that, but think of LXD as an enhanced LXC with the best parts of using Docker, like image repositories. LXD Containers appear to work as if they were virtual machines, but they benefit from being native processes on the host Linux kernel. Zero hypervisor overhead. A few key system resources were virtuallised, so now every container gets it’s own little access window into the shared host’s Linux Kernel.

My home server currently runs a bunch of services, a few for internal use only, some in LXD containers, others native. The list includes:


Not very long in the past, I would have wanted to isolate each service in it’s own LXD container, and use IP:port numbers to connect them together. But that just ended up creating lots of containers, and lengthy and sometimes tricky software upgrades. It also complicates backups. For awhile I tried going old school, with everything running native. But now, I’ve ended up with a mix of both native and LXD.

LXD containers also make good test environments. You can install any version of any package you need to try out, and if it turns out you don’t need it, no problem. You’re just going to start over in a new LXD container with the same in in 10 seconds. You should be building a recipe to re-build a appserver image from base image on up anyway. That’s your DR plan, to be able to rebuild it, restore data and config files from network backups, and be back up in business in an hour.

LXD containers are mostly more like “pets”, and less like “cattle”. You name them, you try to fix them when they’re broken, and you make an effort to keep them alive. The modern devops way requires you simply kill off any ill functioning container, and re-launch the image it’s based on. It’s your upgrade policy, your DR policy, your reboot policy.

Wireguard just needs a basic web GUI admin tool

The Ubuntu system administrator who installs Wireguard can configure it using just the “wg” command interface, so editing a config file, and stopping and restarting Wireguard services is totally unnecessary. But you should backup your config to a wg*.conf file anyway, so it survives reboots and system crashes.

Any Wireguard web GUI should be simple enough to prompt the inexperienced admin through configuring the server’s Wireguard interface(s), including setting up the three most basic configurations – small VPN server, basic VPN client, and custom. If you offer a VPN service, there may need to exist a way for regular users to request access to the VPN accounts, maybe captcha and email verified? Admins can create/list/delete user accounts as they desire.

I will probably use Python, of course, but I need to figure out a safe way to authorize the web user to execute the wg binary command, to prevent abuse. Documentation will be key.

The interesting part will be the part where you sign up new users, verifying their identity, securely creating a new PKI key pair, and generate a recommended client config file to access that VPN. I want a pleasant balance between simple-to-use-for-newbies, and non-hostile-to-experienced-admins, if you know what I mean. There has to be a middle ground. I’ve generally found them to be resolved by creating command and API interfaces. If you present a standard interface to everyone, others can benefit from or extend your backend work, while enhancing and replacing your stupid web GUI.

Routing nothing is trivial. You add no local static routes. The only things you can do is access the vpn server.

Routing everything is easy. First, you add a single /32 route for the VPN gateway’s public IP, pointing towards your default route gateway, and then you add two and routes to usurp the default route, both pointing toward the other end of the VPN.

Basic CIDR routing rules mean the longest route that matches this destination IP wins. Routes only count the total number of 1’s in the route’s subnet mask, so a /24 route is longer than a /0 or a /1, and wins, and a /1 wins over a /0). The default route always has 0 bits in it’s subnet mask, so it’s always the route of last choice. Most clients only have /32 route for their interface, a /24 route for their local LAN, and a /0 default route for everything else.

Wireguard VPN clients add an additional network interface, wg0 usually, and then add routes pointing towards whatever is on the other end of the VPN connection. When you’re a normal client, you want everything to go over the VPN. When you’re connecting to a small work, or satelite office, you might only want to route a few specific subnets down each tunnel. Corporate users might use multiple tunnels, to reach remote data centers via remote jump boxes.

I can easily see turning this into a whole “community in a box” type product, with Matrix/Synapse/Riot for all chat/voice/video communications, Dovecot/Postfix/Mailman for all email communications, Nginx/FastCGI/bbPress for all website/forum services, and Wireguard for all VPN services. The web GUI really needs to start out being totally small community centric, while at the same time, remaining open and compatible with network federation. Let the communities themselves decide which features they want to enable, and which network(s) they want to interconnect with. Let the documentation guide the advanced through creating their own federated Matrix network, independent from anyone else.

Of course any paranoid or deviant community could take advantage of this simple technology, and use it as a tool to keep their communications private, while they plot their dastardly plans. But you have to agree there are a whole lot of solutions that achieve the same thing. I really see no problem with terrorism as a threat to this platform. That *is* the entire point to privacy, so everyone has the ability to keep their one-to-one communications private from everyone else.

After all, when any government bans any variety of VPN software, it won’t prevent it from being created and sold to the 2% who might use it for unlawful gain, it only stops the other 98% from taking advantage of it to protect themselves.

More on Wireguard

I’ve been playing with Wireguard configurations, and am actually impressed at how powerful it us. This single open source product could resolve all the multi-datacenter routing issues we have where I work. It is very powerful, but not yet ready for prime time, if you ask me. I have no doubt some group, either open-source or commercial, will soon create a more powerful configuration management service that will allow us to utilize this speed+power in general.