Using the D-Link DWA-X1850 Wi-Fi 6 USB adapter on Linux (RTL8832AU 802.11ax)

After the introduction of wireless routers, phones and PCIe cards featuring the next generation of Wi-Fi, known as 802.11ax (or simply Wi-Fi 6), finally the first USB 3.0 adapters have arrived on the market:

The ASUS USB-AX56 adapter has two external antennas, while the D-Link DWA-X1850 comes in a more compact case with built-in antennas.
Both support 2 streams dual band on 2.4GHz and 5GHz, labelled “AX1800”, which translates as:

  • 40 MHz channel width on 2.4GHz, using MCS index 11 and short GI (0.8µs), resulting in a nominal rate of 573.5 Mbps
  • 80 MHz channel width on 5 GHz, also MCS 11 with short GI (0.8µs), resulting in the nominal rate of 1201 Mbps

Combining both rates, these are marketed as AX1800, although you typically can’t bond connections and will rather end up with a Link Rate of 1201 Mbit/s only, which may be somewhere around 500 Mbit/s of real throughput (all while assuming you are located very close to the router, and none of your neighbours are transmitting on the same wifi channel, of course).

While the Link Rate will degrade quickly when a few walls need to be penetrated, the receive sensitivity of this new generation of chips can still be considered superior to previous ac adapters, although the limitation to 2 streams might be an issue. Especially if your router supports AC with 3×3 or 4×4, older adapters like the infamous “Death Star” D-Link DWA-192 might still be a better choice.
It uses RTL8814AU and supports AC1900, i.e.

  • 3 spatial streams with 40 MHz channel width on 2.4GHz, using MCS index 9 and short GI (0.4µs), resulting in 600Mbps
  • 3 spatial streams with 80 MHz channel width on 5GHz, using MCS index 9 and short GI (0.4µs), resulting in 1300Mbps

This may seem like not much of a difference, but keep in mind that MCS11 will degrade more quickly with a few walls in between, and when the connection is at MCS9, 2 streams of AX will only be a rate of 960.Mbps compared to 1300 with 3 streams AC.

But back to the first USB AX adapters hitting the markets right now:
Both the ASUS USB-AX56 and D-Link DWA-X1850 are based on the Realtek RTL8832AU chipset, which is the 2-stream variant of the RTL8852AU – this is the most important information when it comes to finding a driver that works on Linux.

When searching github, you will find the repository
https://github.com/shiqishao/RTL8852AU_WiFi_linux_v1.15.0.1-0-g487ee886.20210714
which contains the driver source code from Realtek. There are also a few documents that explain how to introduce your device’s USB VID and PID into the driver:
The relevant file to modify here is os_dep/linux/usb_intf.c, the USB VID e.g. for D-Link is 0x2001, the PID for the DWA-X1850 adapter is 0x3321. For the ASUS USB-AX56, it would be 0B05:1997.

You can find this already patched in my fork of the repo on github:
https://github.com/s-2/RTL8852AU_WiFi_linux_v1.15.0.1-0-g487ee886.20210714

// Update: The most current maintained fork of this driver is now available from the repo of lwfinger, please use this instead: https://github.com/lwfinger/rtl8852au

Now just clone that repo, make and sudo make install, then re-plug the dongle.
After being plugged in, the DWA-X1850 is in USB Mass Storage mode, which can be switched to network adapter mode by ejecting the virtual drive (eventually, it seems this device should be added to the USB modeswitch project).

The blue status LED is currently not working, maybe this needs some addition GPIO definition which is specific to this device.

Also keep in mind that this driver, although being built from source, uses the Realtek proprietary structure, which may not be what the Linux Wireless developers are aiming for.

A corresponding Linux Wireless compatible driver would be “rtw89”, which currently supports only the PCIe version of RTL8852, but I’m sure this may soon be updated to include the USB variants, and one day be available with Ubuntu and other common distributions. For now, at least we have the Realtek driver.

DVB-T2 HD auf billiger China-Hardware?

