Posts Tagged ‘Fiber7’

Sonntag, 3. Juni 2018

Init7 TV7: Offizielle TV7-App für Apple TV

Da ich heute Fiber7s TV7 auf einem Apple TV installieren durfte, auf welchem eine schweizerische Apple ID konfiguriert ist, weiss ich nun endlich, wie die App wirklich heisst:

image-7919

image-7920

Wieso ich das hier poste? Auf unserem Apple TV hier zu Hause habe ich die App nicht gefunden, weil unser Apple TV mit einer — man verzeihe es uns — us-amerikanischen Apple ID konfiguriert ist und wir somit nur den us-amerikanischen App Store durchsuchen können.

Auf Init7/Fiber7s Homepage wird die App zwar mehrere Male erwähnt, hingegen aber nicht, wie sie offiziell heisst. Auch wird nirgends erwähnt, dass sie nur aus dem schweizerischen App Store heruntergeladen werden kann. Letzteren Entscheid würde ich überdenken, da der Anteil an eingewanderten, hochqualifizierten Fiber7-Nutzern sehr hoch sein sollte — und die mögen es in der Regel nicht, eine zweite Apple ID für ihr Leben in der Schweiz zu lösen.

Schick wäre übrigens auch, wenn TV7 analog zu Salt beim erstmaligen Einrichten eines Apple TV 4 oder 4K einen eigenen Bildschirm zur Konfiguration erhielte.

Tags: , , , , , , , ,
Labels: Apple, IT, Leben, Medien, Schweiz

4 Kommentare | neuen Kommentar verfassen

Donnerstag, 31. Mai 2018

Init7 TV7: Installation mit einem Ubiquiti Edgerouter X SFP

(Folgeartikel zum Artikel Init7 TV7: Installation mit einem Turris Omnia-Router)

An einem Zweitstandort betreibe ich einen Ubiquiti Edgerouter X SFP (Firmware v1.10.0) mit einem offiziellen FlexOptix-Transceiver von Fiber7. Damit dieser Router IPTV-Multicast ins LAN weiterleitet, waren folgende Anpassungen an der Konfiguration nötig (hat mich 90 Minuten meines Lebens gekostet):

Firewall

Auf rudimentärem Deutsch: Lasse IGMP sowie Multicast UDP durch die Firewall gegen das Internet

...
firewall {
    ...
    name WAN_IN {
        ...
        rule 4 {
            action accept
            description "Allow IGMP (max)"
            log disable
            protocol igmp
        }
        rule 5 {
            action accept
            description "Allow Multicast"
            destination {
                address 224.0.0.0/4
            }
            log disable
        }
    }
    name WAN_LOCAL {
        ...
        rule 4 {
            action accept
            description "Allow IGMP"
            log disable
            protocol igmp
        }
        ...
    }
    ...
}
...

IGMP Proxy

Auf rudimentärem Deutsch: Empfange IGMP-Traffic aus dem Internet und leite ihn in das LAN weiter.

...
protocols {
    igmp-proxy {
        interface switch0 {
            alt-subnet 0.0.0.0/0
            role downstream
            threshold 1
        }
        interface eth5 {
            alt-subnet 0.0.0.0/0
            role upstream
            threshold 1
        }
    }
    ...
}

Multicast-Status abfragen

Um zu überprüfen, ob Multicast grundsätzlich funktioniert, loggt man sich per SSH auf den Router ein und gibt im CLI folgende Befehle ein:

$ show ip multicast interfaces 
Intf             BytesIn        PktsIn      BytesOut       PktsOut            Local
switch0            0.00b             0       31.17MB         24316        Y.Y.Y.1
eth5             31.17MB         24316         0.00b             0   X.X.X.X
$ show ip multicast mfc
Group           Origin           In          Out                Pkts         Bytes  Wrong
239.254.127.63  Y.Y.Y.5        eth5        switch0               1       116.00b      1
239.255.255.250 Y.Y.Y.50       eth5        switch0              56       17.61KB     56
239.77.3.21     77.109.129.16    eth5        switch0           37379       47.91MB      0

