Es ist das Jahr 2025, 27 Jahre nach der Standardisierung von IPv6. Die 1blu RootServer unterstützen kein IPv6, wie auch die meisten anderen Produkte bei 1blu. Traurig.

Der Support antwortet mit der gleichen Nachricht wie letztes Jahr:

Wir bedauern Ihnen mitteilen zu müssen, dass IPv6 bei Ihrem Produkt aktuell noch nicht unterstützt wird. Unsere Technik arbeitet bereits daran dies zu ermöglichen. Bitte haben Sie Verständnis, dass wir Ihnen jedoch noch keinen genauen Termin nennen können.

Wir werden zu einem anderen Hoster wechseln.

Siehe auch:

• 1blu ipv6 status 2024
• 1blu ipv6 status 2023
• cubewerk: 1blu ipv6 status 2020
• 2015-06: presse@1blu.de: Aktuell bieten wir IPv6 leider noch nicht an.

5 Jahre nach Projektstart haben wir endlich einen Glasfaseranschluss bekommen, und zwar mit der enviaTel als ISP.

Kurz nach der Umstellung bemerkte ich, daß SSH-Verbindungen nach einiger Zeit unterbrochen wurden und hängen blieben - anfangs konnte man sie normal benutzen, aber dann reagierten sie nicht mehr auf Eingaben.

FritzBox?

Als Router bekamen wir eine Fritzbox 5530 Fiber, und diese machte ich auch erstmal für das Problem verantwortlich.

AVM selbst dokumentiert, daß FritzBoxen Verbindungen nach 15 Minuten trennen.

Weiterhin gibt es im Netz viele Berichte über dieses Problem, allerdings sind die meisten schon mehr als 15 Jahre alt:

• 2005: Abbrüche bei SSH connect ins WAN über Fritz Box
• 2006: Putty und "Connection reset"

  lt. support ist der timeout der fritzbox hochoptimiert und kann daher nicht per einstellung geändert werden.:-Ö

• 2008: SSHFS-Verbindung bricht nach einiger Zeit ab
• 2009: Timeout Option für TCP/UDP - Filesharing
• 2021: häufiger Abbruch langlaufender TCP-Verbindungen

  Eine FRITZ!Box macht nach 15 Minuten TCP-Verbindungen einfach zu.

Bevor ich mit an den enviaTel-Support wandte, wollte ich aber erstmal genauere Daten haben.

Problemeingrenzung

Der Blogpost My ISP Is Killing My Idle SSH Sessions. Yours Might Be Too. verwies auf das Tool NAT-TCP-test, dessen Server aber leider nicht mehr läuft. Das Kompilieren des Codes auf dem Server war mir zu aufwändig, weshalb ich eine Alternative suchte.

Zuerst probierte ich es manuell, schwenkte dann aber schnell auf einen Automatismus um:

$ date && ssh cweiske.de "sleep 240; date"
Fr 20. Sep 10:25:30 CEST 2024
Fr 20. Sep 10:29:30 CEST 2024

Die aktuelle Zeit wird ausgegeben, dann die SSH-Verbindung aufgebaut, einige Sekunden gewartet und die Zeit auf dem Server ausgegeben. Wenn die Verbindung zwischendurch gekillt wird, wird das 2. Datum nicht zu sehen sein.

Den Befehl startete ich mit unterschiedlichen Wartezeiten in mehreren Shells und bekam 300 Sekunden - exakt 5 Minuten - als Grenze heraus. 300 Sekunden waren ok, 301 nicht mehr.

Da die FritzBox untätige Verbindungen erst nach 15 Minuten trennt, konnte ich sie als Problemursache ausschließen.

Andere Probleme

Nicht nur SSH machte Probleme, sondern auch andere Programme zeigten Fehlverhalten:

Das native E-mailprogramm auf dem DM7080HD-Satellitenreceiver blieb regelmäßig hängen und konnte auch mit dem sonst üblicherweise funktionierendem Programm-verlassen-und-wieder-reingehen keine neuen Mails empfangen.

Im Android-Emailprogramm K-9 Mail konnte ich keine neuen E-Mails mehr abholen bis ich es hart beendet und neu gestartet hatte.

Das Android-Synchronisationstool DAVx5 zeigte Fehlermeldungen an:

Weicher Fehler (maximale Anzahl an Wiederholungen erreicht)

Carrier-Grade NAT

Ich schilderte dem enviaTel-Support mein Problem. Der erläuterte, daß mein Internetanschluss Teil eines Carrier-Grade NAT (CG-NAT) ist. Das bedeutet, daß der Router keine echte öffentliche IPv4-Adresse bekommt, sondern nur eine enviaTel-interne. Beim Test mit ip.cweiske.de bekam ich die 212.99.194.23 als öffentliche IP angezeigt, während die FritzBox die externe IP 100.65.240.42 hatte.

CG-NAT verhindert zum einen Verbindungen aus dem Internet auf den Router (VPN ade) - und zum anderen heißt CG-NAT, daß es noch eine 2. Routerebene gibt, die IP-Verbindungen von der enviaTel-internen IP auf die öffentliche mappt.

Der Support bot mir an, zu Diagnosezwecken auf eine echte öffentliche IPv4-Adresse umzustellen. Sobald das getan war, waren die Verbindungsprobleme weg - SSH-Verbindungen blieben sogar mehr als eine Stunde offen.

Eine FritzBox im Jahr 2024 tötet inaktive SSH-Verbindungen also nicht nach 15 Minuten. Das früher mal existierende Problem existiert nicht mehr.

Ich verwies den Support auf Abschnitt 5 der RFC 5382:

REQ-5: If a NAT cannot determine whether the endpoints of a TCP connection are active, it MAY abandon the session if it has been idle for some time. In such cases, the value of the "established connection idle-timeout" MUST NOT be less than 2 hours 4 minutes. The value of the "transitory connection idle-timeout" MUST NOT be less than 4 minutes.

Das ist genau dasselbe Problem, das ato im oben verlinkten Blogbeitrag hatte.

Zum Schluß habe ich mich mit der enviaTel darauf geeinigt, daß ich die echte IPv4-Adresse kostenlos bekomme bis das Problem behoben ist (statt üblicherweise 3€/Monat).

---

weitere Stichwörter: NAT-Keep-Alive

I use DNS servers from the OpenNIC project because they are uncensored. Now and then one of the servers becomes unavailable and I wonder why my internet is broken - until I remember that it could be the upstream DNS server my home server is using.

To get notified about that problem, and to find out if the chosen tier2 servers are fast enough, I implemented the dnsperftest munin plugin. It was merged into the munin-contrib repository a couple of days ago.

The plugin reads the name servers from your /etc/resolv.conf file and monitors the average response times for a list of domains:

I borrowed some code from the cleanbrowsing/dnsperftest shell script which is unmaintained.

Es ist das Jahr 2024, 26 Jahre nach der Standardisierung von IPv6. Die 1blu RootServer unterstützen kein IPv6, wie auch die meisten anderen Produkte bei 1blu. Traurig.

Der Support meint:

Wir bedauern Ihnen mitteilen zu müssen, dass IPv6 bei Ihrem Produkt aktuell noch nicht unterstützt wird. Unsere Technik arbeitet bereits daran dies zu ermöglichen. Bitte haben Sie Verständnis, dass wir Ihnen jedoch noch keinen genauen Termin nennen können.

Siehe auch:

• 1blu ipv6 status 2023
• cubewerk: 1blu ipv6 status 2020
• 2015-06: presse@1blu.de: Aktuell bieten wir IPv6 leider noch nicht an.

I wanted to prevent clients to see my home server's list of NFS shares, so I disabled its nfs-mountd.service because it is only needed for NFSv3:

rpc.mountd

