Errate das gesuchte Jahr mit Hilfe von 4 historischen Ereignissen. Ein von Wordle und Geschichte inspiriertes Spiel.

Errate mithilfe von 4 historischen Ereignissen das gesuchte Jahr. Ein von Wordle und Geschichten aus der Geschichte inspiriertes Spiel.

Years ago when I was still at Google I used Comcast Business as my ISP. They have IPv6 support (at least at 2016-ish), and everything just works with Google Wifi system. Later, a small local ISP, Sail, became available at my area, so I switched over. They are almost better than Comcast at everything (just being “not Comcast” is already good enough for me), except one thing: they don’t support IPv6. Or at least, they don’t support IPv6 _officially_. Things don’t work automatically in either Google/Nest Wifi system nor Unifi. When I talk to their tech support, they confirm that they don’t support IPv6 and don’t have a timeline for IPv6 support. But occasionally I plug my laptop to the RJ45 cable directly (bypass the router) to debug some issues, I always get an IPv6 address on my laptop that works. Which seem to suggest that they do have IPv6 support _to some level_ , just not ready to “officially support it” for customers yet. So this long weekend I tried to get it working on my Unifi system, and succeeded. ## The setup that worked in the end Note that this is just to document how I got it to work on this particular ISP (Sail). This is pretty much a YMMV situation and different ISPs would likely require different settings. If your ISP supports IPv6 officially, you should ask them for the configurations instead of following my notes here. 🙂 First, in Unifi’s WAN (`Internet`) settings: * Change `Advanced` from `Auto` to `Manual` * Change `IPv6 Connection` from `Disabled` to `SLAAC` * Make sure `IPv6 Type` is `Single Network` * Make sure `Network` below is `Default` (I do wonder if there’s a way to also enable IPv6 for the guest network, though) After that, I can see that there’s an IPv6 address showing up with the IPv4 address on my ISP, and LAN (`Networks`) automatically configured the IPv6 part for the `Default` network. My local devices start to get an IPv6 IP with the same prefix as the IPv6 address I got on my WAN, and egress routing seem to work (`traceroute6 ipv6.google.com` works, `curl -6 https://ifconfig.me` shows the IPv6 address on that device, etc.). But ingress routing doesn’t seem to work. When I traceroute6 to a device’s IPv6 address from outside (a server with IPv6 address I have access to), it ends at the router. It turned out (that’s to Ed) that’s because the default firewall rules on Unifi blocks all traffic originated from external to internal. It makes some sense for IPv4 (does it though? for IPv4 the “internal” zone is all behind NAT so not routable anyways?), but it does not make much sense when you want to run servers on IPv6 in the internal zone. So, I needed a second step, to add a firewall rule, to allow traffic from external zone to internal zone on IPv6. After that, everything works. ## Other setups I tried that didn’t work Before that, I also tried: * WAN setting as SLAAC with Prefix Delegation, with guessed PD size of 64: this gets the IPv6 address on the router from the ISP, local devices can get IPv6 addresses, but IPv6 doesn’t seem to be routable. * I also tried to change LAN setting to use prefix delegation on IPv6. That changed local devices to get a local IPv6 instead, but still unroutable. * From some unifi forum discussion someone suggest to change LAN setting to use static IPv6 as the one you get on WAN from ISP with netmask, that returned my local devices to public IPv6 addresses with the same prefix, but still unroutable. * DHCPv6 on WAN won’t get IPv6 address at all.