Die letzte Zeile war das Resultat, dass ich probehalber Dracula Untold auf Film 4 geschaut habe …

Nachtrag 1: Stream friert ein

Nach der Installation der TV7-App auf dem Apple TV (eigener Blog-Artikel zur App) musste ich entdecken, dass das Bild eines TV-Senders jeweils nach etwas mehr als 3 Minuten einfror (ich tippte nach mehreren Messungen auf ein Timeout von 200 Sekunden — und somit ein strukturelles Problem).

Recht schnell realisierte ich nach etwas Googlen, dass die Firewall-Regel 4 unter WLAN_LOCAL zwingend auch aktiviert werden muss. Diese hatte ich ursprünglich als überflüssig erachtet. Mein Fehler.

Meine Vermutung als IPTV-Laie: Diese (zusätzliche) Regel erlaubt ausgehende IGMP-Pakete. Wenn diese nicht an TV7 gesendet werden können (Heartbeat?), stellt TV7 den Multicast wieder ein. Sobald die Firewall-Rule aktiviert wurde, entfror sich das Bild und die Sendung lief weiter.

Nachtrag 2: Multicast flutet das Netzwerk

Obwohl die Streams nun auf dem Apple TV mit der offiziellen App problemlos laufen, habe ich einen schwerwiegenden Nachteil entdeckt, welcher bei meinem Turris Omnia nicht auftritt: Schaut man mit dem Apple TV einen TV7-Stream, wird das ganze LAN mit Multicast-Paketen geflutet. Dies beeinflusst meinen UniFi Access Point besonders, konnte ich doch einen spürbaren Lag zwischen Tastendruck und Anzeige des Buchstabens auf dem Bildschirm feststellen, wenn ich von meinem MacBook per WLAN per SSH auf einem Laptop im LAN verbunden war.

In meiner derzeitigen Konfiguration sendet der Edgerouter den eingehenden Multicast-Traffic an alle LAN-Interfaces weiter, die am switch0 hängen. Leider habe ich bis jetzt noch keine Lösung gefunden, wie man das auf einzelne Ports einschränken kann (ich brauche eigentlich nur den Apple TV- sowie den Laptop-Port, auf welchem udpxy läuft) respektive wie man IGMP-Snooping aktivieren kann, damit der Edgerouter selber realisiert, welches Gerät/welche Geräte im Netzwerk aktuell gerade Multicast-Streams abspielen möchte.

image-7912

Links

Tags: , , , , , , , , , , ,
Labels: IT, Linux, Medien, Schweiz

Keine Kommentare | neuen Kommentar verfassen

Mittwoch, 23. Mai 2018

Init7 TV7: Installation mit einem Turris Omnia-Router

Gestern liessen Fredy Künzler und seine Init7 die Überraschungsbombe platzen: Ab sofort gibt es TV7, das IPTV-Angebot des ISPs, für alle Fiber7-Kunden kostenlos zum spotgünstigen, symmetrischen 1 Gbit/s Internetabo hinzu:

Medienmitteilung vom 22. Mai 2018

Das bedeutet, dass ich nun über eine 1 GBit/s-Leitung feinste, unkomprimierte HD-Streams aller hierzulande gängigen und einiger eher exotischer Sender empfangen kann — derzeit 215 an der Zahl.

Wieso gerade jetzt? Aus meiner Sicht aus zwei Gründen: Erstens steht die Fussball-WM 2018 vor der Tür, wo man mit einem unkomprimierten Multicast-Stream die Überlegenheit über die Konkurrenz demonstrieren kann (fünf Sekunden vor dem Nachbarn das entscheidende Goal im Final sehen? Check.). Andererseits, weil Salt kürzlich mit seinem (geschwindigkeitstechnisch fragwürdigen) Fiber-Angebot Furore in den Medien gemacht hat, und dort auch IPTV draufpackt (inkl. schicker Integration in iOS).