This process is used by an NFS server to process MOUNT requests from NFSv3 clients. It checks that the requested NFS share is currently exported by the NFS server, and that the client is allowed to access it. If the mount request is allowed, the nfs-mountd service replies with a Success status and provides the File-Handle for this NFS share back to the NFS client.

And indeed, no share list was visible anymore:

$ showmount -e dojo
clnt_create: RPC: Program not registered

But this had consequences, although I tried to use NFSv4 only:

$ cat /etc/fstab | grep media-dojo
dojo:/data/media  /mnt/media-dojo  nfs  noauto,user,nolock,nfsvers=4

$ mount -v /mnt/media-dojo/
mount.nfs: timeout set for Thu Dec 21 21:20:46 2023
mount.nfs: trying text-based options 'nolock,vers=4.2,addr=fdc3:e153::3,clientaddr=fdc3:e153::dcbb:9cea:9873:1f10'
mount.nfs: mount(2): Connection refused
mount.nfs: trying text-based options 'nolock,vers=4.2,addr=192.168.3.3,clientaddr=192.168.3.5'
mount.nfs: mount(2): Connection refused
mount.nfs: trying text-based options 'nolock,vers=4.2,addr=fdc3:e153::3,clientaddr=fdc3:e153::dcbb:9cea:9873:1f10'
mount.nfs: mount(2): Connection refused
mount.nfs: trying text-based options 'nolock,vers=4.2,addr=192.168.3.3,clientaddr=192.168.3.5'
mount.nfs: mount(2): Connection refused

I could not mount the shares from my Debian experimental (trixie) laptop anymore! After re-enabling nfs-mountd on the home server I could mount again:

$ mount -v /mnt/media-dojo/
mount.nfs: timeout set for Thu Dec 21 21:20:54 2023
mount.nfs: trying text-based options 'nolock,vers=4.2,addr=fdc3:e153::3,clientaddr=fdc3:e153::dcbb:9cea:9873:1f10'
mount.nfs: mount(2): Permission denied
mount.nfs: trying text-based options 'nolock,vers=4.2,addr=192.168.3.3,clientaddr=192.168.3.5'
$

A comment on severfault.com explains it:

According to rpc.mountd(1),

"The rpc.mountd daemon implements the server side of the NFS MOUNT protocol, [...] It also responds to requests from the Linux kernel to authenticate clients and provides details of access permissions."

... so it's not needed on an NFSv4 client, but an NFSv4 server still needs it, even though there's no direct communication between clients and rpc.mountd.

Sam Morris, 2023-12-16

So I have to keep nfs-mountd running on the server, but I can deny access from the outside:

mountd: ALL

Listing mounts is not possible anymore, but mounting is:

$ showmount -e dojo
rpc mount export: RPC: Authentication error; why = Failed (unspecified error)

My new home server mounts some NFS shares from the NAS. When electricity is restored after an outage, both NAS and home server boot up at the same time. The new home server is much faster than my rusty NAS, and so services depending on NFS mount data would start too early, possibly removing data from their database (e.g. Gerbera or paperless-ngx).

To not run into that problem I added a systemd service that waits for the NAS to be available before trying to mount the NFS shares.

At first a service that waits for the NAS ("disa", short for DiskStation) to be reachable ping:

[Unit]
Description=Blocks until it successfully pings disa 192.168.3.96
After=network-online.target

[Service]
ExecStartPre=/usr/bin/bash -c "while ! ping -c1 192.168.3.96; do sleep 1; done"
ExecStart=/usr/bin/sh -c "echo good to go"
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

This has to be enabled with

$ systemctl daemon-reload
$ systemctl enable wait-for-disa

Now the NFS mounts are configured to wait for that service to become available:

disa:/volume2/media  /mnt/media-disa  nfs  x-systemd.after=wait-for-disa.service,timeo=50

A systemctl daemon-reload and all is set.

My own OUYA API server has been running since november last year. The game data files have been worked on: Previously missing games were added, wrong developer UUIDs fixed. Many of the games got product data, so that purchases can be restored now and games stuck in demo mode unlock to the full version now.

