Posts Tagged ‘TP-LINK’

Sonntag, 19. Januar 2020

Signal-Werte meiner Ubiquiti UF-SM-1G-S

Kürzlich hat ein Bekannter ein zweites Stockwerk mit Netzwerkverkabelung erschlossen. Hierzu haben wir nicht Ethernet Cat6 gewählt, sondern wegen der Grösse der Lehrrohre auf Glasfaser gesetzt.

Dies bedingt leider aber auch, dass an beiden Enden des Glasfasers SFP-Module verwendet werden müssen, die die Lichtwellen auf Ethernet konvertieren.

Ich habe mich auf der einen Seite für einen gebrauchten Ubiquiti Unifi Switch US-8-150W entschieden, auf der anderen Seite ein bei mir nach Fiber7-Tests unbenutzt herumliegender TP-Link MC220L, der im Modus Auto mit Ethernet auf einen Ubiquiti Unifi Switch US-8-60W gepatcht ist. Als SFP-Module verwende ich beidseitig Ubiquiti UF-SM-1G-S. Als Kabel hat der Bekannte ein Lightwin LWL-Patchkabel LC/APC-LC, Singlemode, Simplex, 15m gezogen.

Aktuell erreiche ich mit diesem Setup auf Seite des US-8-150W folgende Signal-Werte:

  • Output Pwr. -6.03 dBm
  • Input Pwr. -8.57 dBm

Das SFP-Modul ist 47 Grad Celsius warm, die Spannung beträgt 3.284 Volt und der Strom beträgt 31.890 mA. Diese Infos kann man allesamt in Echtzeit über die UniFi Controller-Software auslesen.

Leider habe ich keine Ahnung, ob diese Werte gut oder schlecht sind …

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

2 Kommentare | neuen Kommentar verfassen

Donnerstag, 22. Juni 2017

Wenn Embedded Linux-Geräte kein HTTP HEAD verstehen

Netzwerkgeräte in meinem Intranet überwache ich mit der quelloffenen Software monit. Seit ich einen meiner monit-Server auf Debian Stretch upgegradet habe, häuften sich „Geister“-Fehlermeldungen — immer in Bezug auf Checks, welche die Verfügbarkeit von Web-Oberflächen abfragen. Dies in folgender Form:

...
check host web.server.strasse.emeidi.local with address 10.10.10.10
    if failed port 80 protocol http for 10 cycles then alert
...

Mit dem Upgrade auf Debian Stretch wird auch monit von Version 5.9-1+deb8u1 auf Version 5.20.0-6 aktualisiert.

Ich wartete also den Moment ab, in welchem ich per E-Mail die Fehlermeldung erhielt, loggte mich per SSH auf den Server ein und führte zu Debugging-Zwecken eine Abfrage aus — die Idee war, auf dem selben Server die Abfrage zu simulieren, die monit gegen das entfernte System laufen lässt:

$ wget --server-response "http://10.10.10.10/"
--2017-06-22 22:05:25--  http://10.10.10.10/
Verbindungsaufbau zu 10.10.10.10:80 … verbunden.
HTTP-Anforderung gesendet, auf Antwort wird gewartet … 
  HTTP/1.1 200 OK
  Server: Router Webserver
  Connection: close
  Content-Type: text/html
  WWW-Authenticate: Basic realm="TP-LINK Wireless Dual Band Gigabit Router WDR3600"
Länge: nicht spezifiziert [text/html]
Wird in »index.html« gespeichert.

index.html                   [ <=>                              ]   7,66K  --.-KB/s    in 0,01s   

2017-06-22 22:05:25 (754 KB/s) - »index.html« gespeichert [7841]

Dies funktioniert problemlos. Was Cheibs?

Als ich mir die Dokumentation zu monit genauer anschaute, realisierte ich eine feine, aber entscheidende Option:

PROTO(COL) HTTP
     [USERNAME "string"]
     [PASSWORD "string"]
     [REQUEST "string"]
     [METHOD <GET|HEAD>]
     [STATUS operator number]
     [CHECKSUM checksum]
     [HTTP HEADERS list of headers]
     [CONTENT < "=" | "!=" > STRING]

Quelle: Monit Version 5.23.0 — HTTP

Mit [METHOD ] entscheidet man, ob man einen normalen HTTP-Request („GET“) versendet, oder aber nur einen „HEAD“-Request, der nur nach dem Header einer Web-Site frägt. Das spitzfindige an der Sache:

METHOD set the HTTP request method. If not specified, Monit prefers the HTTP HEAD request method to save bandwidth, unless a response content or response checksum is tested. As some webservers may not support the HEAD method, one may want to set the method explicitly.

