Kernel-Log – Was 2.6.39 bringt (1): Netzwerk-Treiber und -Infrastruktur | heise online
heise PlusAbo
Anzeige

Kernel-Log – Was 2.6.39 bringt (1): Netzwerk-Treiber und -Infrastruktur

Die neue Ipset-Unterstützung vereinfacht den Betrieb einer Firewall, denn mit ihr muss man lediglich eine Tabelle anpassen, um etwa eine ganze Reihe von IP-Adresse zu blockieren. Die Treiber-Situation für WLAN-Chips verbessert sich weiter, da nun auch Ralink und Realtek sich aktiv an der Weiterentwicklung der Treiber im Linux-Kernel beteiligen.

vorlesen Druckansicht
Lesezeit: 21 Min.
c't Magazin
Von
  • Thorsten Leemhuis
Inhaltsverzeichnis

In den Freigabe-Mails zur zweiten und dritten Vorabversion des Linux-Kernels 2.6.39 merkte Torvalds jeweils an, es habe vergleichsweise wenig Änderungen gegeben. Beim RC2 zeigt er sich darüber sehr verwundert und fragte, ob die anderen Kernel-Hacker etwas im Schilde führen würden. Beim am Dienstag dieser Woche freigegebenen RC3 scherzte er abermals in diese Richtung; er lässt aber in beiden Mails auch durchblicken, dass er sich darüber freut und auf einen ruhigen Entwicklungszyklus hofft.

Wie üblich war das Gros der Änderungen für die nächste größere Kernel-Überarbeitung bereits im Merge Window in den Hauptentwicklungszweig eingezogen. Das Kernel-Log kann daher schon jetzt einen umfassenden Überblick über die wichtigsten Neuerungen des Mitte oder Ende Mai erwarteten Kernel 2.6.39 geben. Verschiedene Artikel werden sich dabei nach und nach den verschiedenen Funktionsbereichen des Kernels annehmen. Den Anfang der Mini-Serie "Was 2.6.39 bringt" macht die folgende Beschreibung der wichtigsten Änderungen am Netzwerk-Stack und den darauf aufsetzenden Treibern. In den kommenden Wochen folgen Artikel zur Grafik-Treibern, Storage-Unterstützung, Dateisystemen, Architektur-Code, Infrastruktur und Treibern für andere Hardware.

Nach langer Entwicklung unabhängig vom Kernel stieß nun die Unterstützung für die aktuelle Generation von Ipset zum Linux-Kernel (u.a. 1). Dieses Kommandozeilenprogramm erstellt im Speicher vorgehaltene Tabellen, die typischerweise IP-Adressen oder TCP/UDP-Ports enthalten – etwa eine Liste mit IP-Adressen, die geblockt werden sollen. Der Firewall-Code kann diese Tabellen bei der Paket-Prüfung konsultieren; dazu ist lediglich eine einzelne Iptables-Regel nötig, welche die zu verwendende Tabelle spezifiziert. Das kann das Aufsetzen einer Firewall vereinfachen.

Die Tabellen sind zudem deutlich einfacher und schneller aktualisierbar, als sich Iptables-Regeln einfügen oder entfernen lassen – das erleichtert das vorübergehende Aussperren eines Angreifers. Darüber hinaus soll der Kernel die Tabellen erheblich flotter verarbeiten als einen vergleichbaren Satz einzelner Iptables-Regeln.

Einige speziell auf den Firewall-Betrieb ausgelegte Linux-Distributionen haben daher schon lange Ipset-Unterstützung eingebaut. Die Ipset-Homepage listet die wichtigsten Funktionen des Programms und liefert Tipps und Beispiele; Hintergründe zum Einsatz liefern auch die dort abrufbaren Man-Pages zu Ipset und Iptables.

Die Kernel-Hacker haben im Code für das TCP-Protokoll die Standard-Einstellung für das Initial Congestion Window vergrößert, was die Latenzen bei der Netzwerkkommunikation um 10 Prozent reduzieren kann. Die Änderung geht auf Google-Entwickler zurück, die bei Forschungen mit verschiedenen Betriebssystemen festgestellt hatten, dass einige Standardvorgaben im TCP-Stack von Linux nicht ideal für moderne Internet-Kommunikation waren. Die Kernel-Hacker passten daraufhin bei 2.6.38 bereits das Initial Receive Window an; Hintergründe zu diesen beiden Änderungen liefert LWN.net im Artikel "Increasing the TCP initial congestion window".

WLAN-Treiber, Staccato

Aufgenommen haben die Kernel-Entwickler den WLAN-Treiber rtl8192cu für die Realtek-USB-WLAN-Bausteine RTL8192CU und RTL8188CU (u.a. 1, 2). Genau wie der bei 2.6.38 integrierte Realtek-WLAN-Treiber rtl8192ce setzt er auf den WLAN-Stack des Kernels auf und wurde maßgeblich von Realtek selbst entwickelt. Ältere unter der GPLv2 stehende WLAN-Treiber von Realtek brachten einen eigenen WLAN-Stack mit und schafften es daher zumeist nur in den Staging-Zweig. In der Praxis sind diese Treiber häufig hakelig, da manche Distributionen Staging-Treiber nicht mitliefern; zudem zeigen manche dieser Treiber Probleme beim Zusammenspiel mit Programmen wie dem NetworkManager.

Die Integration der beiden Treiber in den Kernel hat Realtek allerdings nicht selbst vorangetrieben; vielmehr ist sie maßgeblich dem Kernel-Hacker Larry Finger zu verdanken, der einige Aufräumarbeiten vornahm und zwischen Realtek und anderen WLAN-Treiber-Hackern vermittelt. Durch diese Bestrebungen scheint sich die Lage bei Treibern für Realtek-WLAN-Chips langsam zu bessern; ob es für die derzeit nur von Staging-Treibern untersüttzten Realtek-Chips auch noch bessere Treiber geben wird, steht aber noch in den Sternen.

Den Treiber rt2800pci haben die Entwickler um experimentelle Unterstützung für den Ralink-WLAN-Chip RT5390 erweitert; diese ist allerdings als noch nicht funktionstüchtig gekennzeichnet und richtet sich für erste nur an Tester und Entwickler. Genau wie bei den Realtek-Treibern dürfte sich auch die Lage bei WLAN-Treiber für Bausteine von Ralink in Zukunft verbessern, da das Unternehmen neuerdings an den im Rt2x00-Projekt entstandenen Treibern direkt mitarbeitet, die vor langer Zeit zum Kernel stießen. Das berichtete Greg Kroah-Hartman vor einigen Wochen in seinem Blog; ähnlich wie Realtek hatte auch Ralink lange eigene Treiber entwickelt, die es aufgrund von Qualitätsmängeln nur bis in den Staging-Zweig geschafft hatten.

Die Treiber vom Rt2x00-Projekts entstanden weitgehend unabhängig von jenen, die Ralink entwickelt hat; mittlerweile unterstützen Erstere viele Chips genauso gut oder besser. Die Staging-Treiber rt2860sta und rt2870sta für [Update, 20110414-1730]USB-[/Update] WLAN-Chips von Ralink dürften daher bei 2.6.40 vermutlich aus dem Kernel fliegen, denn sie sprechen WLAN-Bausteine an, die die Rt2x00-Treiber mittlerweile unterstützen (1, 2). Wer mit Letzterem noch Probleme hat und daher einen der beiden Staging-Treiber einsetzt, sollte das den Kernel-Hackern zügig melden, damit sie die Probleme beseitigen können oder den Rauswurf vertagen.

Wie schon bei 2.6.37 und 2.6.38 haben die Kernel-Hacker den Code für 802.11n-Chips von Broadcom im Treiber b43 weiter ausgebaut, wodurch dieser nun auch 802.11n-PHYs ab der dritten Generation anspricht (u. a. 1, 2) Einen guten Überblick, welche Broadcom-Chips der Treiber dadurch nun erstmals oder besser unterstützt, liefern die aktuelle Wiki-Seite zum Treiber sowie die Änderungen, die seit Mitte März an ihr vorgenommen wurden; die Bausteine BCM4321 und BCM4322 zählen nun etwa zu den teilweise unterstützten Chips. Die Bausteine BCM4313, BCM43224 und BCM43225 kann der Treiber aber weiterhin nicht ansprechen; die Wiki-Seite listet aber auch, welche dieser Chips der proprietäre Treiber wl oder die von Broadcom selbst vorangetrieben Staging-Treiber ansprechen.

Der Treiber iwlwifi spricht nun auch die WLAN-Chips aus Intels 2000er-Serie an (u. a. 1, 2). Um die Pflege dieses WLAN-Treiber für neuere WLAN-Bausteine von Intel zu erleichtern, haben die Entwickler die Unterstützung für die Baureihen IPW3945 (802.11g) und IPW4965 (802.11n) in den neu angelegten Treiber iwlegacy auslagert.

