Gönnen wir dem CMI sein eigenes Netz!

oder:

Wie Irgendwessen Problem gelöst wurde, weil das elkement gerne schnüffelt, was die ‚Dinge‘ so machen im Internet of Things.

Irgendwer stand vor einer besonderen Herausforderung: Der Chefingenieur und Regler-Freak hatte das ideale Plätzchen gefunden: Genügend Platz und Ruhe, um UVR16x2, CMI & Co für seine Projekte aufbauen, verkabeln und testen zu können. Fast ideal, wenn man es genau nahm. Denn die Siedler hatten diesem Plätzchen kein LAN gegönnt. Das CMI  – das Control and Monitoring Interface, also das ‚Ethernet-Gateway‘ des Reglers – konnte nicht angeschlossen werden. Damit wäre Irgendwer zurück in die Steinzeit des SD-Karten-Hin-und-Hertragens geworfen worden.

Aber ‚glücklicherweise‘ legten gerade einige ganz besonders fiese Kameras und Videorekorder das halbe Internet lahm – und das elkement erinnerte sich dadurch an eine bereits einmal hier publizierte Anleitung zum Thema: Wie kann man als normaler Windows-Benutzer ohne Hackererfahrung herausfinden, welche Botschaften diese (bösen?) Dinge in die Welt senden und empfangen?

Hier wurde ein von Profis oft belächeltes Feature von Windows genutzt – die so genannte Internetverbindungsfreigabe: Ein normaler Windows-PC kann damit in einen Router verwandelt werden: Der PC verbindet sich wie immer per WLAN ins lokale Siedlernetzwerk – und damit ins Internet. Das ‚Ding‘ wird mit den LAN-Anschluss des PC verbunden und kann die ‚freigebene‘ Internetverbindung nutzen. Nachdem der PC jetzt höchspersönlich alle Netzwerkpakete des Dinges weiterreicht, kann der investigative Benutzer diese auch mit Sniffer-Software auf diesem PC untersuchen.

Aber eigentlich kann man diese Funktion ja einfach so verwenden, wie sie vielleicht gedacht war: Einem WLAN-unfähigen Ding wird eine Brücke ins Internet gebaut.

Aus Klimaschutzgründen wurde natürlich ein ausrangiertes Testnotebook verwendet, dem so ein zweites Leben als wichtiger Router ermöglicht wurde.

Die folgende Grafik zeigt die ‚Netzwerkarchitektur‘:

Netzwerk zum Testen eines CMI mit Regler UVR16x2 in seinem eigenen Subnetz

Der Ethernetanschluss des Laptop-Routers wird von Windows mit der IP-Adresse 192.168.137.1 konfiguriert, sobald die Internetfreigabe aktiviert wurde. Dieser Computer wird zum DHCP-Server und weist dem dem ‚Ding‘ eine dynamische IP-Adresse aus demselben Netzwerk zu, z.B. 192.168.137.2. Der WLAN-Adapter erhält eine Adresse aus dem sonst verwendeten ‚Office‘-Netzwerk (oft: 192.168.0.x)

Für Details zu den Einstellungen am PC siehe den früheren Artikel über das Internet der Dinge. Unter Windows 10 muss/kann jetzt auch die Netzwerkverbindung nicht mehr ausgewählt werden, auf der das Ding sitzt. Kleiner Tipp, bestätigt durch die bewährte Methode ‚Googlen in Foren‘: Wenn unter Windows 10 die Internetverbindungsfreigabe nach einem Neustart nicht mehr funktioniert, muss sie nochmals in den Eigenschaften des WLAN-Adapters deaktiviert und wieder aktiviert werden.

Wie früher schon berichtet wurde, kann so eine Kaskade von Netzwerken auch sinnvoll sein, um ein sensibles Ding (wie den Logger BL-NET) vor einem besonders gesprächigen Ding (IP-TV) zu schützen.

