Category Archives: Networking

WLAN-Probleme erkennen und beseitigen

Aus aktuellem Anlass schreibe ich hier einmal etwas zu gängigen WLAN/WiFi-Problemen — wie erkenne ich sie, und wie beseitige ich sie.

(Der aktuelle Anlass ist, dass hier bei uns im Ort endlich die lang ersehnten Aktivierungen unserer Glasfaser/FTTH-Anschlüsse von “Deutsche Glasfaser” erfolgt sind. Daher häufen sich diese Fragen bei mir und anderen Mitgliedern unserer Bürgerinitiative.)

Zunächst einmal ein bisschen Grundlagenwissen, (hoffentlich) so erklärt dass es auch Menschen verstehen können, die nicht Elektrotechnik studiert haben. ;-)

WLAN ist ein “shared medium”, ein “geteiltes (Übertragungs-) Medium”, d. h. die maximal erreichbare Geschwindigkeit wird zwischen allen Teilnehmern eines WLANs aufgeteilt. Führt also gerade eine Station im Netz einen großen Download mit hoher Geschwindigkeit durch, dann werden die anderen Stationen im Netz entsprechend ausgebremst.

WLAN kann auf zwei Frequenz”bändern” stattfinden, dem “alten” 2,4 GHz-Band und dem (relativ) neuen 5 GHz-Band. Client (also Laptop, Handy…) und Router (Access Point) müssen jeweils beide das 5 GHz-Band beherrschen, damit dieses benutzt werden kann (Stichworte sind 802.11a oder 802.11ac, bei 802.11n kann es sich sowohl um 2,4 als auch 5 GHz handeln). Als “Access Point” bezeichnet man das WLAN-Radio in einem Router, es gibt auch separate Access Points, die nur der Koppelung von drahtlosen Stationen an ein drahtgebundenes LAN dienen.

Auf Grund seiner hohen Frequenzen ist das 5 GHz-Band “kurzwelliger”, dadurch ist seine Reichweite gegenüber dem 2,4 GHz-Band begrenzt (es durchdringt nicht so leicht Decken und Wände), was durchaus gewisse Vorteile hat, doch dazu später.

Die gesamten 2,4 bzw. 5 GHz-Bänder werden in so genannte “Kanäle” aufgeteilt, damit sich mehrere Betreiber eines WLANs nicht “ins Gehege kommen” und jeweils einen eigenen Kanal zum Übertragen haben. In eng besiedelten Gegenden, z. B. in Innenstadtbereichen, aber auch durchaus hier bei uns im Neubaugebiet, kommt es oft vor, dass sich Kanäle überlappen. Dies ist unbedingt zu vermeiden, weil dies die Übertragungsrate für alle(!) beteiligten WLANs reduziert.

Um festzustellen, ob diese Situation bei sich selbst vorliegt, sollte man ein Tool wie den kostenlosen WiFiAnalyzer benutzen. Im Bereich “Channel Graph” kann man dann einen Graphen wie den Folgenden sehen:screenshot_20170105-213839-576x1024

Was sagt uns jetzt dieser Graph? Zum einen sehen wir oben in blau, dass hier das 2,4 GHz-Band betrachtet wird (man kann dort auch auf das 5 GHz-Band umschalten, um dieses zu betrachten). Unten sieht man die Kanäle im 2,4 GHz-Band, in Deutschland sind 1-13 erlaubt.

(An dieser Stelle die dringende Warnung, keine verbotenen Kanäle zu benutzen. Dies kann Störungen verursachen. Der Verursacher haftet für alle entstehenden Kosten, das kann schnell in die Tausende Euro gehen, plus eine empfindliche Geldbuße nach sich ziehen!)

Die einzelnen farbigen, mehr oder weniger “hohen” Buckel sind die Frequenzbänder, die die einzelnen WLANs belegen. Wie bereits gesagt sollten sich diese idealerweise nicht überlappen. Die “Höhe” der Buckel zeigen die Signalstärke an. Je höher der Buckel, desto stärker das Signal. Wenn das eigene WLAN von einem oder mehreren fremden WLAN(s) überlappt wird, dann ist der Einfluss umso geringer, je schwächer das oder die fremde(n) WLAN(s) ist/sind.

