Introducing the "Selfnet Network Map"

Deutsche Übersetzung weiter unten.

Our "new" network map is public now which shows the current situation in our (internal) network.

But we also want to describe the path how this project came into existence.

Some years ago several members visited the Gulasch-Programmier-Nacht in Karlsruhe. As a project there they used a Javascript-Library VivaGraphJS, which is a graph rendering engine also used to display molecules, to visualize networks.

Originally the just wanted to know how our network "looks". The point about the funny movable map that resulted from the rendering engine naturally increased the fun factor.

Some years later another member built a Perl script (because he wantet to learn Perl) to scan our internal network automatically and collect the neighor relations between the devices. This script utilizes SNMP queries to our devices and asks for the LLDP Neighbors.

SNMP (Simple Network Management Protocol) is usually used by us to check for usage informations like temperature, cpu usage or network traffic. But it can (with sufficient privileges) also query a lot more information. This information includes the LLDP (Link Layer Discovery Protocol) data of the device. LLDP is utilizing a lower network layer between configured devices (even before using IP addesses) to exchange basic information between devices. It includes the hostnames or the connected ports. So this can also used to find physical faults in connections.

An Example Local Interface Parent Interface Chassis Id Port info System Name ge-0/1/2.0 - xx:xx:xx:xx:xx:xx ge-0/1/0.0

These resulting script data was just used to find missing links or single points of failure (via a script).

The last years we connected those two projects in our network map. The first versions are from 2016 and were used for internal debugging and visualization. Since December 2017 the project is developed in our internal GitLab but only as a "tinkering project" and not as something productive. With the map you could (for example) after bigger network changes or new dormitories check for the network structure and if somewhere fibers are missing or connected in a wrong way.

Meanwhile the project has evolved and several people are using it for debugging or just to understand how our network works.

Thats the reason why we automated it now, "brighten it up" and added several features. Now you can also see the speed of links between devices in colorcode or differentiate hosts by type. The last was quite important as the map became crowded after we added our wireless access points to it.

Cutout of the network map

So for transparancy reasons (and so everybody can have a look how our network is connected) we now published the map on our Website. Direct Link

Of course there are still some small bugs we hope to eliminate as soon as possible.

Thanks to all of our members who helped in any way to realize this project.

Do you want to participate in taking care of such problems in the future? For our network to run smoothly there are a lot of different things to do: management of the equipment (including buying new stuff and getting service), taking care of servers for the network or additional services, debugging problems like this or connecting new dormitories to our network.

If you want to volunteer, it doesn't matter if you are a pro or a starter: Selfnet offers the opportunity to learn everything required. If you are interested in technical stuff, programming, public relations, project management or anything else: We would be glad to welcome you in our team! Just visit our support hours (once the office hours are re-opened).

The Selfnet-Team

Deutsche Übersetzung

Die Selfnet Netzwerk-Karte

Mittlerweile ist unsere interaktive Netzwerkkarte öffentlich geworden, mit der man den momentanen Zustand unseres (internen) Netzes besser nachvollziehen kann.

Wir möchten euch aber auch den Weg aufzeigen, wie diese Entwicklung über die Jahre entstanden ist.

Vor einigen Jahren auf einer Gulasch-Programmier-Nacht in Karlsruhe eine Javascript-Library (VivaGraphJS zur Graphendarstellung, die unter anderem in der Moleküldarstellung genutzt wurde, anzupassen um Netzwerke zu visualisieren.

Ursprünglich war der Gedanke nur, dass man mal "sieht" wie unser Netzwerk eigentlich aussieht. Das die Karte lustig durch die gegend "gebobbelt" werden konnte hat den Spaßfaktor natürlich erhöht :)

Einige Jahre später hat ein anderes unserer Mitglieder ein Script in Perl gebaut (weil er Perl lernen wollte), dass unser Netzwerk automatisch untersucht und Nachbarbeziehungen erfasst. Dies funktionierte über Anfragen an unsere Geräte per SNMP, welche die Nachbarbeziehungen per LLDP abgefragt haben.

SNMP (Simple Network Management Protocol) ist dabei ein einfaches Netzwerkverwaltungsprotokoll, dass wir eigentlich benutzten um zum Beispiel Auslastungsinformationen wie Temperatur, CPU-Last oder Traffic auszulesen. Dieses Protokoll kann aber (mit den richtigen Benutzerdaten) auch andere Informationen abrufen. Diese Informationen umfassen die LLDP (Link Layer Discovery Protocol) Daten des Gerätes. LLDP funktioniert dabei zwischen konfigurierten Geräten auf einer der untersten Netzwerkebenen, noch bevor IP-Adressen benutzt werden und tauscht zwischen verbundenen Geräten Informationen aus. Diese Informationen beinhalten zum Beispiel den Hostnamen oder auch den angeschlossenen Port. Dies kann daher auch dafür genutzt werden, physikalische Fehler in Verbindungen zu finden.

Ein Beispiel Local Interface Parent Interface Chassis Id Port info System Name ge-0/1/2.0 - xx:xx:xx:xx:xx:xx ge-0/1/0.0

Diese Daten wurden ursprünglich dann nur genutzt um fehlende Verbindungen oder fehleranfällige Knotenpunkte zu finden (per Script).

Die letzten Jahre wurde dies dann "verheiratet". Die ersten Versionen sind von 2016 und wurden dann fürs interne Fehlersuchen und zum visualisieren genutzt. Seit Dezember 2017 ist dies Projekt bei uns im internen Gitlab verzeichnet, allerdings eher als "Bastelprojekt" und nicht als "produktives Projekt". Mithilfe der Karte konnte man beispielsweise nach großen umbauten oder neuen Wohnheimen feststellen, ob irgendwo Glasfasern falsch gesteckt sind oder Verbindungen noch fehlten.

