equinox' blog

rtnetlink, Linux, Windows und BSD

2005年06月29日 (水曜日) 01時46分
  • Hecking (⇽ BGP: Nexthops ⇿ Courier sux ⇾)
  • related links:
  • OpenVPN Management Interface
  • man 7 netlink
  • man 7 rtnetlink
  • IP Helper API
  • NotifyRoute...

So. Eigentlich standen hier paar Parolen á la "BSDler wollen doch nur anders sein". Irgendwie passten die dann aber nicht mehr zum restlichen Post, also gab's ein kurzes und schmerzloses dd. Verteidigen muss ich mein geliebtes Linux aber trotzdem mal.

Und wie liesse sich das besser realisieren als einfach mal ein Linux-Feature vorzustellen das ich unter BSD nicht kenne? Aufgefallen ist mir das ganze beim Lesen von Technical Itch: OpenVPN Management Interface» [2]» [3]».

Unter Linux gibts nämlich netlink-Sockets». Die sind allgemein dazu gut, einen Kommunikationskanal zwischen Kernel und Userspace für allen möglichen Netzwerkkram aufzubauen. Als Manifestation davon gibt's rtnetlink» (in Varianten für IPv4 und IPv6). Und das eigentlich fetzige: Man kann nicht nur Einstellungen lesen und schreiben, sondern man wird auch benachrichtigt wenn sich was ändert.

Angewendet sieht das dann so aus:

iproute2-session:
» ip monitor &
(-- Ankunft eines ICMPv6 prefix advertisements)
« 1: eth0    inet6 2001:8d8:81:5c2:203:dff:fe21:3b5/64 \
                  scope global dynamic
«        valid_lft forever preferred_lft 108000sec
» ip a a 127.1.2.3/8 dev lo
« 2: lo    inet 127.1.2.3/8 scope host secondary lo
« local 127.1.2.3 dev lo  table local  proto kernel \
                  scope host  src 127.0.0.1
» ip r a 127.2.3.4 via 127.1.2.3
« 127.2.3.4 via 127.1.2.3 dev lo

IMHO echt genial. Das meines Wissens nach einzige wovon man keine Benachrichtigung bekommt ist wenn sich die äussere IP eines Tunnels ändert. (Für einen diactc Rewrite-"Versuch" mal ausprobiert)

Um wieder auf BSD/Linux zurückzukommen, interessant wird das Ganze wenn man mal vergleicht. Netlink ist eine Linux-Erfindung und existiert meines Wissens nach unter BSD nicht. Soweit ich weiss kommt man unter *BSD für so was nicht am Pollen vorbei.
Bedenkt man jetzt, dass so ziemlich jedes OS die BSD-Socket-API abgekupfert hat, ist das doch schon eine ganz schöne Leistung... zumal BSD und Linux in anderen Bereichen eineiige Zwillinge sind - z.B. bei der Multicast-Routing-API. Die ist grösstenteils identisch - über Multicast blogge ich auch noch mal...

An dieser Stelle der Aufruf an die netten BSDler: Wie macht euer OS so was? Gibt's eine bessere Möglichkeit als Pollen? - Wer was findet schreibe einen Kommentar :)

P.S.: Ach ja, Windows kam ja im Titel noch vor... Das hat dafür eine Funktion» in der IP Helper API».

Trackback:

Linux kqueues?

2005年06月29日 (水曜日) 15時06分 auf: Julians Lisp und Uni-Blog
Es ist nicht einfach Linux-Features in einen BSD-Kernel zu integrieren, ohne den Kernel mit der GPL zu infizieren. Deswegen findet Austausch von Linux nach *BSD auf Kernelseite nur sehr spärlich statt. Andersherum sollte es aber kein Problem sein. Immerhin kann BSDL-Code problemlos in den Linux-Kernel integriert werden. ein guter Kandidat dafür ist IMHO das "kernel queue"-Interface von FreeBSD, das a) schöner zu programmieren als diverse select(2)-Alternativen und auch noch b) meistens genauso effizient oder effizienter ist. Das ganze gibt es laut der Manpage schon seit FreeBSD 4.1. Wo ist nun die Linux-Implementation? Warum gibt es keine funktionierende, sondern nur uralte Patches, die von den Linux-Kernel-Developern ignoriert wurden?
Trackback folgen »
Kommentareintrag:

S O R R Y

2005年06月29日 (水曜日) 22時58分
  • von: equinox

    Sorry! Ich hab vergessen dem apache Schreibrechte auf die backing storage (XML) des blogs zu geben, daher konnte man weder Trackbacks noch Kommentare posten. Tut mir leid!

    (Trackback für Julians Lisp und Uni-Blog per Hand ergänzt. Sorry!)

⇽ MaWi-KulturflatCourier sux ⇾⇿
⇽ BGP: NexthopsCourier sux ⇾Hecking
Copyright © 2005, 2006, 2007 by David L. (equinox)
This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 2.0 Germany License
Creative Commons License

Impressum

      mode   entry
      uri    rtnetlink
      offset 0