400MBit bei Vodafone

Samstag, der 9.6.2018

  • An der technischen Hotline war man in der  gewillt und in der Lage, mir den 400Mbit-Tarif zu buchen. Die habe ich am Samstag, den 9.6.2018 angerufen. Eigentlich wollte ich nur wissen, warum ich mich mit meinen Zugangsdaten nicht einloggen kann, oder warum mir die Webseite sagt, dass es meine Kundennummer entweder nicht gibt oder doppelt vorhanden ist. Es stellte sich heraus, dass ich mich einfach neu anmelden muss, aber dazu später mehr. Die normale Hotline  hat mich bezüglich meiner anfrage an die technische Hotline verwiesen (0800/5266624), wo mir kompetent geholfen wurde. Nicht bezüglich des Logins, aber bezüglich meiner Anfrage.
  • Nachdem wir herausgearbeitet hatten, dass ich mich nur einfach neu anmelden muss, weil ich eigentlich ein KD-Kunde bin, habe ich die nette Dame darauf angesprochen, dass ich eigentlich nur 400 Mbit anstatt 100 Mbit möchte. Sie hat mir Neukunden-Bedingungen angeboten, die ich natürlich sofort angenommen habe. Ich bräuchte allerdings ein neues Modem, da mein 8 Jahre alter Trümmer den aktuellen Docsis-Standard nicht verstünde. Nach kurzer, sehr fachmännischer Diskussion stellte sich heraus, dass auch das neue Modem den Bridge-Modus beherrscht. Soweit so gut. Der Vertrag fängt zwar neu für 2 Jahre an zu laufen, aber warum nicht. Ohne mit der Wimper zu zucken habe ich ja gesagt.
  • Nebenbei habe ich einen Aktivierungs-Code für meinVodafone beantragt, da ich schon wusste, dass ich ihn brauchen würde. Man konnte mir zwar die Bestellbestätigung per Email zustellen, aber nicht den Code…

Dienstag, der 12.6.2018

  • Das Modem wurde an meinen Nachbarn geliefert. In der Mittagspause habe ich es abgeholt, aber wohl wissentlich noch nicht angeschlossen, sondern erst nach Feierabend
  • Natürlich kam es so, wie es kommen musste. Das Teil war nicht mehr im Bridge-Modus, sondern als Router konfiguriert. So weit, so scheiße.
  • Also habe ich bei der technischen Hotline angerufen (s.o.) und darum geben, das Drecksteil in den Bridge-Modus zu schalten. Das geht natürlich seit Montag (welches Jahr und/oder Monat bleibt offen) nicht mehr, aber man könne mir den Aktivierungs-Code sogar per E-Mail zusenden! Hoffnungsvoll habe ich mein Adresse buchstabiert und 90 Minuten gewartet, wie angesagt. Dreimal darf man raten, was ich nicht bekommen habe. Enttäuscht bin ich erstmal ins Bett.

Mittwoch, der 13.6.2018

  • Aufgestanden, Kaffee gekocht und festgestellt, dass ich nur noch eine IPv6-Adresse habe. IPv4 nur noch über NAT. Egarl, Karl, dann stellen wir das Modem halt auf Durchzug. Ich brauch ja nur CIFS von valhalla, und der Trümmer spricht IPv6.
  • Also die MAC-Adresse für die Ports 1-65535/TCP eingetragen, und dann noch UDP, mehr Protokolle kennt der Bremsklotz nicht. ICMP oder IPSEC scheinen nicht zu existieren. Nochmarl egarl, Karl. UDP hinzugefügt, und… Drecksschüppenscheiße! Die MAC-Adresse wäre wohl doppelt vergeben, sagt das bekackte Interface. Natürlich! Es soll Netzwerkkarten geben, die sowohl UDP und TCP-Pakete gleichzeitig empfangen können! Vielleicht sogar noch anderen Verkehr!

Die Lösungen

Alle angeschlossenen Veranstaltungen haben IPv6, also kein Problem. Also erstmal alles Richtung valhalla über VodaFuck routen. Das geht mit:

[Match] 
Name=ext 

[Network] 
DHCP=v4 
IPv6Token=::dead:b0a1 

[DHCP] 
RouteMetric=4096 
RouteTable=199 

[IPv6AcceptRA] 
RouteTable=199 

[RoutingPolicyRule] 
To=2a01:4f8:201:60ce::/64 
Table=199

Table 199 == kd. Das IPv6Token setzt die IP-Adresse auf prefix::Token, egal was das Router-Annoucement sagt.  Die Policy routet alles nach Hetzner über das Vodafone-Interface. Dann muss man nur noch die OpenVPN-Config auf IPv6 umstellen und dem Server an eine bestimmte Adresse binden:

port 1194
local 2a01:4f8:201:60ce::2 
proto udp6

Dazu noch proto udp6 auf client-Seite und der Tunnel steht. Soweit, so gut.

CIFS

CIFS ist zwar einfach, aber man muss wissen, wie. Dazu muss man die IPv6-Adresse in “Windows” umrechnen. Natürlich funktioniert eine literale Adresse in eckigen Klammern nicht. Dieser Scheiß hier funktioniert tatsächlich… Fenster ist immer für eine Überraschung gut!

Sonstiges

Habe bestimmt eine Menge vergessen, aber das kommt dann hier 🙂 Bin gespannt, wann der Aktivierungs-Code in der Post ist.

Dann wäre da noch…

Meine launige Mail an die geschätzten Kollegen:

An: Serverteam Verteiler
CC: <Noch ein Kollege>
Gesendet: Mi 13.06.2018 16:50

Moinsen,

Erlebnisbericht VodaToll:
Voller erwartungsvoller Erwartung habe ich gestern Abend den niegelnagelneuen, schwarz glänzenden Bremsklotz von Vodafone angeklemmt und bekam sofort eine Verbindung! Hmm, zu schön um wahr zu sein, da muss es doch einen Haken geben, und siehe da, es gibt ihn! Wäre ja auch zu schön gewesen, wenn der Trümmer weiterhin im Bridge-Modus (also einfach nur Modem) geblieben wäre. Nein, sämtliche Einstellungen, die ich vor Jubeljahren mal vorgenommen habe, sind zurückgesetzt worden.

Aber kein Problem. Ich hab ja die Nummer der technischen Hoteline. Nur gefühlte 24 Sprachmenüs und drölf Minuten toller Fahrstuhlmusik später hatte ich tatsächlich einen richtigen Menschen am Rohr! Konnte es kaum glauben! Habe sehr freundlich darum gebeten, mein Modem doch wieder in besagten Brückenmodus zu versetzen, aber das war schwieriger als einem Frosch das Kuchenbacken beizubringen. Hätte vielleicht doch lieber bei der Behörde zur Verhinderung der Überschreitung der Lichtgeschwindigkeit anrufen sollen, die hätten das vielleicht hinbekommen.

Laut Aussage der sehr hilfsbereiten Dame am anderen Ende der Schnur ginge das seit genau diesem Montag nicht mehr, und jetzt sei nun mal Dienstag. Da könne sie nichts machen, aber ich könne das ja selbst auf MeinVodafone anbeklacken. Klar doch, sach ich, würde ich ja gerne, hab aber keinen fünfundzwölfstelligen Aktivierungscode, den ich brauche, um mir Zugang zu verschaffen. Kein Problem, sacht sie, den könne sie mir sogar per elegdönischer Post innerhalb von 90! Minuten zuschicken. Nachdem ich meine Schuhgröße, Mädchenname der Mutter, Schwanzlänge, Bauchnabeldurchmesser und die Emaille durchgegeben habe, hat sie einen Knopf gedrückt und mir versprochen, dass ich den geheimen Geheimcode in anderthalb Stunden in meinem Briefkasten hätte. Wenn nicht, möge ich doch bitte mein Dosenfleisch durchschauen…

