Mai 02

Für mich selbst als Merker, damit ich das nächste mal nicht wieder in Panik ausbreche.

Besonderheiten beim „Internet“ via Telekom Hotspot:

  • Öffentliche IP’s gibt es per se nicht – man bekommt irgendwas privates aus dem 10er-Space zugewiesen.
  • V4 only
  • Jede Ziel-IP (egal ob Online oder Offline) ist aus dem Hotspot-Netz ein DNS-Server. Führt zu leichten Panikattacken, wenn man meint seine eigenen Kisten von aussen damit auditieren zu wollen. Vermutung: Alles was auf Port 53 rausgeht, wird von der T abgefangen und dann unter falscher Flagge beantwortet, als wäre es ein openrelay.

Besonderheiten beim „Internet“ via Telekom LTE:

  • Öffentliche IP’s gibts mit LTE nicht mehr (LTE akzeptiert ausschliesslich „internet.telekom“ oder „internet.t-mobile“ als APN – und da gibts halt nur „Private-Address-Space“)
  • v4 Only
  • Port 80 und Port 8080 unterliegen irgendeiner Art Deep-Packet-Inspection (kann nur raten, ob das was mit diesem Zwangsproxy zu tun hat, der jpgs/gifs noch mal nachkomprimiert hat). Fakt ist: Egal ob die Ziel-Adresse offline ist, oder gar keinen Dienst auf den beiden Ports anbietet – es gibt IMMER einen sauberen 3-Wege Handshake. Interessant in dem Zusammenhang: Irgendein Netzelement leitet die Anfragen (so denn die „Echte Ziel-IP“ online ist, und auch n Listener hat) mit leichtem Delay an die Richtige IP weiter. Wenn Ziel-IP offline / kein Dienst, gibts ein „FIN“ per TCP – aber erst nach erfolgtem SYN/SYNACK/ACK.
Tagged with:
Jun 17

So, es ist vollbracht. Die ganzen Consumer-Provider in good ‚ol Germany wollen ja irgendwie nicht so richtig mit ipv6 an den Start kommen. Also habe ich mal selbst Hand angelegt. Einen Provider hat man schnell gefunden. Ich habe mich für sixxs.net entschieden.

Bei sixxs.net bekommt man zunächst einen /64er Block für lau zugewiesen, den man hinterher auf /48 upgraden kann (Vorraussetzung: der 64er Tunnel läuft eine Woche durch / Downtimes, bspw. zum basteln, sind nicht tragisch). Einfach anmelden, „aiccu“ herunterladen, konfigurieren, starten und glücklich sein. Achtung: Aiccu / sixxs.net prüft die Systemzeit – Ein NTP-Client auf dem lokalen Endpunkt hilft da ungemein !

Das 48er-Subnet benötigt man aber nicht wirklich für den Heimgebrauch. Mit dem 64er kann man die restlichen 2^64 Adressen munter im Netz verteilen. Genau da war Anfangs auch mein Denkfehler. Mir war nicht aufgefallen, dass sixxs.net ein Transfernetz zur Vefügung stellt, durch das dass /64er gerouted werden kann. Konkret sieht das ganze nach dem ersten Start wie folgt aus:

  • PtP-Adresse (Da gehts also zu sixxs): 2001:6f8:100:fea::1/128 (Die beiden :: sind die Platzhalter für gaaanz viele Nullen – ausgeschrieben sähe das ganze so aus: 2001:6f8:100:fea:0000:0000:0000:1/128)
  • Lokale Adresse des ersten „ipv6“-Interfaces: 2001:6f8:100:fea::2/64
  • Und jetzt wird’s spannend. Im Webinterface bei sixxs.net kann man sehen, dass das zur Verfügung stehende Netz 2001:6f8:100:dfea::/64 lautet (Man beachte das „d“ bei Octet 7)

Mit dem dfea-Netz (die Adressen sind für den Blogeintrag gefaked) können wir nun intern loslurchen und die Rechner ausstatten. Im simpelsten Falle installiert man sich den radvd (Router Advertising Daemon) und konfiguriert sowie startet ihn. Der verteilt die Dinger dann im LAN. Achtung: Dem LAN-Interface muss man selbst eine (v6-)IP aus dem dfea-Netz verpassen (/etc/network/interfaces) – das macht der radvd nicht. Jetzt noch das ipv6-Fowarding enablen (echo 1 >/proc/sys/net/ipv6/conf/all/forwarding) und schon können alle anderen Rechner per ipv6 mit der Welt in Verbindung treten (oder auch angesprochen werden !!)

Was uns zu einem kleinen Schönheitsfehler bringt. Ich will ipv6, weil ich das genNATte und diese ewige dynamische IP-Vergabe leid bin. Dummerweise vergibt der radvd die IP’s aber höchstdynamisch. Statisch verfügbar wäre in diesem Szenario also allenfalls der Router. Schuld (- Die Diskussion will ich hier nicht führen -) sind die sog. „privacy extensions“ die irgendwelche paranoiden Mitmenschen entworfen haben. Ich war schon bei v4 kein Freund von „Würfel“-DHCP. Ganz abgesehen davon möchte ICH, und nicht irgendein Billo-Router regeln, wer wann wie worüber ins Netz geht. Bei IP’s die man nicht kennt, ist das ein grausames Unterfangen.

Jetzt gibt es zwei Möglichkeiten aus dem Dilemma herauszukommen.

  1. DHCP-V6 aufsetzen (hab ich noch nicht ausprobiert) und die IP’s statisch den Mac-Adressen im LAN zuordnen.
  2. Den Servern händisch statische IP’s verpassen.
  3. Mischbetrieb aus 2 und radvd

Habe mich erstmal für Variante 3 entschieden. Also jeden Server abgrasen und eine IP aus dem dfea-Netz eintragen, Default(-v6-)Route setzen und testen. Die Arbeitsplatzrechner bekommen die IP’s per radvd, die Server sind statisch verdrahtet. Fein, funktioniert.

Jetzt kommt der fieseste Teil, an dem ich zwei Stunden versenkt habe:

Das ganze ist bei Debian nämlich leider nicht Bootfest, da Linux ganz jeck auf Route-Advertisments ist, und sich dort auch eine IP „ziehen“, wenn sie schon statisch eine abbekommen haben. Hier helft eine Kernel-Einstellung in /etc/sysctl.conf:

net.ipv6.conf.default.accept_ra = 0
net.ipv6.conf.default.autoconf=0

Die alleine macht aber auch noch nicht glücklich, da die sysctls beim booten eingelesen werden sollen. Zu diesem Zwecke linkt man sich die /etc/init.d/procps in die runtimelevel-Dirs (/etc/rcX.d/). Hilft auch noch nicht, weil: Die Einstellungen greifen nur, wenn auch das ipv6-Kernel Modul schon geladen ist – sonst laufen die ins leere 🙁 Hierzu ipv6 in die /etc/modules eintragen. Anschliessend booten – et voila: Es läuft !

Jetzt fehlt eigentlich nur noch eins: Eine ordentliche Firewall mit Connection-Tracking. Gibts wohl demnächst mal einen Blogeintrag drüber. Soviel sei gesagt: Connectiontracking geht erst ab Kernel 2.6.26, redirect (bspw. für transparente Proxies) erst ab 2.6.36…

Somit wäre dieses Blog nun auch via ipv6 erreichbar !

Tagged with:
Dez 10


Seit geraumer Zeit sind Rauchmelder in Neubauten ja Pflicht. Macht ja auch durchaus Sinn. Gerade wenn man an solche USV-Aktionen denkt 🙂 Also muss ein Rauchmelder her. Der Otto-Normal-Nerd möchte aber mindestens irgendwas haben, was sich auch in die Standardhaustechnik integrieren lässt – am besten noch ein Set von mehreren Rauchmeldern. Da gibts es zig Varianten:

  1. Die Billigrauchmelder (um die 5-10 Euro)
  2. Die Billgrauchmelder die per 433MhZ miteinander sprechen (ab 60 Euro im Set mit 4 Stück)
  3. Die teueren Systemrauchmelder die nichts anderes als (2) machen, nur das G*ra oder sonstwas draufsteht.
  4. Die sündhaft teueren Rauchmelder mit eingebauten GSM-Modul (ab ca. 150 Euro aufwärts…)

Gelinde gesagt: Alles doof – da es entweder meinen Ansprüchen nicht genügt, oder massivst zu teuer ist.