Dann lass uns das doch mal so simulieren. wget verfügt über die entsprechende Option --spider, die HEAD-Requests versendet:

$ wget --spider --server-response "http://10.10.10.10/"
Spider-Modus eingeschaltet. Es wird geprüft, ob die Datei auf dem Server existiert.
--2017-06-22 22:04:36--  http://10.10.10.10/
Verbindungsaufbau zu 10.10.10.10:80 … verbunden.
HTTP-Anforderung gesendet, auf Antwort wird gewartet … 
  HTTP/1.1 501 Not Implemented
  Server: Router Webserver
  Connection: close
  WWW-Authenticate: Basic realm="TP-LINK Wireless Dual Band Gigabit Router WDR3600"
  Content-Type: text/html
--2017-06-22 22:04:37--  (Versuch: 2)  http://10.10.10.10/
Verbindungsaufbau zu 10.10.10.10:80 … verbunden.
HTTP-Anforderung gesendet, auf Antwort wird gewartet … 
  HTTP/1.1 200 OK
  Server: Router Webserver
  Connection: close
  Content-Type: text/html
  WWW-Authenticate: Basic realm="TP-LINK Wireless Dual Band Gigabit Router WDR3600"
Länge: nicht spezifiziert [text/html]
Datei auf dem Server existiert und könnte weitere Verweise enthalten,
aber Rekursion ist abgeschaltet -- kein Download.

Via: Wget HEAD request?

Et voilà, das war das Problem: Der Embedded Web Server auf dem zu überwachenden Gerät hat Probleme, wenn aus dem nichts ein HEAD-Request kommt. Beim zweiten Anlauf dann ist die Web-Seite offenbar gerendert und der HEAD-Request kann beantwortet werden.

monit scheint nun aber offenbar so programmiert zu sein, dass nach dem ersten Versuch und einer Antwort mit Fehlern kein zweiter Versuch lanciert wird. Deshalb auch die sporadischen Fehlermeldungen.

Wie löst man das Dilemma? Ich wandelte den Test folgendermassen um:

...
check host web.server.strasse.emeidi.local  with address 10.10.10.10
    if failed
	port 80
	protocol http
	with content = "Willkommen"
	for 10 cycles
    then alert
...

Die Anweisung with content = "Zeichenkette" forciert monit, einen GET-Request abzusetzen und keinen HEAD (da nur beim GET-Request ein HTTP-Body mitgeliefert wird). Und schwup, Problem gelöst.

Erweitert

Übrigens: Wem die Ausgabe von wget noch nicht ausreicht, da sie zu wenig geschwätzig ist, kann auch die Debug-Option verwenden:

$ wget --debug --spider --server-response "http://10.10.10.10/"
Setting --spider (spider) to 1
Setting --server-response (serverresponse) to 1
DEBUG output created by Wget 1.19.1 on darwin15.6.0.

Reading HSTS entries from /Users/user/.wget-hsts
Converted file name 'index.html' (UTF-8) -> 'index.html' (UTF-8)
Spider-Modus eingeschaltet. Es wird geprüft, ob die Datei auf dem Server existiert.
--2017-06-22 22:02:44--  http://10.10.10.10/
Verbindungsaufbau zu 10.10.10.10:80 … verbunden.
Created socket 4.
Releasing 0x00007ff99bc231e0 (new refcount 0).
Deleting unused 0x00007ff99bc231e0.

---request begin---
HEAD / HTTP/1.1
User-Agent: Wget/1.19.1 (darwin15.6.0)
Accept: */*
Accept-Encoding: identity
Host: 10.10.10.10
Connection: Keep-Alive

---request end---
HTTP-Anforderung gesendet, auf Antwort wird gewartet … 
---response begin---
HTTP/1.1 501 Not Implemented
Server: Router Webserver
Connection: close
WWW-Authenticate: Basic realm="TP-LINK Wireless Dual Band Gigabit Router WDR3600"
Content-Type: text/html

---response end---

  HTTP/1.1 501 Not Implemented
  Server: Router Webserver
  Connection: close
  WWW-Authenticate: Basic realm="TP-LINK Wireless Dual Band Gigabit Router WDR3600"
  Content-Type: text/html
Closed fd 4
--2017-06-22 22:02:48--  (Versuch: 2)  http://10.10.10.10/
Verbindungsaufbau zu 10.10.10.10:80 … verbunden.
Created socket 4.
Releasing 0x00007ff99bc23110 (new refcount 0).
Deleting unused 0x00007ff99bc23110.

---request begin---
GET / HTTP/1.1
User-Agent: Wget/1.19.1 (darwin15.6.0)
Accept: */*
Accept-Encoding: identity
Host: 10.10.10.10
Connection: Keep-Alive

---request end---
HTTP-Anforderung gesendet, auf Antwort wird gewartet … 
---response begin---
HTTP/1.1 200 OK
Server: Router Webserver
Connection: close
Content-Type: text/html
WWW-Authenticate: Basic realm="TP-LINK Wireless Dual Band Gigabit Router WDR3600"

---response end---

  HTTP/1.1 200 OK
  Server: Router Webserver
  Connection: close
  Content-Type: text/html
  WWW-Authenticate: Basic realm="TP-LINK Wireless Dual Band Gigabit Router WDR3600"
Länge: nicht spezifiziert [text/html]
Closed fd 4
Datei auf dem Server existiert und könnte weitere Verweise enthalten,
aber Rekursion ist abgeschaltet -- kein Download.

Via: What headers are automatically send by wget?

Sackgassen

Initial befürchtete ich, dass der Web-Server des Zielsystems sich am User-Agent des Requests verschluckt. Doch dies war eine falsche Vermutung. Nichtdestotrotz könnte man monit so konfigurieren, dass es einen alternativen User-Agent sendet:


‚User-Agent‘ header can not be set via ‚http headers‘ array

Und noch ein anderes Beispiel: Trying to configure monit to use https protocol but it sticks with http

Tags: , , , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 19. März 2017

OpenVPN mit iPhone, iPad und MacBook Air — aber nicht mit Travel Router TP-LINK TL-MR3020

Auf Grund der bald bevorstehenden Reise in die USA habe ich mir heute Zeit genommen, einen VPN-Server einzurichten, mit welchem ich mich unterwegs in den USA mit iPhone, iPad und MacBook Air verbinden kann.

Obwohl heutzutage die meisten Web-Sites mit HTTPS kommunizieren, stelle ich damit sicher, dass allfällige unverschlüsselte Kommunikation im Hotel-WiFi nicht abgehört werden kann. Als netten Nebeneffekt gaukle ich meinen Geräten weiter vor, dass sie sich in der Schweiz befinden und umgehe so allfällige Geoblocks. Da wir seit einem Jahr eine Glasfaster-Internet-Anbindung mit 1 GBit/s symmetrischem Datenverkehr verfügen, sollte die Performance höchstens noch von der hohen Latenz getrübt werden.

Ich hatte bisher bereits eine Lösung im Einsatz (im Grunde zwei, PPTP sowie OpenVPN mit einem Shared Key), doch nun war es an der Zeit, das Gefrickel aufzuräumen und eine zukunftstaugliche, performante und sichere Lösung zu bauen, welche (fast) nativ mit macOS und iOS funktioniert — konkret mit Tunnelblick unter macOS sowie mit OpenVPN.app unter iOS.

Die beiden Applikationen kann man mittels .ovpn-Textdateien als VPN-Clients konfigurieren.

Ich bin im Grossen und Ganzen der Anleitung „How To Set Up an OpenVPN Server on Ubuntu 16.04“ von DigitalOcean gefolgt, habe die Konfiguration dabei aber meiner Heimnetzwerk-Architektur angepasst und mittels Bash-Scripts automatisiert. Denn irgendeinmal muss ich den OpenVPN-Server aktualisieren und bin mit dem DevOps-Ansatz sicher, mittels Knopfdruck wieder eine funktionierende Lösung bereit zu haben.

Die Anleitung zeigt einen netten Weg auf, wie man sich die .ovpn-Dateien vollautomatisierte mittels eines bash-Scripts erstellt.

Ich verwende nun für alle meine Geräte ein eigenständiges Zertifikat, damit ich diese im Notfall einzeln revozieren kann.

Die Konfiguration funktioniert tadellos — einzig bei Tunnelblick (d.h. unter macOS) musste ich die Passagen

...
user nobody
group nogroup
...

wieder auskommentieren, da es sonst zu komischen Fehlermeldungen im OpenVPN-Log des Clients kam. Ausserdem muss man im GUI anklicken, dass der gesamte IPv4-Verkehr durch das VPN geroutet wird:

Wehrmutstropfen: Eigentlich war der Aufbau eines VPN-Tunnels pro Device nur als Plan B gedacht. Denn bei Reisen verwende ich einen TP-LINK TL-MR3020 „Reiserouter“ (klitzekleiner Wireless Access Point, der sich mit USB-Stromversorgung betreiben lässt), um diesen mit Hotel-WiFis zu verbinden und die SSID mit den Zugangsdaten meines Heimnetzwerkes anzubieten. So spare ich es mir, dass das Hotel-WiFi auf all meinen Geräten konfiguriert werden muss.

Auf dem Router habe ich mir das quelloffene OpenWrt (Version Attitude Adjustment) installiert und mittlerweile so konfiguriert, damit es mit allen möglichen WLAN-Netzwerken von Unterkünften funktioniert (einige Hersteller von Gästeportalen frickeln massiv mit dem Netzwerk herum, um Clients auf die Landing Pages zu bringen).

Plan A war es nun eigentlich, OpenVPN auf dem Router selbst zu installieren und jedes Mal automatisch eine Verbindung mit meinem OpenVPN-Server in der Schweiz herzustellen, sobald der Router eine Internet-Verbindung herstellen kann. So hätte ich nicht pro Endgerät einzeln eine VPN-Verbindung aufbauen müssen und die Verschlüsselung wäre ohne weitere Interaktion standardmässig aktiviert gewesen.

Eine Anleitung zur Installation von OpenVPN als VPN-Client auf einem TP-LINK TL-MR3020 findet sich dazu im Netz (plus eine generische Anleitung für OpenWRT), doch leider habe ich erst während der Installation bemerkt, dass der Router nicht genügend Speicherplatz mit sich bringt, um die Pakete openvpn, openssl und andere Libraries zu installieren:

Da opkg nicht komplett durchgelaufen ist, musste ich die über das Router-Filesystem verstreute Überreste der Pakete eigenhändig entfernen (indem ich die .ipks vom offiziellen Repository händisch herunterlud, mit gzip entpackte und die resultierenden Dateien dann erneut mit tar und gzip entpackte):

.
./kmod-tun_3.3.8-1_ar71xx
./kmod-tun_3.3.8-1_ar71xx/etc
./kmod-tun_3.3.8-1_ar71xx/etc/modules.d
./kmod-tun_3.3.8-1_ar71xx/etc/modules.d/30-tun
./kmod-tun_3.3.8-1_ar71xx/lib
./kmod-tun_3.3.8-1_ar71xx/lib/modules
./kmod-tun_3.3.8-1_ar71xx/lib/modules/3.3.8
./kmod-tun_3.3.8-1_ar71xx/lib/modules/3.3.8/tun.ko
./kmod-tun_3.3.8-1_ar71xx/postinst
./liblzo_2.06-1_ar71xx
./liblzo_2.06-1_ar71xx/usr
./liblzo_2.06-1_ar71xx/usr/lib
./liblzo_2.06-1_ar71xx/usr/lib/liblzo2.so
./liblzo_2.06-1_ar71xx/usr/lib/liblzo2.so.2
./liblzo_2.06-1_ar71xx/usr/lib/liblzo2.so.2.0.0
./libopenssl_1.0.1h-1_ar71xx
./libopenssl_1.0.1h-1_ar71xx/usr
./libopenssl_1.0.1h-1_ar71xx/usr/lib
./libopenssl_1.0.1h-1_ar71xx/usr/lib/libcrypto.so.1.0.0
./libopenssl_1.0.1h-1_ar71xx/usr/lib/libssl.so.1.0.0
./openvpn_2.2.2-2_ar71xx
./openvpn_2.2.2-2_ar71xx/conffiles
./openvpn_2.2.2-2_ar71xx/etc
./openvpn_2.2.2-2_ar71xx/etc/config
./openvpn_2.2.2-2_ar71xx/etc/config/openvpn
./openvpn_2.2.2-2_ar71xx/etc/init.d
./openvpn_2.2.2-2_ar71xx/etc/init.d/openvpn
./openvpn_2.2.2-2_ar71xx/etc/openvpn
./openvpn_2.2.2-2_ar71xx/lib
./openvpn_2.2.2-2_ar71xx/lib/upgrade
./openvpn_2.2.2-2_ar71xx/lib/upgrade/keep.d
./openvpn_2.2.2-2_ar71xx/lib/upgrade/keep.d/openvpn
./openvpn_2.2.2-2_ar71xx/usr
./openvpn_2.2.2-2_ar71xx/usr/sbin
./openvpn_2.2.2-2_ar71xx/usr/sbin/openvpn
./zlib_1.2.7-1_ar71xx
./zlib_1.2.7-1_ar71xx/usr
./zlib_1.2.7-1_ar71xx/usr/lib
./zlib_1.2.7-1_ar71xx/usr/lib/libz.so
./zlib_1.2.7-1_ar71xx/usr/lib/libz.so.1
./zlib_1.2.7-1_ar71xx/usr/lib/libz.so.1.2.7

So konnte ich die Überreste schlussendlich entfernen (der Router bootete nach der Bereinigungsaktion tatsächlich noch) und der Router hat nun wieder 800 KB Speicher frei … wie zu DOS-Zeiten!

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

1 Kommentar | 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

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