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:
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.
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.
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:
Summary: Temporarily change the OUYA's network configuration to use 178.254.13.17 as DNS server.
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.
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.
adb shell
su
to become the root user
mount -o rw,remount -t ext4 /dev/block/platform/sdhci-tegra.3/by-name/APP
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.
If you still get the "Unable to connect" error, then you are missing the ouya_config.properties file.
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:
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.
I wrote an Android application that acts as HTTP server by opening a socket and listening on port 8080. During development I used the QEMU-based Android emulator that is integrated with Android Studio. Simply sending requests to the emulated Android machine does not work, some preparation is necessary.
I used the post Android AVD Networking by rhill solutions as basis, which unfortunately only exists on the Internet Archive in 2022.
I had to setup port forwarding from my local machine to the Android emulator (AVD, Android Virtual Device). The first emulator has a management interface on port 5554, which you can connect to with telnet:
$ telnet localhost 5554 Connected to localhost. Escape character is '^]'. Android Console: Authentication required Android Console: type 'auth <auth_token>' to authenticate Android Console: you can find your <auth_token> in '/home/cweiske/.emulator_console_auth_token' OK auth thisismysecretaccesskey Android Console: type 'help' for a list of commands OK redir add tcp:8080:8080 OK quit Connection closed by foreign host.
This enabled the forwarding of requests to localhost:8080 to the Android application listening on port 8080 in the emulator:
louyapi
louyapi - local OUYA API server
]]>
I wanted to disable Firefox' DNS-over-HTTPS in my network so that my custom home domains still work.
It is possible to do that network-wide by preventing the canary domain use-application-dns.net from getting resolved (NXDOMAIN).
I use Dnsmasq on my home server, and to disable the canary domain I only had to add the following line to the configuration file:
address=/use-application-dns.net/
I have two WiFi access points in the house, a FritzBox 7412 and a TP-Link TL-WR740N v4 running the open source DD-WRT firmware.
I also use Munin for monitoring my home, and had the fritzbox-munin plugin installed to see the number of connected WiFi devices:
There was no dd-wrt plugin available for munin, so I built one: The source code can be found at my git server and on sourcehut: ~cweiske/dd-wrt-munin.
As of 2022-03-11, the dd-wrt-munin is part of the official munin-contrib plugin repository.
It will generate a graph like this:
Now I had two graphs; one for the devices on the FritzBox, and one for the DD-WRT router. I wanted to have them in one single graph. The keyword here is loaning data:
wifidevs.update no wifidevs.graph_title Connected Wifi devices wifidevs.graph_args --base 1000 wifidevs.graph_vlabel Number of devices wifidevs.graph_info Sum of all access points wifidevs.graph_scale no wifidevs.graph_category network-wifi wifidevs.graph_total Total wifidevs.total.label not_used wifidevs.total.type GAUGE wifidevs.total.draw AREA wifidevs.total.stack \ frit_rt=frit:fritzbox_wifi_devices.wifi \ tpli_wz=frit:dd_wrt_wifi_devices_tpli_wz.wifi
This combines the wifi data from plugin fritzbox_wifi_devices on node frit and the wifi data from plugin dd_wrt_wifi_devices_tpli_wz. The result is what I wanted:
My dd-wrt-munin plugin uses DD-WRT's /Status_Wireless.live.asp page and tries to parse it. Here are some example data with two connected devices:
{wl_mac::F8:D1:11:8B:23:42}{wl_ssid::home.cweiske.de}{wl_channel::11 + 7 (2462 MHz HT40)}{wl_radio::Radio is On}{wl_xmit::18 dBm}{wl_rate::150 Mbit/s}{wl_busy::20053342 ms}{wl_active::785275128 ms}{wl_quality::98%}{wl_ack::15µs (2250m)}{active_wireless::'48:2C:A0:74:23:42','','ath0','1:33:36','72M','1M','HT20SGI[PS]','-61','-95','34','780','-58','0','0','0','98:CD:AC:2E:23:42','','ath0','1 day, 8:19:17','43M','48M','HT20SGI','-72','-95','23','560','-71','0','0','0'}{active_wds::}{assoc_count::10}{packet_info::SWRXgoodPacket=1965092;SWRXerrorPacket=0;SWTXgoodPacket=13036095;SWTXerrorPacket=0;}{uptime:: 16:59:35 up 9 days, 2:40, load average: 0.00, 0.01, 0.04}{ipinfo::: Disabled}
This are blocks beginning with { and ending with }. The block name is up to the first :::
wl_mac::F8:D1:11:8B:23:42 wl_ssid::home.cweiske.de wl_channel::11 + 7 (2462 MHz HT40) wl_radio::Radio is On wl_xmit::18 dBm wl_rate::150 Mbit/s wl_busy::20053342 ms wl_active::785275128 ms wl_quality::98% wl_ack::15µs (2250m) active_wireless::'48:2C:A0:74:23:42','','ath0','1:33:36','72M','1M','HT20SGI[PS]','-61','-95','34','780','-58','0','0','0','98:CD:AC:2E:23:42','','ath0','1 day, 8:19:17','43M','48M','HT20SGI','-72','-95','23','560','-71','0','0','0' active_wds:: assoc_count::10 packet_info::SWRXgoodPacket=1965092;SWRXerrorPacket=0;SWTXgoodPacket=13036095;SWTXerrorPacket=0; uptime:: 16:59:35 up 9 days, 2:40, load average: 0.00, 0.01, 0.04 ipinfo::: Disabled
The active_wireless line is a bit cryptic, but the source code wireless_madwifi.c: active_wireless_if helps to understand the columns:
websWrite(
wp,
"'%s','%s','%s','%s','%dM','%dM','%s','%d','%d','%d','%d','%d','%d','%d','%d'",
mac,
radioname,
wc->ifname,
UPTIME(wc->uptime, str),
wc->txrate / 10 * mul / div,
wc->rxrate / 10 * mul / div,
info,
wc->signal + bias,
wc->noise + bias,
wc->signal - wc->noise,
qual,
wc->chaininfo_avg[0],
wc->chaininfo_avg[1],
wc->chaininfo_avg[2],
wc->chaininfo_avg[3]
);