VMWare RDM: ESXi-Boot wird minutenlang verzögert

Schlecht. Ein ESXi-Host sollte zwecks Update „mal schnell“ neu gestartet werden, doch nun sind mehr als 30 Minuten vergangen und es gibt noch immer kein Lebenszeichen. Selbst für Server etwas ungewöhnlich und lange genug um den VMWare-Updater in einen Timeout laufen zu lassen. Nach einiger Zeit war das System zwar wieder korrekt gebootet und zeigte keine weiteren Auffälligkeiten, eine solche Wartezeit wäre bei Störungen jedoch sehr hinderlich, also gehen wir mal auf Quellensuche.

Im Log finden sich mehrere Einträge, welche durch die Zeitstempel massive Wartezeiten erkennen lassen:

***T09:53:18.467Z cpu1:***)vmw_psp_mru: psp_mruSelectPathToActivateInt:346: Changing active path from NONE to vmhba0:xx:xx:xx for device "Unregistered Device".
***T09:53:18.467Z cpu1:***)StorageApdHandler: xxx: APD Handle  Created with lock[StorageApd-0xxxx]
***T09:53:18.467Z cpu1:***)ScsiEvents: 501: Event Subsystem: Device Events, Created!

***T09:53:18.467Z cpu1:***)VMWARE SCSI Id: Id for vmhba1:xx:xx:xx xxxxx
***T09:53:18.467Z cpu1:***)VMWARE SCSI Id: Id for vmhba0:xx:xx:xx xxxxx
***T09:53:58.506Z cpu2:***)ScsiDeviceIO: xxx: Cmd(0xxxx) 0x1a, CmdSN 0x1 from world 0 to dev "naa.xxx" failed H:0x5 D:0x0 P:0x0 Possible sense data: 0x0 0x0 0x0.
***T09:53:58.506Z cpu1:***)ScsiDeviceIO: xxx: Could not detect setting of QErr for device naa.xxx. Error Timeout.
***T09:54:08.631Z cpu19:***)NMP: nmp_ResetDeviceLogThrottling:3343: Error status H:0x0 D:0x18 P:0x0 Sense Data: 0x0 0x0 0x0 from dev "naa.xxx" occurred 989 times(of 989 commands)
***T09:54:38.524Z cpu2:***)ScsiDeviceIO: xxx: Cmd(0xxxx) 0x1a, CmdSN 0x2 from world 0 to dev "naa.xxx" failed H:0x5 D:0x0 P:0x0 Possible sense data: 0x0 0x0 0x0.
***T09:54:38.524Z cpu1:***)ScsiDeviceIO: xxx: Could not detect setting of sitpua for device naa.xxx. Error Timeout.

Das Ganze wiederholt sich dann mehrfach. Also ein SCSI-Timeout? Der Host ist per FibreChannel an diverse Storage-Systeme angebunden, sollte jedoch auch nur die für ihn relevanten LUNs sehen. Zumal nach dem langem boot auch alle Datastores verfügbar und VMs ohne Fehler online waren.

Nach einigem Suchen dann die Erkenntnis: Die angekreideten LUNs gehören zu einem Windows-Cluster und sind als RDM vorgesehen. ESXi versucht nun beim Booten diese LUNs zu scannen, was jedoch nicht gelingt da der Cluster auf einem anderen Host aktiv und die Partition somit dauerhaft gesperrt ist. Zur Abhilfe muss man diesen Scan beim Boot explizit für die betroffenen LUNs auf jedem Host deaktivieren:

esxcli storage core device setconfig -d naa.xxxx --perennially-reserved=true

https://kb.vmware.com/kb/1016106

VMWare vSphere-Client per SSH-Tunnel

Bild: https://www.adlerweb.info/blog/wp-content/uploads/2016/07/vmlist-300×205.pngUgh – eine VM hängt und ich habe kein VPN ins zugehörige Netz. Aber jetzt extra hinfahren? Auch unschön. Glücklicherweise gibt es noch einen SSH-Zugang, den ich hier nutzen kann. Also schnell Tunneln – doch welche Ports? Nunja, nehmen wir für den „alten“ vSphere-Client folgende:

  • 443
  • 992
  • 993

Wer jedoch versucht mit 127.0.0.1 oder localhost zu verbinden wird auf Probleme stoßen – bei mir lief der Client auf diesen IPs keinen Connect zu. Ein kurzer Griff in die IPv6-Kiste mit dem guten, alten [::1] half und ließ die Verbindung zu.