Der einige USB-Chips von Atheros ansprechende Treiber ar9170usb soll bei 2.6.40 aus dem Kernel fliegen, da der bei 2.6.37 integrierte Treiber carl9170 ihn ersetzt.

  • Nach der bei 2.6.37 integrierten Basis-Infrastruktur zum Betrieb als Xen-Host (Dom0) folgt mit Kernel 2.6.39 das Netzwerk-Backend, über das die Frontend-Treiber in Xen-Gästen (DomU) mit anderen Systemen kommunizieren. Das Storage-Backend fehlt allerdings weiterhin, daher wird kein sinnvoller Betrieb als Dom0 möglich sein, ohne weitere Patches einzubinden.
  • Zum Netzwerk-Stack stieß der Paket-Scheduler CHOKe ("CHOose and Kill" oder "CHOose and Keep"). Er basiert auf dem Algorithmus [Update, 20110414-1730] Random Early Drop (RED; im Commit-Kommentar und dadurch in einer früheren Version dieses Artikels fälschlicherweise als "Random Exponential Drop" bezeichnet) [/Update] und ist primär für Router und Bridges interessant, um Überlastungen beziehungsweise Staus zu vermeiden; Hintergründe dazu liefert LWN.net in "The CHOKe packet scheduler". Neu ist auch der Stochastic Fair Blue (SFC) scheduler, der Ideen der 1999 publizierten Forschungsarbeit "BLUE: A New Class of Active Queue Management Algorithms" aufgreift.
  • Der Bluetooth-Code beherrscht nun die in der Bluetooth-Spezifikation 4.0 definierten Low Energy (LE) Connections. Neu dabei ist auch der Bluetooth-Treiber btwilink für den WiLink7 von Texas Instruments. Zudem gab es eine ganze Reihe von Nokia-Entwicklern eingebrachte Detailverbesserungen im Bluetooth-Code, zu denen die Links im Artikelabschnitt "Die kleinen Perlen" führen.
  • Der Netzwerk-Stack bietet ab 2.6.39 Mechanismen, um einige Aufgaben für QoS (Quality of service) an Hardware auszulagern.
  • USB-Netzwerk-Chips mit einer global eindeutigen MAC-Adresse weist der Kernel fortan mit "eth" beginnende Namen zu; für andere, typischerweise zur Point-To-Point-Kommunikation eingesetzte Chips bleibt es beim Präfix "usb".
  • Der USB-NIC-Treiber smsc95xx unterstützt jetzt auch die SMSC-Chips LAN9530, LAN9730 und LAN89530.
  • Der Treiber wl12xx für die WLAN-Bausteine wl1271 and wl1273 von Texas Instruments beherrscht nun auch den Betrieb als Acess Point (AP) (u. a. 1, 2, 3, 4, 5).
  • Zum Kernel stieß auch der Treiber c_can für den C_CAN Controller von Bosch, dessen Logik in einigen Produkten von ST Microelectronics steckt.
  • Der für Encapsulating Security Payload (ESP) zuständige Funktionen erweiterten die Kernel-Hacker um Unterstützung für die in RFC 4303 spezifizierten IPsec Extended Sequence Numbers (ESN) (1, 2).
Git-Pull-Requests 1 2 3 einige Änderungen 2.6.37 2.6.38

Die kleinen Perlen

Viele kleinere, aber keineswegs unbedeutende Neuerungen finden sich in der folgenden Liste mit den englischen Commit-Überschriften der jeweiligen Änderung. Die Einträge verlinken genau wie viele der Verweise im vorangegangenen Text auf das Webfrontend des von Linus Torvalds gepflegten Git-Zweigs mit den "offiziellen" Kernel-Quellen auf Kernel.org. Der über diese Links angezeigten Commit-Kommentar und der darunter ausgegebene Patch liefern zahlreiche weitere Informationen zur jeweiligen Änderungen.

Vor jedem Link finden sich in eckigen Klammern einige Buchstaben und Zahlen. Ein "C" kennzeichnet Patches mit Änderungen an Kconfig-Dateien, welche die Konfigurationsoptionen samt der zugehörigen Hilfetexte enthalten, die bei der Kernel-Konfiguration über "make menuconfig" oder "make xconfig" angezeigt werden. Ein "D" steht bei Patches, die die Dokumentation verändern, die im Kernel-Zweig unterhalb von Documentation/ liegt. Ein "N" weist Änderungen aus, die eine neue Datei anlegen. Die Zahl vermittelt einen groben Eindruck zur Größe des Patches: eine "1" kennzeichnet Änderungen, die inklusive Kommentar zwischen 10 und 20 KByte groß sind, eine "2" für solche, die zwischen 20 und 30 KByte Umfang haben; Änderungen ohne Zahl sind kleiner als 10 KByte, Patches mit einer "9" hingegen 90 KByte oder größer.

LAN

WLAN

Various

Weitere Hintergründe und Informationen rund um Entwicklungen im Linux-Kernel und dessen Umfeld finden sich in den vorangegangenen Kernel-Logs auf heise open. Neue Ausgaben des Kernel-Logs werden auf den Identi.ca- und Twitter-Konten "@kernellog" erwähnt; die englischen, bei den Kollegen von "The H" erscheinenden Übersetzungen auf den Identi.ca- und Twitter-Konten "@kernellog2". Gelegentlich zwitschert der Autor des Kernel-Logs unabhängig davon über einige Kernel-Log-Themen bei Identi.ca und Twitter als "@kernellogauthor". (thl) (thl)

Beliebte Bestenlisten

Alle Angebote
Newsletter heise-Bot heise-Bot Push Nachrichten Push Push-Nachrichten