Installation

Am Abend zog ich zu Hause die Bastelhandschuhe an und machte mich daran, die von TV7 ausgesendeten UDP Multicast-Streams über meinen Router ins interne Netzwerk zu transportieren.

Dank der vom ISP netterweise verfassten Anleitung für den Fiber7-Router meiner Wahl, den Turris Omnia, war das ein Klacks:

Anleitung Fiber7 TV7

Kurz zusammengefasst:

  1. In LuCI einloggen und unter System > Software das Softwarepaket igmpproxy installieren. Hierzu musste ich zuerst einmalig Update lists anklicken, und danach in das Suchfeld Filter den Namen des Pakets eingeben. Noch Find Package klicken und dann in der linken Spalte den Link Install anwählen.
  2. Per SSH auf die Kommandozeile des Routers einloggen und die Konfigurationsdatei unter /etc/config/igmpproxy anpassen (s. unten). Daraus wird dann /var/etc/igmpproxy.conf generiert
  3. In LuCI unter System > Startup igmpproxy auf enabled schalten und einmal start (resp. bei mehrmaligen Versuchen restart) drücken
  4. Per SSH auf der Kommandozeile des Routers mittels ps | grep -i igmp überprüfen, dass der Prozess läuft:
     6728 root       804 S    /usr/sbin/igmpproxy /var/etc/igmpproxy.conf

/etc/config/igmpproxy

config igmpproxy
	option quickleave 1

config phyint wan
	option network wan
	option direction upstream
	list altnet 0.0.0.0/0

config phyint lan
	option network lan
	option direction downstream

Init7 empfiehlt einen Reboot, welchen ich schlussendlich doch noch durchgeführt habe, aber nur, weil etwas mit dem Test-Stream (s. unten) nicht funktioniert hat. Ich kann mir vorstellen, dass der Router Multicast auch ohne Reboot hinkriegt, lasse mir aber gerne das Gegenteil bestätigen.

Test

Um möglichst viele potentiell störenden Parameter auszuschliessen, schloss ich mein MacBook 12″ mittels eines USB-C-auf-Ethernet-Adapters direkt an einen Ethernet-Port des Routers an. So schliesse ich aus, dass Switches zwischen dem Endgerät und dem Router Multicast vermüeseln (mein 8-Port UniFi- und mein 16-Port TP-LINK Gigabit-Switch funktionieren tadellos, ohne irgendwelche Konfiguration).

Anschliessend wollte ich den Empfang mit dem im FAQ-Artikel „Kann ich vorab testen, ob mein Router TV7 (Multicast) unterstützt?“ verlinkten Stream auf den Big Buck Bunny (Bedeutung) testen. Doch leider kriege ich diesen Stream bis heute nicht zu laufen — weshalb ich gestern zuerst auf ein Konfigurationsproblem tippte und deshalb den Router doch noch einem Kaltstart unterzog (ich bin mir fast sicher, dass das nicht nötig gewesen wäre).

image-7881

Nachdem ich mir sicher war, dass igmpproxy sauber läuft, entschloss ich mich schlussendlich, einfach die im FAQ-Artikel „Kann ich TV7 auch auf anderen Geräten als Apple TV anschauen?“ erwähnte M3U-Datei herunterzuladen und in VLC 3.0.2 zu öffnen. Und siehe da: Wenige Sekunden später, nach nicht einmal 30 Minuten Installationsdauer, sah ich die Tagesschau gestochen scharf in höchster Auflösung auf dem Retina-Display meines MacBooks entgegenflimmern:

image-7882

Tags: , , , , , , , , , , , ,
Labels: IT, Linux, Medien

1 Kommentar | neuen Kommentar verfassen

Samstag, 24. März 2018

iphone-blog.ch und die Ankündigung von Salts 10 GBit/s Glasfaser-Angebot

Das Schweizerische iPhone-Blog habe ich eigentlich nur abonniert, um rechtzeitig auf die gelegentlich stattfindenden Rabattaktionen für iTunes-Gutscheine aufmerksam zu werden.