Just finished my Alaska Milkrun trip. The flights I took are: The milkrun stops With an overnight stop at Juneau (JNU), as Alaska Airlines no longer sells the whole milk run as a single flight, it’s on either side of Juneau now (the other side is direct between Juneau and Seattle or Anchorage). And also you are not allowed to buy the whole flight between Seattle (SEA) and Anchorage (ANC) anyways. This was the 737-700 plane for the first half (SEA-KTN-SIT-JNU) at Seattle airport. Unfortunately I didn’t get the angle for the tail number: The 737-700 for SEA-KTN-SIT-JNU half Currently all Alaska milkrun flights are operated by 737-700, and Alaska Airlines kept those 737-700s only for milkruns and other small hops inside the state of Alaska (otherwise it’s only -800s, -900s, and MAXes). They used to use 737-400 combi for milkruns, which is a special configuration that’s half cargo and half passengers. This was near the US-Canada border before arriving at the first stop, Ketchikan. The border is that “thin” river at the top left of the photo: The US-Canada border near KTN This is a glacier at Baranof Island, where the 2nd stop, Sitka, is at. The name of the islands around Sitka sound very Russian, a reminiscence/reminder that the state of Alaska was purchased from Russia: A glacier at Baranof Island After Sitka, I arrived at Juneau for the night. My original plan is to go to Tracy’s Crab Shack for dinner. I was really looking forward to it. I took my parents to Juneau in 2016 for the Glacier Bay National Park, and that’s the only meal my dad enjoyed. He’s not accustomed to western food, but he can always appreciate crab. But unfortunately the first half of my milkrun flight was delayed and when I arrived at Juneau it was already past 10pm and Tracy’s Crab Shack was already closed. The next morning, I went back to JNU for my second half of the milkrun. Juneau also has a lot of seaplanes parked there: A seaplane at JNU And while waiting for my flight arrive from Seattle, I also saw a few seplanes took off from the runway (not from water) there. Before my flight arrived, another milkrun flight arrived from Anchorage on the next gate: N611AS at JNU Then, my flight also arrived: N609AS at JNU For the majority part of the flight between Yakutat and Cordova, the scene is about the snow peaks above the clouds, from the mountains of Wrangell-St. Elias National Park (or Klaune National Park on the Canadian side, which from the look of it is the same mountains just on the other side of the imaginary line): Snow peaks above the clouds But there’s also a big glacier right before we arrive at Cordova: Glacier just before Cordova After Cordova, we arrived at the final destination of the milkrun, Anchorage. This is the view of ANC before we landed: ANC from above I also took my camera with me, but none of the photos I took from the window of the plane with it was actually good, so I ended up only used the photos of my phone instead (except the 2 photos at JNU). At Anchorage I drove my rental car to Potter Marsh to see some birds, and finally put my camera into use. I saw a goose mama with some chicks: A goose mama with some chicks And some beautiful magpies (or at least I think they are magpies, I’m not 100% sure though): A magpie at Potter Marsh The whole album is at Google Photos.

I had been using Google/Nest Wifi routers since the original OnHub days. Later upgraded to Google Wifi, then Nest Wifi Pro. While there are a lot of good things from those systems, there are also some really annoying things. The original OnHub had broken/non-existing NAT loopback implementation, which took them several months to finally fix. Then when Nest Wifi Pro is released NAT loopback is broken again for several months until they finally fixed it; With Nest Wifi Pro they also switched from the Google Wifi android app to Google Home app, which often gives you lies (a mesh point is down but the app says everything is fine), stale info, or every action takes several seconds to refresh. So, earlier this year, we finally had enough and decided to move to other wifi routers. I asked my colleagues for suggestions, and decided to buy into Ubiquity’s UniFi system. In particular, we bought a Dream Router 7 for the main router, and an Express 7 for meshing and providing wired connection to PS5 Pro, because PS5 Pro’s wifi chip is not great. Among several features it provided, one is to set up VPN clients on the router level and auto route traffic from the devices to the VPN client. This also comes with a challenge, because I run a Linux server at home (an Intel NUC box), with dynamic DNS client to run in an hourly cron job to make sure I have the domain pointing to the correct IP (as I don’t have static IP). The dynamic DNS client just gets the “correct” IP by getting its egress IP from the API, so if the request is routed via VPN, then it won’t be able to get the correct IP address to set. Of course I can set routing rules to make sure those requests don’t go through VPN. But domain based routing rules are brittle with DNS security used, and IP based routing rules are infeasible because that requires me to keep an up-to-date list of all the possible IPs the API endpoint can resolve to. So instead, I turned to another new feature provided by UniFi: their REST API can tell me what my external IP is. I just need to generate an API key from site manager, then this can be done via a simple `curl` + `jq` pipe: apikey="..." ip=$(curl --header "X-API-Key: ${apikey}" --header 'Accept: application/json' "https://api.ui.com/v1/hosts" | jq -r '.data.[0].reportedState.ip') And then I can feed `${ip}` to my dynamic DNS client to use. But things get complicated when you want to use that in cron jobs. In cron jobs, you don’t want to output anything to `stdout`/`stderr` when things are OK, as anything output will be treated as an error and send a mail to admin, and I don’t need hourly mails. In cron job you also want it to fail early if things go wrong, so you don’t set a wrong IP to your DNS. With all those in mind, the simple one line piping command needs to be expanded into something like: apikey="..." curlout=$(curl --silent --show-error --fail --header "X-API-Key: ${apikey}" --header 'Accept: application/json' "https://api.ui.com/v1/hosts" 2>&1) if [ $? -ne 0 ]; then echo "$curlout" exit 1 fi ip=$(echo "$curlout" | jq -r '.data.[0].reportedState.ip') At that point, it no longer makes sense to pipe `curl` + `jq`. It makes more sense to implement that in the dyndns client itself. This way, I also can handle more logic like filtering through the IPs returned by the API to find the first public v4 IP. In the end, I just add the new unifi api key to my cron job as another arg: exec /path/to/ddporkbun --apikey="${apikey}" --secretapikey="${seckey}" --unifi-apikey="${unifikey}" --domain="mydomain.com" --subdomain="dyndns" --log-level=ERROR