Archiv ‘IT’

Sonntag, 27. August 2023

UniFi Switch PoE-Probleme — und meine Lösung

Unser Haushalt ist komplett mit Ubiquiti UniFi Netzwerk-Hardware ausgerüstet.

Unter anderem hängt im Verteilschrank beim g.fast-Modem ein UniFi US-8-60W. Die Ports dieses Switches sind auf 5 Ports einer UniversMCS Hausverkabelung gepatcht, plus Modem, plus Powerline in den Keller und die Waschküche.

Unter anderem führt ein UniversMCS-Multimediakabel in das Wohnzimmer. Dort geht es von einer Bodenklappe mittels eines braunen Ethernet-Kabels (ähnliche Farbe wie das Parket) zu einem UniFi US-8 (ohne eigenes PoE). Dieses Kabel liefert mittels PoE Strom für den Satelliten-Switch. An diesem Switch hängt unter anderem der Apple TV und der Sony Bravia-Fernseher, sowie ein UniFi FlexHD Access Point. Den UniFi FlexHD versorge ich ebenfalls mittels PoE mit Strom, d.h. der Access Point ist am PoE-Passthrough-Port (Nummer 8) angesteckt und wird indirekt vom Verteilkasten mit Strom versorgt.

Problem: Jedes Mal, wenn ich die Firmware des Switches im Verteilkastens aktualisiere und sich dieser neu startet, ist der Satelliten-Switch offline. Nach viel, viel Rätseln, aus- und umstöpseln (zuerst dort, dann hier, dann hier, dann dort) hier die Symptombekämpfung meines Problems:

Sobald der Satellitenswitch tot ist, begebe ich mich in das Wohnzimmer, und ziehe ALLE Ethernet-Kabel aus. Anschliessend stecke ich zuerst das braune PoE-Kabel ein — und nur dieses. Dann warte ich, bis die weisse LED des Switches zu leuchten beginnt. Erst dann stecke ich die zwei anderen Netzwerkgeräte sowie den Access Point ein. Nach ein paar Minuten ist der Switch online, und der Access Point auch wieder.

An was das liegt weiss ich nicht genau, vermute aber, dass der Switch irgendwie nicht damit klarkommt, wenn der Switch und FlexHD gleichzeitig PoE-Strom ziehen.

Das Problem besteht seit unserem Bezug der Wohnung im Oktober 2021, und unzählige Firmware-Updates haben es nicht gelöst. Beim heutigen Firmware-Upgrade aller Komponenten schien das Problem vorerst nicht aufgetreten zu sein (der Wohnzimmer-Switch ging um 21:23 Uhr offline, um 21:25 Uhr war er wieder da) — doch um 00:35:30 Uhr ging der Switch plötzlich offline.

Nachtrag: Ein Kollege gab mir den entscheidenden Tipp: Kann es sein, dass der Switch nicht mehr hochkommt, weil zu viel Strom gezogen wird? Volltreffer.

Der UniFi Controller verfügt über ein Log, und was fand ich dort?

The device plugged into Verteiler (UniFi US-8-60W) Port 8 requires more power than the port can provide. Please connect it to a port capable of the required PoE output.
Learn more.

Meine Recherchen über die PoE-Fähigkeiten meiner Hardware haben ergeben:

  • Wie es die Typenbezeichnung des US-8-60W bereits sagt, kann der Switch über PoE total 60W bereitstellen.

  • Diese 60W können über 4 der 8 Ports geteilt werden (Ports 5, 6, 7 und 8).
  • Ein einzelner Port aber kann maximal 15.4W bereitstellen.
  • Das bedeutet, dass mein US-8 zusammen mit dem UniFi FlexHD im Wohnzimmer maximal 15.4W ziehen dürfen. Wenn sie mehr ziehen, schaltet sich der Port wohl ab, oder der Verbraucher (Access Point) kriegt kein Strom mehr.
  • Der US-8 benötigt maximal 12W für das Switching. In Realität sind es aber unter 5W, obwohl ich vermutlich auch noch messen sollte, wenn man über Apple TV HD-Content streamt.
  • 12W ist auch die maximale Leistung, die über den PoE-Passthrough ausgeben werden kann
  • Kann der Switch somit maximal 24W ziehen? Das würde mit dem Netzteil passen, welches 48V mit 0.5A bereistellt (24W).
  • Die aktuelle Leistung, die über den PoE-Port gezogen wird, lässt sich im UniFi-Controller für den US-8-60W und auch für den US-8 ansehen: Aktuell gerade 10.38W, mit dem von mir höchsten je gesehenen Wert von 11.49W.
  • Somit ist der US-8-60W nicht wirklich das Problem — er könnte 15.4W bereitstellen, doch der US-8 kann nur maximal 12W weiterleiten.