Linux: Optisches Laufwerk RAW über Netzwerk einbinden

(Hinweis: Der Artikel lag schon etwas rum – möglicherweise sind die verwendeten Tools nicht mehr aktuell)

Hmmm – ungünstig. Das einzige optische Laufwerk steckt in einem Linux-Server, ich möchte die Discs jedoch auf einem anderen Gerät verwenden. Üblicherweise reicht hier ein File-Share wie Samba, NFS o.Ä. aus, wenn man jedoch beispielsweise kopiergeschützte DVDs abspielen möchte ist eine solche Freigabe nicht ausreichend. Glücklicherweise können wir hier einen alten Bekannten bemühen: iSCSI. Dies hatten wie bereits für Festplatten besprochen, kann aber auch für optische Laufwerke genutzt werden.

Server / Target

Nach dem Aufruf von targetcli sollten wir die altbekannte Textkonsole erhalten, welche auf der Root (/) der Konfiguration startet. Im ersten Schritt registrieren wir das physikalische Laufwerk /dev/sr0 als Backstore und aktivieren es für iSCSI. Sofern nicht bereits vorhanden wird automatisch eine TPG erzeugt.

/> cd backstores/pscsi
/backstores/pscsi> create name=cdrom_backend dev=/dev/sr0
Note: block backstore recommended for SCSI block devices
Created pscsi storage object cdrom_backend using /dev/sr0
/backstores/pscsi> cd cdrom_backend
/backstores/p...cdrom_backend> /iscsi create
Created target iqn.2003-01.org.linux-iscsi.testserver.x8664:sn.3299e9a7999b.
Created TPG 1.
Global pref auto_add_default_portal=true
Created default portal listening on all IPs (0.0.0.0), port 3260.

Nun müssen wir noch eine LUN erstellen um Clients den Zugriff zum Gerät zu ermöglichen. Diese Konfiguration findet im Kontext der TPG statt, die nötige ID wurde ja weiter oben angezeigt. Da nur ein Backstore verfügbar ist wird dieser automatisch ausgewählt. Da es sich um ein Testnetz handelt verzichte ich auf eine Absicherung und alle alle Clients zu – bei CD-Laufwerken ein überschaubares Risiko.

/backstores/p...cdrom_backend> cd /iscsi/iqn.2003-01.org.linux-iscsi.testserver.x8664:sn.3299e9a7999b/tpg1/
/iscsi/iqn.20...e8a7999b/tpg1> cd luns
/iscsi/iqn.20...99b/tpg1/luns> create /backstores/pscsi/cdrom_backend
Created LUN 0.
/iscsi/iqn.20...99b/tpg1/luns> cd ..
/iscsi/iqn.20...e8a7999b/tpg1> set attribute authentication=0 demo_mode_write_protect=0 generate_node_acls=1 cache_dynamic_acls=1
Parameter cache_dynamic_acls is now '1'.
Parameter authentication is now '0'.
Parameter generate_node_acls is now '1'.
Parameter demo_mode_write_protect is now '0'.
/iscsi/iqn.20...e8a7999b/tpg1>

Zuletzt wird die Konfiguration gespeichert, so ist sie z.B. auch nach einem Neustart noch vorhanden

/iscsi/iqn.20...e8a7999b/tpg1> cd /
/> saveconfig
Last 10 configs saved in /etc/target/backup.
Configuration saved to /etc/target/saveconfig.json
/> exit
Global pref auto_save_on_exit=true
Last 10 configs saved in /etc/target/backup.
Configuration saved to /etc/target/saveconfig.json

Client / Initiator

Auf der Clientseite benötigen wir ebenfalls eine Userspace-Software. Ich nutze zur Konfiguration iscsiadm aus dem Paket open-iscsi. Hier wird erst über Discover geprüft welche LUNs auf der TPG/Ziel-IP verfügbar sind. Über Login werden diese dann verbunden.

# iscsiadm --mode discoverydb --type sendtargets --portal 10.11.12.13 --discover
10.11.12.13:3260,1 iqn.2003-01.org.linux-iscsi.testserver.x8664:sn.3299e9a7999b
# iscsiadm --mode node --login
Logging in to [iface: default, target: iqn.2003-01.org.linux-iscsi.testserver.x8664:sn.3299e9a7999b, portal: 10.11.12.13,3260] (multiple)
Login to [iface: default, target: iqn.2003-01.org.linux-iscsi.testserver.x8664:sn.3299e9a7999b, portal: 10.11.12.13,3260] successful.

