Qualcomm oder Mediatek?

Technik Hardware
1

Hallo Leute,

da ich mich häufiger unbeliebt mache, weil ich so ein „Fan“ von Qualcomm-Chips bin und den vermehrten Einsatz von Mediatek-WLAN-Chips bei Freifunk kritisch sehe, möchte ich hier ein paar Gedanken dazu teilen.

Von Qualcomm gibt es grundlegend drei verschiedene Generationen an Chips:

ath9k
Die ath9k-Chips entsprechen dem 802.11n-Standard. Auch wenn sie etwas älter sind, waren sie die ersten, die uns richtiges Meshing nach 802.11s-Standard ermöglicht haben. Der Grund dafür ist, dass diese Chips die einzigen sind, die direkt vom Kernel gesteuert werden. Das heißt, dass auf ihnen kein closed-source-Firmware-Blob läuft. Der Kernel steuert quasi direkt die Hardware. Zudem haben diese Chips weitere mächtige Features wie einen Spectrum Analyzer, den man vielleicht unter Ubiquiti-Firmware bereits als AirView kennengelernt hat. Der Treiber für ath9k konnte in den letzten Jahren kontinuierlich weiterentwickelt werden. So wurde zum Beispiel Airtime Fairness implementiert, das den Gesamtdurchsatz mit vielen Clients in manchen Fällen um mehr als 70% steigern konnte.

Qualcomm
ath10k
Die ath10k-Chips entsprechen dem 802.11ac-Standard. Es gibt sie einmal als reine WLAN-Chips, die per PCI meist an einen ath9k-SoC angeschlossen werden oder als IPQ40XX-SoC. Der IPQ40XX SoC verfügt über einen sehr leistungsstarken ARM-Quad-Core-Prozessor mit 1.3 GHz Taktrate wohingegen ath9k-SoCs meist lediglich über einen MIPS24/74Kc-Prozessor mit 550-750 MHz Taktrate verfügen.
Leider ist Qualcomm hier zu einem closed-source-Firmware-Blob übergegangen. Es war jedoch möglich, ein NDA mit Qualcomm zu unterzeichnen, um eine eigene Firmware zu implementieren. Das hat zum Beispiel die Firma Candelatech gemacht und die Ad-Hoc/IBSS-Unterstützung eingebaut, die einige Communities noch statt 802.11s einsetzen. Auch diese Chips verfügen über einen Spectrum Analyzer und einige undokumentierte Features, die noch nicht im Open-Source-Treiber nutzbar sind. Die Firmware der ath10k-Chips wird auf einem sehr mächtigen RISC-Prozessor ausgeführt. Es ist möglich, neue Features „für Geld“ implementieren zu lassen. Einige der Chips wurden sogar softwaremäßig mit 802.11ac Wave 2-Technologie nachgerüstet.

ath11k
Das sind die Chips der kommenden Generation nach dem 802.11ax-Standard. Diese Chips sind viel Leistungsfähiger als alles, was wir bisher gesehen haben. Leider sind diese Router bisher noch nicht erschwinglich, aber sie werden wohl die Basis kommender Freifunk-Router bilden.

Qualcomm-Chips sind die Wahl von Routerherstellern von Enterprise-WLAN-APs wie Ubiquiti, da diese über Funktionen verfügen, womit sich das Hidden-Node-Problem lösen lässt (TDMA), sie Signale „hören“ können, die unterhalb der Empfangsschwelle liegen (Spectrum Analyzer) und diese softwaremäßig gut updatefähig sind. Deshalb besitzen diese Router häufig einen externen und somit nicht den Temperaturen des Prozessors ausgesetzten Taktquarz (silberner Kasten), auf den jeder einzelne Router in der Fabrik mit einem Golden Device abgestimmt wird. Sie sind in der Lage auf die Mikrosekunde genau Signale loszuschicken und können sogar mit einigen Softwaremodifikationen zur Ortung eingesetzt werden.

Mediatek
MT762X
Die Chips dieser Reihe bilden die Grundlage der meisten Mediatek-Router. Sie haben meist ein 2.4GHz-Modul und einen MIPS24Kc-Prozessor als MIPSEL mit 580 MHz. Das 2.4 GHz-Modul läuft mit einem closed-source-Firmware-Blob, der seit Jahren nicht geupdatet wurde und nur über die minimal notwendigen Funktionen verfügt.