Bei der Lancierung des Salt „10 GBit/s“ Glasfaser-Angebots in dieser Woche stiess mir der Artikel „Salt steigt mit revolutionärer Fiber Box in Schweizer Festnetzmarkt ein – inkl. Apple TV App“ auf dem iPhone-Blog sauer auf: Zu viel Marketing-Blabla und zu viele fragliche Adjektive („revolutionärer“, „ultraschneller“, „weltweit erstes Angebot“, „totale Weltneuheit“). Wieso schreiben Drittparteien, als wären sie direkt von Salt angestellt?

Eine kurze Google-Suche zeigte, dass die Autoren des Blogs schlicht und ergreifend einfach zwei der drei Medienmitteilungen des Anbieters in das Blog kopiert hatten (man nehme jeweils den ersten Satz des ersten resp. sechsten Paragraphen und füge den Text in das Google-Suchformular ein – tada):

Unkritisch wiedergegeben, nichts hinterfragend — dann kann man es auch gleich sein lassen mit Bloggen.

Insbesondere, weil ja bereits kurz nach der Ankündigung die ersten Stimmen laut wurden, welche diese ominösen „10 GBit/s“ in Frage stellten — gemäss Fredy Künzler, dem Inhaber von Init7, teile man bei der von Salt einzusetzenden GPON-Topologie diese Bandbreite mit 31 oder gar 63 Kunden. Rein mathematisch ergibt das dann doch nur noch Bandbreiten von 312.50 MBit/s resp. 156.25 MBit/s pro Dose.

Mein bissiger Kommentar wurde vom Blog jedenfalls nicht freigegeben:

image-7832

PS: Ich bin Fiber7-Kunde und finde Init7 persönlich einen tollen ISP, bin aber auf keinster Weise wirtschaftlich mit dem Unternehmen verbandelt.

Tags: , , , , , , ,
Labels: Schweiz

Keine Kommentare | neuen Kommentar verfassen

Donnerstag, 22. März 2018

Wo unterhält Fiber7 in Bern POPs?

Auch hier ist Init7 sehr transparent:

Unsere Fiber7 PoPs

In Bern sind dies aktuell (März 2017):

image-7790

  • 640BOL – Bollwerk
  • 640BRE – Breitenrain
  • 640BUE – Bümpliz
  • 640BUZ – Burgernziel
  • 640BEM – Mattenhof
  • 640KOE – Köniz
  • 640LAG – Länggasse
  • 640WAB – Wabern
  • 640WEH – Weissenbühl

Der POP 640NIE (Niederwangen) ist noch ausgegraut.

Tags: , , , , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Dienstag, 11. Oktober 2016

Turris Omnia: Erste Erfahrungen

Am Freitag, 7. Oktober 2016, wurde mir mein über Indiegogo ge-crowdfundeter Turris Omnia-Router ins Büro geliefert.

Am Sonntag-Abend ging ich mit dem Gerät online. Zeit für ein erstes Fazit:

Fiber7 SFP funktioniert (noch) nicht

Der Router wird mit einem SFP-Slot ausgeliefert. Optimal, dachte ich mir, so kann ich meinen Gerätedschungel lichten und den im Januar gekauften Fiber Media Converter TP-LINK MC220L auf’s Altenteil schicken.

Zu früh gefreut! Wie von mir im offiziellen Forum beschrieben und von Michael Stapelberg bestätigt funktioniert der flexOptix BIDI LX SFP Transceiver aktuell nicht im Router.

Zuerst ging ich (fälschlicherweise) davon aus, dass das Problem bei Turris zu suchen ist, doch ein Tweet von Fiber7 von heute Dienstag, 11. Oktober 2016, legt nahe, dass auf Seite ISP resp. auf Seiten des SFP-Herstellers noch etwas geändert werden muss:

Performance

