 Ja, hallo zusammen. Zunächst mal möchte ich mich bei euch bedanken, dass ihr am vierten Tag noch so spät hier seid, um einem Talk zuzuhören. Und ich möchte einfach mal damit anfangen, dass ich mich ein bisschen vorstelle und euch sage, was ich mache. Ich bin ein Open-WRT-Entwickler schon seit über zehn Jahren und ich habe mit den Linux-W-Land-Treibern eigentlich genauso lang schon zu tun gehabt. Und als ich mir so ein bisschen Gedanken darüber gemacht habe, was ich auf dieser Konferenz erzählen will, habe ich so ein bisschen eine Rückschau gehalten und habe geschaut, was waren denn so die wichtigsten Themen, über die ich öfter nachdenke während meiner Arbeit am Projekt. Und eines der Hauptprobleme, die ich öfter mal habe, da ich ja ein Linux-Treibere-Entwickler bin für WLAN-Karten, ist eben die Freiheit, diese WLAN-Treiber zu erweitern und Änderungen zu machen und wirklich vernünftige Treiber im App Streamer zu haben, die nicht nur für einfache Sachen benutzt werden können, wie zum Beispiel, um sich mit existierenden WLANs zu verbinden, aber sondern auch um mehr zu machen, wie zum Beispiel das, wie das File from Project oder eigene Access Points hinzustellen oder eine eigene Infrastruktur aufzubauen. Software Freiheit in diesem Sinne und Freiheit für die eigene Hardware sind eigentlich eine ziemlich große Sache in diesem Zusammenhang. Und ich will also erst mal anfangen, euch zu erklären, warum es eigentlich eine Riesensache ist, hier in dieser Hinblick Freiheit zu haben. Viele der Access Points, die so für die Endbenutzer sind, haben so viele Sicherheitslöcher. Ich habe einige Zeit damit zugebracht, an diesen Routern zu arbeiten, die grundsätzlich unsicher waren und ich habe angeschaut, wo diese Sicherheitslücken herkommen, die Leute dazu bringen, monatelang daran rum zu forschen. Und was ich in vielen Fällen gefunden habe, ist, dass es meistens etwas war, wo jemand mit einem Hintergrund in Sicherheitstechnik nur wenig Zeit damit verbracht hat, diese Devices sich genauer anzuschauen und da schon die ersten Löcher gefunden hat. Also ich denke mal, ihr könnt bei vielen Geräten erwarten, dass da noch weitere Sicherheitslücken gefunden werden und noch viel mehr Möglichkeiten, dass sich Geräte damit verbinden und Remote Code ausführen können. Denn im Grunde, Großteil des Codes, der auf diesen Geräten läuft, ist einfach grausam und deshalb ist so mit einer Gründe, warum wir in der Lage sein müssen, die drahtlosen Treiber selbst zu verändern. Denn die werden immer komplexer und je komplexer ein Stück Software ist, umso einfacher ist es normalerweise, darin auch Fehler zu finden. Und das bringt mich zum zweiten Teil, Stabilität. Normalerweise, was man in einem Access Point so hat für den Endbenutzer mit den Treibern, die dabei liegen, es ist was, was in einem ganz bestimmten Szenario getestet wurde. Sie haben es vielleicht getestet, irgendwie validiert, sie haben einige Kleins sich damit verbinden lassen in einem isolierten Umgebung mit einer wohlbekannten Konfiguration. Und wenn man davon abweicht und irgendwelche Änderungen macht, dann kann man mit gewisser Wahrscheinlichkeit davon ausgehen, dass das nicht, dass das einfach kaputtgehen wird. Und einfach nur, weil die Treiber sind sehr komplex und damit ist ein riesiger Wartungsaufwand verbunden. Und natürlich, es braucht einiges dazu, diese Probleme wirklich an ihren Quellen zu korrigieren. Bei Open Source Quellen ist es so, jeder kann drauf schauen, jeder kann seinen Beitrag leisten. Und wenn wir das haben, dann kann man Feature implementieren, die von den Herstellern als irrelevant anzusehen, also angesehen werden. Ich habe euch eben gesagt, dass das Freifunkprojekt eine riesengroße Sache ist. Und der Adhoc Mode, der wird halt, der hier benutzt wird, wird in vielen Fällen von den Chipsatzherstellern einfach nicht als relevant angesehen. Aber das ist eben genau das, was diese Riesennetzwerke betreibt. Und wenn wir freie Treiber hätten, könnten wir genau das implementieren. Und darum geht es im Grunde bei diesem Talk. Und um es jetzt mal ein bisschen so in, in der richtige Perspektive zu setzen, will ich euch mal so meine Reise durch die Linux Wireless-Welt beschreiben. Ich habe also angefangen, damals gab es noch sehr wenig Freiheit in diesem Hinblick und was hat sich dann so über die Zeit verändert. Wenn ich mal so meinen allerersten WLAN-Router mir anschaue, da gab es nur einen Bineertreiber, der für Linux 2.4 geschrieben war. Und er hat ein paar echt üble Kernel Hacks gemacht, um da irgendwelche Änderungen vorzunehmen. Und das war sehr, sehr schwer, dieses Ding weiterzuentwickeln. Und wir konnten eigentlich so gut wie keine Änderungen an den Treiber selbst vornehmen. Und es war erst viele, viele Jahre später, als dieser Treiber dann durch einen Open Source-Treiber ersetzt wurde, der durch Reverse-Engineering erstellt wurde. Aber der hat leider nie dieselbe Stabilität erreicht, wie dieser Bineertreiber. Also wie ihr das seht, da ist sehr, sehr wenig Freiheit. Aber das war halt einfach das Beste, was wir hatten damals, um Access Points zu bauen. Später kam dann der Mad-Wi-Fi-Treiber. Das ist zum Teil offen. Es gibt eine Bineerkomponente, der im Kernel-Kontext läuft. Aber zumindest war es nicht mehr von einer bestimmten Kernelversion abhängig. Und ein großer Teil des Treibers war offen. Und das erlaubte es uns sehr viel mehr Tests zu machen, mit dem Adhoc-Modrum zu spielen und alle diese Sachen rauszuprobieren. Aber es war immer noch nicht vollständig frei, weil halt immer noch Teile darin enthalten waren, die wir nicht, mit denen wir nicht richtig rumspielen konnten. Und das wurde erst später durch einen vernünftlichen Upstream-Treiber korrigiert. Und das war natürlich Jahre nach dem Ursprungsprojekt. Dieses war immer noch abhängig von unfreien Bineerdaten. Und es war damals schon ein paar Jahre zu spät, um für die Forschung eigentlich relevant zu sein. Denn als das wirklich nutzbar wurde, da war die Hardware schon veraltet. Aber es war immer noch ein benützlicher Prototyp, um einige der Kerninfrastrukturkomponenten von dem Mac 802.11 Treiber zu entwickeln. Und die Grundform des Algorithmus wird nach wie vor von vielen Treibern in diesem Stack verwendet. Das ist aber eigentlich gar nicht der interessanteste Teil meiner Zeit, die ich mit dem Linux Wireless-Treiber zugebracht habe. Denn was dann kam, war der RTR9K-Treiber. Und es war jetzt so, das war von Atheros, die einen sehr beliebten Chipsatz herstellen. Die haben den Treiber selber geschrieben und sie haben ihn veröffentlicht. Sie haben ihn in den Upstream eingebracht. Und das war eigentlich ein Riesenschritt vorwärts. Und anders als die früheren Versuche, Treiber mit Wi-Fi zu machen, war dieser Treiber komplett offen. Vom ersten bis zum letzten Bit. Man konnte alles machen, wie er die Funkparameter eingestellt hatte. Man konnte mit dem Code, der die Übertragungspower eingestellt hat und die Frequenz konnte man rumspielen. Und man kann mit einigen dieser richtigen Low-Level-Funkparameter rumspielen. Das war also wirklich ein Traum für ein solches Projekt. Und wir konnten damit unseren eigenen Access-Point bauen. Aber das alles nutzbar zu machen, war trotzdem noch eine ziemlich große Sache. Denn die ursprüngliche Entwicklung wurde quasi durch die Anforderungen von einem Laptop-Kunden getrieben. Die wollten Linux auf ihrem Laptop betreiben und hatten diese Atheros-WLAN-Karte eingebaut. Und der Hersteller wollte, dass das unter Linux funktionierte. Und da haben sie quasi Qualcomm und Atheros gezwungen, diese Treiber herzustellen und in den Kernel Upstream einfließen zu lassen. Und das ist eines der Beispiele, wo es nicht viel bringt, als Chips-Hersteller über diesen Wert und die Philosophie der freien Software zu wissen, man muss wirklich einen Kunden haben, der diesen Treiber verlangt, um diese Entscheidung zu treffen. Und diese Chips wurden natürlich nicht nur ein Laptops benutzt, sondern ähnliche Chips wurden auch in Access-Points verbaut. Und das war ein ziemlich großer Druck von der Community, da immer mehr Code offen zu legen und zu dokumentieren und das Ganze ein bisschen voranzutreiben. Ich selber habe wahrscheinlich mehr als drei Jahre Arbeit, da rein investiert, diesen Treiber in Produktionsumgebungen nutzbar zu machen. Und das hatte der netten Effekt, dass ab einem Punkt der Treiber stabil genug war, dass Kunden von Atheros die Embedded Hardware hergestellt haben, bei Atheros nachfragten, ob dieser Treiber auch kommerziell supportet wurde anstelle eben des Referenztreibers. Und das war so der Punkt. Atheros hatte sich nie hervorgestellt, dass sie das mal supporten müssten. Also mussten die sich erst mal anschauen, wer in der Community macht denn überhaupt hier die ganze Arbeit. Das war zum meisten Teil eben ich. Also haben die ihre Kunden wiederum zu mir geschickt, um Support zu bekommen. Aber es gab auch ein paar Probleme damit mit dem Athera9K. Jede Menge Arbeit hat die Community machen müssen, um das wirklich stabil zu machen. Denn der Hersteller war nicht gewillt, da irgendwelche Ressourcen reinzustecken, im Gegensatz zu ihrem eigenen internen Entwicklung, um eben diesen Treiber besser zu machen. Sehr viele Leute in der Community waren von der Firma und auf diese Art und Weise, die hatten Interesse daran, einen besseren Open Source Treiber bereitzustellen und das Projekt voranzutreiben. Aber das ging manchmal sehr langsam vorwärts. Wir hatten also an einer Stelle hatten wir einen der Manager überzeugt, dass dieses Open Source Ding, dieses Open Source Ding nicht weggehen würde. Und der ist aber dann irgendwann zu einer anderen Firma gewechselt und sein Nachfolger hat dann quasi nichts mehr davon gehalten. Also wir mussten dann viel diese Überzeugungsarbeit nochmal leisten, um eben da ein wirklich nachhaltiges Projekt auf die Beine zu stellen. Und naja, wenn eben die Kunden danach fragen, dann springen die sofort darauf an, denn sie wollen ja denen was verkaufen. Diese Open Source Treiber hatten also nur sehr begrenzte Ressourcen zur Verfügung. Mit dem Art her, 9k waren an einer Stelle nur zwei Leute, die daran arbeiten, später dann nur noch eine. Und dieser eine hatte auch nicht besonders viel Zeit. Also wir kamen irgendwann an die Stelle, wo dann wirklich nicht mehr sehr viele sehr viele Beiträge von Atheros kamen und im Grunde wurde das alles dann nur noch von der Community gewartet. Und während dieser Zeit, als sie noch so dabei waren, sich zu überlegen, ob sie mehr Ressourcen uns bereitstellen könnten, haben sie diese verrückte Idee, wie man den Athera 9 Codebase vereinigen konnte mit der Codebase ihres internen Treibers und die beide synchronisieren konnte und irgendwie einen Weg finden konnte, die Entwicklung von beiden Treiber in dieselbe Richtung gehen zu lassen. Und das geht so wirklich ein bisschen gegen das Linux Entwicklungsmodell. Sie waren also nicht bereit, sich diesem Entwicklungsmodell zu verschreiben, bevor sie diesen ganzen Vereinigungsprozess komplett rausgefunden hatten und das war fast unmöglich. Ein großes weiteres Problem mit Athera 9k war, dass diese 802 LFN Ships, die sie unterstützten, weg am Aussterben sind und es gibt dann den neuen Treiber Athera 10k. Da haben sie einfach die neuen um eins erhöht, denn sie wollten quasi das gleiche erreichen, was wir mit Athera 9k erreicht hatten. Das hat natürlich nicht richtig funktioniert, denn warum erzähle ich dann später, aber es war so schlimm, dass ich irgendwann entschieden habe, komplett aufzuhören und mir eine Alternative auszudenken. Und dann kam MediaTec. Und die haben, sie sind viel kleiner als Quarkom. Man hat da sehr viel weniger Bürokratie in dieser Firma, an der man vorbei muss. Und die haben herausgefunden, dass diese Open Source Geschichte eine richtig schöne Sache ist aus vielen verschiedenen Gründen. Und sie haben dann beschlossen, dass sie einen 802 LFN upstream Treiber wollen. Sie wussten allerdings nicht, wie sie das anstellen sollten. Ich habe ihnen dann Hilfe angeboten und habe angefangen, damit einen neuen Treiber zu schreiben für diesen Shipsatz. Das hat ungefähr ein Monat gedauert, aber ich habe Geld dafür bekommen. Ich war quasi ein Contracter in diesem Moment und es ist vielleicht ein guter Ersatz, wenn wir genug Hardware bekommen mit diesem Shipsatz, für die es kann ein guter Ersatz werden für die Sachen, für die wir vorher RTL 9K benutzt haben. Das Problem damit ist allerdings, dass wie in RTL 10K auch, gibt es eine proprietary Firmware, die einige Sachen kontrolliert. Und das ist eigentlich so ein Widerspruch gegen diese Sachen, die wir wollen. Das Gute aber wiederum ist, dass die Firmware sehr klein ist und sehr einfach ist. Also sie setzt nur ein paar Kanäle und macht ein bisschen Kalibrierung. Und das sind Sachen, die vielleicht für manche Forschungsprojekte interessant sind, dass man damit rumspielen kann. Aber meistens für die tagtäglichen Sachen, die man damit erledigt, ist es wirklich nicht relevant. Das heißt, der Treiber gibt uns die Möglichkeit, den kompletten Datenfahrt zu kontrollieren. Und das ist das, was wir brauchen, um Mesh-Netzwerke zu bauen, Rate-Control und Software zu machen und diese ganzen nützlichen Dinge. Also es ist nicht ganz so frei, wie RTL 9K, aber es ist benutzbar. Und ich hoffe, dass eines Tages sich eine Lage sein werde, sie zu überzeugen, das Ganze auch open source zu machen. Die Firmware auch. Es ist vielleicht möglich, denn sie sind mittlerweile, meinungsopensource, eine ganz gute Idee ist. Jetzt zum Punkt. Schauen wir uns an, was mit RTL 10K nicht richtig ist. Und ich habe darüber nachgedacht, wie ich das vorstellen soll. Und im Endeffekt habe ich mich dafür entschieden, ein paar Fotos zu zeigen, die dem intellektuellen Level entsprechend auf dem, die Entscheidungen getroffen wurden. Lasst uns also mit dem ersten Anfang, das ist sehr wichtig, ein Kiffer. Er stellt einen Nachfolger für einen populären, freien Software-Dreiber, aber nimmt die ganz interessanten Teile und packt sie in proprietary Firmware. Also und dann gab es Handlungsrasierer und dieses Gesetz besagt, dass man nie von Bösewildigkeit ausgehen soll, wenn auch alles durch Dummheit erklärt werden kann. Der nächste Punkt. Sie wollten sich so viel Arbeit wie möglich ersparen. Und sie hatten einen Mikro-Kontroller, der sehr mächtig war. Aber sie haben gesagt, wie mit den mobilen Chips, wir werden alles aufloaden, denn wir wollen unsere Mobilentwicklung mit der Netzwerkeentwicklung zusammenlegen und die selben Ansätze für Mobile und Access Points verwenden. Und natürlich, das kann Ressourcen sparen, aber es gibt viele unterschiedliche Anforderungen und alles in einen Top zu werfen ist sehr schwierig. Und alles an eine proprietary Firmware aufzuloden, abzuschieben, geht gegen das, was die Community erwartet und was für die Geräte am besten ist. Sie schoben also Scanning, die Datenfahrt und viele andere Dinge ab. Und vor allem der Rate Controller ist Scotty und wir können ihn nicht ersetzen. Und da steht viel nützliche Entwicklung im Wege. Und das ist ein großer Grund für mich, nicht mehr mit AT-HCK involviert zu sein. Der nächste Punkt, ein wenig lustiger. Sie haben sich sehr viel Mühe gegeben, Abstraktionen zu entwickeln, die die Software kompatibel halten, während ihre eigenen Software Ingenieure die die Firmware als Erweiterung betrachten. Und sie haben jegliche Version, jeglichen Branden, denen sie erstellten, konfus gemacht und das widersprach dem Sinn der ganzen Sache. Wir haben also fünf verschiedene Firmware Interfaces und unterschiedliche Versionen und manchmal Versionen für einen Chipset und man hat dann komplett andere Versionen bei der API und die muss dann aber alles übernehmen, weil der Linux Kernel eigentlich kompatibel mit den Firmware Veränderungen sein sollte. Und das ist alles ein großes, eine große Verwirrung und ich sehe da keine Besserungen in nächster Zeit. Und als ich angefangen habe, mich mit AT-HCK auseinanderzusetzen, habe ich entschieden, ich könnte mich an diesem Gewühl beteiligen, aber das wäre ein Vollzeitjob mehrere Monate lang mit einer sehr kleinen Hoffnung langfristig Erfolg zu haben wegen den ganzen bürokratischen Entscheidungen. Deswegen habe ich mich entschieden, ich will damit nicht zu tun haben und ich will das Entwicklerhersteller mehr Verständnis für Open Source haben. Und noch ein Punkt. Sie haben entschieden, wir werden nicht normales 802.11 Frames vom Treiber verwenden und deswegen haben Sie sich ein sehr ausgefeiltes Native Wi-Fi einfallen lassen und ich glaube, diese Bezeichnung stemm von Microsoft. Sie benutzen also den Windows Networking Stack, der gefälschte 802.11-Header hat, die der Treiber erwartet und sie nehmen das, stecken es in Silikon, in Silicium und warten, dass der das Linux das versteht und setzten vieles Richtige durch Falsches und erwarten, dass immer noch alles gut funktioniert beim Übertragen der Pakete. Also ich habe viel Zeit damit verbracht hier über Qualcomm und Ether-Ros zu reden. Also was gibt es noch für Hersteller? Broadcom. Sie haben einen Soft-Mac-Treiber für jüngere Geräte geschrieben, aber nur für eine oder zwei Generationen von Chips und für 802.11 AC und dann haben Sie entschieden, nur Full-Mac zu unterstützen. Das bedeutet, man hat den 802.11 AC Datenfahrt nicht mehr in der Software, man kann einige Ethernet-Sachen konfigurieren, aber man hat keine Flexibilität mehr und das ist so ein Ding auch mit anderen Geräten mit Marvel. Die haben auch einige Full-Mac-Geräte, aber meistens auf Mobile beschränkt. Aber sie folgen demselben Trend wie die AT-HCNK mit der Entwicklung von ATP-Chips, wo auch viele Dinge an proprietary Firmware abgelegt werden und das Firmware-Interface ändert sich die ganze Zeit und sie nehmen die ganze Kontrolle weg, aber haben noch genügend Crudencode im Kernel, um sich hinzustellen und zu sagen, wir haben ein Linux-upstream-Treiber, der jedoch für andere Dinge außer für ein regulär Access-Point unbrauchbar ist. Dann gibt es noch Intel, die sind sehr beschreckend. Sie haben ein wenig AP-Support für einige Dinge, aber niemand benutzt es wirklich, einige Leute haben es ausprobiert, aber es funktioniert nicht wirklich. Niemand benutzt, vielleicht benutzen das manche in sehr limitierter Weise, um direkt Wi-Fi zu machen, aber für eine wirkliche Benutzung ist es nicht geeignet. Bei Reartag ist es ähnlich. Die bringen immer mal wieder neue Chips raus und man hat neue Treiber und sie tun immer mehr Zeug in die Firmware und auch das ist die falsche Richtung und da sehen wir, wir haben eine sehr beschränkte Auswahl und ich hoffe eben auf Basis von MediaTag etwas bauen zu können für den Markt und bei dieser Diskussion über die Hersteller von Chips, da gibt es eben die Herausforderung und auch einige Möglichkeiten etwas zu verbessern und darüber möchte ich jetzt reden. Also was können wir mit den Herstellern tun? Ihnen etwas beizubringen ist sehr schwierig. Wie bei Atheros, wie schon gesagt, da gibt es viel Bürokratie und manchmal gibt es da intern genügend Leute, um Open Source auf die Agenda zu schieben, aber in den meisten Fällen werden sich die Leute dafür nicht interessieren und sich für die billigste Lösung entscheiden, denn sie haben, wo sie keine Kosten haben, die sie, also sie wollen Kosten vermeiden, die sie nicht einem gewissen Businessplan zuschreiben können, denn sie gehen davon aus, dass ihre Kunden nicht an Open Source interessiert sind. Was dazu führt, dass, was leider daran liegt, dass ihre Kunden noch nichts Nützliches basierend auf Open Source gesehen haben und deswegen auch nicht danach fragen. Wenn ihre Kunden etwas darüber wissen, dann könnten die Kunden sehr einfach beim Hersteller bewirken, dass mehr auf Open Source-Basis passiert und dann eben auch in großen Mengen. Und ein gutes Beispiel ist hier Google Chrome OS, denn die haben in ihren Teams tatsächlich Leute, die mit den Chipset-Herstellern geredet haben und sie in die richtige Richtung gelenkt haben. Und zu Anfangs haben sie, glaube ich, die Forderung dargestellt, dass sie alle Treiber, die sie von den Herstellern bekommen, Open Source sein müssen. Aber das ist noch nicht genug, denn es gibt immer noch schlechte Chip-Hersteller, die schwierig zu integrieren sind und deswegen haben sie mit der Zeit dann eben verlangt, dass sie Treiber upstream sein müssen. Und, kannst du den letzten Satz? Und das hat dann sehr viel besser funktioniert. Die große Frage ist also, können wir eine Kundennachfrage für freie Treiber erzeugen? Denn ich glaube, das ist wirklich die einfachste Möglichkeit hier in diesem Ökosystem etwas zu verändern. Und einige der Möglichkeiten, wie wir dies tun könnten, die eventuell funktionieren, meiner Meinung nach, wäre, die Großkunden mit genügend Umsatz darüber aufzuklären, dass Open Source eine sehr gute Möglichkeit ist, Entwicklungskosten zu sparen. Denn viele Hersteller, die Sedizium von verschiedenen Herstellern verwenden, bemerken, dass die Referenzsoftware der Hardware in sehr limitierte Art und Weise getestet wird, nur immer in Default, im Standardmodus. Und wenn man von diesen Test-Szenarien abweicht und den Treiber eines anderen Herstellers in ein anderes System on a Chip steckt, dann hat man einfach Ungereimtheiten und Hacks. Und die Hersteller gehen eben immer davon aus, dass man alles von ihnen, von nur einem Hersteller kauft. Und wenn Hersteller mit freien Treibern, freien Kernacode, upstream arbeiten, dann muss man sich nicht, dann muss man keine Angst haben, diese Dinge zu vermischen. Denn das sind die Test-Szenarien dann sehr divers und in verschiedenen Konditionen und auf verschiedenen Plattformen. Und normalerweise ist eben ein Treiber auf einem Chip zugeschrieben, dass es nicht von Hardware-Support auf diesem System on a Chip abhängt, sondern erlaubt es, kompletiert zu werden für viele verschiedene Architekturen, sonst wäre es nicht sehr nützlich. Man muss nur darauf achten, dass der Code gut geschrieben ist und auch in vielen verschiedenen Konfigurationen funktioniert. Und mit solch einer Qualitätskontrolle kann man so etwas integrieren und auf einem System sehr gut arbeiten. Wenn man nur einen Treiberplopp, irgendein Beliebigen bekommt, dann wird das epischeitern. Und ich glaube, ein wichtiger Punkt beim Unterrichten der Kunden ist ein guter Referenzcode und Beispiele. Vor vielen Jahren hatte ich mal ein Meeting bei Broadcom, als ich immer noch für QCA gearbeitet habe. Und ich saß auch mit ein paar Managern zusammen und einer der Leute dort war zuständig für die SDK und er sagte mir, oh ja, wir wissen von OpenWRT und Kunden fragen uns oft nach Features, die OpenWRT supportet. Und dann gehen wir hin und bauen die Features selber nach. Und das ist etwas, was funktioniert. Man zeigt also den Leuten, was mit einer vernünftigen Plattform alles möglich wäre. Und dann sagt man ihnen, jetzt geht es zu dem Hersteller und verlangt das auch von dem. Und je nachdem, wie viele Kunden man damit erreicht, kann das wirklich einen Unterschied machen. Und es gibt noch einen weiteren Weg, der manchmal recht nützlich ist, nämlich die sogenannte GPL Enforcement Action zu unterstützen. Wenn es also eine Gruppe von Leuten gibt, die die GPL gegenüber einem bestimmten Routerhersteller durchsetzen, weil man zum Beispiel sieht, dass der Routerhersteller mehrfach dabei erwischt wird und in Verfahren entwickelt wird, weil er die GPL verletzt, dann ist es schön, wenn man denen sagen kann, hey, wenn ihr jetzt Open Source auf das benutzen würdet, dann hättet ihr viel weniger Probleme bei der Lizenzierung. Ihr würdet es einfach veröffentlichen und ihr hättet eine ganz klare Trennung zwischen dem Open Source Code und dem properitären Code. Und es wäre alles sehr viel einfacher. Denn in vielen Fällen ist es nicht wirklich der Routerhersteller oder der OEM, der die GPL verletzt, sondern ist das Referenzcode des Chip Herstellers, der da manchmal ein bisschen ungenau mit den Lizenzen umgeht. Und die Chip Hersteller wiederum, für die ist das ein Verkaufsargument. Die haben also Angst über, dass sie da am Markt Probleme bekommen und bessere Hardware bauen ist eben schwer. Also machen sie sich lieber, setzen sie sich lieber von anderen Herrschern ab, indem sie andere Software beilegen. Und ich habe da immer diese Vergleich, sie kämpfen immer darum, ob das Rad nun fünf oder sechs Ecken haben sollte. Also richtig haben sie es also noch nicht ausgefallen, dass wir mittlerweile dabei sind, was zu bauen, was rund ist. Und dass sie haben noch nicht erkannt, dass das eine tolle Idee sein könnte. Vielleicht sollten wir mit ihnen reden. Dann gibt es einen weiteren großen Spiele hier in diesem Spiel, der uns in die Suppe spuckt. Das ist die FCC, also die amerikanische Federal Communications Commission. Es ist so eine Hassliebe zwischen der FCC und mit uns manchmal haben sie gute Sachen gemacht und haben gute Sachen gefordert, diese ganze Netzwerk Neutralitätsdebatte. Da sind, stehen sie wohl auf der richtigen Seite, glaube ich zumindest, ich habe es nicht so ganz verfolgt, aber hier bei der Wi-Fi Geschichte, das ist richtig, richtig problematisch. Ihnen ist also aufgefallen, dass manche Leute Access Points hingestellt haben, die mit Wetterradarstationen interferiert haben und sie haben geschaut, wo kommen diese Signale her und haben gesehen, hey, da gibt es Leute, die spielen an diesen Funk-Einheiten rum und vielleicht sollten die das nicht tun, vielleicht ist die Tatsache, dass diese Leute damit rumspielen, das Problem. Das heißt also, sie behandeln den Zugriff von Benutzern auf solche Parameter der Funkchips als ein Problem. Und jetzt sagen sie natürlich, okay, gegen die Benutzer können wir nicht vorgehen, denn da gibt es so viele von. Also gehen wir lieber auf die Hardware Hersteller zu und stellen sicher, dass die wiederum sicherstellen, dass der Benutzer ausgeschlossen wird von diesen Parametern. Das gab dann einen Riesenaufschrei in der Technik-Community von einigen Schlüsselleuten, die teilweise wirklich mit der Entwicklung des Internets zu tun hatten. Das hatten die wahrscheinlich nicht erwartet. Ich wahrscheinlich dachten die, dass sie, dass das keine Kurse Kontroverse hervorrufen würde, denn sie wollten ja eigentlich nur sicherstellen, dass die Wetterradar besser funktionieren und sie haben dann diese Regel nochmal überdacht und sind ein bisschen zurückgerudert. Aber in manchen Fällen sind diese neuen Richtlinien genauso schlecht wie die Ursprünglichen. Also es gibt da zum Beispiel diese Sache, wo in der ersten Version die Routerhersteller gebeten wurden, zu beschreiben, wie sie etwas wie eine freie Firmware wie DDWAT verhindern wollten. Und die Hersteller mussten wirklich beschreiben, wie sie die freie Firmware verhindern und in den neuen Regeln, da sacken sie dann stattdessen, ja, das war gar nicht unsere Intention. Wir wollten diese, diese Geräte nicht, nicht vergrippeln in dieser Stelle. Wir wollten nur sicherstellen, dass sie die Funkmodule nicht beeinflussen können. Aber es wurde ihnen wiederholt gesagt und sie verweigerten sich aber, das zu verstehen, dass es eine große Unterschied ist zwischen der Intention und dem, was dann hinten rauskommt. Und da haben sie immer noch ein Problem mit diesem Konzept. Sie stehen immer noch auf dem Standpunkt. Es wird ja nur diese Parameter für diese Funkmodule werden vor Manipulation geschützt und alles andere nicht. Aber wie ich gehört habe, sind einige der Hardware-Hersteller schon darauf gekommen, dass, dass die Funkteile alleine vor Manipulation verhindern ist schwer. Das ganze Ding allerdings zuzumachen ist einfach, also wird das gemacht und es interessiert ja eh keinen. Nicht wahr? Und was mir auch gesagt wurde, bei einem anderen Talk auf diesem Kongress, es ist eine ganz interessante, ganz interessante Zufall, wenn man sich das Timing dieser Regeln anschaut und auch sieht, wer dieses Funkspektrum sonst noch benutzt, nämlich es hat damit LTE etwas zu tun. Also es gibt da so ein, ein, ein lizenziertes Spektrum, was vollständig unter deren Kontrolle steht und anscheinend ist das immer noch nicht genug, um die Bandbreite zu garantieren. Also sagen die einfach, hey, wir nehmen einfach noch ein bisschen von dieser Bandbreite mit dazu, die eigentlich von diesem Spektrum dazu, das eigentlich zu Wi-Fi gehört. Und da müssen wir uns wirklich Gedanken machen, wie wir damit umgehen. Es gibt also eine ganze Reihe von Leuten, die da aktiv sind und ihr könnt auf den News-Seiten lesen, wie die Leute sich über die FCC beschweren. Die Hauptprobleme da sind eigentlich, dass es viele Leute nicht verstehen, dass es genauso wichtig ist, die dagegen zu kämpfen, dass die Funkparameter nicht mehr veränderbar sind, wie es ist, dagegen zu kämpfen, dass die ganze Plattform geschlossen wird. Es sind so viele interessante Sachen, die zum Beispiel Freunde von mir entwickeln einen Weg, dynamisch die Sendeleistungen des Funkteils für die Stationen getrennt einzustellen. Wenn man das System also rausfindet, okay, der ist näher dran, dann können wir die Sendeleistungen verringern und den selben Durchsatz bekommen. Und das ist in meiner Meinung nach, ist eine gute Sache für sehr dichte Netzwerke, wo sehr viele Accesspoints in dicht befolgerten Gebieten sind. Und die neuen Chips machen das aber weiter und weiter unmöglich, solche Sachen zu machen. Denn der Zugriff auf die Hardware-Level-Parameter, die wir brauchen, um sowas zu bauen, der verschwindet. Und es wird mit irgendwelchen lahmen Ausreden begründet. Und wir müssen rausfinden, wie man diese Debatte in die richtige Richtung widerschiebt und die Leute nicht einfach überzeugen, dass es nicht gut ist, einfach immer den Bequemeren wegzuwählen. Wir haben außerdem ähnliche Probleme in der EU. Die TSI hat entschieden, dass sie was Ähnliches machen, was in manchen Fällen sogar weitergeht als das, was die FCC gefordert hat. Und ich glaube, wir haben immer noch mehr Zeit, die zu beeinflussen. Denn es ist momentan eine EU-Direktive und es muss immer noch von den einzelnen Mitgliedsstaaten implementiert werden und den Nationales Recht umgesetzt werden. Und da haben wir also ein bisschen mehr Zeit in den jeweiligen Ländern, da Leute zu motivieren und Politiker zu motivieren, gegen diese Sache anzukämpfen. Ich kann jetzt nicht so viele Details, der inneren Details preisgeben. Ich versuche, mich aus diesen politischen Sachen rauszuhalten. Aber ich dachte, es ist wichtig, dass ich das zumindest erwähne, denn es könnte sein, dass das sich zu einer ganz großen Sache entwickelt. Okay, was ist also mit diesem ganzen Zuschließen von Hardware? Ich habe erwähnt, dass die Hardwarehersteller das schon im Betracht ziehen, damit sie einfach sich mit den FCC-Regeln nicht so sehr herumschlagen müssen. Und dann gibt es die Routerhersteller, die das bereits jetzt schon teilweise tun. In manchen Fällen ist das also eine Ausrede, damit sie einfach nicht so viele Supportkosten haben, wenn sie verhindern können, dass die Leute einfach ein benutzerdefiniertes Betriebssystem draufflaschen. In manchen Fällen ist die Ausrede. Wir möchten verhindern, dass die Chinesen unsere Geräte klonen. Und na ja, es anscheinend haben die ein bisschen Auto-Equipment, was sich ganz gut verkauft. Und mit diesen neuen Geräten können sie den Bootloader sozusagen zuschließen und können verhindern, dass jemand eine benutzerdefinierte Firmware flasht und sagen eben, ja, das ist damit die Chinesen das nicht rauskriegen. Und in manchen Fällen habe ich gesehen, dass dieser Lockdown auch benutzt wird als eine billige Ausrede, um den Markt zu segmentieren, wenn man also in einem Market ein paar Features wegnimmt und das als die Basic-Version verkauft. Und dann hat man dieselbe Hardware und macht nur eine andere Firmware drauf, unter den anderen Schlüssel und damit sind alle Features verfügbar. Und dann hat man verschiedene Zielgruppen im Markt und man kann dann durch DRM beispielsweise forcieren, dass die Leute nicht einfach die Firmware von dem anderen Gerät draufflaschen. Und was ich jetzt gerne auch diskutieren würde mit euch ist, was können wir tun gegen all diese Sachen? Ich habe ein paar Ideen hier aufgeschrieben. Also diese Geschichte mit der FCC, das müssen wir publik machen. Es gibt einen weiteren Punkt, den ich noch nicht erwähnt habe. Wir können die Sicherheit analysieren der existierenden Geräte, die da draußen sind, um eben das Argument viel überzeugender zu machen, dass es schlecht wäre, diese Geräte zuzuschließen, weil sonst die Leute Probleme nicht mehr fixen könnten. Die Geräte kommen von den Herstellern und sind total verbackt und sie machen der Netzwerk unsicher. Und wir brauchen einen Weg, Hardware zu haben, die wir selbst reparieren können. Und wir müssen sicherstellen, dass wir aufzeigen, dass das ein ein ein industrieweites Problem ist und das so gut wie alle Router da draußen eine grauenvolle Software laufen, die sehr viele Sicherheitsprobleme hat. Wenn wir das zeigen können, dann können wir vielleicht die ganze Tragweite verdeutlichen. Und eine weitere Sache, wo ich etwas Hilfe gebrauchen könnte. Freie 802 11 Treiber zu schreiben. Mit der Erfahrung, die ich über die Zeit aufgebaut habe, habe ich in einem Monat so einen Treiber schreiben können. Und ich würde jetzt gerne Support für einen Support für einen zweiten Chipsatz konnte ich in fünf bis sechs Tagen nachbauen. Es kann schon Monitormot machen, es kann Pakete aussenden. Es kann ein bisschen scannen. Ich hätte nur gerne, dass mehr Leute sich da beteiligen in diesem Feld, so dass wir die Ressourcen haben, so dass wenn der Chipsatz Hersteller kommt und sagt, wir wollen einen Open Source Treiber, aber wir brauchen Hilfe. Dann können wir mit einem Pool von Leuten aufwarten, die sich das anschauen können und können den Code so verbessern und freie Softwaretreiber dafür schreiben. Ich kann euch aus meiner eigenen Erfahrung sagen, dass das ein ziemlich interessantes Feld ist, in dem man arbeiten kann. Und es ist ein tolles Gefühl, wenn man ein Stückchen Code beiträgt. Und man zum allerersten Mal sieht man, hey, der Monitormot funktioniert jetzt und ich kann wirklich Pakete aussenden. Und man sieht den Fortschritt, den man über die Zeit macht. Das macht meiner Meinung nach viel Spaß. Und ich hoffe, dass mehr Leute darauf kommen, dass das ein sehr interessantes Feld ist, auch ein herausforderndes Feld. Und eine der Dinge, die ich gerade eben diskutiert haben mit einem meiner Freunde ist, ein paar Minuten vor diesem Talk, ist, ich bin der Meinung, wir sollten zusammenkommen und sollten etwas niederschreiben, dass auf die Entscheidungsträger zugeschnitten ist von Schippherstellern und Routerherstellern, vielleicht differenzieren je nach Zielgruppe, wo wir sozusagen herausfinden, in welcher Welt die leben, welche Konzepte und in welchen Bahnen die denken und etwas erzeugen, was ihnen Argumente gibt, den Open Source Weg einzuschlagen. Und ich hoffe auch, dass ich da etwas Feedback von euch und von den Leuten, die diesen Stream schauen bekommen, wie wir so etwas beinstellen könnten. Und das ist im Grunde alles, was ich habe. Und ich hoffe, dass ihr jetzt ein paar richtig gute Fragen für mich habt. Ja, vielen Dank für diesen Talk, sehr interessant. Ist jemand hier, wenn jemand schon ein ganz guter C-Programmierer ist, was ist der beste Weg, da ein bisschen Feedback zu bekommen? Und wie kann man da... Also ich selbst bin kein sehr guter C-Programmierer und ich habe wahrscheinlich die Ressourcen, aber ich wollte einfach mal dich dazu einladen, ein bisschen praktische Tipps zu geben. Wenn jemand diese Ressourcen hat und hat diese Fähigkeiten und kann C-Programmieren und hat ein bisschen Verständnis, wie man Linux-Dreiber programmiert, was muss er oder sie tun, um wirklich in dieses Projekt zu kommen? Ich glaube, es ist eigentlich relativ einfach. Man wählt einfach etwas, wo man ein Gerät im Netzwerk findet, das Wi-Fi hat und man merkt, dass es auf Linux irgendwie supportet ist, aber noch nicht zu 100 Prozent. Und dann fängt man damit herum zu spielen und man findet heraus, was tatsächlich vor sich geht. Man benutzt einen Debugger und man spielt einfach damit herum und schaut, was dabei passiert. Ich glaube, das ist tatsächlich die beste Motivation, um sich mit so etwas auseinanderzusetzen. Man macht keinen Plan, Schritt eins, zwei, drei, sondern man spielt mit etwas herum, bis man beginnt, mehr zu verstehen und sollte diesen Prozess genießen. Ja, vielen Dank für diesen tollen Talk. Ich habe eine Frage über Firmwares. Soweit ich weiß, gibt es sehr wenige Wi-Fi-Chips, die eine freie Firmwares haben. Und ich glaube, das ist wahrscheinlich ... Die einige Sicherheitsprobleme werden nicht wirklich erforscht. Wenn man zum Beispiel ein PCI-Gerät hat und hat einen Backen der Firmwares, dann kann man im Grunde den gesamten Rechner über eine DMA-Attacke lahmlegen. Und wie siehst du das? Was ist der Zustand momentan bei Firmwares und haben wir das Potenzial, mehr Chipsatze mit freien Firmwares zu bekommen? Also, bis jetzt, der Kampf gerade geht darum, freie Treiber zu bekommen. Und ich glaube, freie Firmwares, das ist noch ein weiterer Schritt irgendwann später. Ich denke, es ist ein sehr wichtiger Schritt. Es ist sehr wichtig, wenn es um die Sicherheit von Geräten geht. Du hast ja gesagt, wenn man eben alles offloadet, dann hat man da komische Sachen in dem proprietären Treiber drin, die TCP passen und auch andere Protokolle. Und ich erwarte, dass da sehr viel schlechter, nicht funktionierender Code drinsteckt und dass es da Exploits für gibt. Nur ist leider das Bewusstsein dafür nicht sehr groß, denn es gab noch nicht sehr viele Attacke in der Praxis. Eine Frage aus dem Internet. Welche Laptop-Hersteller brauchen diese Atheros-Treiber? Es gibt nicht so viele Laptops heutzutage mit Atheros-Treibern. Für eine kurze Zeit gab es einige Laptop-Kunden, die es benutzt haben. Ich weiß nicht, ob sie auch wirklich eine hohe Quantität verkauft haben. Aber ich glaube, Atheros baut heutzutage keine Karten mehr für Laptops. Gibt es irgendwelche WLAN-Karten oder Chipsetze, die du empfehlen würdest, im Sinne von, dass sie eine offene Firmware haben, wo die Firmware offen ist, offengelegt wird und hackbar ist? Ich weiß nur von einem solchen Gerät. Ein altes Atheros-11-11-N-USB-Gerät, das zur Hochzeit sehr viele Pro-Open-Source-Leute bei Atheros gearbeitet haben, die das Management überzeugt haben, solch ein Gerät zu bauen. Es gab danach nicht mehr viel Entwicklung in diesem Bereich. Die Firmware wurde auch Open-Source gemacht, nachdem das Gerät schon längst obsolet war. Aber wenn du nach dem Gerät H9T, HTC suchst, dann gibt es offene Firmware, und du kannst alles selbst kompilieren. Hallo, danke für diese Arbeit, die du da reingesteckt hast. Ich bin von einer Open-Vertil-User-Gruppe, also vielen, vielen Dank. Ich habe mal versucht, etwas an FreeBSD mitzuarbeiten für Atheros Chips. Das war vor ein paar Jahren, als Atheros noch Dokumentationen bereitgestellt hat. Gibt es irgendwelche Hersteller, mit denen es einfacher ist, wenn man Dokumentationen benötigt? Also, ich habe jetzt kein Problem, damit irgendeine Verschwiegenheitsklausel zu unterzeichnen. Aber ich glaube, viele Hersteller sind da sehr, sehr zögerlich, irgendeinem Kälter draußen die Dokumentation der Hardware zu geben. Nun, mit MediaTek habe ich jetzt eine gute Beziehung. Also, wenn du in diesem Feld mit solchen Treibern arbeiten willst, dann könnte ich dich wahrscheinlich mit ihnen in Verbindung bringen. Und für meine eigene Arbeit, ich habe die Dokumentation unter einer Verschwiegenheitsklausel bekommen. Und vielleicht könnte ich sie ja überzeugen, sie noch an weiteren Entwickler weiterzugeben. Wie können wir Hersteller ausüben? Okay, wie kann man Hersteller drängen? Die Chipsets oder für die Router? Es steht nicht hier, es bezog sich wahrscheinlich auch Folie 20. Nun, die Hardware-Hersteller, das hängt davon ab, auf welchem Level? Die Hardware-Hersteller selbst, wenn man die richtigen Kontakte hat, dann findet man heraus, dass man manchmal nur die Ingenieure mit den Entscheidungsträgern verbinden muss. Denn dann lernt das Management über die Folgen von schlechten SDKs und sie werden sehen, wie schön es ist, etwas Offenes zu haben. Und die haben die Macht, die Chipset-Hersteller zu überzeugen. Und als Chipset-Hersteller, wenn man mit den Marktführern wie Broadcom redet, die interessieren sich einfach nicht sonderlich für Open-Source, denn sie sind bereits in einer sehr guten Position. Und sie wissen um den Wert ihrer Chips und ihre Software und sie werden wahrscheinlich eher nicht denken, dass sie gerade irgendetwas falsch machen. Und in solchen Fällen muss man sich dann wahrscheinlich eher an die Underdogs, an die kleineren Unternehmen wenden und ihnen Möglichkeiten geben, mehr Hardware zu verkaufen. Viele Chipset-Verkäufer, die ich kenne, haben sicherlich Käufer verloren durch den schlechten Zustand ihrer Software. Und sie müssen eigentlich eingesehen haben, dass bessere Software zu mehr Kunden führen kann. Es gibt mir ein sehr gutes Gefühl, als ich mal den Quellcode geguckt habe und da deinen Namen drin fand. Ich habe ganz vernünftige Kenntnisse in CEC++ und ich würde gerne was beitragen. Ich hätte gerne gewusst, es gibt eine Website oder ein IRC-Kanal, wo ich mal mit den Leuten mich austauschen kann, die jetzt bereits Beiträge leisten. Welch, was genau, Linux Wireless oder OpenWRT? Ja, Treiberentwicklung. Ich glaube, es gibt nicht viel Koordination zwischen Linux Treiberentwicklern. Also jeder macht so sein eigenes Ding und dann wird er auf einer Mailingliste über Patches diskutiert. Ich glaube, das ist nur interessant für Leute, die bereits alte Hasen in diesem Feld sind und sich mit Treibern auseinandersetzen. Ich weiß nicht, ob es Lernkurse für Anfänger gibt. Aber man kann es sehr leicht mit Personen in Kontakt treten. Also, wie schon gesagt, nimm etwas, das bereits da ist und versuche, mit Geräten rumzuspielen, versuche einen Bug zu fixen und beschäftige dich mit einem Gerät auf einem sehr detaillierten technischen Niveau. Ich sage nicht einfach nur, wie kann ich dies und das machen, sondern was sind die spezifischen Details von diesem Teil und was sind die Details von jenem Teil. Und das kann dann zu Diskussionen führen. Und ich glaube eben, es gibt viele Möglichkeiten, einfach beim Herumspielen mit Geräten etwas zu lernen. Ich habe eine Frage über etwas, was ich nicht richtig verstanden habe. Dein Talk hat den Titel Freedom Considered Harmful. Was genau betrachten die Hersteller als gefährlich? Warum, was ist die Motivation, dass sie das gerade nicht veröffentlichen? Ich verstehe, warum... Ich verstehe Gründe dafür. Was sind die Gründe dagegen? Einige der Gründe sind, sie haben immer Angst davor, die Kontrolle zu verlieren in vielerlei Weise. Man bekommt den Eindruck, dass sie glauben, dass wenn sie etwas veröffentlichen, dass andere Leute das nehmen würden und verändern würden und sie haben dann keine Kontrolle mehr darüber, was genau dort passiert. Und das ist anscheinend für die Hersteller sehr wichtig. Und große Unternehmen wie Qualcomm, die in diese komische Vorstellungswelt richtig drinstecken. Qualcomm, ihr Geschäftsmodell, sind Patente, Patentlizenzen. Und deswegen muss damit die Anwälte glücklich bleiben, alles über andere Firmen geregelt werden. Und die Anwälte selbst bauen natürlich sehr große Paranoia auf, über all die schlechten Folgen, die Open Source Software haben könnte. Da könnte es dann zu Copyright Verletzungen kommen und wenn man es nicht als Open Source veröffentlicht, dann ist es immer noch da, aber die Leute sehen es wenigstens nicht. Und vielleicht ist es ja auch in manchen Fällen einfach so, dass sie nicht die erbärmliche Qualität ihrer Software der Welt offenlegen möchten. Wie groß müsste ein Kunde sein, um den Hersteller davon zu überzeugen, freie Software zu machen? Ich glaube in manchen Fällen hängt das einfach davon ab, vielleicht eine Million Chips pro Jahr zu kaufen. Also es muss tatsächlich groß sein. Kleine Unternehmen mit 10 oder 100.000 Chips, die werden nicht dazu führen, dass Hersteller ihr Verhalten überdenken und eventuell verändern. Eine weitere Frage aus dem Internet. Warum müssen die Hersteller nett sein? Sie bekommen keine Profite davon, wenn die Forscher sich mit der Hardware befassen. Wie willst du sie dazu bringen, netter zu sein? Na ja, das Ding ist, mit solchen Forschungen, die nützliche Forschung, von der sie profitieren, die Hersteller, die kommen von der Open Source Richtung, das sind nicht Leute, die teures Forschungs-Equipment kaufen. Und viele der Hersteller sind auch nicht in dem Geschäftsmodell solche, nur darüber über Forschungs-Hardware Geld zu verdienen. Und das ist noch ein weiterer Punkt damals bei Atheros, als sie sehr freundlich Open Source Software gegenüber eingestellt waren. Da haben sie gesagt, viele kleine Unternehmen zu haben, die in der Lage sind, Hardware zu bauen und die sich durch Open Source Software selbst unterstützen können und die Support Kanäle der Käufer zu nutzen. Das mag wertvoller sein als ein großer Kunde. Also es geht natürlich um Verkaufszahlen und nicht nur darum, net zu sein, aber es hängt wirklich davon ab, einfach überzeugende Argumente zu liefern. Wenn man aus der Perspektive von den Leuten in solchen Unternehmen sich da reinversetzt, dann ist es einfach so ein Mindset, so eine Denkrichtung zu finden, dass sie eben immer, dass man von einer finanziellen Richtung her denkt. Okay, das war die letzte Frage. Felix, vielen Dank für deine Arbeit.