Idealerweise spricht man sich als Nachbarn gegenseitig ab, wer welchen Kanal belegt, damit eben nicht solche Überlappungen zu Stande kommen. Der Bereich “Access Points” in der oben empfohlenen Android-App ist hier sehr hilfreich. Wenn man sich auf der eigenen Straße bewegt, kann man an der Signalstärke relativ schnell erkennen, wo welches WLAN “zu Hause ist”.

Ein Access Point benutzt zu jedem Zeitpunkt nur einen bestimmten Kanal (bzw. mehrere Kanäle gebündelt, um den Durchsatz zu erhöhen). Viele Access Points sind ab Werk so eingestellt, dass sie sich automatisch den “besten” Kanal suchen. Ich persönlich rate dazu, den eigenen Access Point fest auf einen bestimmten Kanal einzustellen und diesen mit den Nachbarn zu koordinieren, um besagte Überlappung zu verhindern.

Eine weitere Einstellung sollte auch nach Möglichkeit modifiziert werden. Viele Access Points erlauben die Einstellung der Sendeleistung. Diese sollte möglichst konservativ gewählt werden derart, dass der Access Point die eigenen Geräte gerade noch gut erreicht, jedoch nicht viel weiter sendet. Sonst kommt eben die erwähnte Überlappung zu Stande, die man gerne vermeiden möchte. Access Points, die so eine Überlappung feststellen, können dann durchaus ihre Sendeleistung (in vorgegebenem Rahmen) erhöhen, um den anderen zu “übertönen”. Dies geschieht, damit wieder ein gewisser “Signal-Rauschabstand” gewährleistet ist, um das (eigene) Signal vom “Rauschen” (dem Fremdsignal) sauber trennen zu können.

Um Überlappungen zu reduzieren oder zu vermeiden kann man auch die Kanalbreite reduzieren. In dem obigen Screenshot sieht man hauptsächlich WLANs, die eine Kanalbreite von 20 MHz benutzen. Wie bereits kurz erwähnt kann man die Kanalbreite erhöhen, um einen größeren Durchsatz zu erzielen. Das rote WLAN im obigen Diagramm benutzt eine Kanalbreite von 40 MHz. Dadurch kommen entsprechend viele Überlappungen zu Stande.

Reduziert man die Kanalbreite, so vermeidet man ggf. eine Überlappung vollständig oder reduziert zumindest die Anzahl der überlappenden Netze. Obwohl dadurch die (unter Idealbedingungen) maximal erzielbare Kanalbreite reduziert wird, wird man wahrscheinlich in der Praxis feststellen, dass der Betrieb nun wesentlich stabiler ist und die Transferraten womöglich höher sind als vorher!

Alternativ, und das ist meine dringendste Empfehlung, kann man auf das 5 GHz-Band ausweichen. Wenn alle eigenen Geräte dieses unterstützen, dann empfehle ich, das 2.4 GHz-Band komplett abzuschalten. Dies kommt auch einem Bluetooth-Betrieb zu Gute, der auf einem ähnlichen Frequenzbereich stattfindet. Das 5 GHz-Band bietet deutlich höhere Transferraten und den zusätzlichen Vorteil, dass es nicht so “überlaufen” ist wie das 2,4 GHz-Band. Dies ist zum einen der geringeren Verbreitung geschuldet, zum anderen aber auch der deutlich geringeren Durchdringung und damit Reichweite der 5 GHz-Wellen.

Hier noch einmal ein Screenshot von meiner eigenen Situation, diesmal im 5 GHz-Band:

screenshot_20170105-223020Man sieht, dass bei mir überhaupt nur zwei Netze im 5 GHz-Band sichtbar sind. Mein eigenes (welches man an Hand der Signalstärke sehr einfach identifizieren kann) und ein fremdes. Der Signal-Rauschabstand zwischen diesen beiden Netzen ist jedoch so groß, dass das Fremdnetz quasi nicht stört. Ich erreiche hier Transferraten von mehr als 200 MBit/s in beide Richtungen (beim Senden und beim Empfangen) mit Stationen, die das unterstützen.