Eigentlich hätte ich erwartet, dass der neue Router näher an die Schallgrenze (d.h. 1 GBit/s Down- und Upstream) herankommt. Doch mein stündlich laufendes Script, welches die Geschwindigkeit zu Init7s Ookla Geschwindigkeitsserver (Ookla Server ID 3026) misst, sagt etwas anderes aus:

ookla-init7-asus-rt-ac66u-turris-omnia
image-6997

Links sieht man die Werte, die ich mit einem Asus RT-AC66U (Merlin-Firmware und mit deaktivierter Firewall) erzielt habe; rechts (nach dem Unterbruch) die Werte von Turris Omnia (mit aktivierter Firewall).

Beim Client handelt es sich um einen Intel NUC DC3217IYE, welcher mit einem Cat 5e-Kabel über einen 16-Port TP-LINK TL-SG1016D über ein 20m Cat 6 STP-Flachband-Kabel auf einen ZyXEL GS1100-8HP PoE Switch via ein Cat 5e-Kabel am Turris angeschlossen ist.

Ich gehe davon aus, dass die Performance höher wäre, wenn ich einen nicht so schmalbrüstigen Client verwenden würde. Und ja, die Firewall des Turris könnte ich ja eigentlich der Performance wegen auch deaktivieren. Doch mich reizt es, die Crowd-Firewall eingeschaltet zu belassen, um mich und mein Netzwerk besser vor Gefahren aus dem Internet zu schützen.

Doch das spielt hier keine Rolle, weil im Setup einzig der Router selber ausgewechselt wurde, der Rest blieb gleich.

Michael hingegen kommt der Schallmauer gefährlich nahe — 927 MBit/s:

Führe ich speedtest-cli (ein Python-Script) direkt auf dem Turris Omnia aus, erhalte ich folgende Werte:

# ./speedtest-cli --simple --server 3026
Ping: 4.704 ms
Download: 684.35 Mbit/s
Upload: 208.04 Mbit/s

CPU-Auslastung

Dank der Aufzeichnung der Vitalparameter des Routers mittels Cacti musste ich soeben feststellen, dass die beiden CPUs des Gerätes seit heute Mitternacht (sprich seit meinem zweiten, fehlgeschlagenen Test mit dem SFP-Transceiver) 100% beträgt. Auf beiden Cores:

turris-omnia-cpu-0-usage
image-6998

turris-omnia-cpu-1-usage
image-6999

Ein Login auf dem Router und htop zeigen, welche Prozesse die Last verursachen:

turris-omnia-socat-cpu-usage
image-7000

Die Prozesse habe ich direkt in htop mittels F9 und SIGKILL abgeschossen (ein Neustart von socat im LuCI-Interface unter System > Software hat nichts gebracht). Jetzt ist die CPU-Auslastung im einstelligen Prozentbereich und die Load Average bereits bei 0.40.

LEDs

Natürlich dürfen frei konfigurierbare LED-Farben nicht den Ausschlag geben, ein Produkt zu kaufen. Dennoch möchte ich dies nicht mehr missen. Nun sehe ich nämlich von der Eingangstüre unserer Wohnung aus, ob der Router läuft (grünes LED für Power) und ob er mit dem Internet verbunden ist (rotes LED für WAN). Hinzu kommen weiss blinkende LEDs, die mir zeigen, dass im LAN Pakete herumgeschickt werden.

turris-omnia-leds
image-7001

IPv6

Das Ding würde auch IPv6 unterstützen, doch mental, fähigkeitstechnisch und auf Grund meiner leicht komplexeren Netzwerk-Infrastruktur im LAN sehe ich mich derzeit nicht imstande, diesen Schritt bereits zu wagen. Gut zu wissen, dass Turris auf jeden Fall bereit wäre:

Usability

Verwirrend (und unschön) ist es, dass der Router über zwei Web-Oberflächen verfügt: Einerseits das von Turris Omnia selbst entwickelte Foris, welches einen Wizard, aber kaum Einstellungsmöglichkeiten bietet, andererseits das OpenWRT-LuCI-Interface, über welches man jedes hinterste Bit des Routers konfigurieren kann (oder so).

Das letztere Interface kannte ich so bereits von meinem TP-LINK TL-MR3020 Travel-Router, der mich auf Reisen überall hin begleitet. Ganz interessant ist hier der Paket-Manager des Turris, obwohl ich abgesehen von snmpd und ethtool noch kein Paket installiert habe. Die Bedienbarkeit dieses Interfaces ist aber nicht so simpel gehalten wie bei einem Consumer-Router und benötigt deshalb eine gewisse Einarbeitungszeit.

Nachtrag: Unboxing-Photos

Turris vom Flickr-Benutzer Doommeer

Tags: , , , , , , , , , , , , , , , , , ,
Labels: IT

4 Kommentare | neuen Kommentar verfassen

Sonntag, 20. März 2016

Ookla Speedtest für Fiber7 respektive Init7 konfigurieren

Damit der Ookla Speedtest bei mir sauber funktioniert, habe ich mir ein Benutzerkonto angelegt und folgende Einstellungen gemacht:

Ookla Speedtest Fiber7 Settings
image-6587

Von grösster Wichtigkeit ist es, folgenden Server als Standardserver auszuwählen:

Winterthur [CH] - Init 7

(Gemäss dem HTML-Quellcode handelt es sich um den Server mit der Ookla-ID 3026)

Nur so testet man die theoretisch verfügbare Geschwindigkeit zwischen dem eigenen Router, der Telefonzentrale, in welche das Fiber- respektive das Kupferkabel führt, und dem ISP-internen Netzwerk.

Auf der Test-Oberfläche ist dann der Button „BEGIN TEST. YOUR PREFERRED SERVER“ zu wählen:

Ookla Speedtest Begin Test Preferred Server
image-6588

Nachtrag

Noch einfacher geht es für uns Linux-Geeks von der Kommandozeile. Ein findiger Zeitgenosse scheint das Ookla Speedtest-Protokoll reverse engineered und seine Erkenntnisse in einem Python-Script zusammengefasst zu haben.

Nachdem man das Script heruntergeladen und ausführbar gemacht hat, misst man die Geschwindigkeit zum Init7/Fiber7-Speedtest-Server folgendermassen:

$ ./speedtest-cli --server 3026
Retrieving speedtest.net configuration...
Retrieving speedtest.net server list...
Testing from Init7 (Switzerland) Ltd. (85.195.234.162)...
Hosted by Init 7 (Winterthur) [117.24 km]: 3.615 ms
Testing download speed........................................
Download: 584.35 Mbit/s
Testing upload speed..................................................
Upload: 498.04 Mbit/s

Tags: , , , , , , , , , , , , , , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 20. März 2016

Gigabit FTTH mit Asus RT-AC66U? Hände weg von DD-WRT!

Ende Januar 2016 wurde unsere Wohnung mit Fiber to the Home (FTTH) von Fiber7 (einer Tochter von Init7) erschlossen. Das konkurrenzlos günstige Angebot umfasst eine symmetrische 1 Gbit/s-Anbindung für weniger als 65 CHF pro Monat.

Die Verbindung zum Internet stelle ich mit einem Asus RT-AC66U und dem optischen Wandler TP-Link MC220L her. Auf dem Asus RT-AC66U lief bis letzte Woche DD-WRT mit dem Release r26332 vom 22. Februar 2015.

Von Powerline zu Ethernet-Kabel

Da ich mich beim Besuch der Elektriker von BKW ISP AG dazu entschied, den OTO im Wohnzimmer installieren zu lassen (die Alternative wäre das Büro gewesen), stellte sich mir das Problem, dass ich bis vor kurzem die maximale ISP-Geschwindigkeit nicht testen konnte: In der Stube betreibe ich einige Multimedia-Geräte wie den TV, den Apple TV sowie einen UniFi AP-PRO. Nur der UniFi WLAN-Access Point verfügt über einen Gigabit-Ethernet-Port — doch mit dem Access Point lässt sich die maximale Performance des Internetanschlusses nur schlecht testen.

