Telekom VDSL2 100/40

Bestellung und Auslieferung

Am 27.04.2016 habe ich via Internet Magenta Zuhause L bestellt (100/40 Mbit). Als Neukunde hat man sich geradezu rührend um mich gekümmert. Am 09.05.2016 wurde ich angerufen, um die Details der Installation abzuklären. War ganz gut so, denn aus den zahlreichen E-Mails habe ich nicht erkennen können, ob ein Techniker kommen muss oder nicht.

Es musste ein Techniker kommen. Das Zeitfenster war grandios: zwischen 8 und 16 Uhr. Allerdings hat er angerufen, bevor er losgefahren ist und angekündigt, dass er in 20 bis 30 Minuten vor Ort sei. So war es dann auch.

Als Erstes hat er ein Gerät an die TAE in der Wohnung angenöppelt, danach ging es in den Keller zum Hausanschluss. Dort hat er zwei Drähte rausgerupft und zwei andere aufgelegt. Wieder in der Wohnung hat der den Anschluss durchgemessen: 109Mbit/s Downstream. YEAH!

Das war Kundenservice par Exellence, muss ich sagen. Kann mich nicht beschweren!

Hartware

Da ich einen Router wollte, den man als Modem betreiben kann, habe ich den angebotenen Speedport-Trum nicht bestellt, da die Telekom den Modem-Modus aus der Firmware entfernt hat. Nach ein wenig F&E hat sich das Draytek Vigor 130 als Waffe der Wahl herausgestellt. Kostenpunkt: 103,92 € bei Amazon.

Laut Beschreibung vectoring-fähig, hat allerdings nur einen LAN-Anschluss. Egal, Karl. Hadante soll es routen 🙂

Voller Erwartung habe ich das Teil also angenöppelt und auf den Sync gewartet. Als er denn endlich da war, kam die große Enttäuschung: Lediglich 16Mbit/s, es sprach nur ADSL2+ 🙁 Also noch mehr F&E…

Dabei stellte sich heraus, dass ich eine spezielle Firmware benötige, damit das Teil VDSL spricht. Die bekommt man hier: Vigor130_v3.7.9_modem7.zip ist das Archiv der Wahl. Das ist die Version für G.Vectoring. Nach dem Firmware-Update hatte ich endlich die erwarteten 100/40 Mbit, Juchuu!

Modem-Betrieb

Um das Teil als Modem zu betreiben, muss man folgende Einstellungen vornehmen:

Internet Access -> General Setup
DSL Mode: Auto
VLAN Tag insertion (ADSL): Disable
VLAN Tag insertion (VDSL2): Enable
 Tag value: 7
 Priority: 0

PPPoE läuft auf VLAN 7, VLAN 8 ist IPTV, AFAIK. Abspeichern + Reboot des Modems. Dann:

Internet Access -> MPoA / Static or dynamic IP
MPoA (RFC1483/2684): Enable
Bridge Mode: "Enable Bridge Mode"

Abspeichern und obligatorischer Reboot des Modems. Danach darf man den “Roaring Penguin” bemühen.

Linux-Setup

Ich habe mir eine 1Gbit/s NIC von Intel gekauft: Die Intel EXPI9301CTBLK PRO1000 (Kernel Module e1000e). Die ist direkt mit dem Modem verbämselt. Wenn man den Benutzernamen unfallfrei zusammen klöppelt, ist der Rest ziemlich schmerzfrei. Der Benutzername lautet: <Anschlusskennung><Zugangsnummer>#0001@t-online.de. Die Daten stehen in den Einrichtungsunterlagen. Also:

# pppoe-setup

und die Daten eingeben. Danach

# pppoe-start

um zu testen, ob es funxioniert. Wenn ja, kann man den Service adsl aktivieren:

# pppoe-stop
# systemctl enable adsl
# systemctl start adsl

Um auch Pakete zu routen, muss die MTU für TCP komischerweise auf maximal 1382 festgetackert werden:

# iptables -t mangle -A POSTROUTING -o ppp0 -p tcp -m tcp \
--tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1382

Habe erstmal fertig. Das Policy Routing ist leider schwieriger als gedacht, und IPv6 mit wechselnden Prefixen ist mehr oder weniger nutzlos 🙁

IPv6 configuration Hetzner

(obsolete, superseded by https://tollana.d-tor.org/notes-to-self/?p=585)

Well, another issue I just noticed after the recent reboot of valhalla. When bridging, do never, ever use IPv6 autoconfiguration on the actual ethernet interface or the bridge itself. That will totally screw up the routing!

Disable it by adding the following lines somewhere in /etc/sysctl.d:

net.ipv6.conf.wan.use_tempaddr = 0 
net.ipv6.conf.wan.autoconf = 0 
net.ipv6.conf.br0.use_tempaddr = 0 
net.ipv6.conf.br0.autoconf = 0

You can change it directly by echoing the values to the respective proc files. Unfortunately, the changes only take effect after shutting down and taking the interface up again. So be really, really careful! Be warned: The interface won’t have an IPv6 address any more, so make sure that you have IPv4 connectivity!

You can do this with e.g. screen:

# screen
# ip link set down wan ; sleep 1; ip link set up wan

 

Archlinux and Networkmanager

NetworkManager is a nice piece of software, congrats to the developers! But there are several catches on Arch Linux:

  1. Disable systemd-networkd
  2. Disable systemd-resolvd
  3. The most important one: Remove the package openresolv! If you don’t, you may end up  with an empty /etc/resolv.conf! It will be there for one or two seconds, but then the openresolv-scripts will remove it and in the best case link it to some non-existing file in /run

OpenVPN and IPv6-Bridging

Nothing is as easy as it seems. Sigh… 🙁

I was getting strange timeouts when accessing sites via tunneled IPv6 (OpenVPN). Turned out that the sender never got the ICMPv6-Redirect from the tunnel endpoint, i.e. OpenVPN-Server. The ICMPv6-Packet is sent from the link-local address of the gateway (fe80::some:thin:g/64), because it gets dropped in the FORWARD-Chain of the gateway if the policy is DROP.

Setting it to ACCEPT magically makes things work, but that’s equal to turning off the firewall. Allowing traffic from and to fe80::/8 doesn’t help, either. Never figured out why.

What now? The physdev-module comes to rescue! Despite its name it can match the (virtual) tap-interface of the OpenVPN-Server. Just add the following rules to the beginning of the FORWARD-Chain:

ip6tables -I FORWARD -m physdev --physdev-out tap0 -j ACCEPT
ip6tables -I FORWARD -m physdev --physdev-in tap0 -j ACCEPT

and things run smoothly again 🙂