Die Leuchtfeuer Gondors - in Leipzig. (ehemaliger Güterbahnhof Stötteritz - es sind in der Tat Lampen ganz oben an den Masten, und die brennen die ganze Nacht durch.)
Mein blog ist übrigens nicht tot, ich frickel' grad ein neues Design und hoffe dann bald mal wieder interessante Sachen hier zu posten.
(Handyfoto übrigens - ein Wunder dass das überhaupt aussieht...)
Ohne Worte:
Subject: Congratulations! To: equinox at diac24 net From: gsoc at google com Date: Thu, 12 Apr 2007 00:18:11 -0700 Dear Applicant, Congratulations! This email is being sent to inform you that your application was accepted to take part in the Summer of Code. Please check your student home page in the SoC web application at http://code.google.com/soc/student_home.html to determine which of your applications was accepted.
Beim Aufbau des diac24.net-VPNs gab es hin- und wieder Punkte, an denen wir uns entscheiden mussten. Zum Beispiel mussten wir uns entscheiden, ob wir „numerierte” oder „unnumerierte” Tunnel verwenden. Numeriert bedeutet, dass jeder Tunnel sein eigenes /30er IP-Subnetz hat; unnumeriert bedeutet dass die Tunnel keine eigenen IPs haben sondern jeweils die „Haupt”-Adresse des Routers verwenden.
Die Entscheidung in dieser Angelegenheit wurde so ca. 2002 getroffen, als das VPN noch aus TroJan und mir bestand, und noch über OSPF statt BGP lief. Wir wollten nicht so viel Müll in unseren Routingtabellen und haben uns für unnumerierte Tunnel entschieden. Mittlerweile zweifle ich jedoch an dieser Entscheidung, und zwar aus diesen Gründen:
Jedenfalls habe ich mich entschlossen, zwischen charon und dem SpaceBoyZ numerierte Tunnel auszuprobieren. Aber sehen wir uns erst mal an, wie das IPv4-Routing bisher funktioniert:
Auf den ersten Blick nichts besonderes. Was man im Bild allerdings nicht sieht, ist, dass das BGP-Peering über IPv6-Linklocals läuft. Also... woher nimmt der bgpd den Nexthop für IPv4? - Diese Frage hatte ich mir leider bisher noch nie gestellt. 15 Minuten und einige Verwunderung später kannte ich die Antwort:
Nachdem ich nämlich dem Tunnel ein eigenes Subnet verpasst hatte, bekam ich plötzlich keine IPv4-Routen mehr. Das Peering selbst war in Ordnung, an den IPv6-Linklocals hatte sich ja nichts geändert und ich bekam korrekt meine IPv6-Routen. Die Fehlersuche ergab, dass die Routen in sh ip bg ne SBZ received-routes ordnungsgemäss erschienen, es aber nicht nach sh ip bg ne SBZ routes schafften. Die Neighbor-Übersicht zeigte 0 accepted prefixes. Ein genauerer Blick in received-routes enttarnte das Übel:
Network Next Hop Metric LocPrf Weight Path 172.22.24.0/28 172.22.24.1 1 0 64624 i
Einige Sucherei und Fragerei in #quagga» später hatte ich dann als Antwort dass ich IPv4 und IPv6 über getrennte Peerings laufen lassen soll. Der damit verbundene erhöhte Konfigurationsaufwand passte mir allerdings nicht wirklich in den Kram. Ausserdem war das schöne an den IPv6-Peerings dass man die unangetastet lassen konnte, auch wenn sich am Tunnel etwas ändert.
Ungefähr eine halbe Stunde später war das Ergebnis dann dieser Patch». Die Änderung ist ziemlich minimal, anstatt einfach die Router-ID zu verwenden sucht der bgpd jetzt das Interface, über das das Peering geht, nach einer IP ab. Dadurch findet er die korrekte IP:
Zufrieden betrachtete ich meine nun wieder gefüllte IPv4-Routingtabelle:
Network Next Hop Metric LocPrf Weight Path 172.22.24.0/28 172.22.255.253 1 0 64624 i
Der Erfassungsbereich des Patches schliesst nicht nur numerierte Tunnel ein; prinzipiell sind alle Fälle betroffen, wo über IPv6 gepeert wird und bei denen die BGP Router-ID nicht dem Nexthop entspricht. (Wenn ich das korrekt verstanden habe gab es da beim c3d2 wohl auch mal Probleme auf cthulhu)
Der Patch ist an die quagga-Mailingliste submitted, aber Antwort habe ich noch keine bekommen. Mittlerweile existieren im diac24.net 2 numerierte Links: René <--> equinox <--> SpaceBoyZ. Das Ganze scheint stabil zu funktionieren.
René war nett und hat ein OpenWrt-Package für Quagga 0.99.6 gebastelt. Ich war fauler und hab nur eins für 0.98.6 gebaut. Downloadlinks:
Happy Patching!
Jaaaa, der 23C3 hier in Berlin eröffnet gerade mal eine sehr interessante Möglichkeit: Segor» ist nur einen Katzensprung entfernt. (Okay, der Katzensprung hat fast 2 Stunden verschlungen, aber naja.) Jedenfalls bekommt man bei Segor einiges an I²C-Devices.
Eines dieser I²C-Devices ist der LM75 (National)», der uns mit zugegeben eher schlechter Genauigkeit Temperaturen zwischen -55°C und +125°C über den I²C-Bus messen lässt. (Es gibt auch bessere I²C-Temperatorsensoren, den LM75 zu nehmen war pure Faulheit meinerseits.)
Wie ihr nun schon dem Titel entnehmen könnt, war meine Idee, den LM75 an den DDC-I²C anzuschliessen. Auf dem Fussboden von Saal 1 auf dem 23C3 zusammengelötet sieht das dann so aus:
Praktischerweise hat sich die Anmerkung "selten +5V" auf der Wikipedia-Seite zum VGA-Anschluss» als unwahr erwiesen. Den Pufferkondensator hab' ich mir hackisherweise auch gespart, so dass einfach nur 4 Leitungen an 7 Pins zu verdrahten waren. (Die +5V-Leitung habe ich gleich noch auf die danebenliegenden Adresspins gelötet, sicherheitshalber.)
Um das ganze dann unter Linux anzusprechen benötigt man einen kleinen Kernel-Hack:
--- old/drivers/hwmon/lm75.c 2006-12-11 20:32:53.000000000 +0100
+++ new/drivers/hwmon/lm75.c 2006-12-30 14:32:23.227463353 +0100
@@ -107,8 +107,6 @@
static int lm75_attach_adapter(struct i2c_adapter *adapter)
{
- if (!(adapter->class & I2C_CLASS_HWMON))
- return 0;
return i2c_probe(adapter, &addr_data, lm75_detect);
}
Das ist deshalb nötig, weil der DDC-I²C als Device-Klasse logischerweise nicht I2C_CLASS_HWMON gesetzt hat. Nach anwenden dieses Mikro-Kernel-Patches lädt man das lm75-Modul mit Angabe der I²C-Adresse:
insmod lm75.ko force_lm75=2,0x4f
Die Angabe 2,0x4f ist zu Verstehen als "Bus 2, Adresse 0x4f". Die Adresse entsteht dadurch, dass ich die Adresspins auf +5V gezogen habe (seht euch das Datenblatt an). Die Busnummer muss man ggf. herausfinden.
/sys/class/i2c-adapter/i2c-2/device/name sagt bei mir vga. Nachdem man nun das ganze am Laufen hat, kann man den Temperaturwert auslesen:
$ cat /sys/class/hwmon/hwmon0/device/temp1_input 19500
Wie bei allen Hardware-Monitoring-Treibern muss man den Wert noch durch 1000 teilen.
Upcoming: Ich hab' den natürlich die Temperatur hier auf dem 23C3 in ein RRD loggen lassen. Das bekommt ihr auch noch zu sehen, sobald's etwas aufbereitet ist.
photostream