Nun denn erstmal Dinge sichten – also ab zum Baumarkt und mal einen Rauchmelder der Kategorie „1“ gekauft. Schimpft sich RM120 und hat schlappe 8,- gekostet. Laut ist das Ding ja, wenn man Zigarettenrauch reinbläst, oder mal den Testknopf drückt – bringt nur nix, wenn niemand zu hause ist 🙁 Nach dem öffnen des Geräts, schaut einen ein wenig SMD-Technik (Oha) an, darunter ein IC mit der Aufschrift „CS2105go„. Wie sollte es anders sein, dazu gibts leider kein Datenblatt. Aber Moment, vielleicht ist der CS2105GO-M12 ja Pinkompatibel mit dem MC145010 – Bingo, ist er ! Der MC145010 (manchmal auch MC145012) wird in fast allen Rauchmeldern der Kategorie 1 und 2 (teilweise auch 3) verkauft.

Der aufmerksame Leser merkt was: Bei 2 ist doch eine Vernetzung möglich ! Korrekt, so ist es. Mit anderen Worten: In den Rauchmeldern der Kat.1 ist derselbe IC verbaut, wie in 2, nur das in 1 halt das 433MhZ Modul fehlt. Brauch ich (zumindest jetzt zum Testen) eh erstmal nicht –  doch dazu später. Der MC145010 verfügt über einen sog. I/O Pin, der bei 2er Rauchmeldern dann das 433MhZ-Modul per TTL-High triggert, sobald es qualmt. Beim 1er liegt PIN7 (I/O) tot herum. Perfekt. Also fix den Ground (-) und PIN7 per Kabel rausgeführt und an den Arduino geklemmt:

 

Links (Schwarz) die Masse – Also GND direkt mit dem GND des Arduino’s verbinden,

Recht (Rot), etwas fuckeliger, den PIN7 (I/O) des CS2105GO-M12 auf einen Analogen Input-PIN des Mikrocontrollers legen.

Auf dem Arduino selbst habe ich derzeit die gute Wohnzimmerinfo-Anzeige am laufen, da ist also schon ein „Ethernet-Shield“ drauf. Da dort noch diverse Analoge Ports frei sind, und der Rauchmelder auch direkt deben dem Display wohnen soll, also optimal. Vom Code her gestaltet sich das ganze relativ simpel (siehe unten). Das allerfeinste ist jedoch, dass man nichtmal gegen irgendwelche Vorschriften verstösst, wenn man sich anstelle von Variante 1 für einen Rauchmelder der Variante „2“ entscheidet. Denn alle Rauchmelder bleiben so wie sie sind (sprich: Die piepen trotzdem). Nur einen, in dem 433MhZ-„Netz“, muss man dann an den Arduino anklemmen. Der verbaute Standalone-RM120 piept übrigens auch noch – denn genau dafür ist PIN7 gedacht: I/O !


#include
#include

#define SmokePIN 0

int Smoke=0;
boolean mailsent=false;
byte mac[] = { 0xDE, 0xAD, 0xBE, 0xEF, 0xFE, 0xED };
byte ip[] = { 192,168,0, 100 };

void setup () {
Ethernet.begin(mac,ip);
}

void loop() {
// Read Smokedetector
Smoke=analogRead(SmokePIN);

// GGf. RESET der Variable mailsent

if (Smoke > 900) {
if (mailsent==false) {
firemail();
mailsent=true;
}
}
}

void firemail() {
// IP des Mailservers
byte mserver[] = {192,168,0,101};
Client Mail(mserver,25);
if (Mail.connect()) {
Mail.println(„HELO arduino.domain.tld“); /* say hello (statement after helo is needed but irrelevant)*/
Mail.println(„MAIL From: et_brennt@domain.tld“); /* identify sender, this should be the same as the smtp server you are using */
Mail.println(„RCPT To: et_brennt@domain.tld“); /* identify recipient */
Mail.println(„DATA“);
Mail.println(„To: et_brennt@domain.tld“); /* identify recipient */
Mail.println(„Subject: Burning down the House“); /* insert subject */
Mail.println(„WARNING – Smoke detected !“); /* insert body */
Mail.println(„.“); /* end email */
Mail.println(„QUIT“); /* terminate connection */
Mail.println();
Mail.stop();
}
}

Tagged with:
preload preload preload