So, das soll es gewesen sein. Ich hoffe, dieser Blog-Post nutzt dem einen oder dem anderen. Ich würde mich in diesem Fall über einen Kommentar hier in meinem Blog sehr freuen. Fragen werde ich gerne beantworten. Sollte ich etwas vergessen haben, werde ich den Post noch entsprechend ergänzen.

Viel Erfolg beim Optimieren Eurer WLANs!

DrayTek Vigor130: Warnung vor “ALL”-Firmware

Aus eigener Erfahrung kann ich nur dringend vor der Installation der “ALL”-Firmware-Varianten beim DrayTek Vigor130 warnen, insbesondere wenn zwischen der installierten Version und der zu installierenden Version einige Builds liegen.

Die “ALL”-Variante behält die aktuellen Einstellungen bei, die “RST”-Variante setzt das Modem/den Router auf die Werkseinstellungen zurück. Das klingt schlimmer als es ist, denn wenn man vorher die Einstellungen über das Web-Interface herunter lädt/sichert, kann man diese nach erfolgreichem Upgrade wieder hoch laden/restaurieren.

Wie auch immer, ich hatte Version 3.7.8.3_m7 installiert und wollte auf 3.7.9.3_m7 upgraden, und zwar unter Verwendung der “ALL”-Variante. Beim Upgrade ist nichts schief gelaufen (jedenfalls nicht offensichtlich), trotzdem erhielt ich hinterher folgende Popup-Warnung im Browser:

screen-shot-2016-11-10-at-09-02-12Ich versuchte dann die selbe Firmwareversion erneut zu installieren, aber die Fehlermeldung erschien wieder. Außerdem wurde unten in der linken “Menüleiste” folgende Meldung angezeigt:

screen-shot-2016-11-10-at-10-54-23Ich versuchte also, die “RST”-(Reset)-Variante zu flashen — mit dem selben (Miss-) Erfolg. :-(

Bei einem Telefonat mit der wie immer sehr freundlichen und kompetenten DrayTek-Hotline wurde mir dann empfohlen, die TFTP-Notfall-Wiederherstellung zu nutzen, was ich dann auch tat.

Dazu muss man zunächst das Modem direkt per Netzwerkkabel mit einem Windows-PC/Laptop verbinden, welchen man manuell/statisch auf die IP-Adresse 192.168.1.2 setzt. Dann das Modem ausschalten,  den Resetknopf an der Rückseite mit einem Kuli gedrückt halten, und dann das Modem wieder einschalten. Den Resetknopf für ca. fünf Sekunden gedrückt halten, dann startet der TFTP-Server im Modem.

Nun mit dem Firmware-Update-Tool, welches man bei DrayTek herunter laden kann, die Firmwaredatei an das Modem (unter der default-Adresse 192.168.1.1) schicken. Das ganze sollte übrigens auch mit einem Linux- oder macOS-Rechner funktionieren, es reicht ein normaler TFTP-Client.

Fertig!

Nach dem Reboot dann noch über das Webinterface die Konfiguration wieder restaurieren, und alles ist wieder gut.

Der ganze Vorgang hat insgesamt nur etwa zehn Minuten gedauert.

Update U-Boot on TP-Link TL-WDR4300

A couple of days ago while I was working from home my trusted TP-Link TL-WDR4300 seemed to have died suddenly (just a couple of days after the two year warranty had expired!) — at least this was the result of my initial investigations.

The symptom I had is that suddenly my internet connection seemed to be down — which was surprising enough, as since I upgraded to VDSL2 vectoring my line was rock-solid, and it normally dropped only once a month or even once every couple of months. When I tried to find out what happened I noticed that my router was inaccessible, I couldn’t even ping it. I thought it had crashed, so I power-cycled it to reboot it, but it didn’t come up…

So my conclusion was that it had died.

I quickly reconfigured a Linksys WRT1200AC which I bought a couple of months ago as a spare device, meant to replace the current router “one day”, and put it into operation…

Today I spent some time investigating what actually happened. I wanted to use the serial console of my rev. 1.7 device (the PCB is rev. 1.3), but found that there was no connector in place for the UART, just the holes in the PCB.

dav

So I quickly soldered in the pins, and connected the router to a laptop.

sdr

To my surprise the router booted without any issue at all. I played around with it until I was sure that there was absolutely no problem — I thought the file system in the flash memory might have been corrupted, but everything was ok.

So now that I had opened the device and connected a laptop to the serial console, I thought it would be a good occasion to update the U-Boot boot loader to a modified one by “pepe2k” that adds a lot of very useful features.

I used the instructions pepe2k provided on Github, specifically the part where he describes how to install via TFTP from the serial console. The “biggest challenge” was to find where to download the actual boot loader binary. Finally I found it here.

Genexis FiberTwist-P2410 dissected

By chance I got an early hands-on on a fiber network terminator (NT)/broadband gateway (such a device will soon be installed for my FTTH line provided by “Deutsche Glasfaser.”) I don’t know how it happened, but it suddenly fell apart, so I had a brief look under the hood… :-D

IMG_0673
Genexis FiberTwist-P2410 inside view

The SoC is a Lantiq PXB 4369 EL V2.1 (GRX300), which is a Gigabit Ethernet Router/Gateway SoC with int. 2×2 WiFi. There aren’t any antennas, though, and it seems you can’t add any either. The device is from the GRX 300 series, which is a “CPE Network Processor with integrated WiFi.”

A Russian web site states that its actually the GRX369 series, and that the SoC is clocked with 600 MHz. (Update: The CPU is a MIPS 34Kc V5.6 clocked at 600 MHz, 397.82 BogoMIPS.)

The device can be simply twisted on the wall junction box which is the provider’s fiber hand-over point (“fiber management unit,” FMU.)

On the WAN side we have a Mentech FGE20-N9C-35S as the optical transceiver module (2×5 form factor) for single-mode fiber in passive optical networks (PON). Optical wavelength division multiplexing (WDM) is used so a single fiber can be used for both downstream and upstream data. The maximum data rate this transceiver can handle is 1.25 Gbit/s (which suggests we’re talking EPON, 802.3ah-2004 here…). The reach without intermediate amplification is 20 km(!). Wavelengths of 1,310 nm (upstream)/1,490 nm (downstream) are used.

For LAN connectivity the gateway has 4 Gigabit Ethernet ports, driven by two FPE LG48204DH 2-port LAN transformer modules in a DIP-48 package.

The transceiver is a Marvell 88E1512-NNp2 out of the “Alaska” series, 10/100/1000 BASE-T single-port PHY (so it seems that all fiber/Ethernet ports are on the same switch), supporting Energy Efficient Ethernet (EEE) and Advanced Virtual Cable Tester functionality.

Update: The switch seems to be a Lantiq VRX318 (or compatible).

Firmware is stored in a Elite Semiconductor (ESMT) F59L1G81LA-25T single-level serial (SPI) NAND flash chip in a TSOP48 package. It operates with 3.3V at a clock of 25 ns and has a flash density of 1 Gbit and a bus width of 8 bits. The total memory size is 128 MByte.

RAM is provided by a Winbond W971GG6SB-25 chip, which is a DDR2-800 (5-5-5) SDRAM chip with a size of 128 MByte, operating at transfer rates of 800 Mbit/s per pin with a power supply of 1.8 V. (Update: The RAM is actually clocked at 300 MHz.)

It seems that the broadband gateway is equipped with a serial-console connector.

Here’s another photo that shows where the key components are located:

Genexis FiberTwist-P2410 with key components
Genexis FiberTwist-P2410 with key components

Please let me know if this in any way helps you, or you can contribute to this post.

uhttpd with a certificate chain

To secure access to my router I wanted to use SSL encryption to access LuCi, so I obtained a certificate issued by a well-known CA. The server certificate was not issued directly off the CA, but there was a certificate chain in between.

Using a certificate chain with OpenWrt’s uhttpd is really easy, although as of today this is not yet even documented to be possible on the OpenWrt web site.

I’m using uhttpd_2015-11-08 from a trunk build (r48648) of “Designated Driver”, and certificate chains can be used here without problems.

I didn’t even have to convert from PEM to DER, I just concatenated the server cert and intermediate certs into a single file:

cat /root/server.crt /root/1_root_bundle_1.crt /root/1_root_bundle_2.crt >uhttpd.crt

Hope this helps. If it does please leave a message, thank you.

Brother MFC-7840w “Internet Fax” über DUS.net

Seit einigen Tagen habe ich einen “IP-only”-Telefonanschluss, so dass ich nicht mehr wie bisher mit meinem Brother MFC-7840w-Multifunktionsgerät über einen a/b-Terminaladapter an einem ISDN-Anschluss faxen kann.

Beim Suchen nach Alternativen stieß ich auf dieses Wiki im IP-Phone-Forum, welches mir sehr weiter geholfen hat.

Zunächst musste ich ein Firmware-Update für mein Faxgerät flashen, was die benötigte Internet-Fax-Funktionalität  (T.37-Protokoll) implementiert.

Weiterhin musste ein Anbieter gefunden werden, der dieses Protokoll unterstützt. DUS.net, welches auch im obigen Wiki erwähnt wird, war mir ohnehin schon bekannt, weil ich auf der Suche nach einem guten SIP-Provider bin. Also wollte ich gerne DUS.net als Fax-Provider nutzen, jedoch gibt es da ein prinzipielles Problem:

Um das Dus.net mail2fax Gateway anzusprechen, müssen Zugangsdaten > 50 Zeichen im Betreff-Feld übertragen werden. Die Brother-Firmware (4.0) speichert aber nur 41 Zeichen ab.

Meine Lösung sieht nun so aus: Continue reading Brother MFC-7840w “Internet Fax” über DUS.net

Monitor DrayTek Vigor 130 Line Status

I recently got myself a new DSL modem, namely a DrayTek Vigor 130, as I switched from ADSL2 to VDSL2-Vectoring, so that I couldn’t use my Allnet ALL0333CJ Rev. C any longer.

As I monitor about everything (just kidding) with Nagios, I certainly wanted to implement a check of the modem’s line status.

Here’s what I came up with:

# ARG1: community
define command{
        command_name    snmp_modem_status
        command_line    /usr/lib/nagios/plugins/check_snmp -H '$HOSTADDRESS$' -C '$ARG1$' -o SNMPv2-SMI::transmission.94.1.1.3.1.6.4 -P 2c -r "53 48 4F 57 54 49 4D 45"
        }
define host {
        host_name       dslmodem
        address         192.168.0.1
        use             generic-host-internal
        parents         gw
}

Nagios is running on my intranet server. The next hop when seen from Nagios is my Internet gateway (host “gw”, my router), and from there the next hop is the DSL modem (host “dslmodem.”)

Hope this helps someone… If it does please leave a quick message here in this blog, thanks…

Vodafone VDSL-100 mit diskretem Modem und Router

Heute war endlich “der große Tag” gekommen — mein alter Arcor/Vodafone Annex.B-Anschluss (ISDN/ADSL) sollte umgestellt werden auf IP-only in Form von Vodafone VDSL-100, d. h. VDSL2-Vectoring mit einer Geschwindigkeit von 100 MBit/s für den Downlink, 40 MBit/s für den Uplink.

Bei uns kann Vodafone diesen Anschluss noch nicht basierend auf eigener Infrastruktur anbieten, sondern muss ihn als Bitstream-Produkt von der Telekom einkaufen. Das ist mir aber egal, Hauptsache es funktioniert… ;-)