Das Ergebnis ist ein zusätzliches Blockdevice, welches wie ein Lokales angesteuert werden kann.

# dmesg | tail
[269195.457603] Loading iSCSI transport class v2.0-870.
[269196.464444] iscsi: registered transport (tcp)
[269243.373172] scsi host5: iSCSI Initiator over TCP/IP
[269243.636444] scsi 5:0:0:0: CD-ROM TSSTcorp DVD+-RW TS-H653B D300 PQ: 0 ANSI: 5
[269243.668795] sr 5:0:0:0: [sr1] scsi-1 drive
[269243.669219] sr 5:0:0:0: Attached scsi CD-ROM sr1

 

Deinstallation von Kaspersky Endpoint / Total / Select Security

Wenn es eine Software gibt, welche potentiell mehr Schaden anrichten kann und schwerer zu entfernen ist als ein Virus, dann handelt es sich um ein Produkt aus der Schlangenölbranche. Ein besonderes Schätzchen ist hier Kaspersky, deren Firmenchef sich gerne als Gehilfe diverser Dienste positioniert und aktuell unter Beschuss steht. Aber genug Themenausflug – mein Wunsch ist schnell definiert: Deinstallieren. Vorzugsweise automatisch. Nicht wegen den aktuellen Problemen, sondern eher da die Systeme sauber sein sollen.

Kaspersky besteht dabei in der Business-Variante aus drei Teilen:

Das Kaspersky Security Center (KSC, ehemals Kaspersky Administration Kit oder auch KAK), welches zentral installiert ist und für Management und Deployment zuständig ist

Der Kaspersky Administration Agent, einem kleinen Tool, welches auf allen Rechnern installiert ist und primär die Verbindung zwischen dem Security Center und den Schutzprogrammen des Rechners herstellt. Weiterhin kann es zur Installation von beliebigen Programmen und Patches genutzt werden.

Zuletzt das eigentliche Schutzprogramm, auf Nutzerseite meist Kaspersky Endpoint Security, welches Dienste wie Signaturscan, Software-Firewall und Gerätekontrolle bereitstellt.

Leider ist das Management an vielen Stellen trotz der langen Reife noch ausbaufähig. Verschiedene Sprachversionen oder gar Rechner mit unterschiedlichen Service-Packs der Software lassen sich nur schwer gemeinsam verwalten oder gegeneinander austauschen, die Managementverbindung geht gerne mal verloren und für die Rechnergeschwindigkeit ist eine solche Software ebenfalls nur wenig zuträglich.

Zur Deinstallation hatte ich hierzu üblicherweise eine „Geheimwaffe“: Den KAVRemover. Dieses Tool des Herstellers ist in der Lage viele Installationen auf dem verwendeten Rechner mit einem Schlag zu entfernen. Aus Sicherheitsgründen hat sich der Hersteller jedoch dazu entschieden die Deinstallation mit einem CAPTCHA abzusichern. Da ich nun eine größere Charge Rechner vor mir hatte tut diese Unmöglichkeit der Automation natürlich weh. Also ran an die offiziellen Deinstallationsroutinen.

Erstes Problem: Passwörter. Insgesamt gibt es 2-3 Passwortebenen, mit denen eine lokale Installation im genannten Konstrukt geschützt ist:

Endpoint Security nutzt, wenn in der entsprechenden Policy angegeben, einen Passwortzugang zu allen administrativen Funktionen. Dieses wird auch zur Deinstallation benötigt. Bei neueren Versionen (ab 10.2ish) wird zusätzlich ein Benutzername verlangt, welcher jedoch augenscheinlich auf „KLAdmin“ hardcoded ist.

Bild: https://www.adlerweb.info/blog/wp-content/uploads/2016/07/kavmenu-300×70.pngIst dieses Passwort nicht bekannt, jedoch Zugang und Verbindung zum Security Center noch vorhanden, kann man den Passwortschutz per Policy einfach ausschalten und so die Deinstallation etwas vereinfachen. Hierzu öffnet man die zum Produkt gehörende Policy und entfernt unter „Advanced Settings“ -> „Interface“ die Checkbox „Enable password protection“. Dies muss selbstverständlich für jede Sprache und Service-Pack-Version wiederholt werden.

Der Administration Agent nutzt eine separate Policy und hat ein dediziertes Passwort für die Deinstallation gesetzt. Ob sich dies ebenfalls irgendwo abschalten lässt habe ich nicht geprüft.

Das Passwort lässt sich glücklicherweise bei der Deinstallation als Parameter – natürlich je nach Version mit anderem Namen – angeben. Um die Funktion nutzen zu können muss man das Passwort jedoch vorher umrechnen: Es muss als ASCII-String einer HEX-Repräsentation des Passworts als 16Bit-ASCIIish (sieht aus wie ein Byte-Invertiertes UTF16) eingetragen werden. Besser keine Fragen stellen.

Also rechnen wir mal: Wäre unser Passwort „Geheim“ müssen wir dies erst mal in Hex konvertieren. Hierzu kann man – bei einfachen Zeichen – die gute, alte ASCII-Tabelle bemühen. G ist in HEX 0x47, e 0x65 – und so weiter. Am Ende erhalten wir „47 65 68 65 69 6D“. Da wir jedoch noch die 00en für 16 Bit brauchen wird daraus ein „470065006800650069006D00“. Mit diesem String können wir dann weiter an’s Werk. Zu beachten ist, dass einige Versionen der 10er-Serie (10.0.3361) zwischendrin plötzlich mal nur 8 Bit brauchten um beim nächsten Update wieder auf 16 zu springen. Kurzfassung: Wenns nicht geht einfach anders nochmal versuchen.

Für die Deinstallationen benötigt man weiterhin die MSI-IDs der Produkte. Einige seien hier mal gelistet, wer weitere hat: Die Kommentare stehen offen. Wer sich nicht sicher ist sollte in der Registry unter HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall und HKLM\Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall nach Kaspersky-Einträgen suchen.

Danke an dawinci für das Listen der auswärtigen Agent-IDs

  • Kaspersky Endpoint Security 8.x Deutsch
    • {D72DD679-A3EC-4FCF-AFAF-12E2552450B6}
  • Kaspersky Endpoint Security 10.x (Deutsch, 64Bit)
    • {04CF7FBD-E56C-446D-8FC9-DD444BDBEE8E}
  • Kaspersky Endpoint Security 10.x (English, 32Bit)
    • {7A4192A1-84C4-4E90-A31B-B4847CA8E23A}
  • Kaspersky Admin Agent 9.x/10.x (Deutsch)
    • {2F383CB3-6D7C-449D-9874-164E49E1E0F5}
  • Kaspersky Admin Agent 9.x/10.x (English)
    • {BCF4CF24-88AB-45E1-A6E6-40C8278A70C5}
  • Kaspersky Admin Agent 9.x/10.x (Arabisch)
    • {FA7BF140-F356-404A-BDA3-3EF0878D7C63}
  • Kaspersky Admin Agent 9.x/10.x (Bulgarisch)
    • {4DBF6741-FA51-4C14-AFD2-B7D9246995F6}
  • Kaspersky Admin Agent 9.x/10.x (Tschechisch)
    • {478A6A0B-D177-4402-B703-808C05C56B13}
  • Kaspersky Admin Agent 9.x/10.x (Französisch)
    • {2924BEDA-E0D7-4DAF-A224-50D2E0B12F5B}
  • Kaspersky Admin Agent 9.x/10.x (Ungarisch)
    • {8899A4D4-D678-49F8-AD96-0B784F58D355}
  • Kaspersky Admin Agent 9.x/10.x (Italiänisch)
    • {DC3A3164-36B3-4FB4-B7BF-16A41C35A728}
  • Kaspersky Admin Agent 9.x/10.x (Japanisch)
    • {790C176F-7780-4C84-8B9C-455F5C0E61C5}
  • Kaspersky Admin Agent 9.x/10.x (Koreanisch)
    • {70812A40-973B-4DA1-96B9-C2011280CD99}
  • Kaspersky Admin Agent 9.x/10.x (Polnisch)
    • {1A7B331A-ABBE-4230-995E-BCD99C5A18CF}
  • Kaspersky Admin Agent 9.x/10.x (Portugiesisch / Brasilien)
    • {0F05E4E5-5A89-482C-9A62-47CC58643788}
  • Kaspersky Admin Agent 9.x/10.x (Rumänisch)
    • {FF802D76-E241-41D3-AAB4-DC7FBD659446}
  • Kaspersky Admin Agent 9.x/10.x (Russisch)
    • {ED1C2D7E-5C7A-48D8-A697-57D1C080ABA7}
  • Kaspersky Admin Agent 9.x/10.x (Chinesisch, vereinfacht)
    • {FBD7C01E-49CB-4182-8714-9DB1EAE255CB}
  • Kaspersky Admin Agent 9.x/10.x (Chinesisch, Traditionell)
    • {F6AD731A-36B4-4739-B1D4-70D6EDA35147}
  • Kaspersky Admin Agent 9.x/10.x (Spanisch / Mexiko)
    • {29748B5F-D88A-4933-B614-1CCCD6EFB0B7}
  • Kaspersky Admin Agent 9.x/10.x (Türkisch)
    • {2475A66D-698B-4050-93FF-9B48EE82E2BA}

Die Deinstallationsbefehle für die Endpoint Security lauten:

  • Kein Passwort
    • MsiExec.exe /x {MSI-ID} /qb- REBOOT=ReallySuppress
  • Nur Passwort
    • MsiExec.exe /x {MSI-ID} /qb- REBOOT=ReallySuppress KLPASSWDHEX=470065006800650069006D00
    • bzw. MsiExec.exe /x {MSI-ID} /qb- REBOOT=ReallySuppress KLPASSWDHEX=47656865696D
    • Alternativ kann man bei KES statt KLPASSWDHEX die Variable KLPASSWD verwenden und das Kennwort in Klartext angeben
  • Nutzername + Passwort
    • MsiExec.exe /x {MSI-ID} /qb- REBOOT=ReallySuppress KLLOGIN=KLAdmin KLPASSWDHEX=470065006800650069006D00

Für den Kaspersky Administration Agent lauten die Befehle:

  • Ohne Passwort
    • MsiExec.exe /x {MSI-ID} /qb- REBOOT=ReallySuppress
  • Mit Passwort
    • MsiExec.exe /x {MSI-ID} /qb- REBOOT=ReallySuppress KLUNINSTPASSWD=470065006800650069006D00

Beim Admin-Agent schlägt die Installation teilweise trotz richtigem Passwort mit dem Exit-Code 1603 fehl. In dem Fall kann es helfen einfach mal bis 10 zu zählen und die Deinstallation nochmal zu starten.

Bei /qb- wird ein Fortschrittsbalken angezeigt, welcher leider auch „abbrechen“ ermöglicht. Alternative /qn komplett im Hintergrund.

In meinem Fall habe ich eine Loop, welche für jede bekannte MSI-ID alle Deinstallationsbefehle mehrmals durchprobiert. Bei ca. 90% der Rechner funktioniert holzhammer(); – immerhin etwas weniger Arbeit.

BitBastelei #258 – LED in der Steckdose? Geht das?

BitBastelei #258 - LED in der Steckdose? Geht das?

(60 MB) 00:21:41

2017-10-08 10:00 🛈

Eine LED in die Steckdose stecken klingt nicht sonderlich klug – aber seit wann lasse ich mich davon abhalten. Schauen wir mal was passiert, warum man nicht wie sonst einen Vorwiderstand nutzen sollte und was ein Kondensator damit zu tun hat.

Links zum Thema

[ICStation.com] BitBastelei #257 – Singende Tesla-Spule

[ICStation.com] BitBastelei #257 - Singende Tesla-Spule

(214 MB) 00:26:45

2017-10-01 10:00 🛈

Teslaspulen sind immer faszinierend – und das nicht nur in alten Computerspielen. Durch hochfrequente Wechselspannung und ein großes Übersetzungsverhältnis wird eine Hochspannung generiert, welche optisch interessante Plasmablitze erzeugt. Klingt nach Raketentechnik? Nicht ganz – für ein paar Euro verspricht dieser Bausatz von ICStation.com nicht nur einen einsteigerfreundlichen Aufbau, sondern auch gleich noch eine Musikfunktion.

Achtung: Hochspannung ist gefährlich. Nicht ohne Schutzmaßnahmen betreiben.

Links

Hinweise

Der Bausatz wurde mir von ICStation.com für dieses Video kostenfrei zur Verfügung gestellt

RasPi/OSMC: SSH-Login bricht ab

Mal wieder ein Fehler, der im ersten Moment nicht wirklich zu erklären ist: An einem meiner Mediacenter konnte ich mich nicht mehr per SSH anmelden. Alle anderen Netzwerkfunktionen sahen OK aus, der SSH-Client meines Rechners zeigt jedoch folgendes:

> ssh osmc@1.2.3.4 -v
OpenSSH_7.5p1, OpenSSL 1.1.0f  25 May 2017
debug1: Reading configuration data /home/adlerweb/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 20: Applying options for *
debug1: Connecting to 1.2.3.4 [1.2.3.4] port 22.
debug1: Connection established.
[…]
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.5
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.7p1 Raspbian-5+deb8u3
debug1: match: OpenSSH_6.7p1 Raspbian-5+deb8u3 pat OpenSSH* compat 0x04000000
debug1: Authenticating to 1.2.3.4:22 as 'osmc'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256@libssh.org
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:xyz
debug1: Host '1.2.3.4' is known and matches the ECDSA host key.
debug1: Found key in /home/adlerweb/.ssh/known_hosts:853
debug1: rekey after 1234 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey after 1234 blocks
debug1: SSH2_MSG_SERVICE_ACCEPT received
Authentication failed.
> 

Da es vor dem „Authentication failed“ ein paar Sekunden Wartezeit gibt kam mir ein alter Bekannter in den Sinn: DNS. Meldet man sich per SSH an versucht dieser standardmäßig den zur IP gehörenden Hostname zu ermitteln. Erhält der SSH-Daemon keine Antwort kann es zu einem Timeout kommen und die Verbindung abbrechen. Auch in meinem Fall fand ich in der Konfiguration einen veralteten DNS-Server.

Die ultimative Lösung besteht natürlich darin die Netzwerkkonfiguration zu fixen und somit DNS wieder lauffähig zu bekommen. Um zukünftig den hier nötigen Gang zum Raspi zu sparen und SSH auch ohne DNS lauffähig zu bekommen kann man folgende Zeilen in /etc/ssh/sshd_config hinzufügen:

GSSAPIAuthentication no
UseDNS no

UseDNS schaltet den Reverse-DNS ab – im LAN wohl zu verkraften. GSSAPI kann ohne DNS ebenfalls Fehler verursachen und wird bei einfachen Setups ohnehin nicht aktiv sein, daher auch dies nochmal explizit abgeschaltet. Nach dem nächsten Neustart des sshd sollte der Login dann auch ohne DNS immer und so die Reparatur der Netzwerkkonfiguration auch übers Netz möglich sein.

BitBastelei #256 – Analog-Multimeter Fehlersuche

BitBastelei #256 - Analog-Multimeter Fehlersuche

(94 MB) 00:10:21

2017-09-24 10:00 🛈

Ein alter Bekannter auf dem Basteltisch: Das Elavi 15n aus den 70ern war bereits in meinem alten Intro zu sehen. Nun kam es mit einer wenig aussagekräftigen Fehlermeldung in die Reparaturkiste: Bei Widerstandsmessung geht der Zeiger ins Negative. Schaun wir mal.

BitNotice #126 – Micro-USB Verlängerung

BitNotice #126 - Micro-USB Verlängerung

(12 MB) 00:02:11

2017-09-21 12:00 🛈

Mailbag-Nachschub: Um meine Seek-Wärmebildkamera nicht nur als Selfie-Kamera verwenden zu können hatte ich bisher selbstgebastelte Kabel verwendet. Mal schauen, ob ein fertiges Kabel auch funktioniert und weniger Menschen nervös macht.

1m Micro-USB-Extension, ca. 1€

[ICStation.com] BitBastelei #255 – Geomagnetic Parking Detection Sensor Module

[ICStation.com] BitBastelei #255 - Geomagnetic Parking Detection Sensor Module

(111 MB) 00:37:22

2017-09-17 10:00 🛈

Dieses mal einen – mehr oder weniger – Mystery-Sensor: Ein „Geomagnetic Parking Detection Sensor Module“. Außer dem Namen und einigen technischen Daten ist nicht viel zu finden, also schauen wir mal

Inhalt

00:28 Produktbeschreibung
01:05 Zweckraten
02:09 Ansteuerraten
16:03 Testaufbau
17:20 Protokoll-Decoding
28:45 Echttest

Links:

Modul

Ergänzungen und Korrekturen:

00:24 Zur Klarstellung: Es ging nur um die Reihenfolge – die anderen Teile kommen natürlich auch noch dran

Hinweise

Der Bausatz wurde mit von ICStation.com für dieses Video kostenfrei zur Verfügung gestellt

Nerd Inside