 Willkommen zu unserem ersten Talk. Das sind der Chrissy und der Casa. Beide sind vom Freifunk Braunschweig, seit 2014 dabei, also auch so lange, seitdem es den Freifunk Braunschweig gibt. Seit drei Jahren testen sie auch ihre Firma automatisiert, das machen sie, weil sie auch ein bisschen an ihrer Firma verändern. Und damit sie damit halt besser klarkommen, testen sie, versuchen sie automatisiert zu testen. Heute geht es primär um ihr Test Setup, weniger um die Veränderungen in der Firma. Und ja, also dann jetzt der volle admin automatisiert, gloren auf echter Hardware testen. Moin, moin, los gehts. Wie viele Freifunk Communitys benutzen auch wir gloren und so ein Gloren Release? Das ist ja getestet, aber dieses Gloren Release ist ja nicht das, was man am Ende auf seine Community freilässt. Denn per Design hat so ein Gloren ja noch eine Site-Konfiguration, die dafür für die Community draufkommt. Und viele Communities haben dann auch irgendwelche Pakete oder anderen Änderungen damit draufliegen. Zum Beispiel die Standard-Verordnung oder die Standard-Ort ihrer Knoten einzustellen im Config-Modus. Und auch die Backends sind ja alle leicht unterschiedlich. Und so ein Gerät ist, also es gibt ja nicht nur ein Gerät, für das man so ein Gloren baut, sondern es gibt eine Handvoll, also eine sehr große Handvoll Geräte davon. Und das alles hat uns dazu bewegt zu sagen, naja, so ein Gloren Release mal getestet sein. Aber wir wollen mit unserer Konfiguration da ja noch mal drauf testen. Und insgesamt mit unserem Projekt Parker haben wir relativ viele Änderungen, die auch relativ tiefgreifend in so ein Gloren eingreifen. Und das alles wollen wir natürlich testen und das natürlich automatisiert, denn wir sind ja faul. Ja, und für uns hat sich vor drei Jahren mal die Gelegenheit ergeben, von unserer Stadt Braunschweig eine finanzielle Förderung zu bekommen und einen Teil, den wir uns fördern lassen, wollten, warnen, automatisiert das Testnet. Und wir haben uns damals Fizide gesteckt für dieses Projekt und die möchte ich euch ja immer kurz erzählen und wie weit wir da gekommen sind vielleicht auch. Das erste, was wir damals erreichen wollten, war, wir möchten eigentlich in der Lage sein, unsere frischen Freifunk-Firmware-Images, die wir gebaut haben, vormöglichst überall zu testen. Wir haben damals gemerkt, wenn man erst so ein Bild macht und da läuft noch ein paar Stunden, wenn man echt viele Images bauen muss und dann ist man irgendwann später erst wieder dran und kriegt die richtige Hardware in die Hände, um das auch zu testen, dann dauern die Geliesprozesse unnötig lange. Und deswegen möchten wir eigentlich Hardware haben, die irgendwo liegt und die wir von dort aus benutzen können, ohne dass wir erst die passende Hardware aus dem Schrank zaubern müssen dafür. Und das funktioniert halt auch zusammen mit dem Testen, das sehen wir später. Ein weiteres Ziel, was wir erreichen wollten, war, wir wollten eigentlich so kleine Freifunk-Testbets zu guten Freifunkern aus unserer Community verteilen, von denen wir wissen, dass die Probleme mit dem Internet haben, zum Beispiel, weil das irgendein so ein unsägliches DS-Lite ist, oder, naja, weil es irgendwie ein Kabelnetz oder sowas ist, dann könnten wir halt sehen, wie sieht eigentlich aus deren Perspektive unser Freifunknetz aus, aber das haben wir bisher noch nicht geschafft. Die Hardware ist noch da, das müssen wir zugegebener Zeit mal angehen. Eine weitere Sache, die sehr gut funktioniert, ist automatisiertes Testen von Freifunkimages. Und zwar, wenn so ein Image aus unserem Bildprozess rausfällt, dann bringen wir das auf unsere Testininfrastruktur, schmeißen die Tests an, warten fünf bis zehn Minuten und dann haben wir ein Test-Result, wo wir dann sehen, naja, funktionieren die Dinge, die wir haben wollen eigentlich noch oder sind das Sachen kaputtgegangen. Das letzte Ziel ist, naja, für uns ist schon wichtig, dass Freifunk als Community funktioniert, also sowohl auf der Seite der Router, die wir aufstellen, aber auch auf der Entwicklungsseite. Und da möchten wir euch jetzt was davon zurückgeben und erzählen wir euch heute davon, dann habt ihr einen Steinbruch, wo ihr vielleicht ein paar Sachen von euch verwenden könnt, oder vielleicht wollt ihr das auch einfach so nachbauen, wie wir es haben und seid damit schon glücklich. Wenn man jetzt so Router fernsteuern möchte, gibt es so ein paar Probleme, will ich nicht sagen, wie Herausforderungen, die man lösen muss. Zum einen muss man halt irgendwie mit der Hardware-Interface, weil man möchte jetzt ja echte Hardware testen. Was heißt das? Naja, in der Regel will man irgendwie an den sehr geilen Anschluss von so einem Router ran, weil dann kann ich Low-Larrel mit dem Router und auch mit dem Router, mit dem Bootloader und auch mit dem Linux auf dem Router reden. Und das kann ich auch dann, wenn ich mir ein kaputtes Image geflasht habe oder beim Testen doch mal irgendwas kaputt geht. Also ich brauche die Serial, dann kann ich Low-Larrel fernsteuern. Dann möchte ich in der Lage sein, die Sturmversorgung für diesen Router zu schalten, weil dann kann ich den Router halt neu starten und komme auf jeden Fall definitiv wieder in den Bootloader, ganz egal welchen Zustand ich sonst bin. Und ich möchte in der Lage sein, Knöpfe an so einem Router zu drücken, weil mit gedruckten Knöpfen kann ich auch so was wie einen Druck von den Resets simulieren, mit dem ich dann zum Beispiel wieder den Config-Mode zurückwechsen kann, weil ich das dann später testen möchte. Unsere Router haben State, zum einen haben wir irgendwie so ein Configuration-State, das heißt wir unsere Router wissen mit welchen Gateways sie sich verbinden müssen, sie wissen welchen Namen sie haben und welche Positionen sie sind. Und sie haben auch solchen State wie VPN Keys, sei es jetzt für FastDio oder in unserem Fall häufig für WireGuard, aber das hat State, der auf den Router permanent drauf ist. Und zum anderen haben wir natürlich ein Runtime-State, das heißt unser Router befindet sich in einem Bootloader, befindet sich im Config-Mode, also im Linux oder befindet sich im normalen Running-Mode und all diesen State müssen wir auch mitmanagen. Unsere Router haben per Definition was mit Netzen zu tun, offensichtlich, das heißt auch darum müssen wir uns irgendwie darum kümmern, bei uns haben wir jetzt da im Moment einen sehr einfachen Weg gewählt, aber da ging ja noch mehr, da wird das so später noch ein bisschen was. Ja und wir müssen irgendwie schauen, wie ist das eigentlich mit Testing-Infrastruktur auf dem Target. Wir haben uns dafür ein ganz klares Nein entschieden, wir möchten keine spezielle Testing-Infrastruktur auf dem Target haben, sondern wir möchten, dass all unsere Testing-Infrastruktur außen rum ist und wenn wir auf dem Target was brauchen, dann müssen wir das im Test mitbringen, so dass wir mit einem Vanilla-Gluon, was abgesehen von der Side-Konfiguration genau so oft getappt liegt, halt auch schon testen können. Und damit haben wir auch die minimalste Beeinflussung, die wir mit dem Test erreichen können. Wie sieht das Ganze dann im Hubware-Aufbau aus? Nun, wir haben halt irgendwie einen Router, den wir testen wollen und ich habe jetzt hier schon wieder zum zweiten Mal den 8.1.40er gezeigt und ja, unser erstes Testbett, das wir aufgebaut haben, benutzt genau so ein Router. Warum zwei Gründe, bevor sich die Zehnenegel hochrollen oder vielleicht auch trotzdem? Zum einen, man hat da von Kilogrammweise rumliegen, warum will man sie nicht verwenden, wenn sie kaputt sind, mit man halt den nächsten, man verliert da nicht viel mit. Und das andere ist, zumindest mit unserem Project Parker Freifunknetz, was halt auf Wirecard aufsetzt, funktioniert in die Geräte noch ganz brauchbar und solange Lohen sie weiter unterstützt, sehen wir gerade keinen Grund, sie loszuwerden, also testen wir auf der kleinsten Hardware, die unterstützen wollen. Zu jedem Router gibt es einen Test-Server oder zu Ende-Routern gibt es jeweils einen Test-Server an einem Ort, das sind bei uns Raspberry Pies, weil die sind zu klein und billig und sie haben halt diese GPIOs dran, mit denen wir später noch Dinge schalten können. Wir haben ein Labornetz, weil halt nur diese Geräte drin sind und in denen es Internet gibt, sodass unsere Router später auch unsere Infrastruktur erreichen können nach außen, wenn man testen will, ob sie auch online gehen können. Der Pi oder Test-Server ist auch in diesem Labnetz drin, sodass er da auch erreichbar ist. Unser Kleinnetz von unserem Router steckt mit einem USB-Ethernet-Dongel an unserem Test-Server, sodass wir dann auch klein durch unserem Router sein können. Und USB-Ethernet, weil so können wir dann auch mehrere mit Hubs quasi beliebig viele Router später an unserem Pi anschließen, was das Ganze skalierbar macht. Wir haben als Power Switch ein, so ein Vierfach-Relayboard aus dem Maker-Zubehör vom eBay, da steckt man auf der einen Seite 5 Volt und so ein GPIO von dem Pi dran und auf der anderen Seite hat man halt ein recht potentes Relay, was Dinge schalten kann. Das benutzen wir zum einen um einfach auf der neuen Volt-Seite oder auf der 12 oder 48 Volt-Seite unseres Routers Spannungsversorgung zu schalten. Und zum anderen benutzen wir die auch um die Taster zu überbrücken und können damit dann Tastendrücke simulieren. Und zu guter Letzt haben wir USB-Serial-Adapter, die auf der einen Seite im Router und die Serial-Angulettet sind und auf der anderen Seite halt per USB unseren Pi stecken. Das wirkt jetzt hier alles so wunderschön aufgeräumt auf dieser Folie und Gradlinie, der reale Aufbau ist natürlich wieder ein bisschen wirrer. Aber wenn sich jetzt denkt, man haben die das eigentlich auf einer Holzplatte gespackst, ja wir haben das auf einer Holzplatte geschraubt. Das war damals das Einfachste, was uns gerade entgegen kam und es hat sich bis heute gehalten, deswegen gab es keinen Grund, das zu ändern. Ihr seht unten den Router, mit dem wir testen, 8, 1, 4, 7, 1, Loch in den Deckelgebot, dass die Kabel rauskommen können. In der Ebene darüber sieht man rechts, glaube ich, das USB Serial-Adapter, links USB Ethernet, so ein bisschen hinter der Antenne versteckt. Oben rechts der Pi, oben links das Vierfache-Layboard, wo dann halt die Leitungen hingehen, die man mit diesen Relays schalten möchte. Softwareseitig könnte man natürlich jetzt anfangen, sich irgendwie kleine Shellscript oder Python Snippets zu bauen, die mit der Hardware-Interface, die GPIOs schalten oder irgendwie auf der Serial-Loft-Input warten. Das ist aber irgendwie ganz schön anstrengend und das wäre irgendwie cool, wenn man das abstrahiert hat. Und wir haben uns entschieden das mit Labgrid zu machen. Labgrid ist eine Python-Library, die dafür gedacht ist, so Embedded Linux Fernsteuer Hardware, Fernsteuer. Und das ist ein Open-Source-Projekt, findet man auf GitHub. Und wenn ihr am Blick in die Dokumentation werfen wollt, die gibt es bei ReadTheDocs.io. Das Klammer, ich arbeite für die Firma, die große Teile davon gesponsort hat. Das heißt, ich komme auch häufiger mit dem Ding in Berührung. Ja, wie sieht das dann aus, wenn man sich das mal anguckt? Labgrid, wie gesagt, ist eine Hardware Abstraction-Library, liegt also in der Mitte zwischen der Hardware, die man abstrahieren möchte. In diesem Fall unsere Labor-Technik, also unsere SerialAdapter. Wenn wir uns jetzt die mal angucken, hätte man da in Labgrid nicht nur einen einzelnen Treiber, der weiß, wie man mit einem Serial spricht. Das wäre noch langweilig. Labgrid hat auch Infrastruktur, Mehl für das SerialAdapter zu unterscheiden. Zum Beispiel anhand ihrer Seriennummer oder an einem USB-Port, an dem sie stecken. Und obendrauf gibt es dann Treiber, die wissen, wie man mit einem Bootloader spricht oder auch immer mit einer Linux-Shell spricht, da Kommandos absetzt und sich dann ReturnCode und Ausgabe zurück holt. Es gibt Treiber für verschiedene Power-Switches von irgendwie einem GPIO bis hin zu so einer Server-Fernsteuer-Technik, wo halt irgendwie viele Power-Sockets geschaltet in ein Gerät eingebaut sind. Man kann GPIOs auf verschiedenen Plattformen treiben und es gibt noch wesentlich mehr Treiber. Zum Beispiel, wenn man ein Switcher hat, die SNMP-Können, kann man gucken, an welchen Ports eigentlich welcher IP er hat, bestens rauszufallen. Aber da will ich hier gar nicht mit ein Teil drauf eingehen. Das schaffen wir sonst nicht. Nach oben gibt es jetzt drei Interfaces, mit denen man mit Lab-Grid sprechen kann. Es gibt ein Command-Line-Interface. Das ist das, was man benutzt, wenn man interaktiv mit so einem Router arbeiten möchte. Ich brauche mal kurz für eine Präsentation, ein Screenshot von einem Router im Config-Modus. Dann flashe ich halt ein Firmware-Image und bringe den Router eben dahin. Das kann ich über Command-Line machen. Es ist aber auch ein Python-Library, das heißt, ich kann doch einfach Gegenskripten, wenn ich sowas habe, wie ich möchte gerne mal 1.000 Mal ein Router starten, weil ein Freifunker gemeldet hat, bei jedem 50. Mal funktioniert das irgendwie nicht. Und dann sind Sachen komisch, könnte man das Kripten starten in den Router einfach ganz häufig. Und wenn man den komischen Zustand erreicht hat, lässt man ihn erstellen. Und man guckt sich dann später an, was das Problem war. Das, worum es heute hauptsächlich geht, ist das PyTest-Plugin, ja, dass man das halt ins PyTest integrieren kann. Lab-Grid macht auch viel Vorbereitung schon dafür, dass wir mit dem State unseres Geräts zurechtkommen. Wenn wir uns mal anschauen, zumindest einmal für den Runtime-State, so ein Gerät startet immer im Bootloader, typischerweise ist da einfach der Autoboot an. Das heißt, nachdem der Bootloader gestaltet ist, wartet er für den ganz kurzen Moment und lädt dann das Linux und springt das an. Aber es gibt halt Treiber, die wissen, wie man so ein Bootloader einfängt, den Autoboot unterbricht und dann halt Dinge tun kann. Und das kann man aus dem Lab-Grid fernsteuern und auch verfolgen. Es gibt in Lab-Grid einen Zustandsautomaten, das State-Machine. Das nennt sich das Strategy. Und die Strategy weiß, wie sie erkennt, in welchem State sich gerade so ein Default-Anathest befindet und hat auch Code, der einem von dem einen in den anderen State bringen kann, sodass man halt auch kontrollieren kann, bin ich im Bootloader, möchte ich jetzt ein neues Image per TFDP-Flasche, solche Dinge. Wir haben dann halt PyTest. Ich möchte mal kurz ein bisschen was zu PyTest erzählen, bevor wir da gleich nochmal einsteigen, wie wir das wirklich benutzen. PyTest ist ein Python-Testing-Framework. Das hört sich jetzt erst mal so an, als könnte man da mit super Python-Anwendungen testen. Das ist sicherlich auch richtig, aber es ist wesentlich generischer gebaut. Man kann damit halt im Wesentlichen alles testen. Es ist einfach Infrastruktur, um Test zu bauen. Und Lab-Grid bringt halt ein PyTest-Plug-Image, sodass man dann die Lab-Grid-Infrastruktur im PyTest benutzen kann, sodass man halt Tests schreiben kann, die echte Hardware oder ein echtes Linux auf einem anderen Direkt testen. Wie sieht so ein Test dann aus? Den würde ich mal kurz nochmal erklären. So ein bisschen Überblick zu verschaffen. Nun generell benutzen wir halt offensichtlich PyTest in unserem Python-Code. Und im PyTest gibt es einen Konzept, das nennt sich FixChass. Das ist im Wesentlichen eine Methode, die man später in seinen Tests benutzen kann, und dann ist es intelligent und zwar macht die irgendwelche Vorbereitungen, um in diesem Fall ein Gerät in einen Zustand zu bringen. Die Strategy, die wir jetzt hier benutzen, ist auch ein FixChall, die uns halt das Lab-Grid zur Verfügung stellt. Und mit diesem Transition Shell sagen wir einfach, liebe Strategy, sorg noch bitte mal dafür, dass dieser Router jetzt im Zustand Shell ist, also im geboteten Linux. Und dann machen wir weiter. Das benutzen wir jetzt hier einfach in unserem Test. Das heißt, wenn dieser Test gleich irgendwann mal gestartet wird, also der Buddy dieser Funktion, dann sind wir auf jeden Fall in einer Linux-Shell und können nach Kommandos ausführen. Und Target ist halt eine weitere FixChall, die uns das Lab-Grid gibt, sodass wir dann auch mit dem kompletten Target interagieren können und mit einem Treibern die dazu gehören, also dem Device an der Test und der Zeltsteiltechnik außen herum. Wir holen uns jetzt einfach den Shell-Treiber, der halt über die Serial mit dem Gerät spricht, weil, ja, wir möchten ja mit der Serial reden. Und dann füllen wir darauf einen Kommando aus und holen uns den Rückgabewert, die STD Out und den Return Code. Und dann machen wir darauf noch ein paar Vergleiche. Und wenn das alles gut aussieht, dann war der Test erfolgreich. Wenn irgendwas von dem fehlt, schlägt, dann war es das nicht. Das wäre jetzt hier sogar ein echter Testfall und auch eine wesentlichen vollständige Testzut, die man jetzt benutzen kann, wenn es Target das so hergibt. Aber Casa zeigt uns jetzt noch ein paar Details, wie reale Tests fürs Gnoren aussehen. Genau, diese Infrastruktur, die kann man jetzt natürlich benutzen, um genau unsere Ziele zu erreichen, nämlich Freifunk-Übungen zu testen, Teile der Infrastruktur darüber auch zu testen. Dazu bilden wir genauso eine Strategie, den Flow, den so einen Gloren nimmt, erstmal ab oder den so einen Router nimmt. Wir fangen nämlich mit dem Bootloader unten an, können dann den Router flaschen, kommen mit dem Config-Modus, können diesen Configurieren und können dann im normalen Betriebsmodus Test darauf ausführen. Wenn wir mit dem Bootloader anfangen, sehr einen Test z.B. so aus, der nimmt das Target und hat die Fixture in U-Boot, also sorgt das Labgrid dafür, dass wir im U-Boot sind und kann dann mal den Command-Version ausführen und einfach mal schauen, ob alles in Ordnung hat, ob der Command funktioniert, ist der U-Boot ungefähr so, wie wir uns das vorstellen. Damit wir mit ausreichend Konfidenz in den nächsten Schritt gehen können, nämlich das Flaschen, das ist jetzt kein Test, sondern es übernimmt die Strategie für uns, macht es über TFDP, schreibt das an die richtigen Stellen, gibt die richtigen Kommands ab und das sorgt dann am Ende dafür, dass der Router genau die Form wer geflasht hat, in unserem Fall diese Parkerpunkt bin, die wir auch testen wollen, denn irgendwann müssen wir den Router mit der Form fleschen, die wir haben wollen. Dann wechseln wir in den Config-Modus und doch wieder die Strategie für uns. Das sieht dann oben in good config und dieser Test jetzt zum Beispiel überprüft, ob unsere Default-Kondinaten, die wir hinterlegt haben, auch so im Config-Modus stehen. Um zu schauen, hat der Zyklus funktioniert, dass irgendwie Zeit-Config und unsere eigenen Änderungen alle auch in das Image eingeflossen sind. Da kann man jetzt natürlich noch mehr Tests machen. Wir testen noch, ob der Auto-Updater anders, ob der Branch so ist wie wir uns das vorstellen. Das kann man sich dann aber alles mal in den Quellen am Ende anschauen. Dann konfigurieren wir diesen Router. Da tauschen wir vor allem den VPN-Key, damit die Infrastruktur jedes Mal einen neuen Knoten sieht und wenn wir immer denselben Knoten haben. Wir konfigurieren uns das Private-Wi-Fi-Paket, das wir genommen haben, damit wir das hinterher überprüfen können, dass es funktioniert. Wir nehmen noch so ein, zwei andere Einstellungen vor. Da legen wir ein Haki, damit wir das am Ende testen können. Und dann kommen wir zum Hauptteil, zum Fleisch, unser Testzut, nämlich der Test im Betrieb. Das ist jetzt ein Beispiel, der eben genau diese Private-Wi-Fi-Config im Running-Modus testet. Schaut nämlich einfach mal, gibt es diese Wi-Fi ID, ist die jetzt in der IW-Config tatsächlich am Ende angekommen, wird die tatsächlich ausgestrahlt und dann mal zu schauen, läuft da alles. Da kann man jetzt natürlich noch viel mehr Tests machen, was wir schon haben, ist, dass die Infrastruktur einmal getestet wird, das geschaut wird, ob der DNS-Server funktioniert. Im Parker läuft auf jedem Knoten oder auf vielen Knoten auch noch ein DHCP-Server, das wird alles überprüft. Und wenn man sich dann überlegt, wie wir da noch weiter machen können, was wir auch in Zukunft noch machen werden, ohne VPN, also die keinen eigenen Abling haben, sondern gemescht werden, die müssen natürlich auch so getestet werden. Und dafür braucht man natürlich noch einen zusätzlichen Knoten, der in der Gegend steht, von dem man weiß, dass der funktioniert, mit dem man meschen kann. Man kann einen Klein simulieren, indem man zum Beispiel eine Containerlösung seiner Wahl verwendet auf dem Testserver und sich über eben genau dieses vorhin genannte Interface auf diesen Router als Klein einloggt. Dann kann man mal schauen, bekomme ich eine IP-Adresse, funktioniert meine DNS-Auflösung, kann ich in die Infrastruktur pingen, kann ich ins Internet pingen. Solche Dinge kann man dann mal auch mal testen. Und auch den Schritt des Firma Updates. Also man schreibt im ersten Schritt eine bekannte, eine bekannte gute Firmware auf diesem Router konfiguriert, den testet das kurz durch und schreibt dann mit dem normalen SysUpgrade eine neue Firmware, die man gerade testen möchte rein und kann dann die Tests nochmal durchführen, um zu schauen, funktioniert die Migrationsfade, wie ist das mit bestehender Konfig, um da die Testabdeckung nochmal zu erhöhen. Ja, wie fängt man an, wenn man das jetzt auch machen möchte? Wir haben die Tests in einem Repository auf unserem GitLab, also dem vom Startum 0. Der Link ist jetzt angezeigt. Zum Labgrid nochmal der Link zur Dokumentation und auch zu einem Talk, den Chrisie hier mal gegeben hat, wenn man sich dann auch mehr mit befassen möchte, wenn sich dieses Labgrid so funktioniert und ja, eine, klar man fasst, aktuelle Will of Material, die wir, das sind auch die Bilder, die wir gezeigt haben, die findet man bei uns im Startum, im Blog. Ja, damit will ich sagen Happy Hacking und wir haben jetzt noch ein gutes Stückchen Zeit übrig, von daher stimmen wir jetzt für Fragen im Big Blue Button für euch zur Verfügung und die Diskussion. Danke fürs zuhören. Vielen Dank. Okay, das war ja jetzt relativ viel. Wir haben eine Frage aus dem IAC. Da hat jemand gefragt, was eigentlich diese Gloren ist. Könnt ihr uns das kurz erklären, oder? Ja, sehr gerne. Gloren ist die Firmware auf der eigentlich das viele Freifunknetze beruhen. Was viel Freifunk ausgemacht hat, war ja die breite Verfügbarkeit von Geräten, die man einfach benutzen kann. Und da hat Gloren einen sehr großen Teil zu beigetragen. Gloren basiert auf OpenBAT, was auch eine Firmware für das mobile Router ist oder für Router ist und ja, damit unterstützen wir eine riesige Menge an Geräten. Und jede Community baut sich sein eigenes Gloren, also dieselbe Software mit ein bisschen Konfigurationen unterschiedlich. Genau, das ist das, was das Rückgrat von vielen Freifunknetzen ausmacht. Zumindest von den Geräten, die man sich zu Hause als Endnutzer hinstellt. Okay, danke für die Antwort. Danke, dass ihr euch die Zeit genommen habt und euch auch die Mühe gemacht habt. Trotz, dass ihr trotzdem nicht vor Ort da seid. Wir haben uns selber einen Talk gefreut und ich hoffe, wir sehen jetzt jede Menge kleine automatisierte Test-Setups, die hier überall aus dem Boden schießen. Das würde uns auf jeden Fall freuen. Man findet uns noch im IAC an verschiedenen Stellen und auch in der 2D-Welt, wenn sie denn launched. Genau, ich spreche uns gerne an. Ja, dann vielen vielen Dank für eure Zeit und wünsche ich euch noch einen wunderschönen, also Remote-Kongress. Dankeschön, euch auch. Vielen Dank für die Mühe, vielen Dank fürs Streamen. Dankeschön.