Aus verschiedenen Gründen mag ich keine “All-in-One”-Produkte, insbesondere keine von den Netzbetreibern angebotene:

  • Man muss bei “All-in-One”-Produkten in der Regel immer Kompromisse machen. Wenn ich “diskrete” Komponenten kaufe, d. h. ein separates Modem, einen Router, ein SIP-Gateway, einen Intranet-Server, dann kann ich mir genau die Geräte aussuchen, die meinen Vorstellungen am nächsten kommen.
  • Tritt ein Defekt bei einem “All-in-One”-Produkt auf, dann geht gar nichts mehr. Bei diskreten Geräten bleibt ein Teil der Funktionalität erhalten.
  • Ich bin nicht darauf angewiesen, dass mir der Netzbetreiber (insb. sicherheitsrelevante) Updates (zeitnah) zur Verfügung stellt, da ich mir die jeweiligen Updates jederzeit selbst beschaffen und installieren kann, insbesondere wenn ich auf Open Source-basierende Komponenten setze.
  • Andererseits kann mir der Netzbetreiber auch keine Einstellungen oder Updates “aufzwingen” und damit womöglich meinen Anschluss oder bestimmte Funktionalitäten lahm legen.
  • Netzbetreibergeräte sind oft in den Funktionen beschnitten. Bei Unitymedia z. B. muss man für die Aktivierung des WLANs extra bezahlen!

Daher setze ich folgende diskrete Geräte ein: Continue reading Vodafone VDSL-100 mit diskretem Modem und Router

VPN-Probleme bei CGN/NAT444?

Diesen Artikel habe ich ursprünglich für unsere “Bürgerinitiative PRO Glasfaser” geschrieben. Da das Thema von allgemeinem Interesse sein dürfte veröffentliche ich ihn in leicht abgewandelter Form auch hier auf meinem Blog.


Uns haben mehrfach besorgte Interessenten angesprochen die von angeblichen “Problemen mit VPN beim Deutsche Glasfaser-Setup” gehört hatten.

Wir haben daraufhin selbst recherchiert und keine grundsätzlichen Probleme erkennen können, die auf Grund des Designs des DG-Setups zu erwarten sind.

Es handelt sich dabei um ein NAT444-Setup: Private IPv4-Adresse im Heimnetz (LAN), private IPv4-Adresse zwischen CPE (Router) und CGN sowie öffentliche IPv4-Adresse zwischen CGN und IPv4-Internet-Host. Es handelt sich nicht um Dual Stack-lite, da keine private IPv4-Adresse im LAN über IPv6 durch das CPE zum CGN getunnelt wird!

Solange “die IPv6-Migration” nicht beendet ist — sprich: Jeder Client weltweit kann IPv6 nutzen und jeder Host bietet seine Dienste ebenfalls per IPv6 an — sind Transitions-Techniken wie NAT444 von globaler Bedeutung. Daher gibt es einen eigenen RFC zu dem Thema “Einfluss von CGN auf Netzwerk-Anwendungen”: RFC-7021. Dieser RFC gibt keinerlei Hinweise dass es ein grundsätzliches Problem mit gängigen VPN-Anwendungen (NAT444-Szenario, VPN-Client im LAN, VPN-Gateway ausschließlich erreichbar über IPv4, aufgestellt in einer DMZ) geben könnte.

Wenn man (per Google) nach NAT444 sucht stößt man an prominenter Stelle auf diese Seite (die vor mehr als 4 Jahren erstellt wurde, also mittlerweile völlig veraltet ist!). Schon nach damaligem Stand ist die Seite als “dubios” zu bezeichnen.

Nach Aussage des Autors macht NAT444 “VPN” und “SSL” kaputt oder beeinträchtigt diese zumindest. In dieser Pauschalität ist die Aussage nicht sehr fundiert. Zum einen ist VPN nicht gleich VPN, es gibt diverse unterschiedliche Verfahren, die mit Sicherheit — wenn überhaupt — nicht alle gleichermaßen betroffen sind. Zum anderen ist SSL einfach nur eine Encryption Layer, die im Prinzip auf beliebige TCP-Ströme angewendet werden kann (das Protokoll bleibt aber TCP!). Wieso dieser TCP-Strom durch NAT444 beeinträchtigt werden soll erschließt sich mir nicht. Der Autor widerspricht sich mit seiner Aussage übigens selbst da er angibt, dass “Web” und “Mail” ohne Beeinträchtigung über NAT444 funktionieren sollen. Da aber auch bei Web-Anwendungen (HTTPS) und Mail-Anwendungen (SMTPS und POP3S/IMAP4S) “SSL” zum Einsatz kommt stellt sich die Frage wie das zusammen passt…

Um die Frage abschließend zu beleuchten besuchte ich am 26.06.2015 die “Deutsche Glasfaser”, um vor Ort in Heinsberg-Dremmen die beiden verbreiteten VPN-Protokolle “IPSec” (Cisco VPN Client mit XAuth) und SSL-VPN (Cisco AnyConnect) zu testen. Erwartungsgemäß konnte ich keinerlei Probleme mit den beiden o. g. VPN-Protokollen feststellen. Siehe auch diesen Artikel für weitere Infos über meinen Besuch.