MT761XX
Diese Chips sind WLAN-AC-Chips, die per PCI meist an den oben genannten Chip angeschlossen werden. MT7612X-Chips sind Wave 1- und MT7615X Wave 2-Chips. Auch diese nutzen einen closed-source-Firmware-Blob mit minimalen Funktionen, der seit Jahren nicht geupdatet wurde. Über die technischen Möglichkeiten und Erweiterbarkeit ist nichts bekannt.

MT7629X
Sie sollten die Nachfolger-SoCs sein. Sie besitzen einen Dual-Core-ARM-Prozessor und sind mit 2.4 GHz 802.11n und 5 GHz 802.11ac Wave 2 gerüstet. Da sie bislang teurer und weniger leistungsfähig als Qualcomm IPQ40XX-SoCs sind, gibt es bislang kein Gerät auf dem Markt, das diese Chips nutzt.

Die Mediatek-WLAN-Chips werden erst seit kurzem vernünftig von OpenWrt unterstützt, da Felix Fietkau (Mitgründer von DD-WRT und OpenWrt-Ikone) die Treiberentwicklung übernommen hat. Es ist davon auszugehen, dass es keine gravierenden Änderungen mehr geben wird. Die Meshfunktionalität hat seiner Aussage nach keine hohe Priorität.

Mediatek-WLAN-Chips werden hauptsächlich in günstigen Consumer-Routern eingesetzt, da sie auf ein minimales Platinenlayout optimiert sind. Hohe WLAN-Störunempfindlichkeit und eine genaue Taktrate sind hier zweitrangig.

So viel zum Tech-Porn… Was für mich das ausschlaggebende Argument dafür ist, auf Qualcomm-Chips zu setzen, ist, dass wir als Freifunker stark von dem Hidden-Node-Problem betroffen sind. Häufig werde ich gefragt, wieso man nicht 10 Router in einer Kette vernetzen kann, um eine Straße abzudecken. Das Hidden-Node-Problem ist euch ja sicherlich bekannt… Ubiquiti löst das Problem mit ihrem TDMA/AirMax. Dort habt ihr zum Beispiel eine Sektorantenne auf einem Wasserturm (AP) und viele, viele Nanostations, die auf diesen Wasserturm ausgerichtet sind und sich gegenseitig nicht hören (CPEs). Da die CPEs sich gegenseitig nicht hören, greift das Kollisionsvermeidungsverfahren CSMA/CA nicht.
Also senden sie gleichzeitig und beim AP kommt nur Kaudawelsch an. Ist hingegen AirMax auf allen Geräten aktiviert, dürfen die CPEs nur senden, wenn der AP es ihnen erlaubt und somit gibt es keine Kollisionen.
Bei Mikrotik heißt das Verfahren NS2, bei TP-Link „Pharos“, bei Ubiquiti „AirMax“ und bei Deliberant heißt es „iPoll“. Alle nutzen dafür ath9k-Qualcomm-Chips und Ubiquiti sogar zusätzlich ath10k.

Es gab einige Bemühungen ein solches „Zeitschlitzprotokoll“ für ath9k-Chips zu entwickeln.

  • Adrian Chadd hatte bereits 2012 den Anfang für Intel gemacht und in FreeBSD ein TDMA entwickelt, bei dem er die Beacon-Queue des ath9k-Chips für diese Zwecke missbraucht hat.

  • Die Firma NETSHe hat 2015 eine closed-source-Variante mit IBSS und Batman Advanced programmiert und verkauft ihre Software an VoIP-TelCos und einige asiatische Routerhersteller.

  • Sven Zehl von der TU Berlin hat 2016 die Power-Save-Funktionalität missbraucht und das ganze als Forschungsarbeit unter dem Namen hMAC veröffentlicht.

  • 2017 hat die University of Texas eine TDMA basierend auf OpenWrt mit ath9k-Chips gebaut und als Forschungsarbeit unter dem Namen RT-WiFi veröffentlicht.