Drei Mal dürft ihr raten, was nicht passiert ist… Naja, mal sehen, was der nächste Tag so bringt. Vielleicht kömmen ja mit einem Firmware-Update auch die eingestellten Einstellungen wieder.

Das Firmware-Update kam latürnich, aber nicht mit den erwarteten Einstellungen. Heute Morgen durfte ich dann feststellen, dass ich nicht nur nicht im Bridge-Modus war, sondern außerdem auch keine IPv4-Adresse mehr hatte, dafür aber endlich IPv6, was mit meinem alten Bremsklotz noch schwieriger war, als mir den geheimen Geheimcode zuzusenden oder die Lichtgeschwindigkeit zu überschreiten. Das Ganze nennt sich dann DS-Lite. Man bekommt eine private IP-Adresse (RFC 1918), die dann irgendwo im VodaToll-Netz genattet wird, und dazu ein /64-IPv6-Netz geroutet. Kein Problem, da ich über den Telekomiker-Anschluss noch via IPv4 erreichbar bin.

Die 400 Mbit liegen auf jeden Fall an. Das sind nicht nur "bis zu", sondern wirkliche 400 Mbit. Wenigstens etwas. Bin gespannt, ob ich diese Woche noch den Aktivierungskot per Schneckenpost bekommen. Noch viel gespannter bin ich darauf, ob ich mich damit wirklich einloggen kann, und was gebeurt, wenn ich es wage, den Bridge-Modus einzuschalten!

Alles weitere demnäxt in dieser Sendung!

-- 
Bis später!
Arno.

 

Ryzen, Part 5

Well, well, well, after 71 days uptime the system can be considered stable:

Disabling the C6-sleep-state did it:

zenstates.py --c6-disable

Since last reboot the spectre/meltdown disaster happened. DKMS didn’t work any more, because archlinux updated gcc to 7.3 with retpoline support, so it blatantly refused to compile the nvidia module with a different compiler than the kernel was compiled with. That wasn’t really a problem, because X still restarted properly.

But there were other problems like systemd asking for passwords when it shouldn’t, dbus out of date and so on. Well, that’s what you get when running a rolling distribution. So I thought it was time to schedule a kernel re-compile and a reboot.

The re-compile was harder than expected. To put it short:

  • When following the official documentation, do the checkout in an empty directory
  • edit prepare() to do make oldconfig and make menuconfig in this order
  • Don’t forget to uncomment and change pkgbase to linux-ryzen!
  • Don’t makpkg -s on an encrypted volume 🙂
  • If DKMS complains about a compiler mismatch on pacman -U, do IGNORE_CC_MISMATCH=1 pacman -U …

After a successful reboot I decided to install the fallow 16 GB of ram I initially purchased, since RAM timings weren’t really the problem. Now I have a workstation with whopping 32GB RAM:

# free -m 
       total        used        free...
Mem:   32167        5521        8478...
Swap:  16382           0       16382

I kept the RCU_* setting, so let’s see how it turns out. Keeping fingers crossed!

The whole SheBang!

Ryzen, Part 4

Take 4

Well, I didn’t have to wait long. The box crashed right under my fingers only hours after the last changes. So, instead of enabling “Global C-States” in the BIOS, I disabled it explicitly.

Additionally, I used zenstates.py to disable C6 for good, hopefully:

# modprobe msr
# ./zenstates.py --c6-disable 
Disabling C6 state
# ./zenstates.py -l 
P0 - Enabled [...]
P1 - Enabled [...]
P2 - Enabled [...]
P3 - Disabled 
P4 - Disabled 
P5 - Disabled 
P6 - Disabled 
P7 - Disabled 
C6 State - Package - Disabled 
C6 State - Core - Disabled

As suggested here, I also disabled ASLR:

# echo 0 > /proc/sys/kernel/randomize_va_space

Changes so far:

  • Buy new Memory:  16GB G.Skill Flare X schwarz DDR4-3200 DIMM CL14 Dual Kit instead of 16GB Corsair Vengeance LPX schwarz DDR4-3000 DIMM CL15 Dual Kit.  Didn’t help at all, since it’s not a memory timing problem, but a linux problem. About 200€ wasted, yay! The bright side: If the other changes make my system stable, I could install the other 16GB, too. That would be a whopping 32GB for a desktop system 🙂
  • Various BIOS updates.
  • Play with D.O.C.P. settings. Didn’t help, see above.
  • Find out that linux doesn’t like AMD Ryzen processors and build a custom kernel with RCU_NOCB_CPU enabled. Still crashes 🙁
  • Disable C6 with zenstates.py (see above)
  • Disable ASLR (also see above)

Keeping my fingers crossed. If all this doesn’t help, my last option would be to change to Intel. I don’t expect much from my system, just that it runs stable. Very disappointing that AMD can’t get it right…

The whole SheBang!

Ryzen, Part 3

Take 3

Of course neither the new memory nor the BIOS update fixed the random crashes, but fortunately I’ve got another hint: Maybe it’s a linux-specific problem, and not one with memory timing. This post suggests that it’s a problem with C-States and RCU. Adding the following kernel command line parameters should help:

processor.max_cstate=1
rcu_nocbs=0-11

As always, nothing is as simple as it seems 🙁

The C-States

For max_cstate to take effect, I had to actually enable Global C-State-Control in the UEFI-thingy of my mobo! The default was Auto, which in turn defaulted to Disabled. After enabling it, dmesg reported this:

ACPI: ACPI: processor limited to max C-state 1

Before that, there was no mentioning of C-states in the kernel log, so I doubt that it has any impact, but one should never give up hope!

The RCU-Thingy

What it is (quoting Paul E. McKenney from LKML):

Read-copy update (RCU) is a synchronization mechanism that was added to the Linux kernel in October of 2002. RCU achieves scalability improvements by allowing reads to occur concurrently with updates.

It’s much more likely to be the cause of the problem since I once saw something like this after a reboot on the console:

NMI watchdog: BUG: soft lockup - CPU#12 stuck for 23s! [DOM Worker:1364]

The process was “systemd” instead of “DOM Worker”, but that shouldn’t matter. Anyway, the parameter rcu_nocbs=0-11 has no effect if the kernel config option CONFIG_RCU_NOCB_CPU is not set. Guess what, in the stock archlinux kernel it’s unset, lucky me!

So I ventured out to compile a custom kernel for arch. That turned out to be disappointingly easy! The available documentation just works ™! Four hints, though:

  1. Uncomment “make menuconfig”
  2. Edit /etc/makepkg.conf and set MAKEFLAGS to “-j<no-processors+1>” to get parallel builds
  3. If you have a nvidia graphics card and use the proprietary driver, keep in mind that you have to rebuild that one, too. Once again, that was ridiculously easy. Just install nvidia-dkms before updating the kernel with pacman -U and it will be built automagically when you install the new kernel! Detailed instructions are here.
  4. Don’t forget to update your grub-config with grub-mkconfig before rebooting!
Offload RCU callbacks from CPUs: 0-11.

should be in dmesg after a reboot, otherwise it didn’t work. I’m waiting with baited breath how it turns out!

Previous parts of my adventure: Part 1, Part 2.

libvirt snapshots

If you have a VMWare-Background, handling libvirt-snapshots is very counter-intuitive. With VMWare, you take a snapshot and make changes to the actual disk. So when you’re done and haven’t encountered any problems, you just delete the snapshot and be happy.

With libvirt it’s the other way around: You work with the snapshot! This means you have to commit the changes to the base image after making changes! If you just delete the snapshot you’re back where you started! To make things worse, there are internal and external snapshots, and the latter aren’t fully supported by libvirt, meaning you can’t delete external snapshots with virsh.

So, to “emulate” VMWare-Behavior you have to:

  • Create an external snapshot while the VM is shut down:
# snapshot-create-as <domain> <snapshot-name> --disk-only --atomic
  • start the VM again:
#  start <domain>

Don’t let you fool by the output of snapshot-list: even though it says that the domain is shutoff, you’re actually working with the snapshot!

  • Make your changes
  • Once you’re done, commit the changes to the base image. Since libvirt cannot handle external snapshots properly you have to do it by foot. Shut down the VM and go to the directory with the disk images (/var/lib/libvirt/images or such). Then commit the changes to the base image with qemu-img:
# qemu-img commit <filename-of-external-snapshot>

Don’t worry about the destination. It’s in the metadata of the snapshot. Repeat for every disk of the VM and remove the (now very small) snapshot files.

  • Unfortunately libvirt still thinks that there is a snapshot. Delete it with
# snapshot-delete <domain> --metadata <name-of-snapshot>
  • More unfortunately, libvirt still references the snapshot files as base for the virtual disks. So remove them, re-add the real ones and start the VM.

Well, maybe it’s easier with internal snapshots (it should, because the procedure above is quite a dance…), but it works.

NVIDIA: Failed to initialize the GLX module

Another fallout from the dbus adventure: After I had othalla up and running again, I noticed that the graphic performance was really bad. Playing movies wasn’t moving at all, it was more like a slideshow.

Xorg.0.log said:

[  4978.363] (EE) NVIDIA(0): Failed to initialize the GLX module; please check in your X 
[  4978.363] (EE) NVIDIA(0):     log file that the GLX module has been loaded in your X 
[  4978.363] (EE) NVIDIA(0):     server, and that the module is the NVIDIA GLX module.  If 
[  4978.363] (EE) NVIDIA(0):     you continue to encounter problems, Please try 
[  4978.363] (EE) NVIDIA(0):     reinstalling the NVIDIA driver.

Strange… Turns out X loaded the xorg glx module from /usr/lib/xorg/modules/extensions instead the right one from /usr/lib/nvidia/xorg. No idea why, but adding:

Section "Files" 
    ModulePath      "/usr/lib/nvidia/xorg"
    ModulePath      "/usr/lib/xorg/modules"
...
EndSection

to xorg.conf before the regular path /usr/lib/xorg/modules fixed it.

 

DBUS Crap

After today’s (2017/06/16) usual pacman -Syu & systemctl reboot the shit hit the fan. SDDM started up fine, but when I tried to login, nothing happened for a while until I got a nice X11-Widget right from the 80’s telling me that something “could not sync environment to dbus”. Yeah, sure! WTF!?

First stop: Google. I’m not the only one. For some reason I can’t just “startkde” any more, but have to use “dbus-launch startkde” in /usr/share/xsessions/plasma.desktop (that’s where SDDM gets the sessions from). Easy enough. KDE loads and seems to work, but it doesn’t really. Any connection attempt to the session bus fails: can’t connect to the ssh-agent even though it’s started, can’t do systemctl –user <something>, pulseaudio doesn’t work and so on… Craptastic!

Maybe it’s some cruft in ~/.config or ~/.session. Move both away, and just to make sure, ~/.cache, too. One swift reboot later it’s work… Fuck, same shit! While skimming through wiki-pages and forum-posts on my mobile, I read the suggestion to try a new user. OK, can’t hurt, can it?

Yes, it kinda can! Of course that works! Well, at least one way out. So, create a new user and port all settings there. Oh what fun! Well, I learned a lot of lessons, like:

  • If you have an USB2 stick plugged in, entering the UEFI-Crap-Thingy what’s now called BIOS doesn’t work (or takes an eternity, maybe I didn’t wait long enough). At least it still boots if you don’t hit DEL or F2
  • The ssh-agent.service for users is hand-crafted (or stolen from somewhere, I don’t remember). You must have $SSH_AUTH_SOCK set in your .bashrc (the latter is sourced by SDDM, BTW) to make it work.
  • Sometimes it ain’t so bad to have Google accounts. After logging in with Chromium, my bookmarks and extensions were back almost immediately.
  • To start a synergy Server, all you have to do is “systemctl –user enable synergys.service”, if you have a working config in /etc/synergys.conf. Starting the client is another beast, though…
  • How to copy and modify the beet database (stored in $HOME/.config/beets/musiclib.blb in my case):
$ ~/.config/beets $ sqlite3 musiclib.blb
SQLite version 3.19.3 2017-06-08 14:26:16 
Enter ".help" for usage hints. 
sqlite> update items set path = replace(path, '<oldhome>', '<newhome>');
  • You don’t have to fire up QtCreator if rdpk starts and exits immediately. If you tell xfreerdp to use pulseaudio and there’s no daemon running, it will do just that…
  • For some reason, letting minidlnad reindex everything is much, much faster than letting it read the database on startup
  • LibreOffice macros are stored in $HOME/.config/libreoffice/4/user/basic/Standard/Module1.xba for now. You can just copy that file to the new $HOME and have fun with it after restarting it

Maybe it was a good thing ™ to get rid of all the baggage, I don’t know… Sure enough, it happened on othalla, too 🙁

Ryzen

After Lausitzring

I ordered a new motherboard, an AMD Ryzen 6-Core CUP with 16 GB DDR-4 RAM and a Macho Rev. 2b Cooler on Thursday, May 18th 2017. Paid by cash in advance, because mindfactory didn’t offer payment by credit card. Anyway, a colleague of mine ordered a gaming computer there before, so prepayment was no problem. The shipment arrived on Saturday, the 20th, when I was at the Lausitzring. Because we left early, I got the package from my neighbor Sunday evening.

Unpacking

Craptastic. The biggest box in the parcel was the Macho CPU-Cooler! It’s so big that I can’t even close the lid on my casing. Was quite a challenge to assemble. It looks like this:

The heat sink is the big thing in the middle, the turning fan is the white thing to the leftmost. My bedside cabinet was easier to put together!

With the ASUS-AM4-Board you don’t have to remove the backplate. Actually, you can’t. The spacers fit into the threads if you remove the brackets (barely). The heat sink still slides when you fasten the screws, but fortunately it doesn’t really matter.

I benchmarked the whole thing by re-encoding several videos from 1080p to 720p with ffmpeg, threaded. The temp didn’t raise over 65 °C, and it’s blazing fast. My old 6 core did it in real time, now it’s about half the time. At least ffmpeg says so…

Loudness

At first I thought it would be a problem that I couldn’t close the lid, but it isn’t. Actually, the external RAID with 4 hard discs is louder than the CPU fan on full speed. Good thing I orderd the separate cooler. I thought they’d deliver the CPU boxed, with one, but as it turns out, they didn’t.

First Boot

Well, after stuffing everything into the small casing, I pushed the power button and… Nothing! Fortunately I quickly remembered that I forgot to connect the whole Shebang, HDD-Led, power button, speaker and such to the panel. So, disconnect everything (VGA, USB, Network), get it out from under the table and fix it. Next try: One short beep, three long ones, no picture on either display. Shit!

The manual says that it means a missing graphics card. There definitely is one, but maybe in the wrong slot. I now have 3 PCI-Express slots. The first one isn’t usable, because it’s covered by the giant heat sink. So I get under the table and place the NVIDIA-Card into the downmost slot.

That did it! I’m greeted by an UEFI-BIOS and press DEL instantly. Not much to do in there, besides turning on SVM (Virtualization). I managed to get all 3 network cables right the first time, so I have network! The external SATA-casing is no problem, either, instantly recognized. Perfect!

htop shows 12 CPUs, 6 real cores, and 6 Hyperthreading. No fiddling around with UEFI-shit. Grub loads the kernel, as it shoud. Share and enjoy!

Telekom und IPv6 – Total tell, Todd!

Zuvörderst…

… muss man IPv6 Konnektivität herstellen. Wie das geht, habe ich in diesem Artikel beschrieben.

Wenn man aber mehr will…

… wie z. B. ein geroutetes /56er, dann muss man sich weiter anstrengen.

Das geroutete Netz bekommt man nur via DHCPv6. Am einfachsten geht das mit dhcpcd6 und einer dafür gemachten Konfiguration. Davon ausgehend, dass ppp0 das PPPoE-Interface der Telekom ist, muss sie so aussehen:

duid 
noipv6rs 
waitip 6 
ipv6only 
interface ppp0 
ipv6rs 
iaid 1 
ia_pd 1 int
  • iaid ist lediglich ein Identifier, den man referenzieren kann/muss
  • die letzte Zeile “ia_pd 1 int” ist interessant: “int” ist der Name des Netzwerk-Interfaces, dem ein Prefix zugeteilt werden soll.  Standardmäßig bekommt das Teil ein /64-Prefix mit der IP-Adresse Prefix::1/64

ACHTUNG: DHCPv6 läuft über UDP/ipv6, Port 546 ausgehend. Sonst geht gar nix! Hier die Iptables-Regel, wenn die INPUT-Policy Drop heißt:

ip6tables -I INPUT -i ppp0 -p udp -m udp --dport 546 -j ACCEPT

Wenn nix geht, zum Testen die Policies auf “ACCEPT” setzen und dann mit tcpdump schnüffeln.

Wenn man ein Prefix bekommen hat, sollte man…

RADVD installieren…

Und zwar mit folgender Config:

interface int { 
        AdvSendAdvert on; 
        MinRtrAdvInterval 3; 
        MaxRtrAdvInterval 10; 
        prefix ::/64 { 
                AdvOnLink on; 
                AdvAutonomous on; 
                AdvRouterAddr on; 
        }; 
};

“int” ist wiederum das Interface, welches das geroutete Prefix bekommen hat und irgendwie im LAN ist. Wenn an den angeschlossenen Geräten IPv6-Autokonfiguration aktiviert ist, sollten alle glücklich sein 🙂

Nachteile

Mit SLAAC (also Autokonfiguration) und NetworkManager kann zumindest im GUI keine statischen IPv6-Adressen vergeben, da hilft nur IPv4, aber das kriege ich auch noch geregelt 🙂

Hadante Routing

Well, that took quite some doing. Turns out that KabelDeutschland/Vodafone is the least worse provider for VPN-Connections. Routed via Telekom the RDP-Connections are flaky at best.

By default, everything is routed via ppp0/tkom, set up in /etc/ppp/ip-up.d/tkom-up.sh, except for valhalla and the VPN-Server@Work:

/usr/bin/ip rule add to <valhalla>/32 lookup kd
/usr/bin/ip rule add to <work>/32 lookup kd

DO NOT flush all rules, no matter what! This will inevitably lead to “Destination Host Unreachable”, because the rules for looking up main and default are flushed, too. Took me a while to figure out 🙁

To fill the routing table kd, add this to /etc/systemd/network/ext.network:

[DHCP] 
RouteMetric=4096 
RouteTable=199

This adds the routes pushed by DHCP to table 199. RouteTable 199 is defined in /etc/iproute2/rt_tables:

# 
# reserved values 
# 
255     local 
254     main 
253     default 
0       unspec 
# 
# local 
# 
#1      inr.ruhep 
200 tkom 
199 kd

Together with the rules above everything to valhalla and work is now routed via KD.