All went nicely until end of january, people with factory reset OUYAs came into the chat and asked for help because they could not get past the network configuration screen. All they got were the following error messages:

Unable to connect

Please check your Internet connection and try again.

and

Cannot establish a connection with the OUYA Servers. To turn on Wi-Fi, unplug your Ethernet cable and proceed. To retry ethernet, please check your connection and then unplug and re-plug your cable.

The culprit

Luckily I own two OUYAs, so I did a factory reset on the development machine and tried the setup myself: It failed with the same error messages as reported.

The initial setup is managed by OUYAOOBE.apk, the Out Of the Box Experience application. I read the decompiled sources and soon found the culprit, ConnectivityChecker.java:

public Void doInBackground(Void... params) {
    Socket socket = null;
    boolean reachable = false;
    try {
        Socket socket2 = new Socket("devs.ouya.tv", 80);
        reachable = true;
        if (socket2 != null) {
            try {
                socket2.close();
                Socket socket3 = socket2;
            } catch (IOException e) {
                Socket socket4 = socket2;
            }
        }
    } catch (UnknownHostException, IOException e2) {
        // error handling
    }
    setResult(reachable);
    return null;
}

So OUYA's setup application has a hard-coded check to devs.ouya.tv, which was the name of the API server - and it does not use the ouya config override file ouya_config.properties. The DNS record still exists:

$ dig devs.ouya.tv
devs.ouya.tv.		60	IN	CNAME	tokyo-6663.herokussl.com.

But the host that the domain was aliased to does not exist anymore:

$ dig +short tokyo-6663.herokussl.com
$

Apparently Razer's Heroku contract was cancelled or not renewed, and the box that served the redirect from devs.ouya.tv to razer.com was shutdown forever.

The solution

It is possible to get past the network selection screen by letting the OUYA think that devs.ouya.tv still exists, and let it point to some IP address that has a HTTP and HTTPS server running.

Choose one of the following options:

1. Modify the internet router's DNS server

1. Open your internet router's web interface and change the DNS server temporarily to 178.254.13.17.
2. Finish the OUYA setup including registration.
3. Change the router's DNS server setting back to the previous setting or the one provided by the ISP - otherwise you cannot open most web pages anymore.

2. Modify the OUYA DNS server

Summary: Temporarily change the OUYA's network configuration to use 178.254.13.17 as DNS server.

Wifi

1. Connect to your Wi-Fi network. The OUYA shows "It seems we're unable to connect to the OUYA servers at the moment".
2. Press Y to open the network settings.
3. Select the connected Wifi network, and long press the green O button until the context menu appears. Select "Modify network".
4. Activate "Show advanced options".
5. Change the "IP settings" from "DHCP" to "Static".
6. Change the "DNS 1" address to 178.254.13.17.
7. Close the network settings and press O to continue.
8. If you get a popup "Unable to connect", create the configuration file and reboot the OUYA.
9. Once you registered and see the OUYA main menu, go to Manage -> Network Settings and change the network settings back to DHCP.

Ethernet

1. The OUYA setup shows the network information (IP Address, Subnet mask, ...) and the message "Cannot establish a connection with the OUYA Servers."
2. Write down the three addresses: IP Address, Subnet Mask, Router.
3. Press Y to open the network settings. If , then configure the ethernet or wifi device.
4. Change the "Connection Type" from "DHCP" to "Static IP".
5. Manually enter the "IP address", "Netmask" and "Router".
6. Change the "DNS address" address to 178.254.13.17.
7. Save & close the network settings and press O to continue.
8. If you get a popup "Unable to connect", create the configuration file and reboot the OUYA.
9. Once you registered and see the OUYA main menu, go to Manage -> Network Settings and change the network settings back to DHCP.

3. DNS mapping in your router

Some routers allow you to add own domain-name-to-IP-mappings. If your router is one of them, add a mapping for hostname devs.ouya.tv, status.ouya.tv and ouya-updates.s3.amazonaws.com to the IP of my server: 178.254.13.17.