Mittlerweile hat sich das Projekt aber soweit entwickelt, dass mehrere Personen das zum debugging oder zum verstehen des Netzwerkes genutzt haben.

Daher haben wir das Projekt jetzt automatisiert (das man es als Script ausführen kann) und auch etwas "aufgehübscht" und weitere Features eingebaut. So kann man jetzt auch per Farbe die Geschwindigkeit der Verbindungen erkennen, Hosts nach Typ erkennen oder einzelne Sachen nacheinander einblenden. Letzteres war ein wichtiger Punkt nachdem wir angefangen haben die WLAN-Accesspoints aufzunehmen, da die Karte einfach unglaublich komplex wurde.

Ausschnitt der Netzwerkkarte

Aus Gründen der Transparenz für unsere Mitglieder (und damit jeder mal sehen kann wie das alles aussieht) haben wir die Karte nun auf unserer Webseite eingebunden. Direkter Link

Natürlich gibt es noch einige kleinere Probleme, die wir hoffen bald beheben zu können.

Wir danken hiermit allen Mitgliedern, die bei der Realisierung des Projektes beteiligt waren.

Möchtest du in Zukunft bei Selfnet mitmachen und dich ehrenamtlich um solche und andere interessante technische Dinge kümmern? Um das Wohnheimsnetz ordentlich zu betreiben gibt es viele verschiedene Dinge zu tun: Verwaltung der Hardware (inkl. Neukauf von Hardware und mit dem Hersteller bezüglich Service arbeiten), Verwaltung von Servern und anderen Netzwerkdiensten, Analyse von Problemen oder neue Wohnheime an das Wohnheimnetzwerk anschließen.

Wenn du mitmachen möchtest geht es nicht um Vorwissen. Wichtiger ist es Spaß zu haben und noch etwas sinnvolles/praktisches neben dem Studium zu tun. Wenn du dich für Technik, Softwareentwicklung, Öffentlichkeitsarbeit, Projektmanagement oder vieles andere interessierst: Wir freuen uns dich bei uns begrüßen zu dürfen! Besuche einfach eine unserer Sprechstunden, (sobald diese wieder stattfinden.).

Das Selfnet-Team

Why is the WiFi reception not as good as it should be?

Deutsche Übersetzung weiter unten.

If you are unhappy with the performance of the WiFi ensure you are using Selfnet WiFi (Name of the WiFi is "Selfnet"). If you are running your own WiFi check the tips below.

We do hear the feedback about slow network speeds quite often - in particular for devices relying on WiFi.
Here we would like to elaborate on why this is the case and - more importantly - what you can do to change that. We do our best to save the tech talk. If you like to just see solutions - read on. If the text gets too technical just stop reading and reach out to us (e-mail / chat / office hours in a Corona-free time) and we will be more than happy to explain.
Practical solutions - if you are just interested in these - are marked in bold in this article..

Wait, Selfnet runs the network and that's what sucks. What's my part here?
To get this out the door as early as possible: At least half of your experience in the WiFi is something you can (and should?) influence.

Our network is somewhat different to WiFi at home

First of all we need to distinguish one very important part: There is WiFi run by Selfnet in some dormitories and there are thousands of other WiFis. Click here to check if your dormitory is equipped with WiFi operated by Selfnet. That WiFi is simply called "Selfnet".
And then there is WiFi run by many of our members. That's what we call "user WiFi" and it is almost as diverse as our members are. We will try to help with both kinds of WiFi here.

In both cases one more thing should be understood: A student dormitory is what is sometimes called a "densely populated environment".
From technical point of view that means we have a lot of WiFi devices per square meter in the dormitories. (and out-side of them connecting through windows, and on the roof and even in parking lots...)
Just to give you an idea: Most of the students have more than 5 device simultaneously connected to WiFi. And in the same way as you treat your room mates with respect and consider "live and let live" the motto of a reasonable human interaction, so do your devices.
It seems that quite a few students forget how many WiFi devices they actually use. There is the obvious laptop, smartphone, iPad and the occasional watch being connected. But what about your Alexa, your smart home speaker, your TV, your game console(s), your smart light bulb, .... yes these are all there. Most of them all the time.

And yes, they do interfere with one another. Why? Because they do share time on the WiFi network. - That is called air-time.
Very much in the same way as in good old public radio broadcasts, two speakers cannot talk at the same time and be understood. They do speak alternating. One after the other. And that is what your devices do. And even worse they cannot talk and listen at the same time.
However unlike most humans, many of your devices still talk without any active connection / conversation. They check for updates and new messages, they report statistics, ensure the correct time is displayed and just make sure every other device knows they are still there in order to still receive messages.
That brings me to the first piece of advice:
When you are not at home consider switching of some of your devices.
Effect: Medium, plus you are being nice to your room mates.

Yes, you likely do not need to do this at your parents house. And that is nice.
Please keep in mind that in the student dormitories lots of these devices are used in a smaller, denser, environment. Just consider how many devices you are using and how many device your room mates are using. Does that sum up to 30? 40? 42?
Whatever the count might be - it is very likely higher than at your home.

On different frequencies - Or why you should avoid 2.4GHz