Ein Geschwindigkeitstest mit der von Fiber7 empfohlenen Apple TV-App Ookla Speedtest zeigte Durchsätze von annähernd 100 MBit/s — sowohl für den Up- wie auch Downstream. Durchaus realistisch, wenn man bedenkt, dass der Apple TV nur mit einer Fast Ethernet-Schnittstelle ausgestattet ist.

Erst als ich von Digitec das lange vergriffene Wirewin Netzwerkkabel (25m, Weiss, STP, Kat. 6, Flachband) Kabel geliefert bekam, konnte ich das Büro direkt mit einem Cat 6-Netzwerkkabel erschliessen. Ich schaffte es, das Kabel der Fussleiste entlang und unter zwei Türleisten hindurch zu verlegen und so die zwei Gigabit-Switches TP-LINK SG1016D (Büro) und ZyXEL GS1100-8HP (Stube, mit PoE) miteinander zu verbinden.

In der Zwischenzeit verwendete ich ein Powerline-Produkt namens Devolo dLAN 500 duo+, um Stube und Büro über die Stromverkabelung zu verbinden. Der Frevel an der Sache: Ganze 50 MBit/s brachte ich so über die Leitung.

Erster Speedtest

Nun also waren der Mac mini und der iMac mit Gigabit-Ethernet an den Internet-Router angebunden. Voller Spannung startete ich den ersten von Init7 gehosteten Ookla Speedtest vom Mac mini aus — und erhielt mehrmals in der Folge folgende Messwerte zu Gesicht:

Ookla Speedtest Fiber7 DD-WRT
image-6583

Was zum Teufel? Verkauft mir Fiber7 vielleicht nur ein Zehntel des angepriesenen Durchsatzes?

Netzwerkkabel testen

Um das Problem einzugrenzen, teste ich als erstes das soeben verlegte Netzwerkkabel: Auf dem Mac mini startete ich iperf im Server-Modus:

$ iperf -s

Dann ging ich ins Wohnzimmer und verband einen Toshiba-Laptop mit integriertem Gigabit-Port an den Switch im TV-Schrank und lud mir iperf in der Version 2.0.5-3 auf den Rechner. Ich öffnete eine Kommandozeile und führte folgenden Befehl aus:

$ iperf -c 10.1.2.3

Der Mac mini zeigte darauf folgende Durchsätze an:

------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 128 KByte (default)
------------------------------------------------------------
[ 4] local 10.1.2.3 port 5001 connected with 10.1.2.4 port 56432
[ ID] Interval Transfer Bandwidth
[ 4] 0.0-10.0 sec 721 MBytes 604 Mbits/sec
...

Am Ethernet-Kabel von der Stube ins Büro konnte es also definitiv nicht liegen.

Direkt am Router

Ich schloss den Laptop per Kabel direkt an den Router an und führte den Oookla-Geschwindigkeitstest erneut durch: Auch hier wieder der „mickrige“ Durchsatz in der Grössenordnung von Fast Ethernet (100 Mbit/s). Lag das Problem allenfalls am Geschwindigkeitstest, bspw. am Server von Fiber7?

Ookla Geschwindigkeitstest testen

Ich machte mich auf die Suche nach einem im Internet verfügbaren iperf-Server und wurde auf der iperf-Web-Site fündig: Public iPerf3 servers. Ich wählte debit.k-net.fr, installierte auch noch iperf 3 und führte dann den Test aus:

$ iperf -c debit.k-net.fr

Auch bei dieser Aktion kam ich nicht nur annähernd in die Nähe der erwarteten 1 Gbit/s. Somit war für mich bewiesen, dass das Problem zwischen Router und dem ISP liegen musste. Doch wo genau?

DD-WRT

Langsam aber sicher wuchs in mir das Misstrauen gegenüber der Frickelware DD-WRT. Was, wenn die Open Source-Firmware die Performance des Routers einbrechen liess?