Gerüchte um die Abschaltung von DVB-T zugunsten eines Nachfolgestandards gibt es schon seit Jahren, vor einiger Zeit wurde es dann konkreter: Multinationale Ballsportereignisse zeigten sich ja schon in der Vergangenheit als äußerst geeignet, um neue Generationen von Entertainment-Hardware unter das konsumfreudige Volk zu bringen.

Also mal spaßeshalber bei AliExpress den nächstbilligsten China-DVB-T2-Stick für $18 bestellt, nur so zum Spielen, ohne Garantie auf Empfangbarkeit der terrestrischen Ausstrahlungen in Deutschland. Seit dem 31.05.2016 gibt es nun auch den ersten Pilotmultiplex in den Ballungsräumen.

Es folgt die Essenz aus stundenlangem Wälzen von Bullshit-Bingo und mehr oder weniger hilfreichem technischen Wissen und Halbwissen, das man zu dem Thema finden kann:

DVB-T2 wurde als ETSI-Standard ursprünglich mit MPEG-4 (H.264) eingeführt
in Deutschland wird als Videocodec HEVC (H.265) genutzt,
außerdem eine Modulation nach aktuellerer Spezifikation mit Multi-PLP (Physical Layer Pipes)
geschützte Wort-/Bildmarke "DVB-T2 HD" der Landesmedienanstalten als Zertifizierung für Geräte
Übertragung in 1080p50, öffentlich-rechtlich meist hochskaliert, EM-Spiele jedoch nativ in 1080p und damit momentan besser als über Satellit / Kabel!
momentan billigster China-Gadget DVB-T2-Stick von Astrometa:
RTL2832P + R828D (diese Kombination klingt doch irgendwoher vertraut)
+ dazu noch ein externer Demodulator für DVB-T2, fertig ist der Stick für DVB-T2
Demodulator-IC von Panasonic: alte Version MN88472, unterstützt kein M-PLP
Stick aufmachen: neue Hardware-Revision mit MN88473 drin?
juhuu, dann fehlt jetzt nur noch die Software!
Klickibunti-Player TVR von Astrometa für Windows:
immerhin halbwegs zum Scannen geeignet, will bei mir aber auch nach Installation von LAV Filters kein H.265 decodieren

E drücken für Einstellungen
Strg + Alt + Shift + D für erweiterte Hardware-Informationen
VLC unterstützt H.265 (und/oder den Demodulator!?) erst ab Version 3, also aktuelle Nightlies runterladen!
Im VLC dann nicht drauf reinfallen und "DVB-T2" wählen, sondern DVB-T!

What’s the frequency, Kenneth?

Schon bei der Einführung von DVB-T hielt man es seitens der Sendeanstalten offenbar nicht für nötig, die Sendefrequenzen rauszurücken. Neben detaillierten Übersichten zu FM-Radiofrequenzen in den Regionen und den Parametern für den SAT-Empfang wurden DVB-T-Nutzer damals lediglich darum gebeten, auf ihrem Klickibunti-Gerät “einen Suchlauf” durchzuführen.

Geht mit VLC leider nicht, muss auch nicht (man könnte aber sicher einfach ein Batch-/Shell-Skript basteln).

Eine Übersicht der Frequenzen für den DVB-T2 HD Pilotmultiplex (sowie viele weitere Informationen – bisher die mit Abstand hilfreichste Seite) gibt es bei dehnmedia.info.

Im VLC wird der Wert in kHz eingegeben, also z.B. 626000 für Hannover, 658000 für Hamburg etc.

Falls der Empfang in ländlicheren Regionen nur auf dem Dachboden wirklich brauchbar ist, kann man so im Gegensatz zur Klickibunti-Software immerhin auch mit wenigen Klicks einen Streaming-Server aufmachen und übers lokale Netz womöglich sogar direkt auf den Fernseher im Wohnzimmer streamen – falls man sowas besitzt.

Mir hat in den letzten Jahren jedenfalls ein DVB-T-Stick für sporadisches Fernsehen völlig ausgereicht.

Wenn die Privaten nun langfristig mit der DVB-T2-Plattform Freenet.TV planen, ihre Reichweite in den Ballungsräumen zu reduzieren und terrestrisch nur noch verschlüsselt zu senden, sollen sie das gerne tun.

Wenn man dann mittelfristig noch mit der analogen Kabel-Abschaltung rechnen kann, bliebe eigentlich nur die SD-Übertragung auf 19,2° Ost, die dem Deutschen Privatfernsehen überhaupt noch einen Rundfunk-Charakter geben würde – alles andere sind meiner Meinung nach längst Telemediendienste.

Möglicherweise ist das auch mittelfristig die Intention, die lästigen Bedingungen für eine Vollprogramm-Lizenz eines Tages endlich loswerden und über sämtliche Inhalte frei entscheiden zu können?

Vielleicht gibt es dann irgendwann wieder nur noch öffentlich-rechtliches Fernsehen in Deutschland, wie vor über 30 Jahren…

Chipkartenanwendungen und Browser-Integration: Standard gesucht

Da hier in letzter Zeit doch ein gewisses Interesse in Zusammenhang mit dem ComputerBild-Lesegerät und v.a. der beigelegten Karte aufkam, wollte ich nun nochmal etwas allgemeiner auf die Problematik (und bisher verbreiteten Lösungen) der Schnittstelle zwischen Web-Anwendung und Kartenlesegerät eingehen.

Eine Web-Anwendung kann nicht einfach nach Belieben auf die Hardware des Computers zugreifen, was ja grundsätzlich auch erstmal nichts Schlechtes ist; hin und wieder ergibt sich aber doch die Situation, wo dies vom Benutzer gewünscht ist: Bekanntestes Beispiel dürfte hier wohl das Flash-Plugin mit der Bitte um Zugriff auf Kamera und Mikrofon sein.

Für Chipkarten dagegen hat sich noch kein globaler Standard so wirklich durchgesetzt.
Allerdings fehlte es hier bisher auch an Angeboten, die die breite Masse ansprechen; insbesondere lokale Anwendungen mit jeweils beschränktem Nutzerkreis sind geradezu prädestiniert dafür, Insellösungen hervorzubringen.

Eine inzwischen schon relativ verbreitete Anwendung kommt dagegen aus dem Bankensektor:

Mit der SmartLine von fun communications lassen sich die Funktionen der GeldKarte (die zumindest in der kontaktbehafteten Variante ohnehin schon die meisten mit sich herumtragen dürften) über ein Java-Applet online nutzen.

Alternativ ist auch die Nutzung über das SIZCHIP-Plugin der Sparkassen möglich, das allerdings erst (und nur zu diesem Zweck) installiert werden muss, während Java in den meisten Fällen schon vorhanden sein dürfte.

Wer das nun selbst ausprobieren möchte, findet auf der GeldKarte-Seite die Möglichkeit, die im Chip gespeicherten Informationen auszulesen: http://www.geldkarte.de/_www/de/pub/geldkarte/privatnutzer/services/karten_tests.php

Hierzu genügt schon ein Klasse-1-Leser (für kontaktbehaftete Karten, da die meisten GeldKarten bisher nicht kontaktlos sind) – die Transaktion wird dann am Bildschirm über eine virtuelle Tastatur bestätigt. Grundsätzlich wäre es also möglich, eine Transaktion z.B. umzuleiten; bisher hat das scheinbar auch niemanden gestört, erst jetzt mit dem nPA wird der Eindruck erweckt, als seien Klasse-1-Leser ein erst in diesem Zusammenhang entstandenens Problem.
Allerdings speichert die eigene GeldKarte immer auch die ID der jeweiligen Händlerkarte, mit der der Empfänger schließlich seine Umsätze bei seiner Bank einfordert, d.h. es wäre im Zweifelsfall relativ gut nachvollziehbar, wo das Geld gelandet ist.

Beide Varianten sind für den Betreiber kostenpflichtig, und damit für Anwendungen abseits von Zahlungsfunktion oder Altersverifikation für die meisten Websites erstmal weniger interessant.

Eine ebenfalls proprietäre aber für alle Beteiligten kostenlose Methode stellt REINER SCT mit “One Web, one Key” zur Verfügung.
Die Serverkomponente bzw. Spezifikation zur Einbindung in eigene Web-Anwendungen soll in Kürze bereitgestellt werden; vermutlich wird es zukünftig auch möglich sein, eigene Karten nach PKCS#11 für OWOK zu verwenden(?); außerdem soll z.B. auch der neue Personalausweis unterstützt werden.

Voraussetzung für den Nutzer ist hier jedenfalls wieder die Installation des passenden Browser-Plugins.

Nun ist der Gedanke des Logins auf Webseiten ohne Benutzername und Passwort an sich nichts neues, und so hat natürlich auch Microsoft hierzu seit längerem eine Lösung parat:
Windows CardSpace ermöglicht dem Benutzer das Erstellen und Verwalten von virtuellen ‘Karten’, mit denen man sich bei Webseiten anmelden kann, die dies unterstützen. Zusammen mit einigen anderen bekannten Unternehmen wurde die Information Card Foundation gegründet – es handelt sich hier also um einen offenen Standard.

Eine sehr interessante Möglichkeit, sich mit InformationCards einzuloggen, bietet die Seite openidbycard.com, die übrigens von fun communications (s.o.) betrieben wird.
Man kann sich damit auf einer beliebigen OpenID-Website anmelden, indem man einfach openidbycard.com eingibt und anschließend eine (selbst erstellte!) virtuelle Karte zur Identifikation sendet; man ist hier also mehr oder weniger sein eigener OpenID-Provider.

Wer das nun selbst testen möchte, mag vielleicht überrascht sein, als Windows-User (konkret: ab dem .net-Framework 3.0) CardSpace bereits vorinstalliert zu finden, und kann nun einfach mit dem Internet Explorer eine Seite mit OpenID-Unterstützung besuchen und eine persönliche Karte erstellen. Für Firefox gibt es das IdentitySelector-Plugin, das ebenfalls auf die lokale CardSpace-Sammlung zurückgreift (natürlich gibt es auch vollständige Open-Source-Implementationen wie openinfocard oder DigitalMe).

Allerdings handelt es sich hier immernoch um virtuelle Karten, die auf dem PC des Nutzers hinterlegt sind. Ginge man nach der derzeitigen Situation der Berichterstattung in Massenmedien, dürfte dieser wohl schon längst nicht mehr als sicherer Raum einzustufen sein. Aber auch für CardSpace gibt es Möglichkeiten, die Karten des Benutzers mit einer ‘echten’ Karte zu schützen; hier wird sich wiederum noch herausstellen müssen, was für eine das sein wird.

Die von ComputerBild in großer Auflage verbreitete loginCard unterstützt jedenfalls keine asymmetrische Kryptografie, und auch der neue Personalausweis lässt sich ohne BSI-Zertifikat nicht zur Identifikation oder gar Hinterlegung eines Schlüsselpaars nutzen.
Natürlich könnte sich auch jeder selbst eine JCOP- oder andere RSA-Karte kaufen, aber die breite Masse der Internetnutzer erreichen am Ende doch immer proprietäre Komplettlösungen (v.a. wenn für den Nutzer selbst kostenlos).
Vielleicht wird OWOK weitere Verbreitung finden, wenn sich mehr Anbieter für die Ausgabe einer solchen (nicht ‘light’) Karte entscheiden, die sich dann neben der Login-Funktion auch für eigene Anwendungen nutzen lässt.

Nun aber noch kurz zu dem Standard, der am Ende nun auch erst diese ganze Aufmersamkeit in dem Bereich verursacht hat:

Das e-Card-API-Framework vom BSI, das unter anderem den neuen Personalausweis umfasst.
Die Browser-Integration wird in Teil 7 der TR-03112 (Kapitel 2.3.1, ab Seite 12) beschrieben – man ist also grundsätzlich nicht auf die Benutzung einer bestimmten Software angewiesen.
Somit ist also zu erwarten, dass bis zum Aufkommen einer nennenswerten Anzahl von Nutzungsmöglichkeiten der eID-Funktion (sowie der Verbreitung des neuen Ausweises in der Bevölkerung) längst eine Open-Source-Alternative zu dem 800.000 Euro teuren 68-MB-Datenhaufen namens “AusweisApp” zur Verfügung stehen wird.

Eine große Verbreitung ist in diesem Fall langfristig also zu erwarten, leider lässt sich der Ausweis wie bereits erwähnt aber nicht für lokale Anwendungen nutzen.
Und überhaupt ist im Moment noch offen, ob zukünftig wirklich jeder auch zur Investition in einen Standard- oder Komfortleser zur Online-Nutzung bereit wäre.
Vermutlich nicht, aber wahrscheinlich wird das auch gar nicht mehr nötig sein.

Wenn man so die aktuelle Entwicklung in der Mobilfunkbranche betrachtet, stehen wir gerade sehr kurz vor der (praktischen) Einführung von NFC, also im Grunde soetwas wie ein Kontaktloskarten-Lesegerät in jedem Handy – aber auch mit der Möglichkeit der direkten Kommunikation zwischen zwei Geräten.
Uneinigkeit herrschte hier in der Vergangenheit hauptsächlich über die Verwendung von Sicherheitsmodulen – nun scheint aber mit dem ‘Single Wire Protocol’ der Standard für die Integration sicherheitskritischer Anwendungen auf der SIM-Karte gefunden zu sein (die Mobilfunkbetreiber bekommen hier also wieder die Kontrolle darüber, was auf ihre Karten darf und was nicht…).

Bisher hat Nokia angekündigt, sämtliche Geräte der ‘Smartphone’-Kategorie ab 2011 mit NFC auszustatten (das C7 besitzt bereits die Hardware-Funktionalität dafür, welche im nächsten Jahr per Firmware-Update nutzbar werden soll), und auch die Gerüchte um das iPhone 5 mit NFC-Technik tendieren derzeit zum ersten Quartal 2011.

Auch wenn ich persönlich eine gewisse Abneigung gegenüber Apple habe, ist es doch bemerkenswert, welche Macht man inzwischen auf dem Markt hat; mit anderen Worten: Wenn Apple von den Betreibern verlangen würde, SIM-Karten mit Unterstützung für solche Zusatzapplikationen zu verwenden, bliebe diesen wohl kaum etwas anderes übrig, wenn sie das iPhone 5 anbieten wollen (ähnlich der Micro-SIM beim iPad). Wäre also eine Möglichkeit, wir werden sehen ob Apple sie auch nutzt.

Worauf ich aber eigentlich hinauswollte, war die Integration mit Web-Anwendungen. Bisher ist es auch beim Mobilfunk nur über die Installation von Software (Java-MIDlets) möglich, auf die NFC-Funktionen zugreifen zu können.
Es wird sich zeigen, ob sich daran noch etwas ändert, und diese schnelllebige Branche eventuell auch einen offenen Standard hervorbringt, der am Ende sogar in die Desktop-Welt Einzug halten könnte.

Unabhängig davon würde ich jedenfalls auch folgende Kombination für einigermaßen realistisch halten: ein per USB-Kabel am Rechner angeschlossenes Mobiltelefon, das – dank eigenem Display und Tastatur – als Klasse-2 oder -3-Leser zertifiziert sein könnte.
Zumindest erreicht man so sicher eine schnellere Marktdurchdringung als mit dedizierten Kartenterminals, die sonst keinen zusätzlichen Zweck erfüllen, der ihre Anschaffungskosten rechtfertigen würde.