Unser Problem so ein Verfahren für Mesh zu implementieren, ist jedoch noch einmal eine andere Hausnummer, denn bei uns gibt es keine Unterscheidung zwischen AP und CPE. Alle Teilnehmer im Mesh sind gleichberechtigt. Daher gab es Versuche, ein solches TDMA-ähnliches Verfahren für Mesh zu entwickeln und unter dem Namen „MCCA“ zu standardisieren. Der Fokus lag hierbei jedoch nicht darauf, das Hidden-Node-Problem zu lösen, sondern zeitkritische Übertragungen wie VoIP oder Videotelefonie in Mesh-Netzwerken zu ermöglichen. Über 3 Jahre hinweg gab es Zahlreiche Forschungsarbeiten, die vor zwei Jahren zu dem Schluss gekommen sind, dass ein erheblicher Aufwand getroffen werden müsste und weitere Forschungsarbeiten notwendig sind und dass es ohne Zusammenschluss der beteiligten Firmen und staatlicher Förderungen nicht finanzierbar sein wird, ein solches standardisiertes Verfahren zu entwickeln.
Fazit: Zuverlässiges VoIP und Videotelefonie im Freifunknetz über Mesh wird für weiteres ein Träumchen bleiben.

Doch für uns wäre es ja schon ein riesiger Schritt, wenn die Bandbreite über mehrere Hops nicht einbrechen würde. Und dafür forsche ich seit 4 Jahren an einem Verfahren und stehe kurz davor, das fertigzustellen. Wenn das fertiggestellt ist, bedarf es aber noch der Implementierung und das wird niemals auf Mediatek-Chips möglich sein, denn unter Umständen müssen zusätzliche Funktionen in die ath10k und später ath11k-Firmware gepatcht werden.

Einen großen Hoffnungsschimmer gibt es jedoch. Vor kurzem habe ich erfahren, wie das „offizielle Zeitschlitzprotokoll“, das von Ubiquiti usw. genutzt wird, in ath9k/ath10k technisch umgesetzt wurde und es sieht so aus, als wären die notwendigen Funktionen in der ath10k-Firmware vorhanden, aber undokumentiert. Qualcomms Name für diese Funktion ist QB00ST.

BITTE SCHREIBT HIER NICHT QB00ST AUS ODER BITTE NUR MIT ZWEI NULLEN STATT Os.
Ich möchte nicht, dass das hier bei Google gefunden wird.

Naja… Jedenfalls würde meine Motivation, das Meshprotokoll weiterzuentwickeln, erheblich sinken, wenn die Freifunknetze auf einmal aus Routern mit technisch sehr eingeschränkten Mediatek-Chips bestehen würden (davon abgesehen, dass ich auch so nicht besonders beeindruckt von der Performance und der Kompatibilität mit Qualcomm-Chips bin).
Dann würde ich eher in Erwägung ziehen, die Software für gutes Geld zu verkaufen.

19 „Gefällt mir“
2

Dürfte die Problematik sich nicht ohnehin mit 802.11ax und OFDMA merklich entspannen?
Klar, das ist noch etwas hin, bis die meisten Knoten im Netzwerk das unterstützen. Aber ich denke das könnte ein Treiber für die Aufrüstung sein.

3

@Felix
Bei Mesh verschiebt sich das Problem mit OFDMA nur, denn dann müssen sich die Mesh-STAs absprechen, welche Carrier sie benutzen, um das Hidden-Node-Problem zu umgehen und dabei sinkt die Bandbreite bei den Meshtopologien, die wir im Freifunknetz haben dramatisch.

Ein Ansatz, um solche Probleme ohne Absprachen zu verringern, ist das ziemlich unbekannte „Fractal Coding“. Dabei werden fraktale Algorithmen genutzt, um die Carrier auszuwählen, die man benutzt und sie wechseln mit jeder Transmission. Dadurch werden Kollisionen allgemein stark vermieden, aber es ist schwer darüber Informationen zu finden, weil das Militärtechnik ist.

4

Du schreibst es ja selbst, die treibende Kraft hier ist einfach das Geld.

Wenn jemand heute nach einem Freifunk Router fragt, den er im Geschäft kaufen kann dann kann man eigentlich nur noch mit FB4020/4040 oder Unifi AP AC Lite antworten.

Wenn der potentielle neue Freifunkter dann aber auf den Preis schaut hat sich das Thema Freifunk auch wieder erledigt. Es gibt leider derzeit keinen erschwinglichen Router neu im Geschäft zu kaufen. Wer Neulinge anfüttern will muss so defakto auf gebrauchte Geräte zurückgreifen.

5

Moin @anon88999732,

vielen Dank für deinen tollen Beitrag!

Was du beschreibst nenne ich den Linuxschen Teufelskreis der schlechten Treiber:

Dass jetzt allerdings Medithek-Router so gefeiert werden, entspricht wieder dem Linuxschen Teufelskreis der schlechten Treiber (günstigste Hardware hat keine guten Treiber, Hersteller schert sich nicht, es gäbe teurere Hardware mit guten Treibern, aber Geizkragen wollen unbedingt die günstigste Hardware verwenden, also werden rückwärtsingenieurte Treiber verwendet, die aber kacke sind, am Ende profitiert der Hersteller mit der linuxfeindlichsten Einstellung und das ganze geht im nächsten Produktzyklus genauso weiter).

Selbstzitat von hier.

3 „Gefällt mir“
6

Also soweit mir bekannt ist, wurde Felix Fietkau von Mediatek für die Entwicklung bezahlt. Es würde mich doch schon sehr wundern, wenn er trotzdessen alles hätte rückwärts entwickeln mussen. Außerdem gibt es inzwischen eine linux-mediatek mailing list, auf welcher mindestens 4 Mediatek-Entwickler Patches beisteuern. Ein Unternehmen das sich um Linux nicht schert sieht für mich anders aus.
Außerdem gibt es noch 2 RedHat Entwickler die bei der Entwicklung mithelfen, einer davon hat letztens erst die Unterstützung für den MT7615e Chip beigesteuert.
P.S.: Dieser Vortrag von Fietkau beleuchtet das Thema mal aus einer anderen Ecke und zeigt wieso Qualcomm doch nicht so goldig wie beschrieben ist, zumindest aus Entwicklersicht.

7

Du hast die Aussage aus dem Zusammenhang gerissen. Sie bezog sich generell auf allemöglichen Hardwarekomponenten und die Erkenntnis, dass Unternehmen, die weniger in Treiber entwickeln meistens doch am Ende auch Hardware an Linuxnutzer absetzen können.

Ich kann die Treibersituation nicht im Detail beurteilen sondern versuche die Information von Technikdetails befreit zu kommunizieren.

Bzgl. des Treiberzustands kann ich mich nur auf die Einschätzung anderer verlassen:

Einen geschlossenen Blob bereit zu stellen, ist für mich die Definition eines Unternehmens, was sich nicht schert und die Linuxidee bzw. die Idee freier Software nicht verstanden hat.

2 „Gefällt mir“
8

Sorry wenn ich das aus dem Zusammenhang gerissen habe, für mich war der mt76 Zusammenhang noch gegeben.

Closed source Firmware blobs hast du mit ath10k genauso, bzw sogar in schlimmerer Form. Schau dir mal den Vortrag an, da wird schön dargestellt was Qualcomm für Mist anstellt.

9

Macht ja nichts.

Qualcomm waren doch vorher auch schon die bösen, bevor sie Atheros gekauft haben. Soweit ich mich erinnere.

Linux und WLAN-Chips ist so eine Sache. Von daher freut es mich, dass @anon88999732 sich da so reinhängt.

2 „Gefällt mir“
10

Das hat ja aber wenig damit zu tun ob nun Qualcomm oder Mediatek besser ist. Es unterstreicht eher, dass Qualcomm bereits seit Jahren wenig auf OpenSource gibt und alles in Blobs packt.

Der Vergleich zwischen den beiden Herstellern hinkt ohnehin stark. Qualcomm verkauft bereits seit vielen Jahren Chips, hat viel Erfahrung im OpenSource-Umfeld und wird, was die Offenheit der Treiber betrifft, trotzdem immer restriktiver.
Mediatek ist weitaus jünger am Markt, hat wenig OS-Erfahrung, packt viel weniger Magic in die Firmware, sodass viel vom Treiber kontrolliert werden kann, stellt Entwickler für den Linux Support ab und wird hier trotzdem in die „Billig-und-OS-feindlich“ Ecke gestellt.

3 „Gefällt mir“
11

Das ist hier der Knackpunkt. Felix sah nicht, was der ath10k-Chip kann, sondern nur was öffentlich implementiert wurde und Mediatek hat sich bereiterklärt, die open-source Treiberentwicklung zu unterstützen und ihm die ganzen vertraulichen Dokumente bereitgestellt. Qualcomm hat jedoch von Beginn an ihre Treiber als open-source veröffentlicht und einen full-time Kernelentwickler dafür eingestellt (Kalle Valo). Felix sagt hier am Anfang des Videos auch, dass Mediatek nicht so frei ist wie ath9k.

Worüber er sich eigentlich aufregt, ist dass Qualcomm dazu übergegangen ist, eine Firmware einzuführen, die alles offloadet und dass Qualcomm andauernt Änderungen in der Firmware macht, die alles umstoßen. Wenn man jedoch versucht herauszufinden, wie der Chip funktioniert, dann sieht man, dass es Sinn macht, wie diese Firmware aufgebaut ist, weil sonst der Hauptprozessor hoffnungslos überfordert wäre und das Timing nicht eingehalten werden könnte. In dem Fall hat Qualcomm einfach die Features für ihre „Premiumkunden“ vorne angestellt und den Treiber drumherum gebaut. Felix sagt ja auch in dem Vortrag, dass das eher wie ein LTE-Modul aussieht. Ja, das ist es auch, aber dafür ist es halt viel mächtiger, wenn man weiß wie es zu programmieren ist.

Fakt ist, dass Qualcomm bisher immer noch den besten open-source WLAN-Treiber von allen Chipherstellern bereitgestellt hat und dafür einen sehr erfahrenen full-time Kernelentwickler engagiert und vergleichsweise erst seit kurzer Zeit Felix für die Entwicklung von Mediatek bezahlt wird (und das auch nur bis zu einem bestimmten Stabilitätsgrad und dann altert der Treiber wieder vor sich hin).

Dass bei Qualcomm auf Firmware-Blobs gesetzt wird, hat technische Gründe. Dass das Firmware-SDK nicht open-source veröffentlicht wird, liegt daran, dass die Ähnlichkeit zu ihren LTE-Modems (wo sie Marktführer sind und bleiben wollen) gegeben ist, denke ich.

Fakt ist außerdem, dass Mediatek-Chips einfach nicht mehr können, als sie gerade tun.

Wenn man sich von Adrian Chadd einen Vortrag anhört (der vollen Zugang zu den vertraulichen Dokumenten von Qualcomm hatte), dann kriegt man auch wieder einen anderen Eindruck.

2 „Gefällt mir“
12

Danke für deine Ausführungen und den Link, den Vortrag kannte ich noch nicht.

13

Ich sitze seit vier Jahren an dem Thema, weil ich mir wünsche, dass wir zumindest für PtmP-Setups nicht mehr auf Ubiquiti-Firmware etc. angewiesen sind und am besten das ganze für Mesh nutzbar machen können. Vor drei Jahren hatte ich mal einen Gluon-Fork gebaut, wo ich ein Benutzerinterface ähnlich wie man es von Ubiquiti kennt, eingeführt hatte und hMAC getestet habe. GitHub - freifunk-graviton/graviton: Wireless router firmware optimized for PtP & PtmP deployment
Leider war das performancemäßig ziemlich enttäuschend und ich habe das schnell beiseite gelegt.

Außerdem habe ich seit Jahren einen JavaScript-Parser für die Spectrum Analyzer-Daten auf einem meiner Rechner, den ich, wenn ich die Zeit finde, aufräume und einem LibreMesh-Entwickler zukommen lasse, der bereits eine einfache UI dafür geschrieben hat.
https://blog.freifunk.net/2017/08/29/gsoc-libremesh-spectrum-analyzer-summary/

NETSHe arbeitet an einer Implementierung von QB00ST für ath9k, aber die wollen damit verständlicherweise Geld verdienen. Das heißt wir müssten das irgendwie finanzieren, um das in open-source zu kriegen. Die Frage ist auch, ob wir das überhaupt noch wollen, wenn wir das für ath10k haben.

ath10k ist jetzt fünf Jahre alt und das Interesse von Qualcomm ist gesunken, alles unter Verschluss zu halten. Vor kurzem hat ein Routerhersteller versehentlich Dokumente geleakt, die einen sehr guten Überblick über die Möglichkeiten der ath10k-Chips geben und vielleicht sogar alles beinhalten, was notwendig ist, um das QB00ST unter OpenWrt zum Laufen zu bringen. Darauf habe ich gewartet.

Mit diesen Daten wäre es durchaus möglich, Ben Greear für die Implementierung der für „Mesh-QB00ST“ benötigten Funktionen zu bezahlen,

Leider sieht es aktuell so aus, als sei ich der Einzige, der da ohne kommerzielles Interesse dran sitzt und ich habe auch nicht die finanzielle Freiheit, da viel Zeit reinzustecken. Ich hoffe, dass es sich als einfach herausstellt und dass wir, wenn klar ist, was gemacht werden muss, es finanziert bekommen. Vor fünf Jahren hätten wir mit Sicherheit über eine Million Euro dafür zahlen müssen. Mittlerweile liegt es eher im Bereich von unter 100.000 Euro.

Wie gesagt sehe ich aber auch keinen großen Nutzen mehr darin, wenn wir größtenteils auf Mediatek umsatteln. Dann würde ich eher überlegen, es als Lizenz-Modul zu veräußern. Das heißt es wäre dann closed-source, aber für Freifunk nutzbar. Dann würde ich z.B. von Routerherstellern pro Gerät eine angemessene Lizenzgebühr nehmen und von Freifunkern den symbolischen Euro. Trotzdem wäre es eher eine Liebhaberei als ein ordentliches Geschäft und ich werde langsam alt und hab meine Schäfchen noch nicht ins Trockene gebracht.

Vor vier Jahren war Freifunk ein hot topic und auch dieses Forum war extrem aktiv. Mittlerweile ist das Thema ein wenig abgeflaut und wir sitzen hier als harter Kern. Unsere ideologischen Grundsätze müssen mit der harten Realität in Einklang gebracht werden. Hätte ich vor einigen Jahren noch die Idee von Freifunk „Premium-Services“ mit schnellen Supernodes als Verletzung des Pico-Peering Agreements, das kommerzielle Anbieten des Betriebs von Freifunkknoten durch Systemhäuser und den bewussten Verzicht auf Gemeinnützigkeit zum Wirtschaften kritisiert, bin ich mittlerweile der Überzeugung, dass es gar nicht anders geht und eine Neuaufstellung unserer Grundsätze überfällig ist. Während der 5G-Ausbau mit riesigen Summen staatlich subventioniert wird, nehmen wir die Möglichkeiten, die wir durch unseren Fuß in der Tür bei der Politik in Kommunen und Ländern haben, nur ungenügend wahr. Obwohl z.B. mit WireGuard mit ordentlicher Verschlüsselung ein vergleichbarer Durchsatz zum Tunneldigger-Ansatz erzielt werden kann, wird es bisher kaum eingesetzt, weil eine vernünftige Implementierung (ohne GRETAP-Hacks) nicht ohne finanzielle Bezuschussung möglich ist. Weil ich in Freifunk ohne Verschlüsselung nicht das Potential sehe, was es an Zensurresistenz haben könnte, habe ich mich dem Thema angenommen. Das gleiche gilt für die technischen Grenzen, die wir aktuell im Mesh haben. Ich würde mir wünschen, dass wir viel mehr Zusammenarbeit in der Softwareentwicklung hätten bzw. mehr Communities sich an der Gluon-Entwicklung beteiligen würden, statt ihre eigene Firmware zu entwickeln und auch bereit wären, gewisse Projekte, ohne die die Entwicklung ausgebremst wird wie NeoRaiders NeCo, der Dezentralitätsansatz von christf und das Domain-Selector-Konzept von tata, finanziell unterstützt werden.
Mein „Traum“ ist immer noch, dass Gluon irgendwann in einem Zustand ist, in dem wir die Funktionalitäten von LibreMesh einbauen und eine gemeinsame Entwicklungsbasis bilden können. Die Realität ist, dass wir vorher von der von adorfer sogenannten „kollektiven Selbstausbeutung“ wegkommen müssen und ich sehe nicht, dass das in nächster Zeit passieren wird.

18 „Gefällt mir“
14

Leider kann man den Herz-Button nur einmal betätigen. Aber du sprichst mir aus der Seele.

Ich bin gerade (mal wieder) umgezogen und habe mich natürlich gleich der örtlichen Mesh Community angeschlossen (in meinem Fall ist das nun tomesh).
Es ist interessant zu sehen, wie dort andere Ansätze verfolgt werden als beim Freifunk. Man hat hier noch gar kein Netz aufgebaut sondern forscht viel mehr zu den Dezentralen Basisdiensten.
In knapp drei Wochen findet hier dann die kleine aber feine OurNetworks Konferenz statt. Ich bin gespannt welche Ansätze dort vorgestellt werden und wie sich das auf Freifunk anwenden ließe.
Vielleicht müssen wir auch beim Freifunk in Deutschland etwas umdenken und wieder mehr zu einer Einheit zusammenfinden.

Ich bin interessiert auch Lösungen dafür zu finden, wie wir Leute finanzieren können, die die richtigen Technologien für uns weiterentwickeln. Wir müssen dazu mal zusammenkommen und Ideen sammeln, wie ein Funding aufgestellt werden kann und welche Töpfe man dafür anzapfen kann. Möglichkeiten und Geld ist sicherlich in ausreichende Menge vorhanden. Man muss nur wollen.

2 „Gefällt mir“
15

Danke für diese tolle Analyse!

16

Danke für deinen sehr ausführlichen Beitrag. Der Qualcomm Beitrag war sehr interessant. Hab trotzdem nochmal eine Frage.

Was für ein 2.4 GHz Modul meinst du? Viele SOCs die auf MT7621A basieren, benutzen z.B. einfach 2 x MT7615E, das im 2.4 GHz und 5 GHz arbeiten kann. Und dort findet aufjedenfall aktiv Treiberentwicklung statt.

17

Ja der Treiber wurde von nbd die ganze Zeit weiterentwickelt, aber für die Firmware, die auf dem Chip läuft, gab es keine Updates. Die ist closed-source. Der ath9k hingegen hat keine Firmware und ist damit komplett per Software kontrollierbar, open-source und dementsprechend zukunftsfähig. Das Problem mit den fehlenden Firmware-Updates bei den Mediateks ist, dass sie verbuggt war oder ist und nbd das auch nicht fixen kann. In meinen Augen war damit der Chip nicht zukunftsträchtig und gehörte nicht in einen produktiv genutzten Router. Zu meinem Erstaunen hat Mediatek vor kurzem ein Firmwareupdate bereitgestellt. kernel/git/firmware/linux-firmware.git - Repository of firmware blobs for use with the Linux kernel
Ob das langfristig weiterhin gemacht und tatsächlich Bugs gefixt werden, weiß ich nicht. Es ist sehr intransparent. Das sind halt Consumer-Chips und der Consumer interessiert sich nicht dafür. Wenn Mediatek bei ihren neueren Chips offener als Qualcomm mit dem was ihre Chips machen, umgeht, regelmäßig Firmwareupdates rausbringt, die tatsächlich Bugs fixen usw., dann würde ich Mediatek-Chips empfehlen. Bisher war das aber nicht der Fall. Bei Qualcomm weiß ich, dass eine(r) von uns Freifunkern z.B. eine NDA unterschreiben und den Firmwarecode ansehen könnte. Bei Mediatek werde ich das mal anfragen.

3 „Gefällt mir“
18

Danke nochmal für die Antwort. :wink: Sry, ich war mit den SOCS und den WLAN Chips durcheinandergekommen. :rofl:

Hat das mal wer gemacht? :slight_smile:
Wie ich den Qualcomm-Menschen verstanden habe, soll so wenig wie möglichst auf dem Chip gemacht werden, also zeitkritische Sachen wie ACK-Generation. Wie er auch im Vortrag gesagt hat, sind die CCA Sachen sehr interessant sowie ACK ausstellen und alles mögliche. Das wäre ja auch sehr für uns Interessant. :wink:

Ich verstehe die Argumente zum Teil mit dem closed-source, aber ich schätze die Innovationsfähigkeit, Verbesserungspotential und Erweiterbarkeit höher ein. Es wäre so schön wenn Mediatek den OpenSource Weg eingeht. :slight_smile:

19

Ich hab gehört, dass Qualcomm jetzt auch die Sourcen wieder für den CT-Entwickler geclosed hat? :open_mouth:

20

@Polynomialdivision Das habe ich auch gehört. Es war aber nur eine Frage des Geldes wie mir gesagt wurde. Wenn wir da Bedarf haben, was zu patchen, ließe sich das schon lösen. Warten wir mal die Verhandlungen ab und ranten schön über Qualcomms Policy… Vielleicht hilft das. Womöglich wird Qualcomm aber genug in der API freigeben, dass jemand MCCA implementieren kann. Da hatte kürzlich eine Firma angefragt, die EU-Fördergelder für die Entwicklung beantragen will, weil ich mal dazu etwas gemacht hatte.

1 „Gefällt mir“