Ich informierte mich im Netz über die offizielle Firmware des Routers und durfte erfreut feststellen, dass das letzte Update kürzlich, am 28. Januar 2016, veröffentlicht worden war. Nach einer kurzen Recherche stiess ich auch auf die vom User „Merlin“ modifizierte Version der Firmware. Ich entschied mich, den Firmware-Wechsel zu wagen und zog Asuswrt-Merlin in der Version RT-AC66U_380.57_0 dem offiziellen Firmware von Asus vor.

Frühlingsputz: DHCP und VPN

Bevor ich aber das Vorhaben startete, entschied ich mich angesichts eines im April bevorstehenden Routerwechsels zwei Funktionalitäten vom Router weg auf einen Linux-Server zu verlagern: Den DHCP-Server sowie ein OpenVPN Site-to-Site-VPN zu meinem Elternhaus. Wie ich erst zu dem Zeitpunkt realisierte, gehört solche Funktionalität nicht auf einen Consumer-Router, sondern auf einen schicken, kleinen Linux-Server (Intel NUC), welcher ein „anständiges“ Linux, ausreichend Speicherplatz und Subversion-Anbindung möglich macht.

Asuswrt-Merlin

Wie in einem Artikel auf DD-WRT beschrieben, setzte ich den Router über das DD-WRT auf die Werkseinstellungen zurück. Anschliessend lud ich über das Web-Interface die Firmware (.trx) auf den Router und wartete den Transfer sowie die Installation ab. Der Router kam problemlos hoch und erschien nun mit der neuen, standardmässigen Oberfläche.

Nach einem erneuten NVRAM-Reset funktionierte auch die Konfiguration: Das NVRAM voller DD-WRT-Variablen wurde beim Rücksetzen nämlich irgendwie nicht gelöscht und überschritt plötzlich das maximal mögliche Volumen von 65 KB, weshalb die Routeroberfläche subtile Fehlfunktionen und Fehlermeldungen aufwies.

1 GBit/s!

Nachdem ich die Konfiguration des Routers abgeschlossen hatte, führte ich voller Spannung den nächsten Speedtest durch. Hatte sich der Aufwand, der mich fast das gesamte Wochenende gekostet hatte, gelohnt?

Ookla Speedtest Fiber7 Asuswrt-Merlin
image-6584

Beruhigt lehnte ich mich in den Bürosessel zurück und feierte innerlich der Beginn des nächsten Breitbandzeitalters.

Tags: , , , , , , , ,
Labels: IT

4 Kommentare | neuen Kommentar verfassen

Mittwoch, 2. März 2016

Bedeutung der LEDs eines TP-LINK MC220L

Seit Ende Januar 2016 ist unsere Wohnung mit 1 GBit/s FTTH von Fiber7 gesegnet. Ich betreibe dazu einen Asus RT-AC66U-Router mit DD-WRT an einem TP-LINK MC220L. Vereinfacht gesagt wandelt das TP-LINK-Gerät die Lichtsignale vom OTO herkommend in elektrische Ethernet-Signale um.

Bei der Aufschaltung unseres Anschlusses musste ich zwei Dinge beachten:

Einerseits spricht der TP-LINK MC220L ausschliesslich mit Gigabit-Ethernet-Anschlüssen. Zu Testzwecken wollte ich einen uralten Apple AirPort Express an den Wandler anschliessen, doch auf Grund des 100 MBit/s-Ethernet-Ports des AirPorts war kein Uplink zu finden. Zum Glück erfuhr ich recht schnell von diesem „Feature“.

Andererseits erstellte ich mir aus dem Online verfügbaren PDF-Handbuch des Wandlers folgenden Screenshot, um die LEDs zu deuten:

TP-LINK MC220L LEDs
image-6565

Die Verbindung funktioniert (bei mir), wenn die LEDs PWR, LINK FX sowie LINK TP ständig leuchten und die LED TP RX entweder ebenfalls ständig leuchtet oder zumindest blinkt.

Tags: , , , , , , , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen