Categories
Computers Debian English Linux Networking Routers Ubuntu

rsyslog Configuration for remote Logging

I want all the network devices in my house to log to a central location, so that log messages can be

  • stored permanently (if I switch off an access point, normally all logs are gone), and
  • automatically checked for interesting events.

So I needed to set up my internal Ubuntu-based server to receive log messages from these devices via the syslog protocol.

My requirements were:

  • Logs from different devices should go into a dedicated file each.
  • Logs from the local machine should not go into any of these files, but the standard Ubuntu logging should be continued to be observed.

It took me a while to figure out how the “ultimate” configuration should be, but here’s the result in case anybody else has similar requirements:

Categories
Communications English Networking Security Travel

Doing “IT” from Egypt

I was recently in Egypt for two weeks of vacation. As I’m running my own “bare-metal” root server, I needed to take care of it even while on vacation, to look after updates and alerts on a daily basis.

So I prepared myself well, and I would like to briefly let you know what I did, and what worked, and what didn’t work.

Preparation

First, I set up WireGuard on my server. It’s a UDP-based VPN that is very lightweight and fast. By chance I found out, though, that Egypt doesn’t work in Egypt, as it’s being blocked by Egypt’s authorities. 🙁

So I looked for alternatives and came across Outline. Outline is not actually a “real” VPN, but a proxy using the Shadowsocks protocol, which was explicitly designed to circumvent internet censorship. It can also proxy UDP traffic.

That is one amazing piece of software.

For certain Cloud Service Providers (Digital Ocean (just $4/mo.!), Google Cloud, Amazon Web Services), you can literally install it with a single click in a desktop app, the Outline Manager, which is available for Windows, macOS, and Linux.

Categories
Communications Networking Routers

Wie man (physische) Netzwerkprobleme spielend leicht lokalisieren kann

Kürzlich habe ich endlich etwas “angepackt”, was ich schon seit einigen Jahren tun wollte: Ich habe das LAN in meinem Haus “logisch segmentiert” durch die Verwendung von VLANs, um unterschiedlichen Traffic auf jeweils einem einzigen Kabel transportieren zu können.

Wozu braucht man sowas? Ganz einfach, z. B. um ein Gästenetzwerk vernünftig implementieren zu können, wenn man mehr als nur einen WiFi-Access Point in seinem Netz hat. Anbieter wie Ubiquity haben sowas bestimmt so implementiert, dass auch technisch weniger bewanderte Personen es nutzen können, aber mir ist Ubiquiti einfach zu teuer in dem Ausmaß, in dem ich deren Hardware bräuchte. Außerdem macht es ja auch schlicht Spaß, sich sowas auf Open Source-Basis selbst zu bauen… 😉

Ich habe bei mir also auf OpenWrt-Basis ein (für ein Einfamilienhaus) relativ komplexes Netzwerk aufgebaut. Folgende Komponenten sind u. a. enthalten:

Jetzt hatte ich kürzlich ein Problem, an dem ich wirklich hart zu “knacken” hatte. Irgendwann kam ich zu dem Schluss, dass es nicht auf Layer 2 (Ethernet) oder höher (IP) liegen müsse, sondern eher auf Layer 1 (physikalische Ebene, also Verkabelung).

Ich habe mir also für sage und schreibe 10,99 EUR einen deleyCON Netzwerk-Kabeltester bestellt. Selbst für eine einmalige Anwendung (aber dabei bleibt’s ja nicht…) war mir der Preis akzeptabel.

Und siehe da, ich hatte tatsächlich ein Verkabelungsproblem in meinem Netzwerk. An einer Netzwerkdose war das Kabel nicht vernünftig aufgelegt.

Diesen Fehler hätte ich ohne den Kabeltester nicht gefunden. Der Tester ist wirklich auch von Personen, die keine ausgebildete Netzwerktechniker sind, sehr einfach zu nutzen. Signalgenerator ans eine Ende des Strangs hängen, “Abschluss-Stecker” ans andere, und schon werden die einzelnen Adern durchgetestet, und man kann durch LEDs sehen, wo der Fehler ist.

Ich kann dieses Gerät nur absolut weiterempfehlen. Für etwas mehr als einen Zehner kann man da nichts falsch machen…

Lasst mich gerne wissen, ob Ihr meine Meinung teilt, falls Ihr Euch auch dieses Gerät zulegen solltet…

Categories
Computers deutsch Networking Routers Uncategorized Windows

Mein Internet funktioniert nicht, was tun?!

Diesen Hilfeschrei hat bestimmt jeder schon oft gehört. Aber nur die wenigsten wissen, wie man heraus finden kann, wo genau das Problem liegt.

Ich versuche in diesem Blogpost einmal, eine auch für Laien verständliche bzw. leicht anwendbare Anleitung zu liefern, wie man bei Internetstörungen zu Hause dem Problem auf die Spur kommen kann…

Zunächst einmal ein paar (wenige) Grundlagen. Ohne diese geht es einfach nicht.

Egal, was Sie im Internet tun, alles passiert auf Basis sogenannter “IP-Pakete“. Jeglicher Datenverkehr wird “zerhackt” und in Form von kleinen “Häppchen”, eben dieser IP-Pakete übertragen. Alle Geräte, die am Internet teilnehmen, haben eine bestimmte Rolle. Ihr Handy, Laptop oder PC ist in der Regel ein sogenannter “Client“, also ein “Kunde”, die Dienste, die Sie in Anspruch nehmen, werden durch sogenannte “Server” (“Bediener”) erbracht. Wie findet nun Ihr Client den passenden Server? Das funktioniert über ein System namens “DNS“. Es übersetzt für den Menschen lesbare Adressen, wie z. B. “amazon.de“, in IP-Adressen, die Ihr Endgerät für die tatsächliche Kommunikation mit dem gewünschten Dienst benutzt.

Wie werden aber die IP-Pakete zwischen Ihrem Endgerät (Handy, Laptop, Tablet, PC) und den Servern im Internet übertragen? Zunächst muss Ihr Endgerät mit Ihrem eigenen lokalen Netzwerk (auch “LAN” genannt) bei sich zu Hause verbunden sein. Dies kann über WLAN (auch “WiFi” genannt) oder Netzwerkkabel (auch “Ethernet”-Kabel genannt) passieren. Von dort geht es über Ihren Router zu Ihrem Internetprovider, und dann von dort ins Internet. Welche physikalische Verbindungstechnik (Teilnehmeranschlussleitung) Sie zur Anbindung an Ihren Provider verwenden ist grundsätzlich egal: DSL, TV-Kabel, Glasfaser oder sogar Mobilfunk (z. B. über einen Vodafone GigaCube).

Categories
Communications English Networking

Netgear GS108Ev3 – Huge packet loss when pinging management IP

I have a quite complex infrastructure in my house, and I monitor everything.  Among others, I have SmokePing probes towards multiple destinations in my LAN, and also to my internet provider’s infrastructure, and even external hosts.

When I added a graph for the management IP of my Netgear GS108Ev3 8 Port Gigabit Ethernet Smart Managed Plus Switch, which is my “core” switch, I noticed that there is a huge packet loss, in the range of 4% average, about 40% max.

The strange thing is that other destinations in my LAN which can be reached via this switch, have absolutely zero packet loss. That means that the cabling itself is definitely ok, and also that the packet switching functionality of the switch is ok.

So I opened a ticket towards NetGear, and the response I got was quite surprising (but still somehow makes sense):

This is a known issue, and it is by design. The put the highest priority on the packets flowing thru the switch, while the management traffic has a lower priority, so that ICMP packets to the switch’s management IP may get lost, and in extreme cases the web UI may not be reachable at all.

It’s not a big issue for me, because in the end I wanted to create graphs that exhibit whether I have any internal packet loss. Whether the switch’s management interface has packet loss or not is not really important to me. As long as all my internal devices that I actively use, like my NAS devices or streaming boxes, are properly connected with no packet loss, all is well. 🙂

Categories
Computers Debian English Linux Networking

ntp running in chroot stopped working after Debian Stretch upgrade

Today I upgraded my root server from Jessie to Stretch, and suddenly ntp stopped working.

I found errors like follows in the log, which were obviously due to failures in name resolution:

2018-05-31T07:44:48.900756+00:00 myhost ntpd[22855]: giving up resolving host 1.debian.pool.ntp.org: Servname not supported for ai_socktype (-8)

The solution to make this work was to bind-mount some files and directories essential for name resolution into the chroot jail.

First create some directories and some dummy files:

# mkdir /var/lib/ntp/etc /var/lib/ntp/lib /var/lib/ntp/proc
# mkdir /var/lib/ntp/usr /var/lib/ntp/usr/lib
# touch /var/lib/ntp/etc/resolv.conf /var/lib/ntp/etc/services

Then update your /etc/fstab as follows:

...
#ntpd chroot mounts
/etc/resolv.conf  /var/lib/ntp/etc/resolv.conf none bind 0 0
/etc/services	  /var/lib/ntp/etc/services none bind 0 0
/lib		  /var/lib/ntp/lib none bind 0 0
/usr/lib	  /var/lib/ntp/usr/lib none bind 0 0
/proc		  /var/lib/ntp/proc none bind 0 0

Finally mount all these binds:

# mount -a

Thanks to the ArchLinux guys where I found this.

To check whether your ntp is working again, you can use the following command which shows a list of peers known to your ntp server:

# ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 0.debian.pool.n .POOL.          16 p    -   64    0    0.000    0.000   0.000
 1.debian.pool.n .POOL.          16 p    -   64    0    0.000    0.000   0.000
 2.debian.pool.n .POOL.          16 p    -   64    0    0.000    0.000   0.000
 3.debian.pool.n .POOL.          16 p    -   64    0    0.000    0.000   0.000
*ptbtime1.ptb.de .PTB.            1 u   46   64  377   11.483   -0.411   0.201
+ptbtime2.ptb.de .PTB.            1 u   52   64  377   11.502   -0.533   1.069
+ptbtime3.ptb.de .PTB.            1 u   47   64  377   11.451   -0.510   3.866
#batleth.sapient 131.188.3.221    2 u   44   64  377    0.188    1.097   0.176
#5.199.135.170 ( 130.149.17.21    2 u   45   64  377   11.271    0.581   0.396
-mail.morbitzer. 193.175.73.151   2 u   47   64  377    2.760    0.556   0.278
#hotel.zq1.de    161.62.157.173   3 u   46   64  377    0.094    1.384   0.261
-ntp2.m-online.n 212.18.1.106     2 u   47   64  377    7.167   -0.333   0.190
#2a03:b0c0:3:d0: 81.94.123.16     3 u   49   64  377    6.288   -2.071   1.760
#touka.thehomeof 130.149.17.21    2 u   48   64  377    0.206    0.932   0.222
+maggo.info      124.216.164.14   2 u   42   64  377    0.278   -0.137   0.436
+weyoun4.cord.de 124.216.164.14   2 u   44   64  377    2.849   -0.255   0.409
+opnsense.sauff. 222.217.153.8    2 u   43   64  377    0.270   -0.617   0.167
-web1.sys.ccs-ba 192.53.103.104   2 u   35   64  377    0.173   -1.251   0.220
#uruz.org        122.227.206.195  3 u   49   64  377    0.216    1.694   0.309
#clients5.arcani 162.23.41.55     2 u   38   64  377    6.120   -1.500   0.130
+stratum2-1.NTP. 129.70.130.71    2 u   47   64  377   14.043    1.625   0.394

The following command confirms that your current time is actually correct (within certain limits, of course):

# ntpstat
synchronised to NTP server (192.53.103.108) at stratum 2
   time correct to within 15 ms
   polling server every 64 s

If this was helpful, I would be happy to hear from you.

Categories
Communications Computers English Networking Security Uncategorized

Monitoring Microsoft SNDS Status

If you operate a mail server, you should be aware of its “reputation,” because a bad reputation can give you issues sending email to certain recipients.

Microsoft operate a set of services called “Smart Network Data Services (SNDS)” to protect their own email services. If they see spam or other “malicious” activity from your address space, they might put you on a blacklist, and based on that reject email from you. It is easy to register yourself so that you can query the status of your IP address space. Just visit the above site and get started.

I created a quick’n’dirty monitoring script for Nagios to monitor the status of my IP address space in SNDS. Whenever there is data for one of my IP addresses, this script will return a WARNING status, so that I can look into it.

The script looks like follows:

#!/bin/bash

URL='https://postmaster.live.com/snds/ipStatus.aspx?key=12345678-1234-1234-1234-0123456789ab'

content="$(curl -s $URL)"
size=${#content}

if [ $size -gt 0 ]; then
    echo "WARNING:SNDS status seems to be UNHEALTHY"
    exit 1
fi

echo "OK:SNDS status is OK"
exit 0

You also need command and service definitions in Nagios as follows:

define command{
        command_name    check_snds
        command_line    /usr/local/lib/nagios/plugins/check_snds
}

define service {
        host_name                       my_host
        service_description             SNDS
        check_command                   check_snds
        use                             generic-service-internal
        notification_interval           0 ; set > 0 if you want to be renotified
}

Now, Nagios will monitor the “reputation” of your address space for you.

Categories
Communications deutsch Networking Routers

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!

Categories
Communications deutsch Networking

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.

Categories
Communications English Routers

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.