As mentioned above, there are 2.4GHz WiFis and 5.0GHz WiFis. And the later ones are the ones to use.
On a 2.4GHz WiFi the maximum number for WiFis in parallel without causing effects - or interference - for the other WiFis is 3. Now a quick look at the number of WiFis you can see at the moment will very likely show more than 3.
Interference does not mean that you cannot connect. It means you need to share with even more parties "be even nicer / more polite to other devices". Imagine the difference between having one sibling and seven siblings.
To make things worse 2.4GHz is a very popular frequency. You have already counted the number of devices using WiFi for you and your room mates. Now add those with Bluetooth.
Why? Because it is relying the same frequency and Bluetooth usually has priority over WiFi. And while you're at it - please add microwaves, smart home devices (yes, all of them) and remote door openers and all other kinds of remote controls.
Yes, these devices are all on 2.4GHz. Why? - Because device manufacturers can use this frequency free of charge. (Ok, for the microwave oven that's a lie - here you cannot use a different frequency)
Use 5.0GHz WiFi wherever you can. See below an how to do it.
Effect: Highest

If you care use 5.0GHz WiFi that provides you with at least 9 different networks free of interference. There can be more as we can adjust the "channel size".
Knowing if your device actually is connected to a 5.0 GHz network is not as simple. Yes, there are standards for this, but we spare you with that.
For most up-to-date operating systems it is relatively save to assume that they will prefer 5.0GHz WiFi if available. One exception to that rule: iPhones and iPads. However, several devices cannot use 5.0 GHz WiFi. And here are some popular ones that cannot do it: iPhones generation 4 and older, several amazon echo devices (yes, the 2020 entry model still cannot do it; however all of the fireTV devices can do it), older Google / Nest speaker and streaming sticks, many smartphones released prior to 2019, almost all smart home devices, including the Sonos smart speakers and streaming speakers.
Do not run your own WiFi if there is Selfnet WiFi in your dormitory.
Effect: High

If you are operating your own WiFi router or access point

We are sorry but for several reasons there is no Selfnet WiFi in every building. And for those of you in buildings with Selfnet WiFi who still run their own WiFi: Just don't. (unless you absolutely have to). However if you are forced to operate your own WiFi here are some tips on what to do:
1. Switch off 2.4GHz WiFi
Even if you are not using it, it still does consume air-time.
2. If you have to run a 2.4GHz WiFi because one of your devices does not support 5.0GHz: Just change it to the one standard that you do need.
We see a lot of older WiFi standards around the dormitories. If you have a WiFi router that is running WiFi for 20 year-old devices, you probably do not need it. However it is usually active by default.
The problem is that these older - and slower standards - waste even more air-time. Reason for this is, that your WiFi router / access point sends out little messages saying "here I am connect if you dare" and these are sent with the slowest standard it is configured to support.
Look for a supported WiFi Standard (802.11) of N or even better AC (please avoid using b/g/n or g/n - remember, configurations which list several letters will use the slowest one to say "here am I")
3. Nice persons don't scream - please reduce the signal strength
Yes, this is totally counter-intuitive, because what you want is a strong WiFi connection. You should do it anyway.
Having your WiFi signal on full power all the time is the equivalent of having a screaming conversation across the dormitory while all widows and doors are open and everyone in the dormitory is at home. You can have your conversation if you are the only one doing it, but imagine everyone doing it.
4. If you are using 2.4GHz WiFi: For god's sake stop using channel 1
There are 12 channels available for 2.4GHz WiFi in Germany. Most - especially cheaper - WiFi routers / access points are by default configured to use WiFi on channel 1.
Many people do not bother to change that. All your messages do queue up at channel 1 now (remember one is talking at a time and that is not a one per WiFi but one per frequency)... We aren't all trying to use the same door of the train why trying this for WiFi?
Use "automatic" or channels 5 or 9. Note: Some routers provide channels 13 and 14. However these are legally not available for public use in Germany.

One last point with regards to the signal strength: Your smartphone or laptop show you some bars to indicate the reception quality of the WiFi. That indicates your device has a good at reception. It does not tell you anything about sending / transmitting rates.
Especially for our WiFi access points we can tell you that the antennas are really, really good. That ensures that you receive the WiFi. However the antennas - especially in smartphones and tablets - are way smaller than in the access points.
As a comparison imagine you are having a conversation and the other person is using a megaphone. You can hear the other person from far away. But even if you are screaming you might not be loud enough for the other person to understand what you're saying. Same here. Therefore:
If signal is just at 30 - 50% reception strength: Change the location. Sometimes 30cm make a huge difference in reception.
Effect: Medium

One last piece of advice: Cables are a blessing

Use a cable for stationary devices
Effect: Very high
Sure, you do not want to use a cable to connect your smartphone but what about your game console? Or your smart speaker, or your Laptop while you are sitting at your desk?
Connecting with a network cable (given the cable is not broken) provides up to 1GBit/s. That is more than most WiFi can do. Even if when there is just one device connected.

We do hope this helps a bit to get a better connection to the WiFi network. In case you have questions on how to do one or the other thing mentioned here - please reach out via e-mail / chat or visit us during the office hours once Corona-restrictions are lifted.

Cheers,
Your Selfnet-Team

And for those interested here are some very useful details:
1. List of WiFi-Standards for 2.4 GHz and 5.0 GHz 2. Which 2.4GHz Channels do not overlap or interfere 3. Example signal strength in an apartment - see how small changes in location make a huge difference

For our network to run smoothly there are a lot of different things to do: management of the equipment (including buying new stuff and getting service), taking care of servers for the network or additional services, debugging problems like this or connecting new dormitories to our network.

If you want to volunteer, it doesn't matter if you are a pro or a starter: Selfnet offers the opportunity to learn everything required. If you are interested in technical stuff, programming, public relations, project management or anything else: We would be glad to welcome you in our team! Just visit our support hours (once the office hours are re-opened).

The Selfnet-Team

Deutsche Übersetzung

Warum ist der WLAN-Empfang nicht so gut wie er sein sollte?

Wenn du mit Empfang und Geschwindigkeit des WLANs unzufrieden bist, solltest du zunächst sicherstellen, dass du das Selfnet WLAN verwendest (SSID, also der Name des WLANs ist "Selfnet"). Auch für den Betrieb eines eigenen WLANs findest du im Folgenden Tipps zum Verbessern der Performance.

Wir erhalten häufig Feedback zu langsamen Netzwerkgeschwindigkeiten - vor allem bezüglich via WLAN verbundener Geräte.
In diesem Artikel werden wir Ursachen dafür erklären und - wichtiger - was du dagegen unternehmen kannst. Das Technik-Gerede versuchen wir dabei auf ein Minimum zu beschränken. Solltest du dich nur für die Lösungen interessieren, lies weiter. Wenn der Text zu technisch wird, kannst du mit dem Lesen aufhören und uns direkt kontaktieren, zum Beispiel via E-Mail, Chat oder, in einer Zeit nach Corona, auch wieder zu unseren Supportzeiten. Wir werden unser bestes tun, die Thematik zu erklären.

Praktische Lösungsansätze - falls du nur an diesen interessiert bist - sind in diesem Artikel fett markiert.
Moment mal, Selfnet betreibt das Netzwerk, was soll ich also machen?
Eines vorweg: die WLAN-Performance kannst (und solltest?) du zum Großteil selbst beeinflussen.

Unser Netzwerk unterscheidet sich vom WLAN Zuhause

Zunächst muss eine wichtige Unterscheidung getroffen werden: Es gibt das von Selfnet betriebene WLAN und es gibt tausende andere WLANs.
Klicke hier um nachzusehen, ob Selfnet-WLAN in deinem Wohnheim verfügbar ist Dieses WLAN heißt einfach "Selfnet".
Darüber hinaus gibt es von unseren Mitgliedern betriebene WLANs, die so unterschiedlich sind wie unsere Mitglieder selbst. Diese nennen wir "User Wifi". Im Folgenden werden wir versuchen euch mit beiden WLAN-Arten zu helfen.

In beiden Fällen muss zunächst verstanden werden, dass Studentenwohnheime eine Umgebung mit hoher Bevölkerungsdichte sind.
Aus technischer Sicht bedeutet dies eine hohe Anzahl von WLAN-Geräten pro Quadratmeter in den Wohnheimen. (und auch außerhalb, zum Beispiel auf dem Dach oder auf dem Parkplatz...)
Um dir eine grobe Vorstellung zu geben: Die meisten Studierenden besitzen über 5 Geräte, die dauerhaft mit dem WLAN verbunden sind. Und genauso wie du deine Mitbewohner und Mitbewohnerinnen mit Respekt behandelst und "leben und leben lassen" als vernünftiges Motto für menschliche Interaktion betrachtest, tun dies auch deine Geräte.
Viele Studierende vergessen scheinbar, wie viele WLAN-Geräte sie tatsächlich verwenden. Dazu zählen die offensichtlichen Geräte wie Laptop, Smartphone, iPad und gelegentlich auch mit dem Internet verbundene Uhren. Aber was ist mit deiner Alexa, deinen Smart Home Lautsprechern, deinem Fernseher, deinen Spielekonsolen, deiner smarten Glühbirne...? All diese Geräte sind mit dem WLAN verbunden. Die meisten davon dauerhaft.

Und ja, diese Geräte beeinträchtigen sich gegenseitig. Warum? Sie teilen sich Zeit im WLAN Netzwerk. Dies wird als Airtime bezeichnet.
So wie beim guten alten Radio Rundfunk, wo auch nicht zwei Sprecher gleichzeitig reden und verstanden werden können. Sie sprechen abwechselnd. Einer nach dem Anderem. Deine Geräte verhalten sich genauso. Und erschwerend kommt dazu, dass sie nicht gleichzeitig reden und zuhören können.
Anders als die meisten Menschen reden deine Geräte jedoch auch ohne einer aktiven Verbindung/Unterhaltung. Sie sehen nach Updates und neuen Nachrichten, senden Statistiken, stellen sicher dass die korrekte Zeit angezeigt wird oder teilen anderen Geräten mit, immernoch da und für den Empfang von Nachrichten bereit zu sein. Womit wir beim ersten Tipp angekommen sind:
Schalte ein paar deiner Geräte ab, wenn du nicht Zuhause bist.
Effekt: mittel, und du tust deinen Mitbewohnerinnen und Mitbewohnern einen Gefallen

Vermutlich musst du das nicht bei deinen Eltern Zuhause tun. Und das ist gut.
Aber denke daran, dass in Studentenwohnheimen eine Menge solcher Geräte in einer kleineren Umgebung genutzt werden. Überlege wie viele Geräte du und deine Mitbewohner und Mitbewohnerinnen verwenden. Zusammengerechnet ergibt das 30? 40? 42?
Wie viele Geräte es auch immer seien mögen - es sind wahrscheinlich mehr als bei dir Zuhause.

Auf einer anderen Wellenlänge - Oder warum du 2,4GHz vermeiden solltest

Wie bereits genannt, werden zwei Frequenzen für WLAN: 2,4GHz und 5GHz. Und zweiteres sollte verwendet werden.
Die maximale Anzahl an 2,4GHz WLANs, die parallel betrieben werden können ohne sich gegenseitig zu beeinflussen oder zu stören, beträgt 3. Wenn du nach siehst, wie viele WLANs du im Moment sehen kannst, ist die Anzahl höchstwahrscheinlich größer als 3.
Stören sich zwei WLANs bedeutet dies nicht, dass du nicht mit diesen verbinden kannst. Es bedeutet jedoch, dass du mit noch mehr Parteien teilen musst, "noch höflicher zu anderen Geräten seien musst". Stell es dir vor wie den Unterschied dazwischen sieben oder nur einen Geschwister zu haben.
Erschwerend kommt dazu, dass 2,4GHz eine sehr beliebte Frequenz ist. Du hast bereits die Anzahl an WLAN-Geräten für dich und deine Mitbewohnerinnen und Mitbewohner ermittelt. Nun addiere dazu die Anzahl an Bluetooth-Geräten.
Warum? Bluetooth verwendet die selbe Frequenz und hat darüber hinaus in der Regel eine höhere Priorität als WLAN. Und wenn du schon dabei bist, kannst du auch gleich Mikrowellen, Smart-Home-Geräte (ja, alle) und Fernbedienungen aller Arten dazu zählen.
Ja, all diese Geräte verwenden 2,4GHz. Warum? Weil Hersteller dieser Geräte diese Frequenz kostenfrei nutzen können. (Ok, bei Mikrowellen stimmt das nicht, hier keine anderen Frequenzen verwendet werden.)
Verwende, wenn möglich, 5.0GHz. Siehe unten wie das geht.
Effekt: am höchsten

5.0GHz ermöglicht den parallelen betrieb von mindestens 9 unterschiedlichen WLAN-Netzwerken ohne das diese sich gegenseitig stören. Diese Anzahl kann durch anpassen der "Kanalbreite" erhöht werden.
Herauszufinden, ob dein Gerät mit einem 5.0GHz Netzwerk verbunden ist, ist nicht so einfach. Ja, es gibt Standards dafür, aber wir ersparen dir das.
Bei den meisten aktuellen Betriebssystemen kann davon ausgegangen werden, dass sie, wenn möglich, 5.0GHz WLAN bevorzugen. Als Ausnahme sind dabei jedoch iPhones und iPads zu nennen.
Einige Geräte können 5.0GHz WLAN jedoch nicht verwenden. Beispiele für verbreitete Geräte, die dazu nicht in der Lage sind, sind iPhone der Generation 4 und älter, einige Amazon Echo Geräte (ja, Einsteigermodelle aus 2020 können es immernoch nicht, FireTV-Geräte sind hingegen 5.0GHz-fähig), ältere Google/Nest Lautsprecher und Streaming Sticks, viele vor 2019 veröffentlichte Smartphones und fast alle Smart Home Geräte, einschließlich Sonos Smartspeaker und Streaming Speakers.
Betreibe nicht dein eigenes WLAN wenn Selfnet WLAN in deinem Studentenwohnheim verfügbar ist.
Effekt: hoch

Betrieb eines eigenen WLAN Routers oder Access Points

Es tut uns Leid, aber aus mehreren Gründen ist Selfnet WLAN nicht in allen Gebäuden verfügbar. Und an diejenigen, die trotz Selfnet WLAN ihr eigenes WLAN betreiben: bitte, hört auf (außer es geht nicht anders)
Falls du doch dein eigenes WLAN betreiben musst, sind hier ein paar Tipps:
1. Schalte 2.4GHz ab
Selbst wenn du es nicht verwendest, kostet es trotzdem Airtime. 2. Wenn du 2.4GHz WLAN benötigst weil eines deiner Geräte 5.0GHz nicht unterstützt: Konfiguriere es nur für den Standard, den du benötigst.
Wir sehen eine Menge an alten WLAN Standards in den Studentenwohnheimen. Wenn du deinen WLAN-Router für 20 Jahre alte Geräte betreibst, benötigst du das wahrscheinlich nicht. In den Standardeinstellungen ist es in der Regel jedoch trotzdem aktiviert.
Das Problem dieser alten, und langsameren Standards ist, dass sie noch mehr Airtime verschwenden. Das liegt daran, dass dein Router/Access Point kurze "Verbinde dich mit mir, wenn du dich traust"-Nachrichten verschickt und diese mit dem langsamsten Standard, der unterstützt wird, übertragen werden.
Kontrolliere, ob deine Geräte WLAN Standard (802.11) N oder, besser, AC unterstützen. (Bitte vermeide b/g/n oder g/n - Denke daran, Konfigurationen, die mehrere Buchstaben aufführen, verwenden den langsamsten Standard für "Hier bin ich"-Nachrichten)
3. Nette Leute Schreien nicht - bitte reduziere die Signalstärke
Ja, das wirkt kontraintuitiv, du willst ja eine starke WLAN-Verbindung. Du solltest es trotzdem tun.
Das WLAN-Signal auf volle Stärke zu stellen ist in etwa so, als würdest du dich quer über das Studentenwohnheim schreiend unterhalten, während alle Fenster und Türen geöffnet und alle Bewohner und Bewohnerinnen Zuhause sind. Solange du die einzige Person bist, die das tut, funktioniert das, aber stelle die vor jeder würde das tun.
4. Wenn du 2,4GHz verwendest: Um Himmels Willen, höre auf Kanal 1 zu verwenden
In Deutschland sind 12 2,4GHz Kanäle verfügbar. Die meisten, vor allem günstige Router und Access Points verwenden in der Standardeinstellung Kanal 1.
Die meisten Leute ändern das nicht. Deine Nachrichten reihen sich nun alle in Kanal 1 in die Warteschlange (erinnere dich, nur ein Gerät kann gleichzeitig reden. Das ist ein Gerät pro Frequenz, nicht pro WLAN)... Wir versuchen nicht alle durch die selbe Tür in einen Zug einzusteigen, warum sollten wir das mit WLAN versuchen?
Verwende "automatisch", Kanal 5 oder Kanal 9. Anmerkung: Manche Router bieten die Kanäle 13 und 14 an. In Deutschland sind diese jedoch nicht zur öffentlichen Verwendung freigegeben.

Ein letzter Punkt bezüglich der Signalstärke: Dein Smartphone oder Laptop zeigt dir Striche an, um die Qualität deiner Verbindung darzustellen. Dies gibt nur die Empfangsqualität an. Es sagt nichts über die Sendegeschwindigkeit aus.
Wir wissen, dass die Antennen in unseren Access Points wirklich, wirklich gut sind. Dies stellt sicher, dass du WLAN empfängst. Die Antennen in Smartphones und und Tablets sind hingegen viel kleiner als die in den Access Points.
Als Vergleich kannst du dir vorstellen, eine Unterhaltung mit einer Person mit einem Megaphon zu führen. Du kannst diese Person zwar auch aus großer Entfernung hören, aber selbst wenn du schreist bist du vielleicht nicht Laut genug um verstanden zu werden. Hier gilt das selbe. Daher:
Wenn die Signalstärke nur bei 30 - 50% liegt: Ändere deine Position. Schon 30cm können manchmal einen großen Unterschied machen.
Effekt: mittel

Ein letzter Ratschlag: Kabel sind ein Segen

Nutze Kabel für stationäre Geräte
Effekt: sehr hoch

Klar, du kannst kein Kabel für dein Smartphone verwenden. Aber was ist mit deiner Spielekonsole? Oder deinem Smartspeaker? Oder deinem Laptop, während du am Schreibtisch sitzt?
Dich mit einem Kabel zu verbinden gibt dir 1GBit/s (vorausgesetzt das Kabel ist nicht kaputt). Das ist eine höhere Geschwindigkeit als die meisten WLANs bieten können, selbst wenn sie mit nur einem Gerät verbunden sind.

Wir hoffen wir konnten dir ein wenig helfen, deine WLAN-Verbindung zu verbessern. Falls du Fragen hast, wie du die hier aufgeführten Vorschläge umsetzen kannst, schreibe uns via E-Mail/Chat oder besuche unsere Supportstunden nachdem die Corona-Einschränkungen aufgehoben wurden.

Viele Grüße
Dein Selfnet Team

Hier sind noch ein paar nützliche Details für die, die sich dafür interessieren: 1. Eine Liste mit WLAN-Standards für 2,4GHz und 5,0GHz 2. Welche 2,4GHz Kanäle überschneiden und stören sich nicht 3. Beispiel Signalstärke in einer Wohnung - Welchen großen Unterschied ein kleine Positionsänderung haben kann

Möchtest du in Zukunft bei Selfnet mitmachen und dich ehrenamtlich um solche und andere interessante technische Dinge kümmern? Um das Wohnheimsnetz ordentlich zu betreiben gibt es viele verschiedene Dinge zu tun: Verwaltung der Hardware (inkl. Neukauf von Hardware und mit dem Hersteller bezüglich Service arbeiten), Verwaltung von Servern und anderen Netzwerkdiensten, Analyse von Problemen oder neue Wohnheime an das Wohnheimnetzwerk anschließen.

Wenn du mitmachen möchtest geht es nicht um Vorwissen. Wichtiger ist es Spaß zu haben und noch etwas sinnvolles/praktisches neben dem Studium zu tun. Wenn du dich für Technik, Softwareentwicklung, Öffentlichkeitsarbeit, Projektmanagement oder vieles andere interessierst: Wir freuen uns dich bei uns begrüßen zu dürfen! Besuche einfach eine unserer Sprechstunden, (sobald diese wieder stattfinden.).

Das Selfnet-Team

How to DOS yourself

Deutsche Übersetzung weiter unten.

Maybe you have noticed it throughout last weekend - we had several issues with our network stability.

Friday we started upgrading software on several core routers. That's why we first thought the necessary reboots caused the problems. But the interruptions did not stop after the update was complete and even got worse.

A reason were several messages like this

vaih-core-1 dc-pfe: PANIC PANIC PANIC PANIC PANIC PANIC

or this

vaih-core-2 fpc0 SCHED: Thread 24 (PIC Periodic) ran for 1914 ms without yielding

This caused lags, unresponsive and even unreachable devices. As we are using routing protocols to manage our traffic (OSPF and BGP) which require constant communication between the devices. As a result our devices can select the optimal path to send packets. So the unresponsive devices caused routing changes in the network protocols as the backups links took over.

As soon as the backup links took over the affected devices became reachable again and the routing changed back to the primary path. This repeated between 3 and 20 times and took between 30 seconds and 20 Minutes.

Finding the the Root Cause

The logs showed an activation of the devices DDoS-Protection measures, repeating messages like the ones above and dying OSPF- or BGP-connections.

The sporadic nature of this problem made it complicated to debug. You needed to be permanently present to notice the problem when it started and before it was over to run several commands to obtain log files and debug information.

First we thought there was a configuration difference between our two NAT servers, as the traffic was handled by one device when we started upgrading and by the other afterwards. But we could disregard this theory shortly after since the other device showed the same behaviour.

Another possible cause could have been the connection between the routers and the NAT servers but we were also able to verify that the setup was correct.

Directly after the incident started, it was more or less obvious for us the DDoS-Protection was just a symptom but not the cause. It was the same as with the Juriper-Bug. So we followed the same investigation pattern: Looking at the packets sent through the NAT when the lags started.

The result were a lot of packets to "event.selfnet.de", the public IPv4 NAT-Address for the wireless network we use at public events. Around 2.2% of the 3 seconds we took as a sample were directed to this IP. It was a mixture of UDP and a lot of NTP packets. This caused some concern. UDP could be explained with some former unknown - still active - access point. But there should be nobody using this IP for NTP updates.

So we looked at the source of the packets. Some were from a german vServer provider but the NTP-Packets originated mainly from China-Telecom... weird, why should they go around the globe to call us for a NTP update...

Solving the mystery

So now we wanted to verify it is legitimate traffic and found out: A simple ping to the public IPv4 Address returned with an error message "TTL expired" -- which should not happen in a local network...

Further lookups showed IP-Packets bouncing between our core routers (in the internal network) and the edge routers (in the external networks).

The edge routers sent the packets to our NAT (where they should go), but the NAT did not "translate" them. We expect those packets to be translated to the address of the host that opened the connection. Since there was no open connection, the packets should be dropped. But here, the NAT did forwrad the packets without translation. So an IPv4 packet arrived in our core network, that had a public IPv4 address as destination. Since we only use private address space inside the network, the routers have no route for this. So the packet gets forwarded in the direction of the default-route, which is: to the internet. So the packet gets sent back, though the NAT again. This time, the packet isn't expected to be translated, because it didn't originate inside our network and already has a public source address (from China Telecom). So our edge router receives the packet, and we start over. So these packets go back and forth, tens or maybe even hundrets of times, until their time-to-live expires.

To make matters worse all of that happened with 40 GBit/s between the devices while the packets still needed to be processed by the cores routing engine. So the "DDoS Violations" were correct, we DDoS'ed ourself with 40 GBit/s...

After this the pattern was clear to us: All IPs of our pool for internal SNAT (like the "Event" wireless network) were routed in a loop as the NAT did just forward them, even when there was no valid state from an internal IP.

So one packet from an external address was multiplied into (up to) 255 of them which were transmitted with 40 GBit/s between the devices. If you think about our observation before: We had 4000 Packets in 3 seconds. This times 255 translates to roughly a million packets in our internal network... Well, sounds reasonable the DDoS-Protection tried to protect the routing engine of the devices and it became unreachable.

But as the routing engine stopped responding, this caused the BGP- and OSPF-Sessions to die. This started a domino effect: Routing switched to the backup paths, other routers were impacted and when the first device became responsive again (since the load suddenly disappeared), the routing started to switch back to the primary connections - and caused the whole loop again.

The Fix

Finally we knew what we had to do: The packets that do not translate at the NAT should be dropped at the end of handling them.

The fix was applied yesterday around 9 p.m. and since then we haven't detect another larger disruption.

For the ultimate reason we can only speculate: * Was it the new Software? Is there a command or anything which is interpreted in a different way? * Did the reboot of our device change something? * Did somebody try to scan our network for vulnerabilities? * ...?

For now we can not say what is more likely. We can only say that our NAT was not configured in the correct way.

And the moral of the story? Do not trust your own NAT if you already have a history!

Thanks to all of our members who helped in any way to solve this problem. We also apologize to all users of our network, as it wasn't quite stable during the period of recognizing the bug and debugging it.

Do you want to participate in taking care of such problems in the future? For our network to run smoothly there are a lot of different things to do: management of the equipment (including buying new stuff and getting service), taking care of servers for the network or additional services, debugging problems like this or connecting new dormitories to our network.

If you want to volunteer, it doesn't matter if you are a pro or a starter: Selfnet offers the opportunity to learn everything required. If you are interested in technical stuff, programming, public relations, project management or anything else: We would be glad to welcome you in our team! Just visit our support hours (once the office hours are re-opened).

The Selfnet-Team

Deutsche Übersetzung

Wie man sich selbst per DOS angreift

Eventuell hat es der ein oder andere am Wochenende mitbekommen: Wir hatten einige Probleme was die Stabilität der Verbindungen im Netzwerk anging.

Am Freitag hatten wir einige Software-Upgrades auf unseren Core-Routern durchgeführt, weshalb wir dies erst auf die neue Software und die Neustarts im Netz schoben. Doch die Ausfälle hörten auch nach dem Abschluss der Arbeiten nicht auf.

Der Grund waren einige Meldungen unserer Core-Geräte wie diese

vaih-core-1 dc-pfe: PANIC PANIC PANIC PANIC PANIC PANIC

oder auch diese

vaih-core-2 fpc0 SCHED: Thread 24 (PIC Periodic) ran for 1914 ms without yielding

Bei dem Betrieb der Geräte äußerte es sich dabei so, dass diese stockten, nicht mehr reagierten und dann teilweise auch nicht mehr erreichbar waren. Das führte dann wiederum dazu, dass das Routing im Netzwerk auf die Backup-Wege umschwenkte.

Kurz danach war das Gerät dann wieder erreichbar und das Routing schwenkte wieder auf die Hauptleitungen. Das ganze wiederholte sich dann teilweise 3-20 mal über eine Zeitspanne von teilweise nur 30 Sekunden bis 20 Minuten.

Ursachenforschung

In den Logs sah man teilweise die DDOS-Protection anschlagen, wiederholende Meldungen wie die oben und sterbende OSPF-/BGP-Prozesse.

Problematisch war das sehr sporadisch Auftreten des Problems, was die Fehlersuche nicht so einfach machte, da man dauerhaft am Gerät sein musste um während einer Unterbrechung noch Befehle abzusetzen oder Log-Dateien auszulesen, bevor diese wieder vorbei war.

Anfangs war eine Vermutung, dass es eine Diskrepanz zwischen unseren beiden NAT-Servern gibt, da vor den Systemupgrades der Traffic über das eine Gerät ging, danach über das andere. Dies wurde kurz danach aber bereits widerlegt, da auch das andere Gerät die Probleme zeigte.

Da dies nicht die Ursache war ein weiteres mögliches Problem die Verbindung zwischen den Routern und dem NAT, aber auch das konnte ausgeschlossen werden.

Von Beginn an war relativ klar, dass die aktivierte DDOS-Protection nur ein Symptom und nicht die eigentliche Ursache war, da es bei dem Juriper-Bug ähnlich aussah. Also haben wir wie bei jenem Bug auf dem NAT die Pakete die weitergeleitet wurden mal angesehen als sich ein weiterer Ausfall ankündigte.

Das Ergebnis waren viele Pakete an event.selfnet.de, die öffentliche IPV4 NAT-Adresse für u.a. das Event-WLAN. Insgesamt 2,2% bei den knappen 3 Sekunden die wir uns ansahen. Die Pakete bestanden aus UDP Paketen mit kaum Inhalt und relativ viel NTP. Das machte uns schon etwas stutzig. UDP könnte man sich eventuell noch erklären wenn irgendwo das WLAN noch aktiv wäre, auch wenn kein Event ist, aber NTP-Anfragen sollten da nicht aktiv hin geleitet werden.

Also haben wir uns angesehen, wo die Pakete herkamen. Einige Pakete kamen von einem vServer-Anbieter in Deutschland und die NTP-Pakete hauptsächlich von der China-Telecom. Hmmm... komisch, wieso sollten die bei uns NTP machen wollen...

Des Rätsels Lösung

Daraufhin wollten wir verifizieren, ob der Traffic überhaupt legitim ist und stellten fest, dass ein Ping an die öffentliche IP mit der Meldung "TTL expired" zurück kam. Das sollte im lokalen Netzwerk eher nicht so sein...

Beim weiteren Betrachten fiel dann auf, dass die IP-Pakete zwischen unseren Core-Routern (dem internen Netz) und den Edge-Routern (dem externen Netz) Ping-Pong spielten.

Der Edge-Router schickte die IP-Pakete zum NAT (wo sie ja auch hin sollten), das NAT hat diese aber nicht "übersetzt" auf eine interne IP aber schickte es trotzdem weiter und der Core schickte das ganze wieder zurück zum NAT, da die IP ja durchs NAT musste.

Und das ganze mit 40 GBit/s wobei die IP-Pakete zum Routing an die Routing-Engine weitergeleitet werden mussten. Im Endeffekt war das mit dem "DDOS-Violations" also schon richtig, wir haben unsere Router selbst mit 40GBit/s gedost...

Daraufhin ist das Muster auch deutlich erkennbar geworden: Alle IPs aus dem Bereich für die internen SNAT-Dienste (wie eben das Event-WLAN) wurden im Kreis geschickt, da das NAT diese einfach weiterleitete, wenn es keinen passenden State von intern gab, zu den man die Anfrage zurück übersetzen könnte.

Damit wurde aus einem IP-Paket von extern eben bis zu 255 die mit 40 GBit/s zwischen den Geräten hin und her flogen. Wenn man nun noch bedenkt dass es in dem kurzen Zeitraum den wir uns ansahen knapp 4000 solcher IP-Pakete von extern waren kommt man auf etwa eine Million IP-Pakete intern... Irgendwo verständlich, dass dann der DDOS-Schutz anspringt und die Routing-Engine nicht mehr erreichbar ist.

Das die Routing-Engine der Geräte nicht mehr erreichbar war sorgte dann letztendlich dafür, dass die OSPF- und BGP-Sessions ausliefen. Das sorgte dann dominomäßig dafür dass dann im Routing viel umgestellt wurde und teilweise das Problem einfach den nächsten Router traf. Wenn die Routing-Engine wieder erreichbar war, gings wieder zurück auf Ursprung und wenn dann immernoch so viele IP-Pakete da waren, waren wir wieder am Anfang des Kreises und alles begann von neuem.

Der Fix

Nachdem wir dies erkannt hatten konnten wir die Pakete die nicht zum NAT passen am Ende der NAT-Regeln einfach verwerfen.

Dieser Fix wurde gestern Abend ~21 Uhr eingespielt und seitdem konnte wir keine weiteren großen Ausfälle feststellen.

Über die Ursache kann man nun nur spekulieren: * War die neue Software schuld? Wird irgendwas anders interpretiert? * Hat der Neustart der Geräte etwas ausgelöst? * Hat jemand versucht herauszufinden ob unser Netz verwundbar ist? * ...?

Momentan kann man hier denke ich keine genauere Aussage treffen als die, dass letztendlich unser NAT falsch konfiguriert war.

Und die Moral von der Geschicht? Trau deinem eigenen NAT nicht!

Wir danken hiermit allen Mitgliedern, die bei der Fehlersuche und Problemlösung beteiligt waren. Auch wollen wir uns bei den Mitgliedern entschuldigen, die während dieser Zeit nicht auf die übliche Stabilität des Wohnheimnetzwerks zählen konnten.

Möchtest du in Zukunft bei Selfnet mitmachen und dich ehrenamtlich um solche und andere interessante technische Dinge kümmern? Um das Wohnheimsnetz ordentlich zu betreiben gibt es viele verschiedene Dinge zu tun: Verwaltung der Hardware (inkl. Neukauf von Hardware und mit dem Hersteller bezüglich Service arbeiten), Verwaltung von Servern und anderen Netzwerkdiensten, Analyse von Problemen oder neue Wohnheime an das Wohnheimnetzwerk anschließen.

Wenn du mitmachen möchtest geht es nicht um Vorwissen. Wichtiger ist es Spaß zu haben und noch etwas sinnvolles/praktisches neben dem Studium zu tun. Wenn du dich für Technik, Softwareentwicklung, Öffentlichkeitsarbeit, Projektmanagement oder vieles andere interessierst: Wir freuen uns dich bei uns begrüßen zu dürfen! Besuche einfach eine unserer Sprechstunden, (sobald diese wieder stattfinden.).

Das Selfnet-Team