Irgendwer konnte somit wahlweise über das Router-Notebook lokal auf das CMI zugreifen oder über das Internet, also sozusagen bei der Türe raus und beim Fenster wieder rein. Da man vom lokalen ‚Office‘-Netzwerk gar nicht direkt lokal auf das CMI kommt (sondern nur über die ‚Cloud‘), ist das auch halbwegs realistischer Test der späteren Fernwartung über das Internet.

Die Reglerprogrammierung ging damit eigentlich fast schneller als das Aufräumen des Spielplatzes Arbeitsplatzes danach:

irgendein-stilles-plaetzchen-unaufgeraeumt

Wärmepumpen-Forensik – Teil 2: Mitloggen der Heizenergiewerte

Nachdem sich der neue CAN-Bus-Sniffer warmgeschnüffelt hatte mit nicht sehr spannenden Testwerten, wurde es Zeit für den Einsatz im Feld.

Der Raspberry Pi erhielt zunächst einmal einen würdigen Platz, um sich Überblick über den Heizraum zu verschaffen …

Raspberry Pi hat Alles im Blick

Eine typische provisorische Teststellung. Die einzige Stelle, an der am Beginn der Tests das WLAN-Signal halbwegs OK war. Ein ausgekreuztes Ethernet-Kabel gibt’s außerdem auch noch!

Das CAN-Bus-Kabel wurde entsprechend der Bedienungsanleitung an die Wärmepumpe angeklemmt:

Bedienungsanleitung Stiebel-Eltron WPF 7 basic, Abschnitt Kleinspannung

Abschnitt 12.2.3 – Kleinspannung, Bus-Leitung. Die optionale zusätzliche Stromversorgung („+“) wurde nicht verwendet.

Wie beim Testen mit UVR1611 wurde der ebenfalls kurze CAN-Bus nicht speziell terminiert:

Bedienungsanleitung Stiebel-Eltron WPF 7 basic, CAN-Bus angeschlossen

Stiebel-Eltron WPF 7 basic mit offenem Gehäuse – High (rot), Low (blau) und Ground (gelb) sind angeschlossen.

Damit konnten die elkementaren Tests beginnen …

Der beste Arbeitsplatz

(Für eine mögliche Einreichung bei Wettbewerben wie ‚Great place to work…‘)

… und die CAN-Schnittstelle wurde aktiviert, entsprechend der Anleitung von messpunkt.org mit einer Bitrate von 20kbit/s:

sudo ip link set can0 type can bitrate 20000
sudo ifconfig can0 up

Ohne aktive Kommunikation sind auf dem Bus mit Wireshark dann nur alle paar Minuten zwei Pakete zu sehen – die Wärmepumpe will also gefragt werden.

Besten Dank wieder an juerg5524.ch für die Bereitstellung von CAN-Tools und der Elster-Tabellen, die die diversen interessanten Parameter / ‚Indizes‘ enthalten!

Wir verschaffen uns zuerst einen Überblick darüber, welche CAN-IDs die Wärmepumpe überhaupt verwendet. Eine CAN-ID repräsentiert ein Set von Eigenschaften wie z.B. Ausgänge und kann auch Informationen über die Knoten-ID am CAN-Bus enthalten (Zu CAN-Grundlagen siehe z.B. dieses Dokument.)

Wird der CAN-Bus angefragt mit einer Sender-ID von 680 (siehe ) …

./can_scan can0 680

… erhält man folgende IDs …

elster-kromschroeder can-bus address scanner and test utility
copyright (c) 2014 Jürg Müller, CH-5524

scan on CAN-id: 680
list of valid can id's:

  000 (8000 = 325-07)
  180 (8000 = 325-07)
  301 (8000 = 325-07)
  480 (8000 = 325-07)
  601 (8000 = 325-07)

Fragt man gezielt nach jeder dieser IDs …

./can_scan can0 680 180

… sieht man die Liste der Elster-Indizes mit selbst erklärenden Namen der einzelnen Parameter. Die Siedler finden die interessanten (Logging-würdigen) Parameter alle ‚unter‘ der CAN-ID 180 – hier ein Auszug aus dem Output:

elster-kromschroeder can-bus address scanner and test utility
copyright (c) 2014 Jürg Müller, CH-5524

0001:  0000  (FEHLERMELDUNG  0)
0003:  019a  (SPEICHERSOLLTEMP  41.0)
0005:  00f0  (RAUMSOLLTEMP_I  24.0)
0006:  00c8  (RAUMSOLLTEMP_II  20.0)
0007:  00c8  (RAUMSOLLTEMP_III  20.0)
0008:  00a0  (RAUMSOLLTEMP_NACHT  16.0)
0009:  3a0e  (UHRZEIT  14:58)
000a:  1208  (DATUM  18.08.)
000c:  00e9  (AUSSENTEMP  23.3) 
000d:  ffe6  (SAMMLERISTTEMP  -2.6)
000e:  fe70  (SPEICHERISTTEMP  -40.0)
0010:  0050  (GERAETEKONFIGURATION  80)
0013:  01e0  (EINSTELL_SPEICHERSOLLTEMP  48.0)
0016:  0140  (RUECKLAUFISTTEMP  32.0) 
...
01d4:  00e2  (QUELLE_IST  22.6) 
...
092a:  030d  (WAERMEERTRAG_WW_TAG_WH  781)
092b:  0000  (WAERMEERTRAG_WW_TAG_KWH  0)
092c:  0155  (WAERMEERTRAG_WW_SUM_KWH  341)
092d:  001a  (WAERMEERTRAG_WW_SUM_MWH  26)
...
092e:  02db  (WAERMEERTRAG_HEIZ_TAG_WH  731)
092f:  0006  (WAERMEERTRAG_HEIZ_TAG_KWH  6)
0930:  0073  (WAERMEERTRAG_HEIZ_SUM_KWH  115)
0931:  0027  (WAERMEERTRAG_HEIZ_SUM_MWH  39)

Um z.B. den Stand der Raumheizungsenergie in MWh abzufragen, sendet man …

./can_scan can0 680 180.0931

… und der Output enthält gleich die Summe der MWh- und kWh- Angaben (Indices 0930, 0931):

elster-kromschroeder can-bus address scanner and test utility
copyright (c) 2014 Jürg Müller, CH-5524

value: 0027  (WAERMEERTRAG_HEIZ_SUM_MWH  39.115)

Beim Mitschnüffeln mit Wireshark sieht man die beiden Abfagen (Sender-ID 680) und Rückgabe der beiden Werte:

Mitsniffen am CAN-Bus: Wärmepumpe, Abfrage Heizenergie

Netzwerk-Pakete am CAN-Bus: Abfrage der Elster-Indices 0930 (kWh Heizenergie) und 0931 (MWh Heizenergie) mit can_scan. Die Bedeutung der einzelnen Bits wird im Englischen elkementaren Artikel zu diesem Thema beschrieben.

Um das Monitoring dieser Werte zu automatisieren, wird can_scan alle paar Minuten für die interessanten Parameter ausgeführt und der Zahlenwert aus dem Output in eine CSV-Datei geschrieben. Eine andere Option wäre, nur die Abfrage mit can_scan zu starten und den Output dann mit can_logger einzusammeln.

Die CSV-Datei wird dann per FTP an den Server geschickt, der als Datenkrake sämtliche Logfiles aus unterschiedlichen Quellen (UVR1611 / 16×2, PV-Wechselrichter, Smart Meter) zusammenfasst.

Das komplette Skript – wie auch noch etwas mehr Details zur CAN-Forschung – findet man wie immer auf dem elkementaren Blog.

Natürlich muss der neue Logger auch das Professionalitäts-Level des UVR16x2 einhalten, was die Montage betrifft: Deshalb sind im Routinebetrieb nun beide friedlich auf ihrem Holzbrettchen vereint zu finden (und nach einer Restrukturierung der Netzwerk-Architektur gibt es im Heizraum auch verlässliches LAN und WLAN):

Raspberry Pi mit PiCAN-Board von SK Pang, neben UVR16x2

Raspberry Pi mit PiCAN-Board von SK Pang neben UVR16x2 auf ökologischem Brettchen.

Wie der aufmerksame Leser sieht, wurde auch das CAN-Board getauscht – eine serielle Schnittstelle eröffnet Perspektiven für zukünftige Forschungsprojekte. Danke an SK Pang für ein eigentlich gar nicht mehr verfügbares Board!!

Wärmepumpen-Forensik – Teil 1: Mithorchen am Test-CAN-Bus

In grauer Vorzeit war die Aufnahme von Messdaten eine Herausforderung, die an physische und psychische Grenzen ging:

White-Out

White-Out im Winter 2012/13. Bodentemperaturen mussten trotzdem Irgendwer messen!

Wurzelsepp misst

Warten auf das Temperaturgleichgewicht…

Mittlerweile werden fast alle Messdaten automatisch aufgenommen:

Online-Schema CMI/UVR1611/UVR16x2

Online-Schema CMI/UVR1611/UVR16x2 mit den für die Steuerung nötigen Temperatur- und Durchflusssensoren und einigen weiteren Sensoren für ‚Forschungszwecke‘ (Bodentemperatur, Strahlung)

Aber ein wesentlich Sensor hatte sich der Automatisierungswut der Siedler bis jetzt widersetzt: Die offizielle Arbeitszahl in der Messdaten-Dokumentation wird berechnet aus der Wärmeenergie, die Irgendwer tagaus, tagein am Display der Wärmepumpe abliest.

Die Siedler-Wärmepumpe ist zwar ‚absichtlich dumm gewählt‚ – aber vielleicht gibt es ja doch smarte Ansätze? Im Handbuch der Stiebel-Eltron WPF 7 basic werden sie fündig: Im Abschnitt Kleinspannung, BUS-Leitung werden die Anschlüsse CAN-Bus für Fernbedienung angeführt – vielleicht könnte man ja hier die Ergebnisse der bisherigen CAN-Bus-Forschung nutzen? Und vielleicht sogar den derzeit nicht produktiven Raspberry Pi verwenden?

Wie praktisch immer, wenn man glaubt ein Pionier zu sein, findet man im Internet bereits Anleitungen und Tools. Besten Dank an die Stiebel-Eltron-Raspberry-Pi-CAN-Bus-Hacker von messpunkt.org und juerg5524.ch!

CAN-Erweiterungsboard für Raspberry Pi

Erste Herausforderung: Unser Pi ist das ältere ‚Modell B‘. Im Gegensatz zum Nachfolgermodell B+ hatte dieser Pi nur 26 GPIO-Pins für Steuerungszwecke anstatt 40. Die PIN-Belegung hat sich zwar nicht geändert, aber neuere CAN-Boards für 40 Pins passen nicht auf den alten Pi. Der versierte Bastler wird aber auf ebay fündig und freut sich über dieses kleine Board passend für 26 Pins.

Damit ist die CAN-Schnüffel-Hardware einsatzbereit:

Raspberry Pi mit CAN-Board

Raspberry Pi mit aufgestecktem CAN-Board und verdrahtetem CAN-Kabel (grau). Blaues Kabel: Ethernet, schwarzes Kabel: Stromversorgung.

Um nicht gleich die Energieversorgung der Siedlerhütte lahm zu legen und Software zu testen, schnüffeln wir zuerst in einer…

Testumgebung: UVR1611 mit Logger BL-NET

Der Pi-Schnüffler wird daher an einen Test-Bus angeschlossen der aus den folgenden altbekannten Geräten besteht:

  • UVR1611-Steuerung mit einem angeschlossenen Temperatursensor
  • Datenlogger BL-NET, per ausgekreuztem Ethernet-Kabel mit einem Test-PC verbunden, auf dem Winsol läuft. Daten werden jede Minute geloggt. (Überblick zu Logging mit UVR1611 und BL-NET).

Eigentlich müsste jeder CAN-Bus an beiden Enden terminiert werden. Da dieser Test-CAN-Bus wie auch der Wärmepumpen-CAN-Bus nur sehr kurze Kabel verwenden und sie keine negativen Erfahrungen gemacht hatten mit kurzen falsch terminierten Bussen, verzichten die Siedler auf eine korrekte Terminierung.

Test Can-Bus: UVR1611 und BL-NET

Test Can-Bus: UVR1611 (Mitte) mit einem Pt1000-Temperatursensor (Metallhülse, schwarzes Kabel) und Datenlogger BL-NET (oben, weiß). Das CAN-Kabel (grau) verbindet 1) UVR1611, 2) BL-NET (blauer Stecker) und Raspberry Pi (nicht im Bild). Am LAN-Kabel (gelb) ist ein PC mit Winsol angeschlossen.

Software und Konfiguration

Zuerst wird der Kernel des Raspberry Pi auf eine Version upgedated, die die CAN-Schnittstelle unterstützt. Für Details siehe z.B. diesen Blog-Artikel (Abschnitt Software Installation).

In der Raspberry-Pi-Konfiguration muss der für CAN benötigte SPI-Bus aktiviert werden. Dies wird im Detail beschrieben im Blog des CAN-Board-Herstellers SK Pang.

Bitrate einstellen

Der UVR-CAN-Bus verwendet eine Bitrate von 50kbit/s – im Gegensatz zum Wärmepumpen-Bus, der 20kbit/s benötigt. Mit folgendem Befehl wird die Bitrate eingestellt und die CAN-Schnittstelle ‚aktiviert‘:

sudo ip link set can0 type can bitrate 50000
sudo ifconfig can0 up

Bei falscher Bitrate sieht man beim Mitschnüffeln keine Pakete weil das CAN-Interface ’stummgeschaltet‘ wurde (Fehler BUS OFF [*]).

Wenn man alles richtig macht, sind jetzt alle zwischen BL-NET und UVR1611 ausgetauschten Pakete auch für den Raspberry Pi lesbar. Installiert man Wireshark, kann die CAN-Schnittstelle ausgewählt werden … und die Pakete werden korrekt dem CAN-Protokoll zugeordnet:

CAN-Bus-Netzwerkverkehr mitsniffen mit Wireshark

Nachdem Steuerung und Logger diesen Test überstanden haben, wagen sich die Siedler an die Kommunikation mit der Wärmepumpe heran. Fortsetzung folgt … hier in Teil 2.

[*] Etwas mehr Details im elkementaren Artikel zu diesem Thema.

_______________________________________________

Weitere Details zur CAN-Kommunikation der UVR1611

UVR1611, BL-NET und die Gefahren des Fernsehkonsums (X-Akten, Teil 3)

Wieder erreichte uns ein Hilferuf eines tapferen UVR1611-Nutzers – die Siedler möchten die Lösung der Weltöffentlichkeit nicht vorenthalten.

Der im letzten X-Akten-Posting angesprochene UVR1611 Data Logger Pro erfreut sich offenbar großer Beliebtheit: Anstelle von Winsol (aber unter Nutzung des gleichen Protokolles) liest diese Anwendung die von BL-NET geloggten Daten in Echtzeit aus – und macht damit die Logging-Funktion und den Webserver des BL-NET überflüssig. Ressourcen-bewusste Siedler möchten ihren lieb gewonnenen BL-NET daher noch lange weiter verwenden, aber was tun in folgendem Fall?

Im schwarz-rot-goldenen Nachbarland bietet ein namhafter rosaroter Fernmeldedienst IP-TV an. Beim Einschalten des TV fühlt sich der BL-NET offenbar bedroht, und fällt in eine Schockstarre, gekennzeichnet durch ein dauerhaft blinkendes Lämpchen.

Folgender Tüftlervorschlag hatte geholfen: Der BL-NET muss in einem eigenen kleinen Subnetz vor dem TV in Schutz gebracht werden – indem man an die LAN-Seite des Internet-Routers einen weiteren Router hängt, und erst an dessen vom Haupt-LAN abgewandte Seite den BL-NET. Damit kann man zwei Fliegen mit einer Klappe schlagen:

  • Als ‚böse‘ eingestuften Netzwerkpakete werden vom BL-NET ferngehalten. Wir vermuten, dass irgendein Multicast / Broadcast-‚Angriff‘ für den BL-NET zu sehr Science Fiction war.
  • Bei unstillbarem Forscherdrang könnte man als Router auch einen PC mit Sniffer-Software installieren und ggf. das böse Paket identifizieren.

Was uns noch nicht ganz gefällt, ist der zusätzliche Energiebedarf für einen weiteren Router. Mögliche Lösungen sind:

  • Einen Internet-Router verwenden, der mehrere virtuelle LANs unterstützt, oder ein ‚Gästenetz‘. (Geschwätzige und vielleicht auch schnüffelnde Dinge im Internet der Dinge auf diese Art abzuschotten wäre generell keine so schlechte Strategie.)
  • Den Server, auf dem die Datenbank für den Logger Pro läuft, mit einer zusätzlichen Netzwerkkarte als Router zu verwenden.

Die Verwendung eines Windows-PCs als Router und Sniffer-Station wurde in diesem Posting beschrieben.

SW Testbild

Damals waren Fernseher noch ungefährlich für die restlichen Geräte im Dumb Home (Bild: Benutzer Dreinagel, Wikimedia)

Das Internet der Dinge

Die Siedler betonen gerne, dass sie bodenständige Wissenshandwerker sind, die bezüglich visionären Phrasen eine gesunde Skepsis an den Tag legen.

Gewissen Trends können sie sich dennoch nicht verschließen.

Wer würde nicht wollen, dass der Kühlschrank automatisch Pizza nachbestellt oder PV-Module stolz ihren täglichen Ertrag twittern? All das fällt unter den Begriff Internet der Dinge. Diese Dinge sind oft auf abenteuerliche Weise – gewollt oder ungewollt – mit dem Internet verbunden.

Im Sinne einer realistischen Abschätzung von Sicherheitsrisiko zu Nutzen ist praktische Forschungsarbeit nötig. So führen die Siedler eine minuziöse Untersuchung sämtlicher netzwerkfähiger Dinge in ihrer Siedlerhütte durch. Welches Ding kommuniziert ungefragt mit dem Dem Internet? Und welche Siedlergeheimnisse werden dabei ausgeplaudert?

Entgegen den Klischées in Hacker-Filmen ist es gar nicht so einfach, den Netzwerkverkehr mitzuschnüffeln. Das war einmal, als unsere Netzwerkverkabelung noch mit dem Antennenkabel verwechselt werden konnte:

10base2 t-pieceWehmütig bereuen die Siedler auch, ihren Hub aus dem letzten Jahrtausend entsorgt zu haben. Wie beim Koaxialkabel würde jedes angeschlossene Ding alle von allen anderen Dingen versendeten Netzwerkpakete sehen können.

Heute sind auch im billigsten Internet-Router schon Switches eingebaut. Das Möchtegern-Hacker-Notebook kann dadurch nur noch jene Pakete lesen, die für seine Hardwareadresse bestimmt sind.

Davon lässt sich das Elkement nicht aufhalten – und es hat ein Ziel: Der breiten Öffentlichkeit, also auch dem typischen Windows-Benutzer, zu ermöglichen, die Kommunikation seiner Dinge mitzuverfolgen.

Die Lösung besteht darin, das Ding zu zwingen, mit Dem Internet nur über das Hacker-Notebook zu kommunizieren. Das Notebook wird zum Router; das Ding befindet sich also hinter einer Kaskade von zwei Routern: 1) dem Hacker-Notebook und 2) dem eigentlichen Internet-Router.

Dafür verwenden wir ein wenig bekanntes und wahrscheinlich in Expertenkreisen belächeltes Feature: Die Internetverbindungsfreigabe in Windows.

Ein Router hat mehr als eine Netzwerkkarte und verbindet mindestens zwei (adressmäßig unterschiedliche) Netzwerke.

Ein typisches Laptop hat diese beiden Netzwerkadapter!

  1. WLAN – zur Verbindung mit dem Internet-/WLAN-Router
  2. LAN – eine RJ45-Buchse für ein Ethernetkabel.

(2) wird nun verwendet, um das Ding anzuschließen, bzw. genauer gesagt, ein kleines privates Netzwerk aufzubauen, das nur das Ding enthält. Dafür wird ein ausgekreuztes Kabel verwendet.

Zusätzlich muss eine Sniffer-Software installiert werden, wie z.B. das frei verfügbare  Wireshark.

Ziel ist der folgende Aufbau – in der Darstellung werden der Standard-IP-Adressbereich der Verbindungsfreigabe verwendet (192.168.137.x) und 192.168.0.x als typisches internes Netz:

|     Ding    |       |      Laptop-Router      |      |Internet-Router
|     LAN     |-cross-|     LAN     |    WLAN   |-WLAN-|Internes LAN
|192.168.137.2|       |192.168.137.1|192.168.0.2|      |192.168.0.1

Konfiguration:

  • Eigenschaften des WLAN-Adapters suchen, in Windows 7 unter:
    Systemsteuerung
    –Netzwerk und Internet
    —-Netzwerkstatus und -aufgaben
    ——Adaptereinstellungen ändern
  • In den Eigenschaften des WLAN-Adapters auf Freigabe klicken und anhaken der Option: Anderen Benutzern im Netzwerk gestatten die Internetverbindung dieses Computers zu verwenden.
  • In einem Dropdown-Menü werden alle anderen Adapter außer dem zu teilenden angezeigt – hier wird die Lokale Internetverbindung als privates Netzwerk ausgewählt:

  • Der LAN-Anschluss des Dinges wird über das Crossover-Kabel mit der LAN-Buchse des Laptops verbunden.
  • Wenn das Gerät DHCP verwendet, erhält es automatisch eine IP-Adress aus dem Bereich 192.168.137.x. Wenn nicht, muss eine statische Adresse mit x ungleich 1 vergeben werden. Das Router-Notebook erhält die Adresse 192.168.137.1 und ist  DHCP-Server, DNS-Server, und Default Gateway.
  • Wireshark starten, klick auf Capture, Interfaces…, Auswahl des Adapters mit der Adresse 192.168.137.1 … und … Start!

Ein harmloses Praxisbeispiel – der Blu-Ray-Player der Siedler:

Das Ding erhält eine Adresse über DHCP – nur das letzte Paket (‚acknowledge‘) ist hier gezeigt – und versucht dann die MAC-(Hardware-)Adresse für den Router-Computer 192.168.137.1 zu finden – ein DELL-Laptop. Benötigt wird nämlich ein DNS-Server, um einen offenbar hart-kodierten Namen aufzulösen: liveupdate.blurayplayer.samsung.com.

Gut, dass die Kommunikation nicht verschlüsselt ist – sonst könnten wir nicht so einfach mithören.

Mit der Wireshark-Option Follow TCP stream sieht man noch besser, was jetzt passiert:

Der Player ruft die Seite liveupdate.jsp über HTTP auf, schickt die Typenbezeichnung, eine Versionsnummer und den Standort ‚EU‘. Samsung sieht diese Anfrage von der nicht wirklich anonymen IP-Adresse der Siedler in einem kleinen mitteleuropäischen Land kommend.

Samsung antwortet mit [NO UPDATE] und einem Cookie, das bereits vor 3,5 Jahren abgelaufen ist.

Und die Moral aus dieser Geschichte? Nicht, dass es überraschend wäre, dass Geräte versuchen, sich automatisch Updates von einem Server im Internet zu holen. Computer machen das seit ‚ewigen Zeiten‘ – allerdings mit dem ‚feinen‘ Unterschied, dass man hier das Updateverhalten als Besitzer 1) prinzipiell kontrollieren könnte und 2) auch das Mitverfolgen sehr viel einfacher wäre.

Unser Vorschlag für Was gibt es Neues: Das Ding der Woche an seinem Internetraffic zu erkennen!