4. Modify OUYA's /system/etc/hosts file

Each computer has a file /etc/hosts that allows you to define DNS mappings. On Android, that file is located at /system/etc/hosts.

This method will surely work, but takes the most steps. You need to have the "Android Debug Bridge" (adb) command line tool installed on your PC. Have a look at Cyanogen Mod CM11 and the Ouya, it has installation instructions for adb on windows.

1. On your PC, run adb shell
2. Type su to become the root user
3. Make the system partition writable:
   mount -o rw,remount -t ext4 /dev/block/platform/sdhci-tegra.3/by-name/APP
4. Use my server instead of the original one by modifying the hosts file:
   echo "178.254.13.17 devs.ouya.tv status.ouya.tv ouya-updates.s3.amazonaws.com" >> /system/etc/hosts

The connectivity check should work now without rebooting.

Unable to connect

If you still get the "Unable to connect" error, then you are missing the ouya_config.properties file.

Update 2023-04-03

Because I am moving to a new server, the IP address changed from 83.169.45.222 to 178.254.13.17.

Es ist das Jahr 2023. Die 1blu RootServer unterstützen kein IPv6, wie auch die meisten anderen Produkte bei 1blu. Traurig.

Der Support meint:

Aktuell wird IPv6 ausschließlich bei den 1blu-vServern unterstützt.

und

Bitte haben Sie Verständnis, dass wir Ihnen jedoch noch keinen genauen Termin nennen können [bis zu dem IPv6 für Sie verfügbar sein wird].

Siehe auch:

• cubewerk: 1blu ipv6 status 2020
• 2015-06: presse@1blu.de: Aktuell bieten wir IPv6 leider noch nicht an.

Vor einigen Tagen kam ich früh in die Küche und fand einen kaputten Kühlschrank vor: Temperatur war nicht so kalt wie gewöhnlich, Licht im Kühlschrank war aus, und auch die Temperaturanzeige funktionierte nicht.

Also schnell einen Ersatzkühlschrank aus der Scheune geholt und den gesamten Inhalt umgepackt, damit dieser wieder ordentlich gekühlt wird.

Nachdem das Frühstück durch und die Schnitten geschmiert waren dachte ich nochmal über den Kühlschrank nach. Es war komisch, daß alles ausgefallen war - wenn der Kühlkreislauf kaputt wäre, würde wenigstens die Temperaturanzeige und das Licht noch gehen. Aber alles auf einmal...

Ich entfernte dann die Scheuerleiste unter dem Kühlschrank und fand .. einen Shelly Plug - eine per Netzwerk schaltbaren Zwischenstecker. Der war aus.

Mitte diesen Jahres nutzte ich einige der schaltbaren Zwischenstecker um den Stromverbrauch von Haushaltsgeräten zu messen, was erklärt, warum der dort steckte.

Letztes Jahr nutzte ich Shelly-Relais um Schwibbögen zentral ein- und auszuschalten. Vor einigen Tagen hatten wir wieder die Schwibbögen aufgestellt, und einer von ihnen hat einen als Schalter verbauten Shelly. Dieser war konfiguriert, bei Betätigung einen zweiten Shelly auszuschalten, und zwar genau den, den ich zur Strommessung des Kühlschranks genommen hatte.

Auch verfügbar auf: Shelly Support Forum

We got an old 2015 Macbook Pro (A1398) and I let Munin check if it is connected to the Wi-Fi network. When looking at the graphs I saw it was responding to ping packets even though it was sleeping!

A setting in the preferences application is responsible for this:

System Preferences > Energy Saver > Power Adapter > Wake for Wi-Fi network access

(German: Systemeinstellungen > Energie sparen > Netzteil > Ruhezustand bei WLAN-Netzwerkzugriff beenden )

When it is enabled and the Macbook is attached to the power cord, it will respond to pings in the network.

When the setting is disabled, it stops responding to pings 16-40s after closing the lid.