Ich überlege mir deshalb zwei Möglichkeiten:

  1. Den US-8-60W durch einen US-8-150W zu ersetzen, welcher hier noch herumliegt. Der deutlich grössere Switch erlaubt bis zu 34.2W pro Port (Quelle, im Tab Specifications). Ob das das Problem wirklich lösen wird, weiss ich nicht.
  2. Einen anderen PoE-Passthrough-Switch kaufen, welcher über den Passthrough-Port mehr als 12W bereitstellen kann.

Tags: , , , , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Freitag, 7. Juli 2023

Kompatibler SSD-Speicher für OWC miniStack STX

Mit einer meiner alten, 1TB grossen Apple Time Capsules habe ich dann und wann Probleme. Das letzte Mal im Februar 2023, weshalb ich mich damals nach etwas Pröbeln entschied, die Festplatte mit dem AirPort Utility komplett zu formatieren und die Time Capsule dann frisch in die Time Machine meines Mac mini M1s einzubinden.

Nun, vier Monate später, konnten wieder keine Backups mehr auf das Ziel gemacht werden.

Anstelle dem Problem weiter nachzugehen, habe ich mich entschieden, von einer netzwerkbasierten (Ethernet) Lösung auf eine USB-C/Thunderbolt-basierende Lösung umzusteigen und die Time Capsule in den Ruhestand zu versetzen.

Nach etwas Recherche fand ich auf Galaxus eine gebrauchte OWC miniStack STX und bestellte sie kurzerhand. Das Gehäuse schliesst man über ein USB-C/Thunderbolt 4-Kabel an einen USB-C/Thunderbolt 4-Port des Mac minis an. Neben einer internen SATA-Schnittstelle für 2.5 und 3.5 Zoll Festplatten (SSD oder HDD) verfügt das Gehäuse auch über eine NVMe M.2 2280 Schnittstelle.

Nachdem ich eine gebrauchte Seagate Barracuda 6TB (ST6000DM003), ehemals in einem NAS in Verwendung, verbaut hatte (das Gehäuse wird dabei leider laut, wenn die Festplatte anläuft und der Lüfter läuft), machte ich mich auf die Suche nach einer passenden NVMe M.2 2280 SSD, welche parallel zu einer SATA SSD/HDD im Gehäuse betrieben werden kann.

Ich entschied mich für eine Western Digital 2TB SSD (WDS200T2B0B). Zwei Tage später war sie in der Post und ich verbaute sie kurz nach Ankunft in das Gehäuse. Dies ging zügig und reibungslos über die Bühne. Nachdem ich das Gehäuse wieder am Strom angeschlossen hatte, leuchteten auch brav die beiden Festplatten-LEDs A und B (B ist die NVMe).

Doch macOS wollte die zusätzliche Platte partout nicht anzeigen — normalerweise wird man unverzüglich gefragt, ob man die neu entdeckte Festplatte initialisieren möchte. Im Apple Disk Utility tauchte sie nicht auf, und auch nicht im System Report.

Ich kümmerte mich nicht lange um ein gründliches Debugging und schrieb zeitnah dem OWC-Support unter support@owc.com. Die Antwort liess nicht lange auf sich warten — innert fünf Stunden erhielt ich eine Rückmeldung, welche von einem Menschen verfasst worden zu sein schien, und haargenau auf das von mir geschilderte Problem einging (keine Standard-Texte):

Hello Mario,

[…] Upon checking the specifications, it appears that the Western Digital drive is not be compatible with the OWC STX. Although it is an M.2 2280 type SSD, this is a SATA type SSD and not an NVMe which the STX‘ requires to have.

Also, below is the link to which you can see the compatible devices with the OWC miniStack STX:

eshop.macsales.com/item/OWC/T4MS9000

[…]

Peinlich! Aber ich bin mir sicher, dass ich nicht der erste Kunde war, der im Eifer des Gefechts die falsche M.2 SSD bestellt hatte.

Glücklicherweise akzeptierte Galaxus die Retournierung die Ware, während ich gleichzeitig eine zweite SSD bestellte: Dieses Mal war es eine Kingston NV2 2000 GB, M.2 2280.

Nach der Lieferung umgehend eingebaut, poppte unter macOS sofort die Frage auf, ob ich die neue Festplatte initialisieren möchte. Das tat ich, und zwar mit dem APFS mit einer GUID Partitionstabelle (offenbar sei das die beste Wahl für Time Machine-Backups).

Seit gestern sichert macOS den gesamten Inhalt der internen Festplatte nun abwechselnd auf die andere 1TB Apple Time Capsule (extrem langsam), auf die Seagate HDD sowie auch auf die Kingston SSD.

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

Keine Kommentare | neuen Kommentar verfassen

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