Archiv ‘IT’

Montag, 3. Juli 2023

ConBee II USB-Stick wird nach Debian-Update nicht mehr erkannt

Nach einer Stunde debugging, USB-Stick ausstöpseln, einstöpseln und dutzende Male Firmware flashen entdecke ich endlich After a sudo apt update && sudo apt full-upgrade and a reboot deconz no longer connects to the conbee 2:

Das heute Vormittag eingespielte Debian-Update löscht /dev/serial/by-id/*. Dies verhindert offenbar, dass deCONZ Phoscon den USB-Stick findet. Das Problem erkennt man auch daran, dass folgender Befehl nichts findet:

# GCFFlasher_internal -l
GCFFlasher V3_17 (c) dresden elektronik ingenieurtechnik gmbh
Path             | Vendor | Product | Serial     | Type
-----------------+--------+---------+------------+-------

Auf einem Raspberry Pi mit existierendem /dev/serial/by-id/* schaut das hingegen noch so aus:

# GCFFlasher_internal -l
GCFFlasher V3_17 (c) dresden elektronik ingenieurtechnik gmbh
Path             | Vendor | Product | Serial     | Type
-----------------+--------+---------+------------+-------
/dev/ttyAMA0     | 0x0000 | 0x0000  |            | RaspBee 
/dev/ttyACM0     | 0x1CF1 | 0x0030  | DE1234567  | ConBee II

Die Lösung: In deconz.service einfach noch das USB-Device mitgeben: ExecStart=/usr/bin/deCONZ ... --dev=/dev/ttyACM0. ttyACM0 ersetzt man mit dem tatsächlichen Device (findet man mittels dmesg gleich nachdem man es eingestöpselt hat).

Danach den Service stoppen, neu starten — und dann sollte die ZigBee-Welt wieder in Ordnung sein (der Ausfall des USB-Sticks während zwölf Stunden machte es nötig, dass ich bei vielen Sensoren kurz den Knopf manuell drücken musste, um sicherzustellen, dass die Verbindung und Datenanlieferung noch funktioniert …)

Wichtig: dmesg muss den USB-Stick erkennen …

...
[55209365.334638] usb 2-3: new full-speed USB device number 15 using xhci_hcd
[55209365.488837] usb 2-3: New USB device found, idVendor=1cf1, idProduct=0030, bcdDevice= 1.00
[55209365.493029] usb 2-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[55209365.497062] usb 2-3: Product: ConBee II
[55209365.501528] usb 2-3: Manufacturer: dresden elektronik ingenieurtechnik GmbH
[55209365.505835] usb 2-3: SerialNumber: DE1234567
[55209365.512617] cdc_acm 2-3:1.0: ttyACM3: USB ACM device
...

… und mit lsusb muss er auch aufgeführt sein — sonst könnte ein anderes Problem vorliegen:

...
Bus 002 Device 013: ID 1cf1:0030 Dresden Elektronik ZigBee gateway [ConBee II]
...

In der Zwischenzeit hatte ich alles ausprobiert, insbesondere dutzende Male das Firmware geflashed. Hierzu habe ich die ZIP-Datei des neuesten (Beta) Release 4.0.4 von gcfflasher heruntergeladen und auf zwei Linux-PCs sowie macOS entpackt.

Um den Flasher zu kompilieren, installiert man unter Debian zuerst die benötigten Pakete (unter macOS geht’s gleich weiter zur Kompilation):

# apt-get install pkg-config build-essential libgpiod-dev

Danach kompiliert man das Binary:

./build_posix.sh

Anschliessend lädt man die neueste Firmware vom offiziellen Server in das Flasher-Verzeichnis herunter, und gibt dann unter Linux ein:

# ./GCFFlasher -d /dev/ttyACM3 -t 60 -f ./deCONZ_ConBeeII_0x26780700.bin.GCF

Unter macOS lautete der Befehl:

# ./GCFFlasher -d /dev/cu.usbmodemDE1234567 -t 60 -f ~/tmp/deCONZ_ConBeeII_0x26780700.bin.GCF

Auch hier wieder beachten, das effektive Device (unter Linux war es bei mir auf einem Laptop /dev/ttyACM0, auf dem anderen /dev/ttyACM3; unter macOS war es /dev/cu.usbmodemDE24421441) mitzugeben. Dass der Flasher richtig funktioniert, seht ihr, wenn folgende Ausgabe erscheint:

read file success: ./deCONZ_ConBeeII_0x26780700.bin.GCF (163244 bytes)
flash firmware
command reset done
query bootloader id V1
bootloader detected (60)
 100 %ding ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓
done, wait validation...
firmware successful written

Manchmal auch

read file success: ./deCONZ_ConBeeII_0x26780700.bin.GCF (163244 bytes)
flash firmware
command reset done
query bootloader id V1
bootloader detected (60)
bootloader syned: unlock! READY
 100 %ding ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓
done, wait validation...
firmware successful written

Den Diskussionsforen entnehme ich zudem, dass es vorkommen kann, dass das System den USB-Stick „vergisst“. In dem Fall startet man den Firmware-Update-Befehl bevor man den USB-Stick überhaupt eingestöpselt hat. Während sich die Meldungen à la retry connect bootloader /dev/cu.usbmodemDE1234567 auf dem Bildschirm stapeln, stöpselt man den USB-Stick ein, und dann sollte das Firmware-Update umgehend beginnen.

Links

Tags: , , , , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Montag, 19. Juni 2023

Apaches gehärtetes mod_rewrite strauchelt über Leerzeichen (%20)

Seit einem kürzlichen Update Apaches findet sich in den Apache Error Logs vieler Web-Applikationen folgende Fehlermeldung:

[Sat Jun 17 20:23:52.123046 2023] [rewrite:error] [pid 553164] [client 1.2.3.4:49928] AH10411: Rewritten query string contains control characters or spaces

Scripts funktionieren nicht mehr, und Browser zeigen Fehlermeldungen an, wenn man bestimmte URLs aufruft.

Des Rätsels Lösung: Ist mod_rewrite aktiviert, und enthält die umzuschreibende URL ein HTML-enkodiertes Leerzeichen (%20), erachtet das „gehärtete“ Apache dies als Sicherheitsrisiko und blockiert den Request.

Der Workaround: Das mod_rewrite-Flag [B] (Dokumentation) muss in die .htaccess gepfriemelt werden, wie in AH10411 error: Managing spaces and %20 in apache mod_rewrite empfohlen:

RewriteRule ^ajax/(.*) /ajax.php?q=$1 [B]

Als Person, die in der Informationssicherheit arbeitet, bin ich mir aber nicht ganz sicher, ob die Apache-Jungs diese „Sicherheitsverbesserung“ wirklich bis zum Ende durchdacht haben. Ich habe das Gefühl, dass man mit diesem Flag viele Installationen unsicherer macht …

Tags: , , , , , ,
Labels: IT, Linux

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 18. Juni 2023

Unter macOS GNU-Tools statt FreeBSD-Tools verwenden

macOS ist seit 2005 das Betriebssystem meiner Wahl.

Ich arbeite viel auch auf der Kommandozeile und schreibe hin und wieder Scripts, um Prozesse zu automatisieren. Dabei laufe ich immer wieder in das Problem hinein, dass macOS mit FreeBSD Kommandozeilen-Tools daherkommt, und viele Anleitungen im Internet GNU Tools referenzieren.

Oftmals verhalten sich diese Tools glücklicherweise identisch — aber eben nicht immer.

Da hilft es, wenn man MacPorts installiert hat: In vielen Fällen reicht es, dem eigentlichen Namen des Tools „g“ voranzustellen, um die von MacPorts installierte GNU-Version anstelle Apples FreeBSD-Version laufen zu lassen.

Soeben war das ganz nützlich, als ich einen Szene isch Züri Telegram-Kanal-Video-Extraktor programmiert habe:

  • gdate --date="7 days ago" +%Y-%m-%d
  • gtouch /tmp/2023-06-11 -d 2023-06-11

Tags: , , , ,
Labels: Apple, IT, Linux

Keine Kommentare | neuen Kommentar verfassen

Samstag, 17. Juni 2023

exFAT USB-Platten an einem Synology NAS

Das geht, aber erfordert DSM 7 sowie die Installation eines offiziellen, kostenlosen Pakets namens … exFAT Access:

Can I use exFAT external storage devices with my Synology NAS?

Eine unter macOS als exFAT formatierte USB-Festplatte wurde nach der Installation des Pakets umgehend erkannt und unter usbshare1 gemountet.

Tags: , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Mittwoch, 26. April 2023

Zyxel XMG3927-B50A auf dem WAN-Interface anpingbar machen

Gestern habe ich zu Testzwecken einen Zyxel XMG3927-B50A Test-Router gekriegt, weil sich meine Fritz!Box 7582 mehrmals im Tag neu startet, und das Problem immer schlimmer wird.

Leider hat Statuscake nach dem Anschluss des Test-Routers gemeldet, dass es die IP-Adresse meines g.fast-Anschlusses (Copper7 von Init7) nicht mehr anpingen kann.

Aus Sicherheitsgründen deaktivieren viele Consumer-Router, dass das WAN-Interface angepingt werden kann. Diese Funktion kann man problemlos reaktivieren — es ist ganz einfach, wenn man weiss, wo im Zyxel-GUI diese Funktion aktiviert werden muss (im Internet habe ich auf Anhieb und auch nach vielen Minuten Suchen nichts gefunden):

  1. Maintenance
  2. Remote Management
  3. Ping
  4. WAN
  5. ☑ Enable

Vielen Dank dem Init7-Support für den Tipp.

Tags: , , , , , , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Dienstag, 18. April 2023

EXIF-Informationen komplett von JPEGs entfernen

Photos enthalten heutzutage eine grosse Zahl an Metadaten, die bei JPEGs im EXIF-Header abgelegt sind. Das können GPS-Koordinaten sein, aber auch der exakte Zeitpunkt der Bildaufnahme, ob Blitz verwendet wurde, und mit welchen Parametern, Blendenöffnungszeiten und ISO-Einstellungen, sowie bei Spiegelreflexkameras auch die verwendete Linse und die gewählte Brennweite.

Wer Photos aus welchem Grund auch immer davon säubern möchte, verwendet am Besten das Tool jhead, und zwar folgendermassen:

$ jhead -purejpg IMG_7034.jpg

Quelle: Remove metadata from JPGs with jhead

ACHTUNG: Die Datei wird überschrieben. Wer die Originaldatei weiterhin benötigt, sollte zuerst eine Kopie anfertigen. Bei iPhone-Photos habe ich auch schon die Erfahrung gemacht, dass die Orientation des Photos in den EXIF-Daten enthalten ist — werden die EXIF-Daten entfernt, kann es sein, dass das Photo plötzlich auf dem Kopf steht. Damit muss man leben können.

Tags: , , , , , , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Montag, 3. April 2023

OAuth gegen Google Kalender hat sich geändert

Ich habe mir auf einem Linux-Server verschiedene Cron-Jobs eingerichtet, welche Python-Scripts gegen Google Kalender ausführen.

Das eine Script sendet mir und meiner Frau Hinweise per Email, wenn sich in der letzten Stunde bis 30 Tage in der Zukunft liegende Kalendereinträge geändert haben. Ein anderes Script schaltet Kalendereinträge, die ich aus dem SBB-Fahrplan eingetragen habe, auf die Standardsichtbarkeit (anstelle „Privat“).

Letzte Woche funktionierten beide Scripts nicht mehr. Ursache: Google hat die OAuth-Authentifizierung angepasst, und sicherer gemacht (Migrationsanleitung). Das von mir aus dem Internet zusammenkopierte, in Trial & Error zum Funktionieren gebrachte Login-Verfahren funktioniert nicht mehr:

Nach ein wenig Herumpröbeln schaut so die Lösung aus:

...
from googleapiclient.discovery import build
from httplib2 import Http
from oauth2client import file, client, tools

# Added 2023-03
from google.auth.transport.requests import Request
from google.oauth2.credentials import Credentials
from google_auth_oauthlib.flow import InstalledAppFlow
...
googleCredentialsFile = scriptdir + '/token-readonly.json'
SCOPES = ['https://www.googleapis.com/auth/calendar.readonly']
...
creds = None
if os.path.exists(googleCredentialsFile):
    creds = Credentials.from_authorized_user_file(googleCredentialsFile, SCOPES)
if not creds or not creds.valid:
    if creds and creds.expired and creds.refresh_token:
        creds.refresh(Request())
    else:
        flow = InstalledAppFlow.from_client_secrets_file("credentials.json", SCOPES)
        creds = flow.run_local_server(port=0)
    with open(googleCredentialsFile, "w") as token:
        token.write(creds.to_json())

service = build('calendar', 'v3', credentials=creds)
...

Nebenbemerkung: Beim Debuggen der (nun nicht mehr funktionierenden) Original-Routine stolperte ich auch noch über folgendes Problem: Why is oauth2client run_flow giving an Argparse error?

Tags: , , , , , , , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 26. März 2023

Die Log-Syntax zu geöffneten root sessions in auth.log hat sich geändert

Ich verwende monit extensiv, um viele Aspekte meines Linux-Server Fuhrparks zu überwachen.

Ein detektivischer „Sicherheitscheck“, den ich mit monit abdecke, sind Alarme zu frisch geöffneten root Sessions (der Informationssicherheits-Mensch in mir erhofft sich damit, irgendeines Tages so einen Angreifer zu entdecken):

check file su_root with path /var/log/auth.log
  if match "session opened for user root by" then alert

Ich kriege jedes Mal ein Email, wenn jemand eine root-Session eröffnet. Denn in auth.log findet sich dann jeweils folgender Eintrag:

Mar 26 13:33:16 localhost sudo: pam_unix(sudo:session): session opened for user root by pi(uid=0)

Seit einiger Zeit sind diese Emails für einige meiner Debian-Server verstummt (konkret: die x86er, während die Raspberry Pis fröhlich vor sich hermelden).

Heute machte ich mich daran, das Problem zu erforschen und zu lösen.

Erkenntnis: Die Syntax hat sich leicht geändert:

Mar 26 13:33:05 SERVER su: pam_unix(su-l:session): session opened for user root(uid=0) by mario(uid=0)

Deshalb habe ich die monit-Konfiguration angepasst:

check file su_root with path /var/log/auth.log
  if match "session opened for user root" then alert

Jetzt kommen die Alarme wieder …

Tags: , , , , , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Donnerstag, 2. Februar 2023

UAP-AC-PRO weigert sich, die Firmware zu aktualisieren

Komisches Problem am ersten des Monats: Wie üblich aktualisiere ich die Firmware meiner UniFi-Komponenten, welche ich an drei Standorten installiert habe. Einzig der UAP-AC-PRO weigert sich standhaft, das verfügbare Update einzuspielen: Im UniFi-Controller drücke ich auf Update, der Status wechselt zu Updating… — nur um ca. 30 Sekunden später auf Update zurückzufallen. Gefühlte zehn Mal klicke ich den Link, doch es tut sich nichts. Endlosschlaufe, Ground Hog Day!

Nun gut. Ich sage dem Access Point in derselben Oberfläche, dass er sich neu starten sollen. Nachdem die Pings auch zwei Minuten nach dem Neustart ins Leere laufen, beginne ich mir, sorgen zu machen. Schlussendlich sind es fünf Minuten, und das Gerät ist immer noch nicht hochgekommen. Irgendwas ist hier faul!

Ich überlege mir schon, den Bekannten am anderen Standort anzurufen und zu bitten, das Netzwerkkabel vom PoE-Switch zum Access Point kurz auszuziehen. Doch das kann ich ja auch machen — virtuell, aus der Ferne. Ich gehe in die Port Management-Oberfläche des Switches, und klicke auf Power Cycle PoE. Der Port wird grau, und dann wieder grün, und das Stromsymbol (der Blitz) erscheint wieder.

Nach ein paar dutzend Sekunden werden die Pings endlich beantwortet, und der Access Point ist in der Oberfläche nicht mehr ausgegraut. Ein letztes Mal klicke ich auf Update — und tatsächlich: Nach dem Neustart lässt sich das Firmware-Update problemlos durchführen. Das letzte UniFi-Gerät in meinem Fuhrpark wurde nun doch noch aktualisiert.

Tags: , , , , , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Montag, 30. Januar 2023

Bilder-Rückwärtssuche

Die „umgekehrte Bildsuche“ oder „Rückwärtssuche“ (engl. „reverse image search“) kann sehr nützlich sein, wenn man beispielsweise ein Photo an Hand einer Sehenswürdigkeit im Hintergrund lokalisieren möchte.

Nichts einfacher als das: Google bietet die Funktion an, Bilder hochzuladen und mit seiner Datenbank aller Bilder zu vergleichen. Irgendwo habe ich einmal gelesen, dass Yandex (ein russisches Produkt, Cancel in 3, 2, 1!) besser darin sei.

Auf Twitter wurde ich in einem Tweet zu Raketenangriffen in Israel nun auf ein drittes Produkt aufmerksam gemacht: TinEye Reverse Image Search.

Gerne teste ich das bei der nächsten Gelegenheit aus.

Tags: , , , , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen