Well, that wasn’t the greatest day…

It wasn’t the worst either but it felt like the worst in the moment. A couple of days ago I had some weird stomach bug. I might have been food poisoning. I’d like to get a bunch of coding done for Traveller so I can run my next session. I could get sidetracked and talk about how I a got lucky enough to add two new players but I won’t. I drove from Connecticut to Boston yesterday so I didn’t plan to code much. My stomach’s also only about eighty percent. I recently needed ansible because I deleted my gitlab server by accident. And it came to the front of my mind that my ansible code, which is riddled with fact references coded: ansible_distribution|lower in ('freebsd', 'openbsd', ) won’t work in the near future. So I grabbed my favorite hammer, sed, from my unix toolbag and had at this nail. After about an hour and a half I hada git commit where every old reference to ansible_distribution and all of their ilk, ansible_os_system was rewritten in modern form: ansible_facts.distribution. That brought me to the first hassle of the day.

What’s up with ssh today?

The newly minted ansible wanted some testing. I put it on it’s own branch and checked out that branch on my laptop. This issue really effects MacOS where I tend to be more bleeding edge with ansible than my FreeBSD boxes. From my laptop I could connect to my target boxes via ssh without issue but not when ansible started the ssh session. At the end of the day, this turned out to be something in my daily ssh client config saying to prefer IPv4 connections over IPv6 while the default and ansible prefers IPv6. As it turns out I can probably be a bit more permissive about who can use ssh over IPv6 to administer a machine but since too tight is better than not tight enough in security, I left things as is and configured ansible to use IPv4.

What’s the right way to install Magit again?

I use Magit on emacs with git. My love for this product grows as I use it. Like any wrapper around another product, it has it’s warts. Sometime after git v2.40.x the way that refs are stored changes and that threw magit for a loop. So, I figured, updated magit but no update was available. Emacs needed an update to and that’s pretty simple so, I updated emacs and then saw the same problems in magit. Then I updated magit and things went totally south. I learned that the latest version of magit is not in ELPA, it’s in MELPA so I had to configure emacs package repositories. Pulling magit from MELPA fixed those issues.

When did MacOS grow the ability to block local networks?

With two problems down, I took a break. Just before turning in for some sleep, I figures I’d hammer out a couple more tests. To my chagrin I rapidly discovered that from an emacs shell window, I couldn’t ssh to, or ping, any assets on the local lan. This was a big POLA moment for me. It looks like somewhere in the past, MacOS learned to block individual applications from accessing the local network and when I upgraded Emacs, I locked it out from local network access. Thankfully, that was simple to solve.

After a good nights sleep

As I write this, I’m back in the fracas. WordPress has been giving me trouble with stylesheets for quite some time. I think that people play fast and loose with the templating system and that breaks stuff. I won’t argue this because I’m the kind of guy that understands Postel’s Law, but that doesn’t mean that I can’t hate the law’s implications. Luckily, this morning a found a setting that reliably gets my admin stylesheet’s working again. I’ll take one for the good guys.

OpenBSD on Raspberry Pi

 

I haven’t played with Raspberry Pi quite enough. I’ll do a write up on my garage door opener project at another time. But a really promising place for the Pi in my opinion is the role of a traveling router/access point. I don’t find the process of connecting to the WiFi in a hotel room particularly hard. It’s connecting back into my own network to access my my services that is difficult. The methods that I have at my disposal are:

  • IPSec VPN
  • SSH/SCP to selected service
  • Direct access where things are configured for it

Running OpenBSD on a Raspberry Pi gives me a solid place to put an IPSec connection for the whole hotel room network. Getting there involves installing OpenBSD on the Pi in the first place

Ingredients:

  • A Raspberry Pi 3B or 3B+ each model has plusses and minusses
  • An OpenBSD Raspberry pi snapshot release available at this url.
  • OpenBSD does not support the Pi video yet. The install console is serial. You need an Arduino/Raspberry Pi serial cable. The link points to a 4pin style. It connects as follows:
    1. Black <-> Pi GND
    2. White <-> Pi TX0
    3. Green <-> Pi RX0
  • A fast USB stick. OpenBSD can’t run from MicroSD card yet. This one works.
  • A WiFi adapter that you can live with this is going to be a compromise because WiFi has somewhat left the BSDs behind. These two CanaKit Wifi, and  TP-Link WiFi, work.

Continue reading “OpenBSD on Raspberry Pi”

Of IPv6, and unhappy eyeballs

I’m a dinosaur. I still bring a little Soekris Net5501 configured as a NAT gateway with IPsec back home when on vacation. This solution works best in hotels that still offer Wired internet. I do this because:

  • Majorly, In many cases a hotel’s WiFi is a great example of the worst case engineering solution with wifi tuned just well enough that web browsing doesn’t suck but nothing else is considered.
  • Minorly, Hotel’s in the United States will probably be the last places on Earth to get IPv6.

The other advantages should be obvious. By bringing a router I can control or at least police my DNS.

My Soekris is tiny. It takes up about as much space as three tee shirts in my packed bag including an Ancient Apple Airport Express that can be tuned to run on 5GHz only. Off hand I want to mention that configuring 5GHz WiFi in each hotel room might bring the best improvement to WiFi overall but hoteliers can’t do this because lots of people have old devices that don’t do 5GHz or don’t do it well. No one wants to be the guy trying to explain to a customer that the problem isn’t the WiFi, it’s the customer’s 2007 vintage MacBook Pro that can’t use channel 149.

So, note my surprise when I find that things aren’t working better on my custom wifi, homed to the edge router over ethernet, during my latest hotel stay. What happened? I think this…

My router connects the internet and establishes a tuned IPSec tunnel back home. Once that works, it advertises IPv6 addresses from my /48 which route back to my house and then out to the internet. If the latency for all of that is 10ms no one would notice the difference. If it goes greater than 30ms things start getting funky. We’ve crossed into a time where if you have a dual stack machine, one with both IPv4 and IPv6, you’ll try to use IPv6 for outbound work first and revert to IPv4 only when v6 has too much latency. Well, folks, when you have just enough latency, this doesn’t look pretty.

No solution yet and possibly not ever. The problem with latency issues like this is that you can’t easily fix them. That’s why tuning latency out is so important. I’ll post more when I know more.